Workflow question

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Allen wrote:
|
|> If you really need to backup local work to the server you could keep
|> on local machine mirror repo and work with this repo only locally,
|> without bind to the server. And time to time do `bzr push-repo`.
|> Just a thoughts.
| The problem with this is I would really like it to happen automatically
| when I commit. If I forget then when I am somewhere else and want to
| work on my project it will not all be on the server. I would like that I
| just have to tell Bazaar when I am online/offline and when online I will
| automatically get every commit pushed to the server and preserving
| stable revision ids. So bound branches seemed like the right thing but I
| cannot have a chain of bound branches (Eclipse branch -> local branch ->
| remote branch). I figured just unbinding the local to remote branch
| would also be a convenient way to say "I am offline now".
|
| So I guess the question is: Why can't Bazaar support a chain of bound
| branches?
|
| Cheers,
|
| Nick

Primarily because the chain is defined relative to the current branch. And you
may not have access from a 3rd-party branch.

For example, one branch might be bound via sftp to a machine which is not
accessible from the 3rd machine. Or it may be a 'file:///' url, which would
trick bzr into thinking it needed to update your local machine, when really it
is another branch on the remote machine.

Secondarily it just complicates the locking setup. As each branch needs to
ensure that its master has the data at the tip before it can update the tip.
This isn't terrible, as you can build a nested loop of who needs to be updated
(though you would have to watch out for cycles.)

Tertiarily (?) it *really* gets ugly for 'bzr update'. You have to chain up the
branches, where you may not have access to the working tree, and branches can
diverge for update. Right now we already have to deal with the case where a
branch is bound to a master, but has local commits. Now imagine a branch with
local commits bound to a master which has local commits which is bound again up
the stack.

It is all technically possible, but it gets pretty hairy.

As a glimmer of hope, as we improve the smart protocol, we may be able to hide
if a remote branch is bound or not, and have the bzr process on the far end
handle the bound branch.

So when I say commit here it sends the data to the remote process, which works
out that it has to send it to another remote process, etc. Each node still only
sees 1 master branch. Though this doesn't solve the cycle problem. (If you have
A bound to B which is eventually bound back to A but done so through several
proxies, it becomes hard to figure out what is going on.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHyEYCJdeBCYSNAAMRAjxcAJ481oSi2lTIuGJ3aIWuEA6/YFAZ/wCgyjtY
dlKBtE0T6GKVj36FHJSZNOM=
=Yr9l
-----END PGP SIGNATURE-----