Bound branch implementation

[Erik Bågfors]

I find this syntax more complicated.  Now you have shadows, updates
(what are they?) syncs (what's the difference?) merge to and from
(while the current merge command is consistent an simple (just <from>
<to>, where <to> defaults to cwd).

You can have multiple shadows, which will make things complicated,
what do you do if the commit works on one of them but not the other,
then you need to "fail" the first commit.  Uhh...?

pull, push, merge and bind is all I need to care about, it's simple
and easy to explain.  For example, everyone should understand what
"bzr pull path" means almost without explanation, "bzr merge path"
should also be simple to understand. But to understand that "bzr merge
-f path" is very different from "bzr merge path" is hard. I would
think that -f == force and that it overrides local changes, if I was
not to read the documentation.

merge and pull and push should not be under the same command (merge)
since they do different things.  Also, merge requires a commit after,
pull and push doesn't.  So you have to use them differently.

Regards,
Erik

2005/11/13, Nathaniel McCallum <npmccallum at gentoo.org>:
> Call me crazy (feel free to do so), but let me brainstorm for a second.
> What about this?  It seems more consistent and it lessens (by one) the
> top level command namespace (which is already overcrowded).  Basically,
> I'm introducing the idea of "shadow" branches which we can push changes
> to or sync with (bi-directional).
>
> * change the syntax for merge to:
>  - bzr merge <from_URI> <to_URI>   (merge two arbitrary branches)
>  - bzr merge -t|--to <URI>         (does: "bzr merge ./ <to>")
>  - bzr merge -f|--from <URI>       (does: "bzr merge <from> ./")
>  - bzr merge -u|--update [<URI>]   (does: "bzr merge <URIparent> <URI>")
>  - bzr merge -s|--sync <URI> <URI> (performs a bi-directional merge)
>  - bi-directional merges do "bzr merge <a> <b>" then "bzr merge <b> <a>"
>  - refuse merge if any uncommitted changes in any related branch
>  - handle conflicts like a normal commit.  ie:
>    $ bzr merge -s ./ /foo
>      > There are conflicts!  Fix them, commit them, then re-merge...
>    <fix conflicts>
>    $ bzr commit -m "fixed merge conflicts"
>    $ bzr merge -s ./ /foo
> * drop pull (use "bzr merge --update")
> * drop push (use "bzr merge --to /foo")
> * add the following:
>  - bzr shadows -a|--add <URI>      (add URI to the shadow registry)
>  - bzr shadows -d|--del <URI>      (del URI from the shadow registry)
>  - bzr shadows -l|--list           (lists registered shadows/branch)
>  - bzr shadows -u|--update         (foreach: "bzr merge -t <shadow>")
>  - bzr shadows -s|--sync           (foreach: "bzr merge -s ./ <shadow>")
>  - bzr commit  -u|--update-shadows (calls "bzr shadows -u" after commit)
>  - bzr commit  -s|--sync-shadows   (calls "bzr shadows -s" after commit)
>
> * Thus, the "bound branch" case is this:
>   $ bzr branch sftp://someone.elses/branch mybranch
>   $ cd mybranch
>   $ bzr shadows -a sftp://someone.elses/branch  # $parent ?
>   <hack hack hack>
>   $ bzr commit -s -m "my changes"
>
> * To break away from the "binding":
>   <out of the office>
>   <hack hack hack>
>   $ bzr commit -m "my vacation changes"
>   <back at work>
>   $ bzr shadows -s
>
> * Having a public mirror of your archive
>   $ bzr shadows -a ftp://my.public/branch/on/my/www
>   $ bzr shadows -u
>
> * To only push out a feature when it is ready:
>   <start new feature, hack hack hack>
>   $ bzr commit -m "started new feature"
>   <finish new feature, hack hack hack>
>   $ bzr commit -u -m "finished new feature"
>
>
>
>
>
>