From: Mikael J. <li...@mi...> - 2006-11-21 20:07:14
|
Hi Dave, > With the release of 1.3.31, what are people's thoughts about a > migration to subversion? As mentioned, I'm not opposed to this if > everyone thinks it's a good idea. However, if we're going to make > the move, I'd like to set up a plan for doing it so no-one is left > wondering whether or not they should keep using CVS. Thoughts? > I think it's a great idea! Makes branch and release management so much more obvious in that you can access them as regular directories instead of trees growing from files. Plus global file revision, atomic commits, and, and ... But, other than the clear advantages Subversion has over CVS, I can't say I believe there's anything /extra/ that SWIG development would gain. Maybe that one could set up a Trac instance. http://trac.edgewall.com -- Mikael |
From: William S F. <ws...@fu...> - 2006-11-21 22:44:41
|
Mikael Jansson wrote: > Hi Dave, > >> With the release of 1.3.31, what are people's thoughts about a >> migration to subversion? As mentioned, I'm not opposed to this if >> everyone thinks it's a good idea. However, if we're going to make >> the move, I'd like to set up a plan for doing it so no-one is left >> wondering whether or not they should keep using CVS. Thoughts? >> > I think it's a great idea! > > Makes branch and release management so much more obvious in that you can > access them as regular directories instead of trees growing from files. > Plus global file revision, atomic commits, and, and ... > > But, other than the clear advantages Subversion has over CVS, I can't say > I believe there's anything /extra/ that SWIG development would gain. > Maybe that one could set up a Trac instance. http://trac.edgewall.com > SVN is new technology by about 20 years and nearly everyone thinks it is better. I haven't any experience of it, but let's get on with the migration now that 1.3.31 is released. John, is it going to take long to complete? William |
From: David B. <dav...@da...> - 2006-11-21 22:56:22
|
> > SVN is new technology by about 20 years and nearly everyone thinks > it is > better. I haven't any experience of it, but let's get on with the > migration now that 1.3.31 is released. John, is it going to take > long to > complete? I wouldn't mind getting a little information on what's involved in a migration. Is there a way for us to preserve the entire CVS repository as a historical archive? Are all of the old branches of SWIG seamless incorporated into SVN? Perhaps John can jump in here when he gets a chance. Cheers, Dave |
From: Steve P. <spa...@re...> - 2006-11-21 23:33:35
|
David Beazley wrote: > > I wouldn't mind getting a little information on what's involved in a > migration. Is there a way for us to preserve the entire CVS > repository as a historical archive? Are all of the old branches of > SWIG seamless incorporated into SVN? Perhaps John can jump in here > when he gets a chance. > > Cheers, > Dave > For what it's worth, we migrated to svn from cvs about a year ago for my project at Red Hat, and we never looked back. Yes, you can migrate all CVS revision history including branches and comments (we used cvs2svn to migrate). One feature of SVN over CVS is that if you commit several in multiple directories in a single checkin, SVN records this as a single revision. With CVS each file has its own revision history, and changes in two files aren't really correlated. However, the cvs2svn took care of all this, and figured out correlated changes based on checkin times and comments. Other major wins for us were: cheap branching/tagging (cheap enough for every developer to have their own feature branches if appropriate), and renaming of files and directories (big for us since we wanted to change our directory structure, but would have lost revision history with CVS). Steve |
From: Olly B. <ol...@su...> - 2006-11-22 20:56:04
|
On 2006-11-21, David Beazley <dav...@da...> wrote: > I wouldn't mind getting a little information on what's involved in a > migration. Is there a way for us to preserve the entire CVS > repository as a historical archive? Are all of the old branches of > SWIG seamless incorporated into SVN? Yes to both of these. Migration just involves running a standard (and well used) migration script called cvs2svn which generates an SVN "dump file" from the CVS repo. Then you import the dump file into a new SVN repo. The only notable downside is that a checkout takes up more disk space. This is because a clean copy of each file is kept locally, so the trade-off is disk space for benefits from reduced network use - a simple "svn diff" is really fast, as is "svn status" (this reports added/removed/modified files in a similar way to "cvs -nq up"). Also you can revert changes instantly with "svn revert" (compared to the slower "rm FILES" followed by "cvs up"). While SourceForge have made some major improvements to their CVS server speed, it's still sluggish (especially from a different continent). Tags aren't handled in quite the same way, which requires a bit of relearning - to diff against a tag you specify it as a URL rather than with "-r". But in general it's very similar to CVS in a lot of ways. I've actively used both CVS and SVN, and I'm definitely in favour of migrating. Cheers, Olly |
From: David B. <dav...@da...> - 2006-11-27 18:28:43
|
Since there seems to be a favorable opinion of migrating to subversion, I would like to set up some procedure for going about it. Can we set up a specific date for making the migration? A separate date for cutting off CVS commits? Also, can we get some volunteers for helping out? In the meantime, I'm going to continue to use CVS. Cheers, Dave |
From: Dave Y. <ListMail@Yost.com> - 2006-11-27 23:04:19
|
At 12:28 PM -0600 2006-11-27, David Beazley wrote: >Since there seems to be a favorable opinion of migrating to >subversion, I would like to set up some procedure for going about >it. Can we set up a specific date for making the migration? A >separate date for cutting off CVS commits? Also, can we get some >volunteers for helping out? In the meantime, I'm going to continue >to use CVS. Everybody I know says that if you're switching, you want to skip over subversion. Below is what one friend says Dave - - - - I believe meta-cvs, a front end to cvs written in CL, does what you want. But everyone has to buy into using it. There are many vcs now that does what you want and more. http://en.wikipedia.org/wiki/Comparison_of_revision_control_software There are other comparisons floating about. The FreeBSD project is looking at moving to one of mercurial, svk or git. Apple moved from cvs to svk (IIRC) a while ago. At my company we switched to svn and now I am totally biased against it even though I had suggested it(early days it was unstable and it used berkeley DBM for storage but now you have a choice of mysql etc). mercurial (hg) seems quite decent. git I know nothing about that except Torvalds devotees like it. I personally like darcs. But for a new project that will have zillion lines of code I'd recommend switching to hg. In spite of its name it is not temperamental. - - - - > Such comparisons don't have a yes/no on this question: can you issue a single > command to check in all changes since last checkout, including deletions, re > names, and modifications? Yes. hg, svk, darcs, git all do it. Including any file/dir renames/deletes. > And the only way one can pick such a complex and important thing as a vcs is > to ask around. There are too many important issues that tables like that nev > er address, like "Is it a piece of crap?" ;-) Google for a comparison of the above. You will find that four out of five dentist recommend hg (mercury) fillings. > >There are many vcs now that does what you want and more. > > Can you name one that is free? There are at least a dozen that are free including the above four. Without knowing more I'd say use hg as it is quite efficient, actively maintained, no crashes (written in python) and while quite not as state of the art as darcs, it is pretty close to it (and far ahead of cvs) and scales better. I find darcs the easiest to use. I trust it more since it was primarily written by one person and who understands correctness and such. http://blog.interlinked.org/tutorials/darcs.html http://en.wikibooks.org/wiki/Understanding_darcs - - - - - Here is one useful comparison link: http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html |
From: John L. <jl...@ma...> - 2006-11-29 09:00:41
|
David Beazley wrote: > Since there seems to be a favorable opinion of migrating to > subversion, I would like to set up some procedure for going about it. > Can we set up a specific date for making the migration? A separate > date for cutting off CVS commits? Also, can we get some volunteers > for helping out? In the meantime, I'm going to continue to use CVS. > > Cheers, Dave > I have been away from my computer over Thanksgiving, but am back at my computer now. So as was mentioned elsewhere in this thread, the procedure is to copy the cvs repository locally, run the cvs2svn script (which uses SWIG wrappers :) and upload the resulting file to sourceforge. As such, I have already run cvs2svn a couple times with different options to test it. I will continue to update the CVS repository on my local computer as people do updates, and it is easy to rerun the script. If you are interested, I suggest you see http://cvs2svn.tigris.org/cvs2svn.html mainly the part "Deciding how much to convert". As was mentioned before, we will convert everything. Old branches and tags that are converted can then be "svn rm" after the creation of the initial repository, which just removes them from the tip and leaves them around in the history. http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 See section 6. So I can do a convert and upload, but starting from step 6 I don't think I can do it anymore (don't have the sourceforge permissions) # Login to the SourceForge.net website. # Go to the project summary page (https://www.sf.net/projects/PROJECTNAME). # Click on the 'Admin' link. # Click on the 'Subversion' admin page link. # Click on the 'migrate' link on the 'Migration Instructions' section of the page. # Key in the filename of the archive into the 'Source path' field, noting that it must comply with the filename restrictions previously described. I will probably use svndump.bz2 # Check the 'Replace' check box in the same column, if you wish to replace the existing content with the new content to be added. I guess it doesn't matter if this is checked or not # Enter the value you want passed to the --parent-dir argument of the "svnadmin load" command into the 'Destination' field. For most users, this would be left blank. Note that the destionation directory must be created but empty for this to work. We will leave this blank # Click on the 'Submit' button. # The migration will be finished within 24 hours. It could be finished in as soon as an hour or two, depending on the size of your CVS repository and the number of projects queued for migration in front of yours. Returning to the page will display whether it completed, failed or is still in queue. As for a date, how about this weekend? I will do the final cvs2svn conversion and upload on Sunday Dec 3, so no commits after Saturday. I will post here that the upload is done, and Dave can go through the steps above? After the import, we will need to set up the hook scripts to send email on commits and so forth, but commits can be made to the svn repository before (or while) this is taking place. Also, the script to checkout the web pages will need to be updated slightly (mainly change cvs up to svn up...), and a few other changes. John |
From: David B. <dav...@da...> - 2006-11-30 23:08:14
|
On Nov 29, 2006, at 2:59 AM, John Lenz wrote: > > As for a date, how about this weekend? I will do the final cvs2svn > conversion and upload on Sunday Dec 3, so no commits after > Saturday. I > will post here that the upload is done, and Dave can go through the > steps above? > > After the import, we will need to set up the hook scripts to send > email > on commits and so forth, but commits can be made to the svn repository > before (or while) this is taking place. Also, the script to checkout > the web pages will need to be updated slightly (mainly change cvs > up to > svn up...), and a few other changes. > Upon further thought. Why don't we take this kind of slow at first. I'd like to suggest the idea that we set up SVN as kind of a pilot project, but continue to use CVS for awhile until people get a chance to test SVN and make sure it works. Then, once we're satisfied with that, we make the formal transition. Presumably, this approach will require us to convert the CVS repository twice (since we're going to keep working while this is going on). However, it doesn't sound like that's going to be a problem. Thoughts? Cheers, Dave |
From: William S F. <ws...@fu...> - 2006-11-30 23:19:24
|
David Beazley wrote: > On Nov 29, 2006, at 2:59 AM, John Lenz wrote: > >> As for a date, how about this weekend? I will do the final cvs2svn >> conversion and upload on Sunday Dec 3, so no commits after >> Saturday. I >> will post here that the upload is done, and Dave can go through the >> steps above? >> >> After the import, we will need to set up the hook scripts to send >> email >> on commits and so forth, but commits can be made to the svn repository >> before (or while) this is taking place. Also, the script to checkout >> the web pages will need to be updated slightly (mainly change cvs >> up to >> svn up...), and a few other changes. >> > > Upon further thought. Why don't we take this kind of slow at first. > I'd like to suggest the idea that we set up SVN as kind of a pilot > project, but continue to use CVS for awhile until people get a chance > to test SVN and make sure it works. Then, once we're satisfied with > that, we make the formal transition. Presumably, this approach will > require us to convert the CVS repository twice (since we're going to > keep working while this is going on). However, it doesn't sound like > that's going to be a problem. Thoughts? > To be honest, I'd rather just get on with it. If it goes horribly wrong, and we'll know about it after just one or two commits, then we can just revert. We can make a test directory for testing stuff out on for those who want to find their feet with subversion. But by all accounts there ain't much radically different for the basics if you are used to cvs. Maybe those with experience of converting over to svn can let us know whether it went smoothly and easily or not. William |
From: John L. <jl...@ma...> - 2006-12-01 05:32:43
|
William S Fulton wrote: >> Upon further thought. Why don't we take this kind of slow at first. >> I'd like to suggest the idea that we set up SVN as kind of a pilot >> project, but continue to use CVS for awhile until people get a chance >> to test SVN and make sure it works. Then, once we're satisfied with >> that, we make the formal transition. Presumably, this approach will >> require us to convert the CVS repository twice (since we're going to >> keep working while this is going on). However, it doesn't sound like >> that's going to be a problem. Thoughts? >> >> > > To be honest, I'd rather just get on with it. If it goes horribly wrong, > and we'll know about it after just one or two commits, then we can just > revert. We can make a test directory for testing stuff out on for those > who want to find their feet with subversion. But by all accounts there > ain't much radically different for the basics if you are used to cvs. > Maybe those with experience of converting over to svn can let us know > whether it went smoothly and easily or not. > Well, I use subversion every day, and it is great. I know the mono project converted to svn in as little as a day (they have over 400 committers too!) The first time, they didn't pass the right options to cvs2svn, but ran it again and had the svn up within the day. KDE converted, and they have over 1000 committers. KDE took it a little slower, though. Also, most of the problems/issues people like Mono, KDE and such had is configuring and setting up the server. But sourceforge has done all that work already: the server is set up, permissions for everything is set up, the on disk format for the database is configured, etc. With as few committers as we have, maintaining two source controls will just be too confusing and too much work. Olly suggested exporting patches, but that doesn't work too well when you start moving files around in the svn... then we have to go in manually and do it. We can convert, and leave the cvs around if something really breaks. On a basic level, subversion is exactly the same as CVS. svn update, svn add, svn commit. Things like tagging and branching and merging are slightly different (read: easier than CVS). The thing is, subversion and cvs have exactly the same "philosophy", so converting mainly just changing a few commands. It isn't like switching to something like git, darcs, mercurial, or arch, which are branch based and require a different way of thinking. The one thing that, in my mind, makes it easier to convert is that subversion has excellent documentation. Every single thing about subversion is documented, the svnbook is easy to read, easy to reference. Everyone should check out the following http://www.onlamp.com/pub/a/onlamp/2004/08/19/subversiontips.html http://osdir.com/Article203.phtml Subversion has excellent documentation http://svnbook.red-bean.com/ and even has a section "Subversion for CVS Users" http://svnbook.red-bean.com/nightly/en/svn.forcvs.html John |
From: Olly B. <ol...@su...> - 2006-11-28 05:35:25
|
On 2006-11-27, Dave Yost <ListMail@Yost.com> wrote: > > At 12:28 PM -0600 2006-11-27, David Beazley wrote: >>Since there seems to be a favorable opinion of migrating to >>subversion, I would like to set up some procedure for going about >>it. Can we set up a specific date for making the migration? A >>separate date for cutting off CVS commits? Also, can we get some >>volunteers for helping out? In the meantime, I'm going to continue >>to use CVS. There's not a lot of work required - I believe it's just a matter of telling everyone to stop committing to CVS, then running the cvs2svn script (which could take a while), then uploading the result to sourceforge. John Lenz had volunteered to do this, but if he's too busy I could (I've converted a repo before). > Everybody I know says that if you're switching, you want to skip over > subversion. There seems to have been an explosion in version control systems in the past couple of years, and of course everyone has their favourite. I'm sure most do the job at least as well as CVS. Many of them allow all sort of funky things, but we don't actually need those things for SWIG. My preference is firmly for SVN because I'm already familiar with it and I know it works well from actual experience. It's also the simplest to adapt to for anyone only familiar with CVS. And from a practical point of view, the two easy options are "stay with CVS" or "migrate to SVN" because those are the options sourceforge supports. > The FreeBSD project is looking at moving to one of mercurial, > svk or git. Apple moved from cvs to svk (IIRC) a while ago. Note that "svk" is actually built on top on SVN. It allows local mirroring of SVN repos for disconnected working, etc. > At my company we switched to svn and now I am totally biased > against it even though I had suggested it(early days it was > unstable and it used berkeley DBM for storage but now you > have a choice of mysql etc). The original storage for SVN was based on BDB, and it did have some problems. These days the default is FSFS (introduced in 1.1, made default in 1.2), which uses a tree of files. There isn't an SQL based backend to SVN. Cheers, Olly |
From: David B. <dav...@da...> - 2006-11-30 23:24:33
|
> To be honest, I'd rather just get on with it. If it goes horribly > wrong, > and we'll know about it after just one or two commits, then we can > just > revert. We can make a test directory for testing stuff out on for > those > who want to find their feet with subversion. But by all accounts there > ain't much radically different for the basics if you are used to cvs. > Maybe those with experience of converting over to svn can let us know > whether it went smoothly and easily or not. My concern is that I don't want the universe to break and both CVS and SVN to be unavailable for weeks on end. Perhaps a compromise on this would be to do the migration, give developers a few days to try it out and make sure it works. If there are no glitches, then that's it. Otherwise, if there are problems, I don't want CVS to be down while they're resolved. Cheers, Dave |
From: Jason S. <jas...@gm...> - 2006-12-01 06:22:18
|
Hey all, On 12/1/06, David Beazley <dav...@da...> wrote: > > > To be honest, I'd rather just get on with it. If it goes horribly > > wrong, > My concern is that I don't want the universe to break and both CVS > and SVN to be unavailable for weeks on end. It won't break both. If for some reason the SVN dump is not what we want, CVS will still be available read-only to make a better dump. All of Apache Software Foundation switched to SVN, and there hasn't been a single problem in the switchover - countless projects, countless committers... We should just get on with it... As far as wanting some other VCS other than SVN: until it gets offered by the SF admins as an alternative, we have a choice between CVS and SVN. CVS is broken and SVN isn't. Once we've switched to SVN we can still use other tools like svk on top of SVN. Cheers, jas. |
From: Olly B. <ol...@su...> - 2006-12-01 01:23:46
|
On 2006-11-30, William S Fulton <ws...@fu...> wrote: > To be honest, I'd rather just get on with it. Me too - this has dragged on for quite a while already. > If it goes horribly wrong, and we'll know about it after just one or > two commits, then we can just revert. And because all files committed in a single operation get the same repo version, it would be easy to pull out a patche for each commit to SVN since the conversion, and then we can apply these to the CVS repo and continue with that until we've resolved whatever the issue is. > Maybe those with experience of converting over to svn can let us know > whether it went smoothly and easily or not. Doing the actual repo conversion was easy, but John's taking care of that for us anyway (thanks John!) Forcing my fingers to type "svn" instead of "cvs" took a while - I found this harder than adapting to the small changes in the commands you use for certain things (for example, "cvs -nq up" -> "svn status"). Most of the common commands are the same - "cvs up" -> "svn up"; "cvs diff" -> "svn diff". I do find diffing against a tag or branch with SVN a bit more complicated (though I suspect once I've had to do it more than a handful of times it'll start to come naturally). On the plus side, there aren't the odd limitations with such diffing that CVS seems to have - I never worked out how to diff between two dates on a branch with CVS without checking out the branch at one of the dates first. One of the developer scripts for Xapian which used CVS needed a more major overhaul than I'd expected to work with SVN. I don't recall the details (or which script it was), but I think this is unusual. Certainly all the other scripts translated over easily and naturally. Simon Tatham (the main author of PuTTY) has some thoughtful comments on migrating his projects: http://www.chiark.greenend.org.uk/~sgtatham/svn.html You can probably skip to section 5 - the first four are only really relevant if you're an admin setting up SVN yourself. Cheers, Olly |
From: Olly B. <ol...@su...> - 2006-12-01 14:21:22
|
On 2006-12-01, John Lenz <jl...@ma...> wrote: > With as few committers as we have, maintaining two source controls will > just be too confusing and too much work. Olly suggested exporting > patches, but that doesn't work too well when you start moving files > around in the svn... then we have to go in manually and do it. You misunderstand me - I wasn't suggesting that we attempt to run the two in parallel at all! > We can convert, and leave the cvs around if something really breaks. Exactly! I was just pointing out that if after a week or two we discover some reason why SVN isn't an improvement, it would be easy to take the changes committed to SVN and apply them to the CVS tree in the same commits used to apply them to SVN. Then we could return to using CVS. Not that I believe at all we'll regret moving, but Dave seems to be a little nervous and I was trying to allay his fears. I think it's better we migrate now knowing there's an escape route than try to do an experimental conversion. Cheers, Olly |
From: David B. <dav...@da...> - 2006-12-01 14:33:46
|
> > Not that I believe at all we'll regret moving, but Dave seems to be a > little nervous and I was trying to allay his fears. I think it's > better > we migrate now knowing there's an escape route than try to do an > experimental conversion. I'm not sure nervous is the right word. I'm actually itching to start work on a number of SWIG-related things (documentation, etc.). Because of that, I would hate to see the CVS/SVN repository suddenly go wacko. If John thinks he can do a conversion this weekend, I say go for it. If there are things I need to do, let me know. Cheers, Dave |