Re: preliminary version control requirements

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

On Mon, Jul 28, 2008 at 10:21:35AM -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.
 > 
 > Okay, granted. If you want to have that in a requirements list, I
 > suggest explaining it a bit more clearly, since I'm unlikely to be the
 > only person confused.

Erm, it looks pretty clear to me. But I suppose the full requirements
list, when it's ready, ought to have a discussion of each item, so
that will come in due course.

 > > 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.
 > 
 > What's the reason you can't NFS mount in those cases? (I don't
 > disbelieve you, I just want to understand better.)

Well, for several of them, it's because they're on an unsecured
university network. (Which is also, of course, not unconnected to them
being old machines with small disks still doing important things.)

There's also firewalls, although arguably a firewall shouldn't have a
source tree on it at all.

 > > 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.
 > 
 > Git is apparently famous for how well the compression works -- the X
 > people claim that the whole repo is a small multiple of the checkout
 > in size.

Yes, I know. We need to see this in practice before any further
conclusions can be drawn, but it's likely to be something of a problem
given the size of our history and the number of large dead subtrees
hiding in the repository.

 > > 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.
 > 
 > I think there isn't a single VCS that will do that right now.

Monotone will and its conversion script does if asked. Or so I am
told. (By a NetBSD developer, since you seem to be concerned about
"third parties".)

 > > > >    - 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.
 > 
 > That particular requirement can be met. However, there is an implicit
 > requirement here that I want to mention is not going to be met.

No, that is not an implicit requirement. It is explicitly (as
explicitly as is possible without expressly disowning it) not a
requirement. We need keyword expansion. We need to preserve the old
version numbers for reference. Neither of those requirements states
that *new* versions need to be per-file or that keyword expansion has
to report any kind of per-file version.

 > > 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.
 > 
 > I wouldn't mind having to replace them across the whole tree with
 > different names, that would be fairly straightforward work. I agree
 > that having to set up a rube goldberg mechanism would be a big issue.

Yes. With Mercurial, you'd need to hoke something up. It does not do
keyword substitutions, at all, ever, and the developers insist that
you shouldn't want to.

It wouldn't necessarily have to be that complicated; e.g. one could
add a -ident foo option to ld (that drops in an elf note containing
$Ident: foo$) and link with -Wl,-ident,`cd ${.CURDIR} && hg identify`.
Although this might make the build unacceptably slow; hg identify
tries to find out if you've got any modified files, which is nice, but
may involve scanning the entire source tree to check.

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