Re: is the proof in the pudding?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jul 29, 2008 at 07:54:40AM -0400, Perry E. Metzger wrote:
 > > The short answer is that currently none of them is suitable. 
 > >
 > > svn has scalability/resource usage problems,
 > 
 > FreeBSD has successfully managed to import their entire tree and
 > people are using it, so it clearly will scale to the appropriate size
 > of repository.

Nonetheless, many people report that svn uses unreasonable amouts of
memory and/or disk space, especially when compared to other tools.

 > > weird branch/tag semantics,
 > 
 > I see nothing at all weird about the semantics.

Perhaps then you should explain how tagging works and let everyone
decide. Based on how it's been explained to me, I would describe it as
weird.

 > > and has in the past earned a bad reputation for reliability.
 > 
 > I don't think that's true.

That reputation is real and it earned it. The question is whether it's
still relevant, both as a matter of whether the problems have been
fixed and also as a matter of whether the incompetence that led to the
problems (and then incorrectly blamed them on BDB) has been fixed.

 > Based on your comments, I think you haven't actually administered an
 > SVN system in real use. I've run a couple, with dozens of developers,
 > and they're fine.

No. I've been taking notes on what's been said by other people in the
course of the various bikeshed sessions that have already occurred.

It would be very surprising if any one person had extensive experience
with all of the potential candidate tools, so someone has to collect
these notes.

 > > Also it doesn't really offer a whole lot over CVS.
 > 
 > It offers a great deal. Commits are atomic across the entire
 > system. Branches and tags are almost instant. It is possible to move
 > files while retaining history.

But every system other than CVS offers these features. (Also,
according to my notes, rename is implemented as delete and add, so
while tree history is maintained, file history doesn't cross the
rename, so that's only sort of "retaining history".)

 > > git doesn't handle subtrees, uses hash codes instead of version
 > > numbers,
 > 
 > The hash codes are not the same thing as version numbers in other
 > systems. [...]

Yes, they are. They play the same semantic role that version numbers
do in the non-distributed systems.

Would you please stop assuming I have no idea what I'm talking about?
I've been using Mercurial for a number of projects for some time, and
I'm quite aware of why the versions are hash codes, how that makes the
distributed architecture work, and what they are and are not good for.

They are required for a distributed version control system, yes.
However, we don't need a distributed version control system for
NetBSD. Meanwhile, they create a number of usability problems, some of
which have already been touched on: one can't remember them, they are
a hassle to type in when you don't have cut and paste, they're a
(smaller) hassle to paste in even when you do, you can't determine
ordering without digging in the SCM database, etc., etc.

There are also some technical considerations, like tying yourself to a
particular hash function, or what happens if a collision occurs.
(However unlikely that is, it's still possible. And see Val Henson's
paper on compare-by-hash.)

If you need a distributed SCM system, these costs are worth paying;
but if you don't, and we don't, it's not clear that they are,
especially for a large project with a lot of committers and a lot of
users and a lot of communication that needs to identify particular
changesets.

As for an integrity check - they're hardly the only way to do that,
and arguably not a good way either.

 > > can't check out a tree without cloning the full history,
 > 
 > Actually, you can check out a tree without cloning the full
 > history.

Can you? This didn't appear to be possible the last time I tried git,
although maybe I didn't look in the right place, because the UI is
fairly disorganized, which leads to:

 > > and has kind of a messy install with tons of executables.
 > 
 > "Messy?" -- that's a totally unreasonable objection.

It is not. It's a real problem. It's not as serious a problem as some
of the other problems, but this issue, and the user interface
difficulties it's a symptom of, are one of the primary reasons I'm
using Mercurial instead.

*None* of the problems any of the systems have are non-negotiable.  We
can always make our mind up to import perl into base, or cope with
/usr/src taking a couple gigabytes, or do without being able to diff
between release trees, or whatever else if it seems like a worthwhile
tradeoff to gain something else.

However, making such decisions requires an informed analysis of the
tradeoffs, not an out-of-hand dismissal of the issues or criteria or
the idea of making criteria.

I'm quite aware the list you're responded to contained only drawbacks,
not advantages. That's because it was a specific response to another
post in a specific context.

 > If you worry, just throw all the executables into a directory under
 > /usr/libexec or something. The only thing you need in the path is the
 > front end "git" executable.

Is that true now, finally? If so that would be a significant
improvement.

 > I don't know enough about Mercurial, or the others, but based on the
 > dismissal out of hand of quite reasonable systems I don't think I
 > trust the dismissal of the others or DARCS either. I want to see the
 > things installed and try out what it is like to work with them.

darcs would require importing ghc into base. That is a complete
nonstarter.

The conclusion, by the way, is not that nothing is better than CVS,
but that nothing is suitable. CVS isn't suitable either; however, we
already have workarounds in place so there's no barrier to continuing
to use it.

But, be my guest. "Trust" whatever the blazes you want. Go try them
all and get back to us. (And please remember that what you consider
"comfortable" may not be universal.)

In the meantime, please quit bikeshedding.

-- 
David A. Holland
dholland%netbsd.org@localhost