Re: [Arx-users] Hashes for revisions

[Kevin Smith]

Walter Landry wrote:
> But this is annoying, because where you are working on the project
> should not influence which branch the work goes on.  If I am working
> on feature xyz, then all of the work should go into the xyz branch.

Interesting topic.

> In ArX, we already compute the hash of a revision.  So we can use both
> the hash and the ordinary revision number to identify a revision.  You
> would only use the hash to resolve ambiguities.  So a revision might
> have the name foo/bar.baz,14,76a72bc9d.  But if you type "arx get
> foo/bar.baz,14", you will get that revision unless there is another
> revision with a different hash.

Sounds good.

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

> So maybe the best thing is to have "get" retrieve the highest numbered
> revision by default?  

That seems scary and error-prone.

> 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 :-)

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

Kevin