Notes from the version control BOF at the summit

[Florian Weimer]

* Colin Walters:

> First of all, Florian Weimer says:
>
>> On the other hand, tla developers tend to completely dismiss the 
>> centralized model.
>
> This is not true, I am not sure why Florian says this.

It's an impression I got by reading the mailing list.  You have to
look away very hard if you want to avoid it. 8-)

> I do centralized development with arch (tla) all the time.  It is in
> fact much better than CVS or Subversion for this, because it handles
> renames and has true changesets[1].

I used to use arch for centralized development, too, but there wasn't
more than one committer for those repositories anyway.

I'd love to look at a project which uses tla, hasn't got a designated
patch integrator, and has a significant changeset creation rate.
There are quite a few interesting questions: How do they trim logs (to
cut down the inode waste)?  Is the lack of versioned branch creation
(or the complete lack of branch removal) a problem?  Is "tla
push-mirror" fast enough for mirroring new changes from the central
repository?  And so on.

> Now, I am the author of arch-pqm (http://web.verbum.org/arch-pqm), which
> Walter Landry referenced in his email.

arch-pqm seems to require that each GCC developer sets up and
maintains his or her own repository.

I'm not sure how many developers actually have to set up branches and
merge between them.  I've got the impression that a lot of committers
(if they commit anything at all, unlike me) don't really need those
fancy features for their daily work.

>> I mean "experimental" as in "simply aborts for some common usage
>> errors, without supplying a proper diagnostic, and leaving behind
>> something in horribly inconsistent state".  Things have already
>> improved for common codepaths, though.
>
> The error messages, along with the tutorial, are definitely the worst
> things about tla.  However, the error messages are quite fixable.  

On common codepaths, surely.

> I certainly feel confident that we can improve error messages faster
> than someone could redesign a different system.

This may be true, especially since the alternatives (at least those
with merge tracking) aren't much better in this area, either.

> As for leaving things in an inconsistent state - that is unusual in
> my experience.

Then it's probably just my luck.  I see it quite often in conjunction
with revision locks.

>> In addition, I've got a hunch that arch is conceptually on the right
>> track, but has got a few design warts that cannot be addressed without
>> giving up backwards compatibility.
>
> If you have specific problems, we would be interested to hear them;
> please send to gnu-arch-users@gnu.org.

I'm not very fond at all of some of Tom's poster childs,
unfortunately, but I'm going to write something down, probably before
the end of this month.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.