Re: Subversion/CVS experiment summary
# [EMAIL PROTECTED] / 2004-02-12 16:48:25 -0400: On Mon, 9 Feb 2004, Michael Reifenberger wrote: Hi, first, this seems to be a good analysis of SVN and a good starting point for thinking about moving away from CVS. I missed the original thread here, so this point may have already been made ... but ... we tried to use subversion for a project recently, and made a *big* mistake of upgrading to a newer version from what we started with ... and could no longer access the repository ... apparently there is a 'dump / reload' procedure that we weren't aware of at the time, but this is something that should be watched for ... dump/reload cycles required by a new version from time to time are announced prominently. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Thu, Feb 12, 2004 at 04:48:25PM -0400, Marc G. Fournier wrote: note that this was pre-0.34, but since its still under development, there is always the chance that this happens again ... a load of the system took 49hrs, I believe was mentioned ... how long to dump/reload the system once its already in subvsersion format? dump/load is quite fast, but dump format includes the full content of each revision - piping to gzip befor storing is advised for big trees. dump format can easily used to distribute the tree by taking hourly snaps, but not for distribution of checkouts as CVSup can do. Unfortunatley general speed is still an issue. Try to commit a very large diff and you wait forever if you are not going out of memory bevor. There are also obscure workdir problems from time to time which could easily confuse the wide user base. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Mon, 9 Feb 2004, Michael Reifenberger wrote: Hi, first, this seems to be a good analysis of SVN and a good starting point for thinking about moving away from CVS. I missed the original thread here, so this point may have already been made ... but ... we tried to use subversion for a project recently, and made a *big* mistake of upgrading to a newer version from what we started with ... and could no longer access the repository ... apparently there is a 'dump / reload' procedure that we weren't aware of at the time, but this is something that should be watched for ... From the INSTALL file: Version 0.34.0 (released 3 December 2003, from revision r7859) http://svn.collab.net/repos/svn/tags/0.34.0 # ## WARNING WARNING WARNING WARNING WARNING WARNING WARNING ## # ## ## ## This release makes an incompatible change to the Subversion ## ## database.Repositories created with versions of Subversion ## ## prior to 0.34 will not work with Subversion 0.34. ## ## To upgrade, first use 'svnadmin dump' with your existing ## ## Subversion binaries. Then upgrade your binaries to 0.34, and ## ## use 'svnadmin load' to create a new repository from your ## ## dumpfile. ## ## Don't forget to copy any custom configuration/hooks from the ## ## old to the new repository. ## ## ## # note that this was pre-0.34, but since its still under development, there is always the chance that this happens again ... a load of the system took 49hrs, I believe was mentioned ... how long to dump/reload the system once its already in subvsersion format? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
Hi, first, this seems to be a good analysis of SVN and a good starting point for thinking about moving away from CVS. On Mon, 9 Feb 2004, Craig Boston wrote: ... Comments on importing: It's SLOOW. It took 43.9 hours just for src/sys, and this is a relatively speedy system! It starts out at a pretty good pace, but the more commits it processes, the slower each one seems to take. ... Since this should be a one-time action, time should be less of a showstopper (as long its not endless :-) ... * Requires Apache for the network server. There is a simpler CVS-like network protocol, but it suffers from the same problems with access control and locking and the like that CVS does. In order to overcome those limitations, you pretty much have to use Apache/WebDAV. Some may argue that this isn't really a negative, but it certainly doesn't go with the K.I.S.S. philosophy. ... Apache is not strictly required. As far I've seen there is a svnserve server mode available. ... * No cvsup equivalent yet. You can fairly easily use WebDAV to pull a copy of the trunk or a particular branch, but it's not nearly as efficient as the rsync algorithm. There's also no way to use WebDAV to grab a certain date or revision like you can with cvsup -- you have to have the svn client installed. In order to be even a contender to replace CVS, it still needs a *FAST* and *SIMPLE* way to synchronize source with an arbitrary tag or revision. ... For me this is the biggest showstopper for FreeBSD development. But since the whole repository is versioned instead of individual files, in an first step an CTM-equivalent should be easier ( posting something like `svnadmin dump --revision old:new` ...) or are there any native db4-tools for replication available?) Additionaly a bad point is: * SVN hasn't that many (fully integrated) clients than CVS (eclipse, ...) Many are coming/growing but its still not there. ... Good points: * Atomic commits across multiple files * Versions belong to the whole repository. That means that in case of changes you only need the revision number to know what changed in the whole repository. In the FreeBSD environment it's necessary to know the exact time or the affected files (and their individual revision numbers) * It's extremly well documented! It comes with an whole book of documentation. - Section the 4th - Conclusions - Honestly, I don't think Subversion is quite ready yet. However, it is getting _very_ close to being a viable alternative to CVS, for the needs of the FreeBSD project as far as I know them. I'll definitely be trying it out for some of my local projects that are currently stored in CVS. Maybe we could see SVN as an equivalent to p4. Probably most of SVN current shortcomings are also true for p4 (no cvsup for p4 available, only an p4p service for some selected archs) Because SVN tries to be an CVS successor I found its usage very intuitive for an first-time-user like me. Furthermore I personaly don't like closed-source tools for open-source development (when alternatives are available) and would try to avoid p4 if possible. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Subversion/CVS experiment summary
This is a bit of a long email, so please skip unless you're into source code revision management :) This is an informal report on the viability of using Subversion to manage the FreeBSD source code repository. Some of this is generic and will be familiar to anyone who has looked at SVN before, some is more FreeBSD-specific. NOTE: I'm not trying to push one SCM over the other or suggest that CVS is wholly inadequate. This is merely the result of an evaluation for my personal use, and I thought I'd post it in case anyone was interested. CVS has been used by the FreeBSD project for a LONG time for good reasons. Despite its shortcomings, I suspect that it will be in use for quite a while longer. - Section the 1st - Motive - My main motivation for these tests was to bring my local modifications to FreeBSD into some semblance of order. It seems I've amassed a bit of a collection of local patches, 3rd party patches, and side projects -- some of which are mutually exclusive or apply to different branches. Simply keeping a working copy with my changes in it works fine for one project but becomes painful when there are several. I'd also like to be able to keep version history for my modifications. I've heard good things about Perforce, and its effortless merge functionality looks really slick. If I'm ever involved with a major commercial coding project, I'll definitely give it some consideration. For my free-time projects however it's not really an option. A couple of my local mods are in a bit of a grey area as far as the 'non-commercial' license goes, so I'd rather avoid that whole issue. - Section the 2nd - Setup and conversion - Most of my tests were performed on the src/sys portion of the repository. It seemed to be large enough that I could get a general idea of how well Subversion scales, but small enough that I wouldn't spend all week waiting for the import to complete. All tests were done on a Pentium 4 2.8 GHz system with 512MB RAM. I used a local repository on one disk and the working directories on another (for both CVS and SVN). These tests have been done over the course of the last week and a half, using subversion-0.35.1_1. I've heard of attempts to convert the repo for testing using the cvs2svn.py failing (for more details, see the thread at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=640133+0+archive/2004/freebsd-hackers/20040111.freebsd-hackers). These problems seem to be fixed in the most recent version of the script -- I have been able to successfully import sys, bin, sbin, and lib so far. The next target for testing is contrib as it seems to be the most likely candidate for problems with all those vendor branches. Comments on importing: It's SLOOW. It took 43.9 hours just for src/sys, and this is a relatively speedy system! It starts out at a pretty good pace, but the more commits it processes, the slower each one seems to take. For my purposes I would also need some method of incrementally updating the repository with any new commits made to CVS. This doesn't exist yet, but I'm thinking about trying to hack cvs2svn to do this. Kind of an inverse vendor branch I guess. - Section the 3rd - Head to Head - Yeah, I know comparing Subversion and CVS isn't a fair test -- SVN is designed to be much more than CVS. But it's a comparison that will be inevitably made, so might as well get it out of the way. Bad points (for SVN): * Repo size: The src/sys part of the tree alone is 1.2GB. The same portion of the repo in CVS is only 313MB. I had to keep a script running to routeinly purge unused database logs to avoid running out of disk space during the import. * Working set size: SVN keeps a complete copy of every file that is checked out in a hidden directory analogous to CVS directories. This does have some advantages outlined below, but effectively doubles the size of your working directory. * Speed: 0.35 is considerably slower than CVS for some operations. svn checkout is on average about 6 times slower than cvs checkout. Interestingly, CVS seems to benefit from the buffer cache much more than SVN does -- nearly a 50% decrease in execution time for CVS once the cache was populated. Please note however that checking the same thing out over and over isn't a very useful thing to do, and SVN fares better with the more common operations. * Not as thouroughly tested with large repositories. One advantage CVS has is that it
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 11:30:05AM -0600, Craig Boston wrote: This is an informal report on the viability of using Subversion to manage the FreeBSD source code repository. Some of this is generic and will be familiar to anyone who has looked at SVN before, some is more FreeBSD-specific. Wow, you have done the experiment I thought to do one of these days! Cool! - Section the 1st - Motive - My main motivation for these tests was to bring my local modifications to FreeBSD into some semblance of order. It seems I've amassed a bit of a collection of local patches, 3rd party patches, and side projects -- some of which are mutually exclusive or apply to different branches. Simply keeping a working copy with my changes in it works fine for one project but becomes painful when there are several. I'd also like to be able to keep version history for my modifications. That is my primary motivation as well -- sort of a private branch for mods / testing things. - Section the 2nd - Setup and conversion - I've heard of attempts to convert the repo for testing using the cvs2svn.py failing (for more details, see the thread at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=640133+0+archive/2004/freebsd-hackers/20040111.freebsd-hackers). These problems seem to be fixed in the most recent version of the script -- I have been able to successfully import sys, bin, sbin, and lib so far. The next target for testing is contrib as it seems to be the most likely candidate for problems with all those vendor branches. Did you have to modify the script, or pass unusual options? I'd like to reproduce this, but I didn't get very far when I tried a few days ago with the 0.37.0 version of the tool. I also tried refinecvs (formerly cvs2svn.pl), found at http://lev.serebryakov.spb.ru/refinecvs/ but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... Comments on importing: It's SLOOW. It took 43.9 hours just for src/sys, and this is a relatively speedy system! It starts out at a pretty good pace, but the more commits it processes, the slower each one seems to take. That doesn't bode well. Is committing in the new SVN repository also slow? For my purposes I would also need some method of incrementally updating the repository with any new commits made to CVS. This doesn't exist yet, but I'm thinking about trying to hack cvs2svn to do this. Kind of an inverse vendor branch I guess. My thoughts were now going to do something like Tom Lord proposed for an Arch gateway -- just import a CVS working copy into SVN at a certain cut-off date, and setup a bi-directional gateway between the two. That way people can use either tool. The hard problem to solve is indeed getting the changeset from CVS (at least it is when you're not running when a commit is made, as is the case in my setup where I simply cvsup the repository and thus get lots of commits at once). But if the whole repository can be converted it's probably the way to go. - Section the 3rd - Head to Head - Great summary of the pros/cons of either system. * Requires Apache for the network server. There is a simpler CVS-like network protocol, but it suffers from the same problems with access control and locking and the like that CVS does. In order to overcome those limitations, you pretty much have to use Apache/WebDAV. Some may argue that this isn't really a negative, but it certainly doesn't go with the K.I.S.S. philosophy. Actually, would a sort of access control wrapper that is now also used with the FreeBSD CVS repository not work? I do agree that it would be nice to have per-directory access control with the svnserve method. * No cvsup equivalent yet. You can fairly easily use WebDAV to pull a copy of the trunk or a particular branch, but it's not nearly as efficient as the rsync algorithm. There's also no way to use WebDAV to grab a certain date or revision like you can with cvsup -- you have to have the svn client installed. In order to be even a contender to replace CVS, it still needs a *FAST* and *SIMPLE* way to synchronize source with an arbitrary tag or revision. Agreed. * Still no solution for the repeated merge problem. This is supposed to be addressed post-1.0; no official timeframe
Re: Subversion/CVS experiment summary
Stijn Hoop [EMAIL PROTECTED] writes: I also tried refinecvs (formerly cvs2svn.pl), found at http://lev.serebryakov.spb.ru/refinecvs/ but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... Unfortunately there's no good way to avoid this. CVS discards a lot of information about each commit, and in order to reconstruct that information you have to view the repo as a whole. That's not really a problem though, since this is a one-time operation. If / when we decide to switch to SVN, we can easily find a machine with enough RAM to do the job. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 07:49:55PM +0100, Dag-Erling Sm?rgrav wrote: Stijn Hoop [EMAIL PROTECTED] writes: I also tried refinecvs (formerly cvs2svn.pl), found at http://lev.serebryakov.spb.ru/refinecvs/ but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... Unfortunately there's no good way to avoid this. CVS discards a lot of information about each commit, and in order to reconstruct that information you have to view the repo as a whole. That's not really a problem though, since this is a one-time operation. If / when we decide to switch to SVN, we can easily find a machine with enough RAM to do the job. Very true, but... First of all it would make these kind of tests easier if the script implemented it's own sort of cache function. Then I could try and see the feasibility of converting to Subversion by myself, just like the OP has done. I tried reading the source to see if this is easily implemented, but it's still way beyond my meagre perl skills. Second, even after you get the initial conversion done, I think there is a need for resyncing the SVN repository with the CVS repository -- with a state dump from refinecvs this would be relatively easy (only examine the deltas since last time), but this sort of behaviour is impossible with the current script. It would also be useful to implement a bi-directional gateway between SVN and CVS repositories, analogous to the idea someone from the arch project had. See point 3 at http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree (and of course substitute Subversion for arch). That said, as with my comments on Subversion, I was actually pleasantly surprised with my findings about all the tools involved, and the above is certainly only meant as constructive criticism. I think Lev is actually using the FreeBSD repository for testing his script, isn't he? --Stijn -- Tact, n.: The unsaid part of what you're thinking. pgp0.pgp Description: PGP signature
Re: Subversion/CVS experiment summary
cvs-to-perforce scripts use DB files to keep an information on related commits while they scan CVS repo. I didn't try FreeBSD CVS, but whole SGI Linux tree with full history was processed quite effortlessly, without running out of memory. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Monday 09 February 2004 11:53 am, Stijn Hoop wrote: Did you have to modify the script, or pass unusual options? I'd like to reproduce this, but I didn't get very far when I tried a few days ago with the 0.37.0 version of the tool. No, I used the script as-is. The version I have is LastChangedRevision: 8527, with a date of Jan. 29. It looks like that version is slightly newer than the one included with 0.37 (Rev 8512). One thing that may have made a difference is that so far I've been importing things in chunks rather than trying to do the whole repo at once. but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... Does the Python version do the same thing? I didn't think to look at memory usage very closely while it was running :-/ Comments on importing: It's SLOOW. It took 43.9 hours just for src/sys, and this is a relatively speedy system! It starts out at a pretty good pace, but the more commits it processes, the slower each one seems to take. That doesn't bode well. Is committing in the new SVN repository also slow? No, creating a new branch and committing new and changed files to it seems to be just as quick as with an empty repository. I haven't delved into the script enough to know for sure, so this is a wild guess, but I think the speed issue has to do with the script itself. I'm guessing that the method it uses to track the status/branch/etc. of the RCS files is subject to a linear slowdown. I'm going to attempt to verify this by doing a dump / load cycle on the repo that everything was imported into. If it goes quickly then we can assume it's the conversion script. If not, then there are bigger problems... My thoughts were now going to do something like Tom Lord proposed for an Arch gateway -- just import a CVS working copy into SVN at a certain cut-off date, and setup a bi-directional gateway between the two. If I'm reading that right, it sounds similar to a thought I had about just routinely checking out snapshots and committing them on a vendor branch. Of course you'd have to do that separately for each branch you're interested in. IMO, I find it immensely useful to have the entire history of a file at hand. Actually, would a sort of access control wrapper that is now also used with the FreeBSD CVS repository not work? I do agree that it would be nice to have per-directory access control with the svnserve method. Yes, I think the same sort of access hooks (pre-commit?) can be used. The Subversion manual even mentions that, I just forgot about it... That method has always seemed a little... hackish to me. You still need write access (file permissions) to almost the entire repo so it does nothing against editing the files directly -- though with SVN this is a little more difficult as it's all bdb files rather than plain text. Maybe there's a more secure way to do it with a restricted shell that I just don't know about. [ repeated merges ] Which is a shame, this would be a major selling point. On the other hand, considering the amount of work done and the fact that it really works quite well already (at least for my small repository) should make people want to switch :) In the release notes for 0.37 there is a brief blurb about 'svn merge' now notices ancestry by default. I'm not sure exactly what that means or if it's related... It also looks as if Subversion 0.37 (aka 1.0-RC) has just been released. I'll have to take a look at it and see if any of the problems noted above have been resolved. Please let me know the results! Will do! My local Subversion server (one running Apache, not the machine I've been doing the tests on) had just finished upgrading the port. I don't think it needs a dump/load cycle but I'm doing one anyway just to be safe... Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
Alexander Kabaev [EMAIL PROTECTED] writes: cvs-to-perforce scripts use DB files to keep an information on related commits while they scan CVS repo. I didn't try FreeBSD CVS, but whole SGI Linux tree with full history was processed quite effortlessly, without running out of memory. Perforce uses CVS as backing store, so I expect matters are a little different than for SVN. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Mon, Feb 09, 2004 at 01:26:45PM -0600, Craig Boston wrote: On Monday 09 February 2004 11:53 am, Stijn Hoop wrote: Did you have to modify the script, or pass unusual options? I'd like to reproduce this, but I didn't get very far when I tried a few days ago with the 0.37.0 version of the tool. No, I used the script as-is. The version I have is LastChangedRevision: 8527, with a date of Jan. 29. It looks like that version is slightly newer than the one included with 0.37 (Rev 8512). Well, that explains a lot -- for some reason I tested using $LastChangedRevision: 7921 $. I'll try with an up-to-date one then. One thing that may have made a difference is that so far I've been importing things in chunks rather than trying to do the whole repo at once. Yes, I was afraid though that commits might have spanned subtrees. But then again, even if they did they would just get committed as separate revisions to the tree, and I suppose one could live with that. but although it looks like it handles things much better (even vendor branches etc), it loads EVERYTHING into memory -- which means that it eventually grew to 1G of memory/swap at which point my memory was exhausted, and this was at pass 2 of 7... Does the Python version do the same thing? I didn't think to look at memory usage very closely while it was running :-/ As far as I understood it builds a disk cache instead of using malloc(). This might explain the slowness :) My thoughts were now going to do something like Tom Lord proposed for an Arch gateway -- just import a CVS working copy into SVN at a certain cut-off date, and setup a bi-directional gateway between the two. If I'm reading that right, it sounds similar to a thought I had about just routinely checking out snapshots and committing them on a vendor branch. Of course you'd have to do that separately for each branch you're interested in. Yes, that's the idea. You 'just' need a tool that can determine changesets from a CVS repository to automate this. See http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree but substitute Subversion for arch :) IMO, I find it immensely useful to have the entire history of a file at hand. But you do have all history of a file at hand; you just need to have a separate version system for the older history. Which is admittedly a bit unwieldy, but it certainly makes for a smooth transition in the distributed repository case... Actually, would a sort of access control wrapper that is now also used with the FreeBSD CVS repository not work? I do agree that it would be nice to have per-directory access control with the svnserve method. Yes, I think the same sort of access hooks (pre-commit?) can be used. The Subversion manual even mentions that, I just forgot about it... That method has always seemed a little... hackish to me. It is, but it does work. Maybe I'll test and see if I can 'port' those scripts to Subversion :) --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Subversion/CVS experiment summary
On Mon, 09 Feb 2004 20:43:05 +0100 [EMAIL PROTECTED] (Dag-Erling Sm_rgrav) wrote: Alexander Kabaev [EMAIL PROTECTED] writes: cvs-to-perforce scripts use DB files to keep an information on related commits while they scan CVS repo. I didn't try FreeBSD CVS, but whole SGI Linux tree with full history was processed quite effortlessly, without running out of memory. Perforce uses CVS as backing store, so I expect matters are a little different than for SVN. There are two versions of cvs2p4 script and one of them populates repository using p4 commands. Either way, both versions require full scan of source repository to locate related changes and group them together. So matters are not that different for SVN. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
According to Craig Boston: This is an informal report on the viability of using Subversion to manage the FreeBSD source code repository. Some of this is generic and will be familiar to anyone who has looked at SVN before, some is more FreeBSD-specific. Thanks for doing this. I tried the same around 0.12/0.14 and it was a complete disaster with svn crashing with an out-of-memory error after taking all of my 512 MB of RAM and the 2 GB of swap... In the meantime, I'm switching to Arch/tla instead of Perforce for my own projects, the distributed nature of arch makes it enormously useful before I have several machines with repos on them and I want to be able to commit and merge across all these repos and only Arch gives me that (well BK does but I don't like the license and is closed source anyway). I've thought about replacing CVS with Arch in the FreeBSD context, even organised a BoF about that at BSDCon '03, but the development is rather different and I'm not sure it could be applied w/o too much pain. On a side remark, I still don't trust svn way of having everything stored in a BDB. Makes repos far too large, generates lots of logs and makes recovery more complicated. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Darwin snuadh.freenix.org Kernel Version 7.2.0: Thu Dec 11 16:20:23 PST 2003 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion/CVS experiment summary
On Monday 09 February 2004 03:06 pm, Stijn Hoop wrote: Well, that explains a lot -- for some reason I tested using $LastChangedRevision: 7921 $. I'll try with an up-to-date one then. I was looking through the change history for cvs2svn.py and it seems that the 0.37 version is almost exactly the same as the 0.35 version. For some reason it looks like they just re-tagged the old version rather than bring in the changes from HEAD... One thing that may have made a difference is that so far I've been importing things in chunks rather than trying to do the whole repo at once. Yes, I was afraid though that commits might have spanned subtrees. But then again, even if they did they would just get committed as separate revisions to the tree, and I suppose one could live with that. There probably are some commits that do. Only reason I did it like that was to try to trap failure cases more quickly without having to wait for it to get through stage 1 on the whole repo. My plan has always been to go back and try to convert the whole thing when I was sure it would import cleanly and had the resources to do it (the fastest CPU machine I have probably doesn't have enough disk space right now to handle it). Does the Python version do the same thing? I didn't think to look at memory usage very closely while it was running :-/ As far as I understood it builds a disk cache instead of using malloc(). This might explain the slowness :) Ok, that's consistent with what I saw here. It looked like it created several large temporary bdb databases, but I don't remember any excessive swapping going on. Yes, that's the idea. You 'just' need a tool that can determine changesets from a CVS repository to automate this. See http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree but substitute Subversion for arch :) Makes sense. I believe you mentioned earlier that post-commit hooks could be used for this? But that of course requires assistance from the repomaster. It might also be possible to rig up a script to monitor the cvs-all mailing list and get its changesets from there... It is, but it does work. Maybe I'll test and see if I can 'port' those scripts to Subversion :) Yes, it does work as long as your users are relatively trusted and you keep good backups :). Still, it would probably be the most painless transition path to use that over ssh. In regards to the speed test: ARGH! svn dump died on me with this message: * Dumped revision 18576. * Dumped revision 18577. * Dumped revision 18578. * Dumped revision 18579. * Dumped revision 18580. svn: Invalid change ordering: non-add change on deleted path If it's really invalid I wonder how it ended up in the repo in the first place. Not good. I'll have to do some digging to find out what causes that. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
