Re: is the proof in the pudding?

["Perry E. Metzger" <perry%piermont.com@localhost>]

David Holland <dholland-tech%netbsd.org@localhost> writes:
> 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.

> weird branch/tag semantics,

I see nothing at all weird about the semantics.

> and has in the past earned a bad reputation for reliability.

I don't think that's true. Since it left alpha, I haven't heard of
instances of people losing data. I've experienced, with the BDB back
end, instances of the database needing to have the cleanup routines
run in order to get it unwedged, but no one uses that back end any more
anyway. In addition, SVN provides an easy way to dump the entire
database into a coherent set of ASCII change records that are human
readable and editable, and one can do that five times a day without
serious performance problems if you wish.

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.

> 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. Merges are simpler (but not as good as
they are in many other systems.) There's more. I could never imagine
going back to CVS having used SVN.

> svk shares all or nearly all of svn's problems and would also require
> importing perl into base.

I haven't used svk.

> 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. Hash codes do something that version numbers simply can't
do -- a hash code is a unique digital signature of an entire tree! If
you have a hash code, you can be handed a tree and verify that it is
the same one the hash code came from. This is something that a version
number simply doesn't do.

Now, if you really insisted on version numbers, there is nothing in
the plumbing in git that prevents you from counting from the start to
the tip of the tree and having a version number that way. However, it
wouldn't be a good idea. Git makes something possible CVS can't ever
do, which is distributed development, and in a distributed development
environment where someone is committing to their local repository on
an airplane and integrating later, a global version number isn't
possible.

You are, in essence, throwing out a good candidate because it allows
something important, distributed commits! No distributed VC system can
have global version numbers, so by insisting on them, you're saying we
can't ever use a distributed VC system!

Further, by claiming the hash codes are a bad thing, because humans
can't remember them (and of course they can't) you're throwing away
their important feature, which is that they provide a cryptographic
integrity check we don't have at all right now!

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

Actually, you can check out a tree without cloning the full
history. You do need to have the full history on a locally accessible
file system, but you don't need to clone the tree each time. The full
history for NetBSD would fit on a flash drive at this point, so I
don't see why this is an issue.

> and has kind of a messy install with tons of executables.

"Messy?" -- that's a totally unreasonable objection.

Would you claim Postfix is unacceptable because it has something like
27 executables? We have *that*.

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. Personally I don't see how we can veto
something based on it having "too many executables".

> mercurial doesn't handle subtrees, uses hash codes instead of version
> numbers, can't check out a tree without cloning the full history, and
> would require importing python into base. Its branch support also may
> not be adequate.

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.

The only reasonable way to determine if we like them is to try them
out and see how pleasant they are to use. Arbitrary lists of criteria
cannot substitute for finding out what is actually a comfortable
system to work with and what is not.

We cannot remain using old tools that make development harder than it
needs to be merely because we fear change and will not accept any
alteration in the way things have been done. If we get massive
improvements in development process but lose version numbers, or we
need more resources to do checkouts, or what have you, the benefits
might outweigh the disadvantages.

The fact that following a list of criteria to pre-judge systems leads
us to conclude that nothing is better than CVS indicates that the
criteria based judging system is broken, because clearly most of the
new systems are better than CVS.


Perry
-- 
Perry E. Metzger                perry%piermont.com@localhost