Re: preliminary version control requirements

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

On Sat, Jul 26, 2008 at 09:38:29PM -0400, Perry E. Metzger wrote:
 > >    - doesn't require importing things we don't want into base
 > 
 > Not sure what that means.

Well, as an extreme example, a version control system written in PHP
would not be accepted.

 > >    - allows checkout without cloning entire history
 > 
 > I don't necessarily agree with the last bit there. It seems reasonably
 > arbitrary. There are systems that work very well but require local
 > copies of the repository. In a modern environment, where disk is quite
 > cheap, that seems fine to me. (And yes, you can mount a 500GB disk you
 > bought for $80 on your Vax over NFS.)

Disk is not always cheap, and NFS mounting the source tree from
somewhere where it is isn't always an option.

I have a number of machines with source trees that don't have enough
space for the full history, and I'm doubtless not alone.

Of course, this depends to some extent on how big the full history is
compared to the size of the checked out tree on its own. If it adds
10%, that's probably ok. If it triples the size, that's not.

 > > want to have:
 > >    - installs tidily without spewing all over /usr
 > 
 > To some extent, that's up to how NetBSD hacks the sources -- one has
 > arbitrary control over file destinations.

Yes... to some extent.

 > >    - somehow preserves old file version numbers on import for reference
 > >    - uses version numbers that are numbers, not hash codes
 > 
 > I'm not sure that is a critical requirement. Most modern systems don't
 > even have individual file version numbers anyway, they have repository
 > versions with atomic commits across the repo.

Preserving the old version numbers is important because they're
recorded all over everywhere (PRs, mailing lists, etc.) and losing the
ability to correlate all those reports with the source tree would be a
problem.

Meanwhile, there are real reasons why hash codes are bad; they're hard
for humans to use compared to small integers, and they're not ordered
so you can't tell if the version you've got is newer or older than
some version someone's posting about wihout digging around.

 > >    - supports rcsids/keyword expansion
 > 
 > Most of them don't per se do this, in that there aren't version
 > numbers for individual files in any modern system so there aren't
 > expandable RCSID equivalents with a file's individual version number.

Why would it have to be a file's individual version number? It just
has to indicate what stuff a binary file was built with. But we do
need something that does that.

Most of the newer systems not only won't do rcsids but will explain to
you at substantial length why they think you shouldn't want them, but
that doesn't make them right.

We could conceivably get rid of all the existing rcsid strings and
arrange something that didn't require keyword expansion directly in
files, but it would be a lot of work and a big hassle.

 > >    - doesn't exhibit any excessively strange semantic excursions
 > 
 > I don't know what that means.

Bizarre behavior. The first example that comes to mind is the way tags
work in subversion.

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