Distributed transaction rollback

[Jason Harris]

On Jul 5, 2010, at 6:31 PM, Steve Losh wrote:

> On Jul 5, 2010, at 12:31 PM, Dmitry Nezhevenko wrote:
> 
>> Hi,
>> 
>> As everybody now, it's possible to rollback pushed revisions only if
>> we've a way to notify everybody to reclone their repos.
>> 
>> I've some idea, related to 1.6 release. Now mercurial has a way to share
>> some information between clones that is not a part of history (pushkey). 
>> 
>> What do you think about using this feature to share list of "rolled back"
>> revisions? Some extension will verify that and automatically strip
>> revisions in local history that are listed in such key.
> 
> I think it could come in very handy.
> 
>> 
>> There are still a few issues, like there should be a way to automerge list
>> of rolled back revisions on push/pull.
> 
> Also, what happens if I've made a commit on top of changeset X and I pull a notification that it has been removed?
> 
> What if the changeset wasn't removed, but was rebased or histedited?  If this extension would track rebases, histedits, etc, then it might be possible to intelligently rebase my new commit to whatever the new changeset is.
> 
> It would be tricky to get everything right, but being able to rebase a set of published changesets and have it automatically propagate to clones would be very, very handy.
> 
>> 
>> Any ideas/suggestions? I'll try to implement something this weekend.
> 
> Maybe you could make a repository on BitBucket with a wiki so people can share ideas on goals, interface, design, etc.


Actually I have also really wanted such a thing. A while ago I privately emailed Martin about this and here is most of that thread:


On May 17, 2010, at 2:50 PM, Jason Harris wrote:

> 
> On May 17, 2010, at 2:40 PM, Martin Geisler wrote:
> 
>> Jason Harris <jason at jasonfharris.com> writes:
>> 
>>> I don't have time to write this up properly. I'll do it in another
>>> email later, but I have often though that after history editing I
>>> would like to push the edits / inform other clients of the changes. It
>>> would be really nice if I could add some file .hgchanges or something
>>> and in there would be a list of things like:
>>> 
>>> 
>>> c60784ed3389 -> 49efbfd99d14
>>> 866d19d07cdb -> 79248e112b91
>>> 31d4ed8fb512 ->
>>> ffceeabdb9c9 -> c60784ed3389
>>> 
>>> (But with the full hash key)
>>> 
>>> Then when someone updates they can run this script and it will do the
>>> rebasings for them, ie if they have some changes which would be
>>> outgoing to some server, and these changes are ontop of moved branches
>>> in the .hgchanges file, There will be a command to run which will do
>>> the rebasings to bring their clone into line with the server. Is that
>>> clear or does it need more detail?
>> 
>> I think it's pretty clear -- the idea is to tell other people to do 'hg
>> rebase --source X --dest Y' automatically. Or maybe do a series of
>> histedit commands to collapse, reorder and otherwise change the history.
>> 
>>> It seems to me that I will not have been the first person to think of
>>> this :) Do you know if there are plans for such a thing?
>> 
>> I've thought of it too :-)
> 
> :)
> 
>> One problem with this kind of distributed delete operation is that it
>> can go terribly wrong: someone makes a mistake and deletes an early
>> revision. The delete request will spread from repository to repository
>> like a virus, killing changesets along the way. I think someone
>> mentioned that an earlier system had this "feature" and that when
>> mistakes happen, the whole community had to scramble to contain the
>> "killer changeset".
> 
> Well I thought it would mark something as closed or optionally stripped. Hence I am replying on this branch. Actually I would mark it closed and then maybe 6 months later do the stripping...
> 
>> A rebase operation is a bit different from a delete operation since
>> rebasing can be lossless. I can imagine a system that would allow me to
>> propagate lossless rebasings to other. But the system breaks down when
>> you need to resolve conflicts during the rebase.
> 
> I had envisioned that this wouldn't happen automatically. There would be some command
> 
> hg overhaul
> 
> or some other name... :)
> 
> But you could put hooks in to before say pushing note that you are pushing to a dead or closed branch, do you want to rebase these changes according to .hgchanges, etc.
> 
> Cheers,
>  Jason