Re: [Arx-users] Further thoughts on ArX and simplicity

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > Kevin Smith <address@hidden> wrote:
> > 
> >>Walter Landry wrote:
> >>
> >>>Kevin Smith <address@hidden> wrote:
> >>Ok, but here's my current thinking, in abstract form:
> >>
> >>An archive is be a collection of branches. Each branch is an ordered 
> >>collection of patches.
> > 
> > 
> > Right now, everything is ordered.  But with revision hashes, they
> > would become partially ordered.  That is inevitable if you are going
> > to allow two people to work independently on the same line of
> > development.
> 
> Can you define "partially ordered" for me?

If you have three revisions A, B, and C, you might be able to say that B
and C come after A, but you can't say whether B comes before or after C.

As an aside, I have heard that Bitkeeper uses timestamps to determine
an ordering.  I guess their use of ordering is not so critical.  They
also claim that it is not as bad as you think.

<snip>
> >>Where does cherry picking fit into (or conflict with) this vision? Ah. 
> >>We need to know that patch (revision) 57 in branch a is actually the 
> >>same patch as revision 33 in branch b. If we use the hash of a patch as 
> >>its identifier, we can know that we have or have not already pulled that 
> >>patch. We want a map of hash->patch for fast checking.
> > 
> > 
> > Are you talking about patches or revisions? In any case, patch or
> > revision 57 in branch a is never the same as patch or revision 33 in
> > branch b.  They have different names, which is part of the hash.
> 
> I must have been thinking of revisions, since (I guess) patches wouldn't 
> have sequence numbers.

Now you are confusing me.  Both patches and revisions have sequence
numbers.  In mathematical terms, patches are the dual of revisions.

> >>Should we hash just the patch data, or also its metadata? I would think 
> >>it would be just the data, because the metadata might have an additional 
> >>"signed off by", or a fixed typo in the commit comment. That would argue 
> >>for storing each patch in a file named by the SHA-1 of the patch.
> > 
> > 
> > But then the meta-data is no longer trusted.  The right way to fix
> > things like typos is to delete the old revision and commit a new
> > revision with corrected metadata.
> 
> Hm. So given a patch that's already in a revision in my branch, and a 
> patch that someone sends me, how would ArX know whether or not that 
> patch was already in my branch? I thought that was how cherry-picking 
> got into this discussion, but I guess not.

ArX looks at the embedded name of the patch.  If you did something
like change the metadata, then you have a different patch.  Metadata
is important too.

> I'm thinking that the actual change to the source code is what really 
> matters. Whether the metadata was signed off by Fred or Wilma, or 
> whether it was committed yesterday or last year is not particularly 
> interesting to me. As a newbie/outsider, I would think that it would be 
> valuable to ArX to know the hash of the patch itself, exclusive of any 
> metadata. If you don't see value in that, I won't push it.

It is unlikely that you will get exactly the same patch from two
sources.  Some people will agglomerate different fixes, change
whitespace in different ways, etc.  The most likely way is that
someone will submit an ordinary, non-ArX patch that two different
people will incorporate.

Moreover, it _is_ important to know that Fred has approved a patch
rather than Wilma, since we know who is the real boss ;)

Cheers,
Walter