Bound branch implementation

[John A Meinel]

Nathaniel McCallum wrote:
> On Sun, 2005-11-13 at 13:24 +0100, Erik Bågfors wrote:

...

> There are only a few meta-actions (for any values of A and B):
>    A  -> B | A <-  B (uni-directional)
>    A <-> B           (bi-directional)
> 
> The way this is currently handled is this:
> * A  -> B
>   if exists(B):
>      bzr pull and/or bzr merge
>   else:
>      bzr branch A B
> * A <-> B
>   There are lots of ways to do this that we are trying to solve:
>       - branch ; <hack> ; commit ; pull ; merge ; commit ; push
>       - bound branches
> 
> 
> I think the branch mechanism is really good.  It could be expanded to
> take any writeable vfs as the destination.  ie. bzr branch /foo bzr
> +sftp://server/path
> 
> However, can we make merge function more conceptually like branch?
> Thus, in the meta-action scenario above:
> 
> * A  -> B
>   if exists(B):
>      bzr merge A B
>   else:
>      bzr branch A B
> * A <-> B
>   if exists(A) and exists(B):
>      bzr sync A B     # Using "sync"' here rather than "merge --sync"
>   else:
>      error()
> 
> Because of these three types of meta-actions...
>    A  -> B | A <-  B (uni-directional)
>    A <-> B           (bi-directional)
> ... there are three types of relationships:
>    A  -> B: (pushed) mirror
>    A <-  B: (pulled) parent
>    A <-> B: synchronized peer (aka a bound branch)
> 
> This is what I was trying to accomplish with shadows.  Though, perhaps
> they would be better split up into various commands (ie. mirrors --add,
> parent --add, etc).  I'm not sold either way.
> 
> The most important time to think about relationships is at commit time
> (when changes are actually being made to a branch).
> 
> For instance this
>   $ bzr bind
>   <hack>
>   $ bzr commit
>   $ bzr unbind
>   <hack>
>   $ bzr commit
>   $ bzr bind  # sync?
> ... is far less clear to me than this:
>   <hack>
>   $ bzr commit -s # sync
>   <hack>
>   $ bzr commit    # no sync
>   $ bzr peers -s  # sync
> 

One of the specific reasons for bound branches is to enable shared
remote repositories, where you want to make sure everyone is up-to-date.
In the standard case, a branch won't change between bound and unbound
very often. I find that easier to enforce than requiring me to always
remember to do a commit with '-s'.

binding is a specific statement that "I don't want a commit to succeed
if I'm out of date". A lot of people like this model. Certainly it is
more familiar to people who have used CVS/Arch/SVN/etc.

I'm even thinking that we should set up a policy so that the default
behavior of "bzr branch" is to be bound (make it per-user configurable).
That makes everything easier for an admin who is trying to get everyone
to work together, rather than trying to track down where everyone is
committing things.

I am happy to hear alternative possibilities. But the above work flow is
very difficult to scale above a 1-1 relationship, since you have the
problem Erik mentioned, where a commit into one branch, needs to
successfully commit into multiple other branches. We can always add
2-phase commit, but it seems to be unnecessary overhead at this point.

> 
> Anyway, I'm not caught up on a particular implementation, just wondering
> how we can think about branches, their actions and their relationships
> and model our UI against it.
> 
> This is particularly useful when thinking at the GUI level.  Look at
> bzrk.  Why not have a graphical utility that shows the state of all
> registered branches?  Here are some use cases and implementation ideas:
>  ACTIONS
>    * "I want to put the contents of a into b"
>      - drag <a> and drop it onto <b>

The problems with this: Are you saying you want the branch a to become a
sub-tree of b, or that you want the changes in b to appear in a? I
suppose it depends what you are dragging, but I agree that it is an
interesting process.

>    * "I want the contents of a and b to be the same, just this once" 
>      - click "sync", drag <a> onto <b>
>  RELATIONSHIPS
>    * "I want branch b to always be identical to branch a"
>      - click "shadow", drag <a> onto <b>
>    * "I want a to get b's changes and vice versa"
>      - click "shadow", click "sync", drag <a> onto <b>
>    * "I want to know what the static relationships are between branches"
>      - click "shadow", the relationships are depicted using arrows
> 
> Again, just brain storming.  Thanks for listening.
> 
> Nathaniel

Keep thinking about it, see where it leads you. I'm curious how it would
all work out.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051113/6091064a/attachment.pgp