Re: [Arx-users] Hashes for revisions

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > The problems get more complicated with "get".  Should a plain "get"
> > get 7a or 7b?  What if the (a) branch has not been touched for 3 years
> > while the (b) branch has 1000 more revisions following it?
> > 
> > One possibility is for there to be a way to mark a branch as no longer
> > interesting.  
> 
> The monotone folks were, at one point, tossing around the opposite idea:
> marking one branch as the "mainline". Without thinking it through
> deeply, that sounds better to me than marking non-mainline branches.

Do you have a url?  I was thinking of the workflow.  You incorporate
new branches into an archive and then progressively merge them.  As
you merge them, you mark them as uninteresting.  This is what monotone
does currently.

> > So maybe the best thing is to have "get" retrieve the highest numbered
> > revision by default?  
> 
> That seems scary and error-prone.

True.  But it is also simple, transparent, and does what you want 70%
of the time ;)  It is not my first choice.

> > So that is the basic interface.  For implementation, my over riding
> > concern is that it is still possible to serve an ArX archive using a
> > simple ftp or webdav server.
> 
> ...or plain non-webdav http server :-)

With .listing files, yes.

> > Eight hex characters is 32 bits, which means you need about
> > 2^(32/2)=65536 versions of the same revision to create an accidental
> > conflict.  So my current plan is to truncate the sha256 to 8
> > characters when storing it in the archive.  
> 
> Sounds reasonable. What would happen if there were a conflict. Would the
> result be catastrophic?

It would prevent you from having those two patches in the same archive
or applied to the same project tree.  I would not say catastrophic,
but it is rather bad.

> > It is also nice that, if you don't use this feature, the workflow will
> > remain exactly the same as before.  There will still be revision
> > numbers that you can use to identify revisions.  One annoying part is
> > that merges can take a bit longer.  Given the previous example
> > 
> >   1 -> 2 -> 3 -> 4a -> 5a -> 6a -> 7a
> >               |
> >               -> 4b -> 5b -> 6b -> 7b
> > 
> > If you have a tree at 5a, you have to read the patch logs for 6a, 7a,
> > 6b, and 7b to ascertain that you want to update to 7a.
> 
> How badly would this degrade if there were a "large" number of revisions
> with higher numbers?

Pretty bad.  You have to read all of the logs for revision numbers
greater than where you are.  This could be optimized down to two round
trips: one to get the directory listing, and one to download all of
the logs.  Downloading all of the logs could take a long time for a
"large" number of revisions.

However, I can not imagine that you will frequently need to update
from a branch that has a large number of revisions with higher
numbers.  If you update frequently, there should not be many higher
revisions at all.

> I wonder if the monotone folks have a more optimized solution. I can
> think of a few possible things that might help the situation, but I
> don't know if any of them are possible or even if they would
> actually help.

The monotone people have a smart server and store everything in a
database.  This allows them to run arbitrary commands on the remote
end and only send the result.  Also, during a commit, they can use
database transactions to do many things at once.  For example, they
can commit a revision _and_ update which revision is the head at the
same time.  ArX uses renames to guarantee atomicity, which can be
restrictive.

In any case, I am far from decided on all this.  It is just an idea
rattling around in my head, I am open to new ideas, and implementation
is far away.

Cheers,
Walter