Bound branch implementation

[Nathaniel McCallum]

On Sun, 2005-11-13 at 15:03 -0600, John A Meinel wrote:
> 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'.

So in the bound case make it commit --no-sync ;)  Also, if there are
syncable peers, commit --sync would merge their changes in first,
updating automatically.

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

The commit --sync would merge in remote changes first.  It would just do
it automatically, with less user interaction.

One thing that drives me crazy is:
  revision_control <command>
  * I can't do <command> until you run <other command>

Just do it for me! :)  (perhaps a prompt would be in order, but don't
make me go through a whole litany just to do what I want)

> 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. 
The first stage of a --sync'd commit is merging in all remote branches.
That is where it would fail.