Re: [Arx-users] Hashes for revisions

[Walter Landry]

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

Ah, yes.  They did not discuss it too much, but the only
implementation suggestion I saw was to have the equivalent of the
patch queue manager.  I don't think that is going to help us here.

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

Nope.  You can just delete the offending revision.  Presumably you
don't want their patch anyway :) It does mean that ArX would have to
be able to recognize it if it happened.

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

Correct.

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

My guess is about a hundred, but that is really a guess.  We really
have to implement it to find out.

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

Writing meta files is tricky, because you can update the revision
without updating the meta file.

Cheers,
Walter