[PATCH] rollback: try to prevent nasty messes with shared clones

[Matt Mackall]

On Tue, 2011-09-13 at 21:26 -0400, Greg Ward wrote:
> # HG changeset patch
> # User Greg Ward <greg at gerg.ca>
> # Date 1315963560 14400
> # Node ID 20561153542c382a2ef33ba9e296c2f73d3606c3
> # Parent  06c791dab7707265e830f0e4ba343aad0a4c8df5
> rollback: try to prevent nasty messes with shared clones.
> 
> Trouble happens with shared clones (multiple working dirs all sharing
> the same repo store) if you commit in one working dir and then
> rollback that transaction in a different working dir: rollback uses
> partial info (.hg/store/undo but no .hg/undo.*) and generally makes a
> mess of things. Try to avoid that by refusing to rollback unless we're
> in the same working dir where the last transaction was created from.
> 
> This is v2: now with passing tests! No change to actual implementation
> relative to original post (2011/09/12).
> 
> Possible points of contention:
> 
>   * storing the working dir path in a file named journal.wdir (then
>     undo.dir) is a bit weird, since that data isn't needed for the
>     actual rollback: it's used needed to prevent nasty rollback messes.
>     But it's so darn convenient! all the infrastructure I needed was
>     right there.

I think this patch is fine on its own, modulo error message bike
shedding. But I'm a little worried that we're going to slowly collect a
bunch of similar hacks for different tools that do non-append history
changes (mq, strip, etc.). Worse, we might build expectations of safety
where we can't provide it.

So let's step back and look at the big picture:

- multiple working directories can share the same store
- there is no record in the store of the number or location of sharers
- there's no good way to add that information:
  - sharers may be across a network
  - sharers may be moved, copied, or deleted WITHOUT using hg
- any sort of locking/reference counting scheme is inherently broken
- one sharer may remove a changeset that's "in use" by another
- the primary user may be completely unaware that a repo is shared
- core commands that modify history: rollback, recover
- extensions that modify history: mq, rebase, etc.

So annoying!

(Compare this to hardlink clones, where the reference counting is
automatically managed by the operating system. If we restricted shares
to local filesystems (that supported hardlinks), we could use a hardlink
to keep track of shares.)

In terms of rollback, the "most recent transaction" is a global state
that individual sharers don't have great visibility into and may race
against. So your wdir fix can basically be thought of as "sharer A
shouldn't accidentally nuke sharer B's work". Is there a way we can
generalize this notion? Or is rollback a special case in that it
operates on the singleton journal?

Also, we have another issue here. Imagine a team where everyone shares a
repo on z:\project\foo to c:\build\foo because of some legacy/habit. Now
everyone's wdir token is the same! This issue is analogous to storing
PIDs in a lockfile on a shared filesystem - we need a hostname or IP
address in there too.

Finally, I think we should try to sort out the issues here first:

http://markmail.org/message/t3rotun7qw6qwatr

That may bring a bit more clarity to the semantics of rollback on the
working directory.

-- 
Mathematics is the supreme nostalgia of our time.