Re: Notes from the version control BOF at the summit

[Walter Landry <wlandry at ucsd dot edu>]

Florian Weimer <fw@deneb.enyo.de> wrote:
> * Walter Landry:
> 
> >> * 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"?
> 
> No, it's still experimental technology.  Even tla is still in this
> category.

That seems like you're ruling out almost all of the free version
control systems.  You'll only be left with Aegis and Vesta, which
probably won't work for other reasons.

Or when you say experimental, do you mean experimental work-flows?
Subversion has a lot of new code, but the work-flow is basically the
same as CVS.

> >> * 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?
> 
> I don't think so.  It doesn't even exclude CVS.

I see.  In that case, this is not a difficult requirement.  I think
almost all of the free version control systems can examine logs and
view diffs offline.

> >> * 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.
> 
> Line end translation is required, I suppose.

Even that is troublesome.

> > That is not actually true.  TLA and ArX don't require everyone to have a
> > copy of the entire history.
> 
> Quite true.  I think this also a requirement.  I don't want to fetch
> two gigabytes of history before I can check out the HEAD revision.

Bitkeeper copies entire histories around, and the kernel hackers seem
to do OK.  So I think it comes down to quality of implementation.
This can be bundled into "Does it scale?".

> [Mainline without a designated integrator]
> 
> > 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.
> 
> It is easy to rig up, but does it work in practice?  Is there any
> project with a changeset rate comparable to GCC that uses an automated
> patch queue?

It is still new.  I could wave my hands and talk about how it should
scale quite well, but there is really no data.

Regards,
Walter Landry
wlandry@ucsd.edu