[RFC] Pushkey Concept

[Matt Mackall]

On Wed, 2009-09-23 at 00:52 +0200, Adrian Buehlmann wrote:
> On 20.09.2009 23:37, David Soria Parra wrote:
> > Once we discussed a good transfer mechanism I'll come up with some more
> > details about pushable bookmarks in general.
> 
> Wouldn't it make more sense to describe some pushable bookmarks
> use cases first, before looking into the details how to transfer
> them?
> 
> I understand bookmarks as follows:
> 
> A user U1 attaches a bookmark B to a head in his local repo.
> B is set to head revision r0.
> 
> If U1 commits a revision r1 based on r0, B implicitly
> moves on to r1.
> 
> So far, everything just local.
> 
> Assume now a second user U2, who has a clone of the repo
> with bookmark B on r0 (U2 got B by cloning, because the
> new clone pulls bookmarks along with the repo).
> 
> At the same time U2 now committed revision r2 on top of r0
> and thus implicitly moved bookmark B to r2.
> 
> Now assume U1 pushes r1 to a server S. Thanks to the bookmark
> push feature, we now have bookmark B on r1 in the repo on S.
> 
> Now assume U2 pushes r2 to S as well.
> 
> Where is bookmark B now?

Whoever pushes last wins. But user U2 also gets publicly shamed for
ignoring the 'push creates new heads' message.

Let's assume U2 doesn't ignore the message. Instead they pull, the new
bookmark does/doesn't override his local one, they merge, update, then
push - correct bookmark on server.

Because there's a merge involved, whether or not we actually pull the
bookmark doesn't really matter. But in other cases it might. There are a
few possible approaches:

a) never pull remote bookmarks
b) pull remote bookmarks iff doesn't already exist locally
c) pull remote bookmarks iff pulling corresponding csets
d) ask questions whenever there's a conflict
e) always pull remote bookmarks

The first two are a bit problematic. (c) will clobber a local bookmark
if you've moved it yourself, but you should probably merge at this point
anyway (see above). (d) seems tedious. And (e) will clobber things it
doesn't need to.

-- 
http://selenic.com : development and support for Mercurial and Linux