Re: Notes from the version control BOF at the summit

[Colin Walters <walters at redhat dot com>]

[Please CC me on replies]

Hi,

This discussion was pointed out to me, and I'd just like to comment on
using arch in a centralized fashion in the context of gcc, and the
general maturity of tla.

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

Ian Lance Taylor says:

> In arch, each repository is a serialization point for changes.
> Changes are not pushed from one repository to another, they are
> pulled.  Thus somebody (or some automated process) at the master
> repository would be responsible for pulling in revisions from other
> repositories.  Here the committer does the merge, by running a process
> on the master repository.

This is all basically true, but it needs to be said that in order to
work on a project, it is definitely not necessary to create your own
repository (archive).  arch can serve in *exactly* the same way
CVS/Subversion does today, in the update/commit style.  

There is really a direct analogy for using arch in a centralized
fashion:

arch            CVS
----            ----
archive         repository
working tree    checkout
changes         diff
update          update
commit          commit

Now, I am the author of arch-pqm (http://web.verbum.org/arch-pqm), which
Walter Landry referenced in his email.  It allows one to queue up merge
requests which are processed asynchronously.  When writing it, I had in
mind projects which had long-running test suites, much like GCC.  Having
a 'foo commit' process simply hang while your testsuite (and the ones
before you) finish would be highly annoying.  This might be the
"automated process" that Ian was referencing.

In summary, arch lets you be as centralized or as decentralized as you
wish - it doesn't force centralization on you as CVS/Subversion do, nor
does it force decentralization.

Florian also says:

> 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.  I
certainly feel confident that we can improve error messages faster than
someone could redesign a different system.  As for leaving things in an
inconsistent state - that is unusual in my experience.

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

[1] By "handling renames", I'm including actually merging changes past
renames, which I almost always do after renaming a file.  Simply
preserving the log information isn't sufficient.  By "true changesets",
I mean being able to do things like create a directory and a file inside
it in the same commit, in addition to the merging past renames.

Attachment: signature.asc
Description: This is a digitally signed message part