At Tue, 10 Nov 2009 12:40:37 +0900, Curt Sampson <cjs%netbsd.org@localhost>
wrote:
Subject: Re: git copies of cvs modules available
>
> On 2009-11-07 12:05 -0500 (Sat), Greg A. Woods wrote:
>
> > Some CVS branching support can be more painful to use in some ways than
> > it maybe could be if it were improved, but IMO SVN doesn't improve those
> > things in the much better way something like Hg or Git would do.
>
> In my experience, it does. I've never seen a "simple" wrapper script
> that makes branching as simple as it is in svn, and in fact I've never
> seen a simple wrapper script for branching at all.
I'm not sure where you infer the "wrapper script for CVS branching
support" idea from. (I mentioned simple wrapper scripts only in
connection with history retrieval for "renamed" files.)
I agree that there's little that can be done from a "wrapper" or
front-end perspective to improve branch management support in CVS.
I think the real winners at advanced branch management are Git & Hg.
After all, much of the whole concept of distributed development depends
on having powerful branch management tools at your disposal. Git in
particular apparently makes the integrator's job infinitely easier with
its ability to very quickly and efficiently switch a working directory
between branches (without losing local changes) and to migrate change
sets between branches.
> Merging is also
> significantly easier in SVN, though not as easy as in git.
Indeed.
> All that aside, there is no way, on any reasonably large repository,
> even on an SSD drive, to make CVS branch operations work at any
> significant fraction of the speed of svn branch operations.
and branching operations are even faster with Git (and also Hg, as far
as I understand) :-)
> And, users aside, CVS has much higher admin costs, particularly when
> it comes to dealing with repositories that get themselves into odd or
> invalid states. Perhaps part of our disagreement is that, in the case of
> NetBSD, you don't have to deal with the administrative side of using the
> repo.
I don't see how anything in any VCS changes the administrative costs of
managing the repository -- size and #-of-users and complexity == costs.
Git will change the whole concept of what it means to have "a repo".
I'm not sure how it will really work for NetBSD -- I've selfishly only
really considered how it could work for me as a third party developer.
> Note that I'm certainly not saying that, if we want eventually to move
> to a git- or Hg-like system, it's worth doing an intermediate upgrade to
> Subversion.
Phew! :-)
> You may want to have a look at svk; that improved several areas of
> Subversion use for non-committers for me. Also, making Subversion repos
> available by rsync worked significantly better for me than CVSup did.
From what I read briefly about svk it may indeed offer something better
even than CVSup. That doesn't really say anything good (or bad) about
svn though. Conceptually I think something like it could have been
built to work with rsync'ed copies of CVS repos too -- I thought about
doing something similar but never managed to find the Round TUITs.
> > I did try to use "git svn" as an attempt to try to get the best from the
> > SVN repo without having to use SVN daily, but as the manual page says:
> > "The initial git-svn clone can be quite time-consuming (especially for
> > large Subversion repositories)." Perhaps it'll be better (i.e. usable)
> > now that the initial nearly 24-hr clone operation is done.
>
> I've used git svn for this sort of thing, and found it worked quite
> well, aside from initial clone speed, for both svn committers and
> non-committers alike.
Indeed I'm finding "git svn rebase" to be a whole lot faster now that
the initial clone is done -- perhaps as fast as the equivalent "svn
update" though I have not timed either on the same system (nor with
control over the back-end server).
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpIQKUmIizxZ.pgp
Description: PGP signature