Re: git copies of cvs modules available

[Curt Sampson <cjs%netbsd.org@localhost>]

On 2009-11-12 18:13 -0500 (Thu), Greg A. Woods wrote:

> 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.

My point was, in terms of dealing with branches, the distance between
CVS and Subversion is significantly greater than that between Subversion
and Git. Git offers more convenience in merging (at the expense of a
rather steeper learning curve), though Subversion has recently added
some merge tracking features that fix the worst of the merge issues.

> 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)...

I won't get into the details of this, but Subversion offers some of the
same functionality if you simply use a bunch of separate checkouts. The
key concept to realize is that, while git only works with stuff checked
into a repository, you can consider any modified subversion checkout
a (small, possibly very briefly existing) branch. This suffices for
many of the most common use cases. The workflows are rather different,
so if you try to use the git workflow for the same things when using
Subversion, it obviously won't work.

> ...and to migrate change sets between branches.

This is where git shines over Subversion. But how much this really helps
depends on the working style of the project. NetBSD is not heavily
branch-oriented (mostly having developers branching from trunk, and
merging back to trunk only), and so wouldn't see a huge benefit here.
Although our working style might change if we did have that ability.

Again, I'm not saying that git doesn't do some things significantly
better than Subversion, or that we shouldn't move to Git, just that
Subversion is a bigger improvement over CVS than git is over Subversion,
for the stuff we're currently doing in the NetBSD project.

> > 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) :-)

First, you must understand that we're talking a matter of a few seconds
or fractions of a second for either, so neither really offers a clear
advantage over the other. CVS branching operations can take tens of
minutes to deal with on a large repository.

Second, depending on the particular workflow, Subversion is sometimes
faster at branching than Git. Keep in mind, if you just run "git
branch," that does not yet create the branch in the master repo, as "svn
cp" on remote URLs does.

> > And, users aside, CVS has much higher admin costs...
> 
> I don't see how anything in any VCS changes the administrative costs of
> managing the repository -- size and #-of-users and complexity == costs.

Well, I'm guessing you've probably not done long-term administration of
large repos of at least two different VCSes. In my experience, the new
problems Subversion introduces are not as painful as the CVS ones that
go away. Size makes a noticable difference, of course; number of users,
not much difference at all.

> 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.

Very, very well, I should think. It's designed for that sort of thing.

But the key there is patch mangement, more than anything else. You would
see the difference only in that you'd (one hopes) get better responses
to your patches because the developers receiving them would find them
easier to merge. Maybe.

From just your point of view, I believe you would see no difference
between using a git clone of a NetBSD git repo and a git svn clone of a
NetBSD Subversion repo.

> From what I read briefly about svk it may indeed offer something better
> even than CVSup.

It's considerably better, mainly because of Subversion's better branch
management.

> 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....

In theory, yes. But in practice, probably not, because it would be
considerably more difficult to write due to the infelicities of CVS.

> 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).

It should be about the same speed as svn update if you have no local
changes in the branch you're rebasing. dcommit is certainly slower than
svn commit, but still fast enough that it's never bothered me. All of
these cases are dominated by network latency in the typical situation.

cjs
-- 
Curt Sampson       <cjs%starling-software.com@localhost>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com