Re: [Arx-users] Hashes for revisions

[Kevin Smith]

Walter Landry wrote:
> Kevin Smith <address@hidden> wrote:
> 
>>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.

http://lists.gnu.org/archive/html/monotone-devel/2004-12/msg00067.html

The context was that they were trying to figure out how to manufacture
incrementing revision numbers to show the user. A beneficial side effect
might be that it would be easier to create full-featured bidirectional
gateways with "single-headed" systems like CVS and GNU arch.

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

I think that's fine for accidental collisions, which would be extremely
unlikely. Is there some attack where someone could try to render your
archive unusable by injecting a collision? I can't think of one, but
you're in a better position to imagine one.

>>How badly would this degrade if there were a "large" number of revisions
>>with higher numbers?
> 
> Pretty bad.
(snip)

Mostly with remote repositories, if I read between your lines.

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

If you bounced back and forth between laptop and desktop, and did lots
of work between each bounce, you might have dozens of higher revision
numbers in one head than the other. Would that be a "large number"? Or
are we talking hundreds or thousands before it becomes a legitimate problem?

> The monotone people have a smart server and store everything in a
> database.  

True. I was thinking along the lines of writing a meta file each time a
non-branch fork happened, or tracking bidirectional ancestral
relationships instead of only unidirectional. Stuff like that, which
wouldn't need a database.

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

Ok. Feel free to keep bouncing ideas around at your convenience.

Kevin