Deleting bookmarks on the server

[Kevin Bullock]

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:
>> 
>>> Hi All,
>>> 
>>> I'm planning to write an extension that will allow bookmarks to be deleted on a server
>> 
>> You know that you can delete bookmarks on a remote with push -B, right?
> 
> Yes I did know that, the problem is that there is no way to delete the
> bookmark from local clones when they run pull.
> This is what my extension is hoping to do.
> Obviously we can;t delete bookmarks which are not present of the
> server because they could be new, local bookmarks. Instead I want the
> server to tell the client about bookmarks that it used to know, but
> have been removed.
> 
>> 
>>> and have the deletion shared with clients.
>>> This would work by setting the bookmark to point to null, and filtering these from the UI.  This is similar to the way non-local tag deletion works.
>>> I can see two problems with this:
>>> * it would not be possible to bookmark null which is a minor annoyance when creating the @ bookmark on an empty repo
>>> * deleting a bookmark from the server that has been moved on the client cannot be detected as a divergence
>> 
>> The main problem here is that bookmarks have no history (by design), so there's really no way you can design a sensical distributed synchronization protocol for them.
> 
> Are you implying the current synchronisation protocol is nonsensical? :P

Nope, just basically manual. We have basically three things you can do to a remote bookmark: create it, advance it to a linear descendant, and delete it. But deleting it doesn't mean it can't show up again later; you have to work out the "correct" state yourself, and everybody's clone has to be manually made to agree. You're talking about _propagating_ a deletion out to other clones in a more durable (and automated) way.

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

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock