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

[Kevin Smith]

Walter Landry wrote:
> Kevin Smith <address@hidden> wrote:
>
> > Walter Landry wrote:
> >
> > > Kevin Smith <address@hidden> wrote:

> Revision hashes serve two purposes:

Ok. As long as switching to hashes doesn't make ArX more complicated 
than it currently is, AND as long as switching to hashes allows ArX to 
become simpler than it is, then I think I agree that revision hashes are 
a good thing. And also that using random number UID's is a very poor 
substitute that should be avoided.

> > 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 an archive moves, the URL's that referred to it must be updated.
>
> That is exactly what I am thinking.

Yea!

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

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

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.

> > You mentioned that each time a fork is created, that revision needs to 
> > record the branch it came from. Maybe this concept could be split into 
> > two parts. First, a revision can ONLY be forked from within the same 
> > archive. That way, a revision only needs to store a local/relative 
> > branch/subbranch,revision. Meanwhile, a *branch* can be forked from some 
> > other archive. So the URL of the source archive becomes a piece of 
> > branch data, which gets it out of the hash picture and makes it much 
> > easier to update if the source archive moves.
>
> Yep, this is what I was thinking.

Yea again!

I think I'm pretty happy with the direction this is headed. Unless 
you're thinking of changes beyond what I covered in that email, it seems 
like ArX will get a lot simpler. Reading your earlier messages in this 
thread, I can now see that you were often saying the same thing I said 
later, but I didn't understand what you were saying at the time.

Dang, I wish I had a couple weeks with nothing to do so I could dive in 
and help code this! That might happen later this year, but for the near 
term I probably won't have more than a few hours here and there, which 
probably isn't enough to learn the code base enough to help with changes 
this deep and pervasive.

Kevin