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 On Tue, Mar 15, 2011 at 6:39 PM, Richard Hipp <d...@sqlite.org> wrote: > On Tue, Mar 15, 2011 at 4:00 PM, Scott Robison <sc...@scottrobison.us> > wrote: >> >> 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 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. > > >> >> Thanks for any suggestions & guidance. I really want to like fossil >> but am having 'growing pains' or 'migration pains'. >> >> SDR >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
