Re: Notes from the version control BOF at the summit

[Walter Landry <wlandry at ucsd dot edu>]

<Disclaimer>
I develop ArX, a distributed version control system
descended from the larch, the original shell implementation of arch.
<\Disclaimer>

I mostly have some questions about what some of the features mean.

Ian Lance Taylor wrote:
> * Must preserve existing history
>     We can not discard our existing CVS revision information.  It was
>     bad enough losing the older RCS information (it is available in
>     the old-gcc directory in the CVS repository on gcc.gnu.org, but
>     that is inconvenient).

How good must the translation be?

> * The tool must be around for a while, and continue to be supported
>     We don't want to have to change again, at least not for a while.

Define "a while".  Has svk been around "a while"?

> * Ability to work offline
>     For example, the ability to do diffs and examine logs while not
>     connected to the Internet.  Some systems support doing a commit
>     while not connected; more on this below.

Is this meant to exclude centralized version control systems?

> * Run on Unix, Windows, Mac
>     CVS does this already, and we need it.

Is Cygwin acceptable, or must it be a native port?

> * Language support and character set conversion
>     A simple case is appropriate line endings for text files.

Are you sure you want this?  Certainly being able to support
multilingual filenames and data is good.  But to go beyond that and
start transcoding things in the version control system seems fraught
with peril.

> In general, version control systems break down into centralized
> systems and decentralized systems.  CVS is a centralized system.  In a
> decentralized system, such as monotone or arch, everybody using the
> system has a complete copy of the repository.

That is not actually true.  TLA and ArX don't require everyone to have a
copy of the entire history.

> Offline commits brings us to the issue of commit serialization.  We
> require a single blessed version.  This means that we must address the
> issue of effectively simultaneous commits to a single file.  CVS
> prevents simultaneous commits by enforcing serialization at the
> server--the second commit is rejected with an "Up-to-date check
> failed" error.  This is not an option for an offline commit.  (Note
> that even for a decentralized system, we can choose to use enforced
> serialization when not working offline, perhaps through an external
> program).

TLA and ArX solve this problem by using a patch-queue.  The
patch-queue account serves as the custodian of the blessed tree.
People submit merge requests.  If the merge request goes through
without conflicts, then the blessed tree is updated.  I would imagine
this sort of system would be easy to rig up for any of the distributed
version control systems.

Finally, is it important to retain file permissions?  Is it important
to version directories?  Do you need any kind of integrity checks or
patch signing?

Cheers,
Walter Landry
wlandry@ucsd.edu