Re: [Gnu-arch-users] the state of the union

[Andrew Suffield]

On Tue, Aug 17, 2004 at 11:25:45AM -0700, Tom Lord wrote:
>   For one thing, we need changeset orientation.  The Subversion users
>   are visibly feeling the pain of its absense.  All of the other
>   systems are changeset oriented.  It seems to be essential to smart
>   merging.  It's also damn handy for project management and code
>   review: look at how arch has evolved so that *all* changes to the
>   mainline are now patch-flowing through an issue tracker and several
>   layers arch branching and merging.
> 
>   In the past, efforts to unify the changeset mechanisms of the
>   various projects failed.  The primary sticking point seems to have
>   been disagreement about the necessity and desirability of inventory
>   tags.

Ironically, one of the "major" points on my semi-formal list of things
I'd like to see in the next changeset format, is to orient changesets
around logical file identity ("inventory tags") rather than
filenames. The metaphor just makes much more sense; it's the only
intelligent way to describe changesets as functions, and would
eliminate most of the strange edge cases we see with inexact
patching. More on that when we get to the point where we can start
designing the next format (at this rate it'll probably be tla 2.0).

I believe that this approach will give an extremely simple description
of how to apply a changeset, which behaves in the expected manner in
all cases (generating a changeset won't appreciably change).

>   Indeed, cherrypicking has proven very useful in Arch.  And 
>   the reason cherrypicking works in arch is because of our changeset
>   format.  And the reason our changeset format works is because of
>   inventory tags.

Don't underestimate that point. It's also the primary difference
between arch and svn - and in fact, monotone is pretty much
functionally equivalent to svn in every significant respect.

Here's how I like to phrase it to make the point blindingly obvious:

Everybody knows that changesets and tree-versions are interchangeably
convertable. Given one, you can generate the other.

This is only true in the presence of complete history.

The fundamental conversions are:

A complete history of tree-versions converts to a complete sequence of
changesets.

A tree snapshot and a changeset converts to a pair of tree-versions.

When you have a history *fragment*, you can still generate
tree-versions from changesets. You can't do a single damn thing with a
history fragment expressed as tree-versions, except to fetch one of
them.

The ability to fragment history in this manner is what we mean when we
talk about "distributed development". And no, monotone doesn't do
it. It just hauls complete history around to all the clients.

In the simplest possible terms:

We can do something intelligent with the contents of a *single*
revision (that is, one changeset), including merge it. The only thing
you can do with a single revision in the other systems is to fetch it.

> * CA Response: Do Not Be Afraid of the XL
> 
>   If Jblack's attitude towards XL is at all typical I've done a
>   hopelessly bad job of explaining my intentions.

Personally I'm reserving judgement. I can guess at what you're
thinking but don't see any point in doing so.

Furth itself I'm already happy about because I've figured out how to
wedge any arbitrary language into it - it's like the exec() barrier,
only better. It's overcomplicated for this problem but I don't
care. So it's not possible for you to screw that part up.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature