SVN vs. CVS? (was re: CVS branch work best practices?)
Rob Thorne wrote:
So if we are going to start using branches more, and encouraging more developers to play with tags and branch tags, it might be worth studying whether or when to migrate to a more modern system.
i'll be the first to admit that CVS can be daunting to the untrained. however, the entire thread about best practices for branching has nothing to do with CVS's failings regarding branches, tags, and merging. when to branch, if/when/what to merge (and if not, what branch(es) to apply patches to) are generic questions that would face Drupal developers, no matter what revision control system we used. as far as i know, the *only* viable alternative to CVS that might be considered for drupal development is SVN. sadly, in spite of the other ways SVN improved things that CVS sucks at (basically, renaming files), SVN still fails to make merging branches easy. sure, the syntax of the command changed from: "cvs update -j [revision_1] -j [revision_2]" to: "svn merge -r [revision_1] -r [revision_2]" but otherwise, all the same suckiness is there in both cases [1]. getting into the details of this is OT -- my real point is that SVN is no paradise for revision control, especially regarding branches. sure, the "svn tag" operation is orders of magnitude *faster* than "cvs tag" in many cases, but it's no *simpler* to understand or get right. and no one is complaining about wasted time while "cvs tag" runs, they're complaining (with some justification) about wasted time thinking about the revision control problems (when/why to branch/tag, where to apply patches, when to make releases, etc), instead of their Drupal code problems. bottom line: nearly all of the confusion is being caused because of misunderstanding revision control concepts (and the incredibly complicated world Drupal has created for itself, see my other post), not the syntax or functionality of a specific revision control tool [2]. that said, i'm not fanatically opposed to moving Drupal development to a different revision control system, but it's going to take a *LOT* of work, and (in a year of *many* people trying) i've yet to hear an argument that holds any water about ways SVN would significantly improve our development practices to offset the very high cost of switching. that said, if someone(s) wants to pay me enough to do all the work (and i won't make the same mistake of wildly under-guessing how many hours this would actually take from start to finish as i did with the release system) i'd be more than happy to do the clean separation/abstraction required so we could use SVN instead of CVS. if you're serious (and have a big budget), talk to me off list. thanks, -derek [1] http://www.dellroad.org/svnmerge/index has promise to solve some of these problems, and is now included in the SVN source, but it's still basically "contrib" as far as i can tell. :( [2] to address Rob's other comment:
First is the notorious "forgot -kb on cvs add" problem.
this is a non-issue in a repository with a properly configured CVSROOT/cvswrappers file, which thankfully, the Drupal contrib repo has been for at least a few months now. ;)
Although I regularly use SVN, in terms of making an actual change sometime in the future with Drupal releases, we should study git and its wrapper cogito. For developer version control (individual commits nothing to do with central repository), for committing to a central repository, for creating and applying patches, these new tools originally written not so long ago by Linus Torvald, and becoming more and more popular in the last eighteen months or so, are indeed worthy of attention. git: http://git.or.cz/ cogito: http://git.or.cz/cogito/ patchy git: http://www.spearce.org/category/projects/scm/pg/ explanation: http://www.spearce.org/2006/02/pg-version-0111-released.html There are already excellent gui's too. Victor Kane http://awebfactory.com.ar On 2/26/07, Derek Wright <drupal@dwwright.net> wrote:
Rob Thorne wrote:
So if we are going to start using branches more, and encouraging more developers to play with tags and branch tags, it might be worth studying whether or when to migrate to a more modern system.
i'll be the first to admit that CVS can be daunting to the untrained. however, the entire thread about best practices for branching has nothing to do with CVS's failings regarding branches, tags, and merging. when to branch, if/when/what to merge (and if not, what branch(es) to apply patches to) are generic questions that would face Drupal developers, no matter what revision control system we used.
as far as i know, the *only* viable alternative to CVS that might be considered for drupal development is SVN. sadly, in spite of the other ways SVN improved things that CVS sucks at (basically, renaming files), SVN still fails to make merging branches easy. sure, the syntax of the command changed from:
"cvs update -j [revision_1] -j [revision_2]"
to:
"svn merge -r [revision_1] -r [revision_2]"
but otherwise, all the same suckiness is there in both cases [1]. getting into the details of this is OT -- my real point is that SVN is no paradise for revision control, especially regarding branches. sure, the "svn tag" operation is orders of magnitude *faster* than "cvs tag" in many cases, but it's no *simpler* to understand or get right. and no one is complaining about wasted time while "cvs tag" runs, they're complaining (with some justification) about wasted time thinking about the revision control problems (when/why to branch/tag, where to apply patches, when to make releases, etc), instead of their Drupal code problems.
bottom line: nearly all of the confusion is being caused because of misunderstanding revision control concepts (and the incredibly complicated world Drupal has created for itself, see my other post), not the syntax or functionality of a specific revision control tool [2].
that said, i'm not fanatically opposed to moving Drupal development to a different revision control system, but it's going to take a *LOT* of work, and (in a year of *many* people trying) i've yet to hear an argument that holds any water about ways SVN would significantly improve our development practices to offset the very high cost of switching. that said, if someone(s) wants to pay me enough to do all the work (and i won't make the same mistake of wildly under-guessing how many hours this would actually take from start to finish as i did with the release system) i'd be more than happy to do the clean separation/abstraction required so we could use SVN instead of CVS. if you're serious (and have a big budget), talk to me off list.
thanks, -derek
[1] http://www.dellroad.org/svnmerge/index has promise to solve some of these problems, and is now included in the SVN source, but it's still basically "contrib" as far as i can tell. :(
[2] to address Rob's other comment:
First is the notorious "forgot -kb on cvs add" problem.
this is a non-issue in a repository with a properly configured CVSROOT/cvswrappers file, which thankfully, the Drupal contrib repo has been for at least a few months now. ;)
I flinched when I saw the subject line of the email, but alas, I'm going to contribute to the "you should look at ..." noise, which is what this thread may turn into. You should look at Mercurial[1]. It supports the same model of development as git (distributed revision control). It has an extension for patch queues[2]. It is used by several projects[3] like OpenSolaris, and some of Red Hat's bleeding edge tools. If you indeed plan on moving to another system, check out the audit of Version Control Systems[4] the Fedora Project. They looked at CVS, SVN, Mercurial, Bazaar-NG, and Git. I don't know what conclusion they came to, but the information listed may be useful to someone trying to do evaluations. The information is a bit out of date. For instance, there is an eclipse plugin for Mercurial[5]. As you can probably tell, I do have a vested interest. I just setup a few repositories with Drupal Core, and a few modules to ease site updates for me. I did not do a full history import, just a CVS checkout, and "hg init" it has a Mercurial repository. Message me off-list if you want to see them. 1. http://www.selenic.com/mercurial/ 2. http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension 3. http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial 4. http://fedoraproject.org/wiki/Infrastructure/VersionControl/ 5. http://www.vectrace.com/mercurialeclipse/ -- Corey Bordelon On 2/26/07, Victor Kane <victorkane@gmail.com> wrote:
Although I regularly use SVN, in terms of making an actual change sometime in the future with Drupal releases, we should study git and its wrapper cogito. For developer version control (individual commits nothing to do with central repository), for committing to a central repository, for creating and applying patches, these new tools originally written not so long ago by Linus Torvald, and becoming more and more popular in the last eighteen months or so, are indeed worthy of attention. git: http://git.or.cz/ cogito: http://git.or.cz/cogito/ patchy git: http://www.spearce.org/category/projects/scm/pg/ explanation: http://www.spearce.org/2006/02/pg-version-0111-released.html There are already excellent gui's too.
Victor Kane http://awebfactory.com.ar
On 2/26/07, Derek Wright <drupal@dwwright.net > wrote:
Rob Thorne wrote:
So if we are going to start using branches more, and encouraging more developers to play with tags and branch tags, it might be worth studying whether or when to migrate to a more modern system.
i'll be the first to admit that CVS can be daunting to the untrained. however, the entire thread about best practices for branching has nothing to do with CVS's failings regarding branches, tags, and merging. when to branch, if/when/what to merge (and if not, what branch(es) to apply patches to) are generic questions that would face Drupal developers, no matter what revision control system we used.
as far as i know, the *only* viable alternative to CVS that might be considered for drupal development is SVN. sadly, in spite of the other ways SVN improved things that CVS sucks at (basically, renaming files), SVN still fails to make merging branches easy. sure, the syntax of the command changed from:
"cvs update -j [revision_1] -j [revision_2]"
to:
"svn merge -r [revision_1] -r [revision_2]"
but otherwise, all the same suckiness is there in both cases [1]. getting into the details of this is OT -- my real point is that SVN is no paradise for revision control, especially regarding branches. sure, the "svn tag" operation is orders of magnitude *faster* than "cvs tag" in many cases, but it's no *simpler* to understand or get right. and no one is complaining about wasted time while "cvs tag" runs, they're complaining (with some justification) about wasted time thinking about the revision control problems (when/why to branch/tag, where to apply patches, when to make releases, etc), instead of their Drupal code problems.
bottom line: nearly all of the confusion is being caused because of misunderstanding revision control concepts (and the incredibly complicated world Drupal has created for itself, see my other post), not the syntax or functionality of a specific revision control tool [2].
that said, i'm not fanatically opposed to moving Drupal development to a different revision control system, but it's going to take a *LOT* of work, and (in a year of *many* people trying) i've yet to hear an argument that holds any water about ways SVN would significantly improve our development practices to offset the very high cost of switching. that said, if someone(s) wants to pay me enough to do all the work (and i won't make the same mistake of wildly under-guessing how many hours this would actually take from start to finish as i did with the release system) i'd be more than happy to do the clean separation/abstraction required so we could use SVN instead of CVS. if you're serious (and have a big budget), talk to me off list.
thanks, -derek
[1] http://www.dellroad.org/svnmerge/index has promise to solve some of these problems, and is now included in the SVN source, but it's still basically "contrib" as far as i can tell. :(
[2] to address Rob's other comment:
First is the notorious "forgot -kb on cvs add" problem.
this is a non-issue in a repository with a properly configured CVSROOT/cvswrappers file, which thankfully, the Drupal contrib repo has been for at least a few months now. ;)
Corey Bordelon wrote:
I flinched when I saw the subject line of the email, but alas, I'm going to contribute to the "you should look at ..." noise, which is what this thread may turn into.
It already has and this is completely pointless. We are working with ca. 1000 CVS comitters of which some have a hard time grasping a GUI based CVS client on windows. As long as no nice GUI client for such users is available, we don't need to bother looking on any other RCS. Cheers, Gerhard
On Monday, 26. February 2007, Derek Wright wrote:
but otherwise, all the same suckiness is there in both cases [1]. getting into the details of this is OT -- my real point is that SVN is no paradise for revision control, especially regarding branches. sure, the "svn tag" operation is orders of magnitude *faster* than "cvs tag" in many cases, but it's no *simpler* to understand or get right.
Not that I disagree in principle with your reasoning about understanding revision control at all, just for correctness: There is no such thing as an "svn tag" operation. SVN tags are plain copies from trunk (=HEAD) or from a branch, the only difference to branches is that they are not touched anymore after creation (and that they usually reside in tags/ instead of branches/). By itself, SVN doesn't distinguish at all between trunk, branches and tags. sorry about nitpicking, Jakob
On Monday, 26. February 2007, Jakob Petsovits wrote:
There is no such thing as an "svn tag" operation. SVN tags are plain copies from trunk (=HEAD) or from a branch, the only difference to branches is that they are not touched anymore after creation (and that they usually reside in tags/ instead of branches/). By itself, SVN doesn't distinguish at all between trunk, branches and tags.
Er, I forgot the reference for the interested: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.tags Regards, j
Derek Wright wrote:
ways SVN improved things that CVS sucks at (basically, renaming files), And directories. Unversioned directories have always been a real bugbear of CVS for me.
SVN still fails to make merging branches easy. sure, the syntax of the command changed from:
"cvs update -j [revision_1] -j [revision_2]"
to:
"svn merge -r [revision_1] -r [revision_2]" or imagine:
svk smerge /path/to/branch /path/to/other/branch svk push Seriously, an SVN repo comibined with SVK used by developers locally would be a big improvement over plain cvs. At least for contrib, CVS works ok for Drupal core.
and no one is complaining about wasted time while "cvs tag" runs, Well, we had that debate, made those complaints and the idea of changing was shot down - there's no point complaining about something that won't change, that's a waste of even more time. The change from CVS is/was not going to happen, end of story.
bottom line: nearly all of the confusion is being caused because of misunderstanding I think there is also a lot of frustration, in effect we had it easy before. Develop in HEAD, branch for each new drupal version, apply fixes in the released branch directly etc. Fairly simple, in fact you could often *avoid* having to merge at all, it was possible to ignore some of CVS less usable commands. The new system in effect forces us to do more work - and pretty much makes it essential to get to grips with cvs merge.
It's all for the better, but you'll never get people to like doing more work :) And that's without getting into the extra work you have to spend as a user now tracking module updates if you're used to pulling them from cvs.
offset the very high cost of switching And there's the rub. And that's also the problem with 'eating your own dogfood' vs using an off the shelf system. Then again switching systems is always going to be painful.
I don't have any easy answers, and I don't want to knock the great work you've already done Derek - but you're making us all work harder, just get some ear plugs till the anguished screams and swearing die down =D You know we'll all get used to it eventually. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Feb 26, 2007, at 2:22 AM, Adrian Simmons wrote:
I think there is also a lot of frustration, in effect we had it easy before. Develop in HEAD, branch for each new drupal version, apply fixes in the released branch directly etc. Fairly simple, in fact you could often *avoid* having to merge at all, it was possible to ignore some of CVS less usable commands.
you can do all of that today, too. that's basically what i document in the handbook, with the 1, incredibly minor addition of "and make official release tags whenever practical for real releases", which is still optional (and a huge improvement in its own).
The new system in effect forces us to do more work - and pretty much makes it essential to get to grips with cvs merge.
neither part of that sentence is true. 1) the "degenerate case" of the new release system behaves exactly like the old system, even if you make no official release nodes at all. well, ok, you have to do 2 minutes of extra work to make the initial development snapshot release node for a new branch, but effectively, that's 2 minutes of work every 6-9 months or so. 2) the new system does not at all require you to know how to do cvs merge at all. that's exactly why i haven't documented it, since you don't need to, and as soon as i do, people will start sending me personal emails about how to merge their stuff. a) you've always had to (and will need to) backport bug fixes to multiple branches, so long as you're continuing to support older versions of your code. this didn't change from the new system. b) you can do all your new feature development in HEAD and never have to merge. for the 4th time in 12 hours, RTFM: http://drupal.org/node/17570#HEAD c) no one is forced by the new system to add new features to branches that work with older versions of core. however, if you *want* to, you finally *CAN* do this, which is a vast improvement. yes, it's more work, which i've said all along, but no one is *required* to do this extra work. if you don't care about such things, or don't have enough of a user base to care about keeping your "stable" code stable, do whatever you want, including what you've always done. even in the case where you're actively supporting multiple branches for older versions of core, it's not clear to me that official cvs merging is actually a win (due to the fact that core's API changes so much, you often end up with tons of conflicts, anyway). i did this for a little while with project* but have now switched back to just trying to apply (and porting) patches to whatever branches they need to go into in the first place, instead of merging after every official release.
It's all for the better, but you'll never get people to like doing more work :)
that's why i designed it so the extra work (except the 2 minutes every 6-9 months) is totally optional for people who care enough to do it.
And that's without getting into the extra work you have to spend as a user now tracking module updates if you're used to pulling them from cvs.
which, in practice, is tiny. only a small minority of modules have more branches than core does. for the vast majority of cases, you just have to do "cvs co -r DRUPAL-5" and you've got all you need. in the few edge cases where there's a DRUPAL-5--2 branch, you should think twice about if you want that code anyway, and then can just update your checked out copy to that new branch once (and, since CVS is such an excellent tool, it'll remember that for you so the next time you run "cvs update" in the top level of your modules directory, it'll get the code from DRUPAL-5 for most directories, and DRUPAL-5--2 from the ones where you want that). but, this is becoming less and less of an issue, thanks to nedjo, merlin and myself working on the "ask drupal.org if my site is up-to- date XML-RPC interface": http://drupal.org/node/48580
I don't have any easy answers,
i do. ;)
and I don't want to knock the great work you've already done Derek -
good, thanks. ;)
but you're making us all work harder,
not true.
just get some ear plugs till the anguished screams and swearing die down =D
i wouldn't need the ear plugs if all of you took yours out every time i swear and scream in anguish: RTFM!!!! ;) it's all there. if everyone spent 2 hours carefully reading what's in the CVS handbooks, and (gasp) helping to improve the docs if they're not crystal clear, you'd all already know all the stuff i have to keep re-explaining in emails over and over and over. y'all are the ones making *me* work harder. ;) cheers, -derek
Derek Wright wrote:
b) you can do all your new feature development in HEAD and never have to merge. for the 4th time in 12 hours, RTFM: http://drupal.org/node/17570#HEAD OK, I stand corrected, but it'd probably be clearer to long time contrib users if it said (in the section 'Use it for the "new feature" branch for the current stable core') something along the lines of:
"long term contrib users should note that this is in effect the method generally used before the new release system was implemented, you don't *have* to change the way you work with CVS"
do whatever you want, including what you've always done. Honestly, even reading the documentation for about the 4th time[1] it's not at all clear to me that you can effectively 'carry on as usual' as far as CVS is concerned (obviously the web side is a little different).
The documentation provides a very detailed explantion for new users, perhaps what's lacking is 'what's changed' guide for 'long term' contrib users?
tracking module updates if you're used to pulling them from cvs. which, in practice, is tiny. Several hours so far in my case.
only a small minority of modules have more branches than core does. The problem is you have no way of knowing that without surfing each project page and looking, and each time you do an update then it's possible the module maintainer will have changed their working practice. But...
but, this is becoming less and less of an issue, thanks to nedjo, merlin and myself working on the "ask drupal.org if my site is up-to-date XML-RPC interface": http://drupal.org/node/48580 Indeed, I've installed release_monitor too. I can see that this will get easier, which is why I didn't really go into it in the last mail.
I'm also looking forward to your thoughts on: http://drupal.org/node/116131 and whether it's feasible, as you work through the backlog.
next time you run "cvs update" in the top level of your modules directory, I stopped working like that a while back, doing cvs export on the handful of modules I actually use instead, so I can import into my svk repo without all the CVS folders. But really I should sit down and work up a script to strip out the CVS folders before import and just use cvs co...but I'm rambling.
but you're making us all work harder, not true. I stand (largely) corrected. Apologies for such a terrible welcome back.
[1] In my defense I have to say I'm seriously sleep deprived at the moment due to my young children. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Feb 26, 2007, at 1:32 PM, Adrian Simmons wrote:
The documentation provides a very detailed explantion for new users, perhaps what's lacking is 'what's changed' guide for 'long term' contrib users?
good idea. if anyone wants to find the right spot in the handbook for this and draft an initial version, i'd be happy to edit it for correctness... and yeah, i wrote the docs assuming people didn't know much. i figured the "old hands" could read the docs, see how it was (or wasn't) different from what they usually do, and decide for themselves. but, i can see why that wasn't necessarily the best assumption on my part. luckily, online docs can be easily changed after the fact... it's not like i published a physical book about the new release system or anything. ;)
Apologies for such a terrible welcome back.
it could have been (much) worse. ;)
I'm also looking forward to your thoughts on: http://drupal.org/node/116131 and whether it's feasible, as you work through the backlog.
given enough work, just about anything is "feasible". after a very quick skim, i'm not convinced it's such a good idea, or the best thing to spend time on, but i'll read more closely and reply there. -derek
On Mon, 2007-02-26 at 00:33 -0800, Derek Wright wrote:
as far as i know, the *only* viable alternative to CVS that might be considered for drupal development is SVN. sadly, in spite of the other ways SVN improved things that CVS sucks at (basically, renaming files), SVN still fails to make merging branches easy.
I don't even like the branching in SVN.
that said, i'm not fanatically opposed to moving Drupal development to a different revision control system, but it's going to take a *LOT* of work, and (in a year of *many* people trying) i've yet to hear an argument that holds any water about ways SVN would significantly improve our development practices to offset the very high cost of switching.
The two advantages of svn for me are 1) offline work. 2) changes across multiple files in one changeset. I manage 1) using bzr and having a dual bzr/cvs repository. I can manage 2) with tags, but don't. I still don't think those features offset the work that goes into migrating off of cvs. It does the job. We already had this discussion like a year or so ago and it was pretty fruitless. The only thing I got out of it was an excuse to learn about revision control and explore the different revision control tools out there. It was educational if unproductive. .darrel.
participants (7)
-
Adrian Simmons -
Corey Bordelon -
Darrel O'Pry -
Derek Wright -
Gerhard Killesreiter -
Jakob Petsovits -
Victor Kane