List Info

Thread: Re: SVN vs. CVS? (was re: CVS branch work best practices?)




Re: SVN vs. CVS? (was re: CVS branch work best practices?)
user name
2007-02-26 10:32:53
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 < victorkanegmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">victorkanegmail.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 < drupaldwwright.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">drupaldwwright.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.&nbsp; however, the entire thread about best practices for
branching has nothing to do with CVS's failings regarding branches,
tags, and merging.&nbsp; 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:

&quot;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
&quot;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. ;)



Re: SVN vs. CVS? (was re: CVS branch work best practices?)
country flaguser name
Germany
2007-02-26 10:38:21
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

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )