[cvsnt] Betr.: CVSNT to CVS

[Tony Hoyle]

Andreas Krey wrote:
> Most software is written and then a bit modified, and then stays,
> which means repositories don't grow over time, but mainly with
> the code size they contain. Which explains why git often manages
> to have the repository smaller than the (uncompressed) tar ball
> of the head.

A valid and not uncommon model is to keep the resultant binaries in the 
tree for each released version.  Some even go as far as to keep the 
installers for all the compiler versions in there as well, so they can 
guarantee they can replicate a build.  Binaries don't compress very 
well... by the time you had half a dozen in there you'd be talking about 
some serious repository size.

Worst case is those places that put ISO images of their releases in the 
reopsitory as well!

> Which basically means that you need to enable compression if a
> cvs checkout of the head shall be faster than a git clone of the
> *entire* repo.

cvs checkouts are generally always compressed.. but the last time I 
grabbed redhat it took 2 hours on a fast link.  I only wanted a couple 
of files...

> I happen to travel by rail, and while there is GPRS etc., it is
> a bit flaky when you actually move, and it's not exactly fast.
> You definitely don't want to do lots of 'cvs diff's there.

Depends on how you work - I rarely do cvs diffs for example, unless I'm 
checking a commit, and if I'm doing that it's in the office.

> Those people would also be pretty indifferent to switching tools;
> give them a list of old and new commands, and that's it.

As Arthur points out, that's not true - those kinds of people are often 
the most resistant to change.

> Unfortunately, those (the mergemeisters and generally those who
> do the difficult stuff) need to be in the boat. If you omit these
> 10% you got an acceptance problem at least where such people exist.

There's stuff that people never do, except in rare exceptions.  You'd be 
surprised - we've had stuff break in cvsnt and it been 18 months before 
anyone actually noticed.  People think 2.5.03.2382 is pretty stable (and 
it is, generally) but there are several hundred bug fixes since, some of 
them major.. except they don't use that bit so don't notice.

> and lots of general (command line) usability stuff. Just how often you
> have to type repository urls to svn is annoying. (Although the price for the
> biggest shittyness*popularity product goes to ant.)

Never saw the point in ant.

> I note a trend there. :-) Namely the reliance on the commercial
> business case (which is nothing to boo at).

For evs, definately.  It's a big server aimed at commercial customers, 
so they drive the development.  Everything in there so far (AFAIK) is 
stuff that companies have asked Arthur about.

> Conflicting commit resolution?

Can be handled by the admin when they need it.  In practice it doesn't 
happen - if you have a team in the US and a team in India, for example, 
they'll be working on different modules.  They may call into each other 
so they need each others source code, but they won't be modifying each 
other.  Where teams are working on the same modules we've got that covered.

> 'normal' as in 'centralized VCS', of course. :-) The problem is the
> administrative overhead in that, the distributed VCS are a lot more
> democratic (or anarchic) there.

Not so much.. create a branch, setup access control so only that user 
can write to it. 5 minutes max.

Tony