zack's versioning system requirements & subversion

[Nathanael Nerode]

After reading Tom Lord's commentary on arch with respect to Zack's 
requirements list, I thought I might as well write a commentary on 
Subversion.  I'm no expert on it, and anyone who is should correct me. 
:-)

0. Must be at least as reliable and at least as portable as CVS.  GCC
   is a very large development effort.  We can't afford to lose
   contributors because their preferred platform is shut out, nor can
   we afford to lose work due to bugs, and we *especially* cannot risk
   a system which has not been audited for security exposures.  It
   would be relatively easy to give much stronger data integrity
   guarantees than CVS currently manages:

Subversion's security mostly depends on Apache & mod-dav security.  It 
is still in a bug-prone state.  It is nicely portable.

0a. All data stored in the repository is under an end-to-end
    checksum.  All data transmitted over the network is independently
    checksummed (yes, redundant with TCP-layer checksums).  CVS does
    no checksumming at all.

This is currently a shortcoming of Subversion.

0b. Anonymous repository access is done under a user ID that has only
    OS-level read privileges on the repository's files.  This cannot
    be done with (unpatched) CVS.

I don't honestly remember whether Subversion does this.

0c. Remote write operations on the repository intrinsically require
    the use of a protocol which makes strong cryptographic integrity
    and authority guarantees.  CVS can be set up like this, but it's
    not built into the design.

Subversion has this built into the design, in theory; I'm not sure 
it's fully present in the implementation right now.

0d. The data stored in the repository cannot be modified by
    unprivileged local users except by going through the version
    control system.  Presently I could take 'vi' to one of the ,v
    files in /cvs/gcc and break it thoroughly, or sneak something into
    the file content, and leave no trace.

Subversion has this.

1. Must be at least as fast as CVS for all operations, and should be
   substantially faster for all operations where CVS uses a braindead
   algorithm.  I would venture to guess that everyone's #1 complaint
   about CVS is the amount of time we waste waiting for it to complete
   this or that request.  To be more specific:

Subversion generally has this.

1a. Efficient network protocol.  Specifically, a network protocol that,
    for *all* operations, transmits a volume of data proportional --
    with a small constant! -- to the size of the diff involved, *not*
    the total size of all the files touched by the diff involved, as
    CVS does.

Subversion has this.

1b. Efficient tags and branches.  It should be possible to create
    either by creating *one* metadata record, rather than touching
    every single file in the repository.

Subversion has this.

1c. Efficient delta storage algorithm, such that checking in a change
    on the tip of a branch is not orders of magnitude slower than
    checking in a change on the tip of the trunk.  There are several
    sane ways to do this.

Subversion has this, although they're working on an even better one.

1d. Efficient method for extracting a logical change after the fact,
    no matter how many files it touched.  (Currently the easiest way
    to do this is: hunt through the gcc-cvs archive until you find the
    message describing the checkin you care about, then use wget on
    all of the per-file diff URLs in the list and glue them all
    together.  Slow, painful, doesn't always work.)

Subversion has this.

2. Should support this laundry list of features, none of which is
   known to CVS.  Most of them would be useful independent of the
   others, though there's not much point to 2b without 2a, nor 2e
   without 2d.

2a. Atomic application of a logical change that touches many files,
    possibly not all in the same directory. (This is commonly known as
    a "change set".)  One checkin log per change set is adequate.

Subversion has this.

2b. Ability to back out an entire change set just as atomically as it
    went in.

I believe Subversion has this.

2c. Ability to rename a file, including the ability for a file to have
    different names on different branches.

Subversion has this (despite a nasty bug in the current development 
version; this is correct in the architecture, but there's some problem 
with the implementation.)

2d. Automatically remember that a merge occurred from branch A to
    branch B; later, when a second merge occurs from A to B, don't
    apply those changes again.

Subversion does this.

2e. Understand the notion of a single-delta merge, either applying
    just one change from branch A to branch B, or removing just one
    change formerly on branch A ("subtractive merge").

I believe that Subversion understands this.  Whether it can be used in 
practice is another matter.

2f. Perform conflict resolution by automatic formation of
    microbranches.

I don't think Subversion does this.

3. Should allow a user without commit privileges to generate a change
   set, making arbitrary changes to the repository (none of this "you
   can edit files and generate diffs but you can't add or delete
   files" nonsense), which can be applied by a user who does have
   commit privileges, and when the original author does an update
   he/she doesn't get spurious conflicts.

This mostly exists in Subversion; the spurious conflicts were still 
present last I checked, but bring worked on.

4. The repository's on-disk data should be stored in a highly compact
   format, to the maximum extent possible and consonant with being
   fast.  Being fast is much more important; however, GCC's CVS
   repository is ~800MB in size and compresses down to ~100MB.  You
   can do interesting things (like keep a copy of the entire
   repository on every developer's personal hard disk, as Bitkeeper
   does) with a 100MB repository that are not so practical when it's
   closer to a gigabyte.

I'm not really sure how good Subversion is here, but it seems to be 
pretty good.

5. Should have the ability to generate ChangeLog files automagically
   from the checkin comments.  (When merging to basic-improvements I
   normally spend more time fixing up the ChangeLogs than anything
   else.  Except maybe waiting for 'cvs tag' and 'cvs update -j...'.)

Subversion doesn't have this, although it's on the to-do list.


-Nathanael