Re: preliminary version control requirements

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

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

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.

>  > >    - 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.

What's the reason you can't NFS mount in those cases? (I don't
disbelieve you, I just want to understand better.)

> 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.

>  > >    - 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.

I think there isn't a single VCS that will do that right now. If that
were really a requirement, we could never upgrade from CVS. I suspect
we're just going to have to manage old file version information by
keeping the CVS tree around for a while.

> 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.

The lack of ordering is certainly a problem. The length might not be a
problem in practice -- git and the other systems that use them seem to
allow shortest unambiguous prefix, and that's generally only five or
six characters.

>  > >    - 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.

> 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.

>  > >    - 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.

Tags are just version numbers or (if you prefer) tree clones. Why is
that "bizarre"?

I want to caution something overall here. I don't think we can achieve
"perfection". The set of everything you are asking for might be the
null set. We have to be careful not to overconstrain the problem.


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