Discussion:
[fossil-users] svn to fossil-scm migration
Scott Robison
2011-03-15 20:00:45 UTC
Permalink
So, I have a subversion repository that I've been using for about 18
months for personal stuff I work on at home and a parallel trac
installation. It has served me well, but I figured I should try out a
dvcs since the world is moving that way. Having been a fan of SQLite
for years I discovered fossil and liked what I read (integrated bug
tracking & wiki) and wanted to give it a shot.

I downloaded a fossil binary for Windows, created an empty repository,
played around with it for a bit, liked it well enough to take the next
step of importing my subversion repository and see how that worked.

After searching for a while, I found a way to import my svn repository
into fossil. svnadmin dump followed by svn-dump-fast-import followed
by fossil import --git. It 'worked' in that I had a fossil repository
after all was said in done. I ran fossil ui, looked at the timeline of
20 most recent items, so far so good. Next I clicked on 200 entries
and got an APPCRASH from Windows 7. "fossil.exe has stopped working"
with the typical check/close/debug options.

I fear that my problem is probably likely due to the very different
models between svn & fossil (or maybe a less than perfect conversion
utility). My svn repo resembles:

\repo
\trunk
\projects
\vendor
\third-party-libraries
\vendor
\third-party-libraryies
\tag-1
\tag-2
\tag-3
\current

Is there a better way to do what I'm trying to do, or should I give up
on the 'ideal' of keeping my subversion history in the new fossil
repository? Also: is it practical to try to maintain multiple projects
in a single repository as I'm trying to do, or should I give that up
and go for a single repo per project?

Thanks for any suggestions & guidance. I really want to like fossil
but am having 'growing pains' or 'migration pains'.

SDR
Richard Hipp
2011-03-15 20:51:27 UTC
Permalink
Post by Scott Robison
Next I clicked on 200 entries
and got an APPCRASH from Windows 7. "fossil.exe has stopped working"
with the typical check/close/debug options.
I fear that my problem is probably likely due to the very different
models between svn & fossil
It should never crash, regardless of any model differences.

What version of Fossil are you running? (What does "fossil version" say?)

Can you send me your repo by private email so that I can try it here and
debug the problem?
--
D. Richard Hipp
***@sqlite.org
Scott Robison
2011-03-15 21:14:33 UTC
Permalink
Post by Richard Hipp
It should never crash, regardless of any model differences.
What version of Fossil are you running?  (What does "fossil version" say?)
Can you send me your repo by private email so that I can try it here and
debug the problem?
One, fossil version reports "This is fossil version [1d93222627]
2011-03-01 19:04:32 UTC", downloaded from the fossil-scm.org site at
"2011-03-12 09:23:15 UTC".

Two, I would be happy to send the repository to you by private email.
Well, more like a link to a file in a private email, since the fossil
repo is about 425 MB (not MiB). If you are still interested in seeing
a copy of the repo, let me know and I'll forward the required
information.

SDR
Richard Hipp
2011-03-16 01:54:23 UTC
Permalink
Post by Scott Robison
Post by Richard Hipp
It should never crash, regardless of any model differences.
What version of Fossil are you running? (What does "fossil version"
say?)
Post by Richard Hipp
Can you send me your repo by private email so that I can try it here and
debug the problem?
One, fossil version reports "This is fossil version [1d93222627]
2011-03-01 19:04:32 UTC", downloaded from the fossil-scm.org site at
"2011-03-12 09:23:15 UTC".
Two, I would be happy to send the repository to you by private email.
Well, more like a link to a file in a private email, since the fossil
repo is about 425 MB (not MiB). If you are still interested in seeing
a copy of the repo, let me know and I'll forward the required
information.
Thanks again for the repo. The segfault problem is fixed in the latest
check-in:

