Bound branches revisited

[Kevin Smith]

John A Meinel wrote:
> Now the question is, I think binding to B should update the A's working
> directory (same as 'pull').
> But should binding to B update B's working directory? This obviously
> could only happen on the local filesystem right now.

It strikes me that the word "bind" implies a two-way binding. But if I 
understand the feature, binding A to B does not automatically create a 
binding in the opposite direction. That is, B has no idea that A has 
been bound to it, right? Perhaps using the word "bind" is causing some 
confusion. Is there a better term that hints at the asymmetrical nature?

To answer the specific question above, I would have to ask what would 
happen if I did:

   Bind A to B
   A commit

If B's working directory would be updated by the commit, then I would 
expect this:

   A commit
   Bind A to B

to do the same. If the first case doesn't touch B's working directory, 
then neither should the second case.

In an earlier thread, Rob suggested disallowing binding to a branch that 
has a working tree. That would simplify (eliminate) this case. Arguing 
against that idea, you described your use-case, which is to keep a 
desktop and laptop in sync.

It seems to me that you could use a "central" branch that has no working 
directory as a go-between, or "hub". Desktop working branch would be 
bound to the hub, which would have no working directory (and might be 
located on the desktop, or on a LAN server). The laptop working branch 
would be bound to the hub, except when working offline.

I have never worked like that, but it seems like a plausible solution. I 
just thought I would throw it out there to see if it has any appeal. It 
mirrors the pattern that would be needed by three developers working on 
a single project in a centralized mode.

Kevin