Re: preliminary version control requirements

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

David Holland <dholland-tech%netbsd.org@localhost> writes:
> Here is a preliminary list of requirements for a version control
> system for NetBSD.
>
> This is probably not very complete, so please post additions (or
> deletions/quibbles) and I'll update my master copy as needed.
>
>    ------------
>
> must have:
>    - isn't ridiculously slow
>    - scales to size and history-depth of netbsd (and pkgsrc)
>    - reliable/mature/ready for primetime
>    - doesn't require importing things we don't want into base

Not sure what that means.

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

>    - supports working with subtrees
>    - supports renaming files
>    - supports branch management adequate for releng
>
> 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.

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

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

>    - supports history/log/diffs that follow renames
>    - doesn't exhibit any excessively strange semantic excursions

I don't know what that means.

> would be nice to have:
>    - whole-tree atomic commits

That's all the modern ones -- none still work like CVS -- so you can't
even avoid it if you wanted to.

>    - supports cloning/copying files
>    - supports sideways change propagation among cloned files
>    - supports disconnected operation
>    - supports private branches


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