http://www.fossil-scm.org/fossil/info/cbafc702a9
Post by Scott Robison
SDR
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Richard Hipp
2011-03-16 00:39:11 UTC
Permalink
Post by Scott Robison
I fear that my problem is probably likely due to the very different
models between svn & fossil (or maybe a less than perfect conversion
\repo
\trunk
\projects
\vendor
\third-party-libraries
\vendor
\third-party-libraryies
\tag-1
\tag-2
\tag-3
\current
Is there a better way to do what I'm trying to do, or should I give up
on the 'ideal' of keeping my subversion history in the new fossil
repository? Also: is it practical to try to maintain multiple projects
in a single repository as I'm trying to do, or should I give that up
and go for a single repo per project?
Thanks for sending your repo! It is quite interesting. The tip of trunk
contains 446,786 different files in 37,217 directories, including:

* Complete sources to 5 different versions of Python
* Complete sources to 15 different versions of SQLite
* Complete sources to 8 different versions of Boost
* Complete sources to 4 different versions of Tcl and of Tk
* Complete sources and data files to 8 different versions of ICU
* Plus multiple versions of 11 other vendor libraries...

A complete checkout is 5.7GB.

Fossil should not segfault, and I will fix that problem. But in the
meantime, I have these recommendations:

(1) Keep vendor libraries in separate repositories - one repo per library.

(2) If you really need to keep vendor libraries in your own repository, use
the versioning system to store different versions of the vendor libraries as
different check-ins. Do not create separate subdirectories storing
different versions of the same library all within the same check-in. It's a
versioning system, not a filesystem.
Post by Scott Robison
Thanks for any suggestions & guidance. I really want to like fossil
but am having 'growing pains' or 'migration pains'.
SDR
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Scott Robison
2011-03-16 02:03:23 UTC
Permalink
When I said "very different models" I meant "different models of usage
between a centralized vs distributed vcs". And I was right! :)

In any case, glad the repo was useful to you to in improving fossil.
Rather than trying to dump my entire centralized repo into a single
distributed repo, I'll have to try breaking it into separate projects.
Still trying to get my head around the dvcs model.

I've heard people going on and on about how great dvcs systems are,
but I just haven't been able to see it from their perspective. The
selling point to me about fossil is the integration of bug tracking &
wiki & all those other goodies that I currently have to maintain
separately. Svn & Trac are a nice cooperative pair, but I really like
the idea of a single exe along with a single repository file.

I'd better stop rambling. Thanks again for your immediate attention to
the report and the fix.

Take care.

SDR
Post by Scott Robison
I fear that my problem is probably likely due to the very different
models between svn & fossil (or maybe a less than perfect conversion
\repo
 \trunk
   \projects
   \vendor
     \third-party-libraries
 \vendor
   \third-party-libraryies
     \tag-1
     \tag-2
     \tag-3
     \current
Is there a better way to do what I'm trying to do, or should I give up
on the 'ideal' of keeping my subversion history in the new fossil
repository? Also: is it practical to try to maintain multiple projects
in a single repository as I'm trying to do, or should I give that up
and go for a single repo per project?
Thanks for sending your repo!  It is quite interesting.  The tip of trunk
* Complete sources to 5 different versions of Python
* Complete sources to 15 different versions of SQLite
* Complete sources to 8 different versions of Boost
* Complete sources to 4 different versions of Tcl and of Tk
* Complete sources and data files to 8 different versions of ICU
* Plus multiple versions of 11 other vendor libraries...
A complete checkout is 5.7GB.
Fossil should not segfault, and I will fix that problem.  But in the
(1) Keep vendor libraries in separate repositories - one repo per library.
(2) If you really need to keep vendor libraries in your own repository, use
the versioning system to store different versions of the vendor libraries as
different check-ins.  Do not create separate subdirectories storing
different versions of the same library all within the same check-in.  It's a
versioning system, not a filesystem.
Post by Scott Robison
Thanks for any suggestions & guidance. I really want to like fossil
but am having 'growing pains' or 'migration pains'.
SDR
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Loading...