Re: [Arx-users] Hashes for revisions

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> So if I understand your original problem statement (the desktop/laptop
> case), we're really trying to detect and identify different heads that
> were created on different computers, within the same branch.
> 
> We have one conceptual archive, but two actual copies. One is an ArX
> mirror of the other. Or are they each mirrors of each other? In some
> cases, might one be an scp exact copy of the other?

All of the above.

> Maybe we could assign each local tree a UUID, and always append the UUID
> to the revision ID when you do a commit.

I don't quite see how that would work.  Trees are disposable, so I
could imagine development habits where UUID's are always changing.

However, you did give me an idea.  We could append the hash of the
previous revision to the name.  So if you have three revisions and
their hashes as

0  abd2b236
1  64d9820b
2  092938be

They would be named

  ,0,abd2b236
  ,1,64d9820b,abd2b236
  ,2,092938be,64d9820b

That would give us the connections between revisions.  That would
allow us to build up the revision graph with a single listing.

This would solve the performance problem of figuring out what branch
you are in when merging at the cost of larger revision names.  It
doesn't solve the problem of how to mark a revision as "main" or
"uninteresting".

To solve that, one possibility is to add a new file "uninteresting" to
the patches.  If it exists, then the branch terminating with that
patch is not considered for default "get" and "merge".  However, it
would complicate mirroring, since we would have to check for the
existence of that file every time you mirror, even if nothing changed.

Another possibility is to add a new file ",uninteresting,<hash>" among
the list of revisions.  So when you do a listing of the revisions, you
will get that file as well.  Mirroring is not too bad, since you have
to do the listing anyway, and you can check hashes to see whether it
changed.  The only trick is how to update the file atomically.  Hmm.

Cheers,
Walter