Deleting bookmarks on the server

[Stephen Lee]

On Mon, Apr 29, 2013 at 2:11 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> On 28 Apr 2013, at 10:54 PM, Stephen Lee wrote:
>
>> On Mon, Apr 29, 2013 at 1:24 PM, Kevin Bullock
>> <kbullock+mercurial at ringworld.org> wrote:
>>>
>>> On 27 Apr 2013, at 10:42 PM, Stephen Lee wrote:
>>>
>> I guess I'm imagining a special node, which rather than being the root
>> of every branch (like null) is considered a child of every branch.
>> Moving a bookmark to this special node would hide it from the UI as
>> though it had been deleted.  It would be synced just like a normal
>> bookmark and this node would be a valid dest from any other node.
>> Perhaps if another SHA1 sum was reserved like 'FF' * 20 it could be
>> used for this special node.
>>
>> Hence there would be two kinds of delete: the current one which means
>> "stop tracking this bookmark", and the new delete which means "tell
>> all clients that this bookmark is not needed anymore" (UI implications
>> of this TBD...)
>
> The central problem is that you'd have no ordering of deletes of the same bookmark, so if Alice "deletes" the bookmark with your extension, and Bob pulls the deletion, but then later re-creates the bookmark, you can't resolve the correct state of the bookmark.
>
> Compare this with tags: if Alice deletes a tag (creating a commit), and Bob pulls that, but later re-creates the tag (creating another commit), the actions are ordered, because they're part of history.
>

I hadn't considered that situation since the SCM requirements from the
Powers-that-be require that bookmark names are never reused.  So in
this situation, Bob should not have re-created it, and deleting it
again is correct (annoying, but correct).
In general however, my idea isn't going to work.

Steve