Bzr bind/unbind ideas

Nicholas Allen nick.allen at onlinehome.de
Fri Dec 1 22:25:37 GMT 2006


Hi,

Checkouts and bound branches are a seriously cool feature in bzr. I am
wondering if the way they are implemented could be improved though and
the concepts simplified in the process. Typically when one uses a bound
branch one is trying to get the same kind of workflow as in a
centralised version control system but with the added benefits that a
distributed system gives you (that you can commit locally and offline etc).

After thinking about this I think the bzr commands may be able to be
reduced, the concepts simplified and to be able to more acurately mimic
the centralised model when desired without loosing any of the benefits
of the distributed model.

One problem I see with bzr's concept of a checkout is that if someone
else beats me to the checkin to the main line then I will be forced to
do a bzr update first. This is necessary of course but the real problem
is that this now changes how the history will be presented on the
mainline because my revision now gets "wrapped up" in another revision.
Also, if I happened to commit locally because I was on a train and then
I want my changes on the mainline should bzr really wrap all my changes
up that I made locally into one revision (the only thing they have in
common is that I made them on a train not that they are related in any
other way)?


I may be wrong here or overlooked something but...

What I was thinking is when you push to a location bzr would ALWAYS
assume it is bad to change the order of the revision history at the push
location. That is a push should only ever append to the revision history
and not reorder it in the push location. I think this is a reasonable
assumption. When you try to push somewhere and the push would change the
order of revisions (ie the branches have diverged) bzr would always
display an error message. You would then use the update command (instead
of the merge command) to update your branch from the push location. When
you do so it would reorder the revisons in your branch so that the
changes you made came after the ones at the push location (so your
changes are added to the end of the revision history). If there are no
conflicts then you will be able to push to the location again and this
time it will succeed. In this case your revisions will appear as
separate revisions and they will not be wrapped up in a revision as they
are currently. As conflicts are usually quite rare this will be the most
common case. In the case that you update and you get conflicts then bzr
would wrap your revisions up and they would appear as sub revisions as
it currently does.

The bind command is then just an "auto push" command in that it tries to
push to the location after every commit. If the user wants to commit
locally then they can unbind or pass --local to the commit as present.
There is no need to bind again though after working offline and wanting
to get your changes on the mainline. Once you are happy with your local
commits and want them on the mainline then you just try to push there
and the above process will happen. This also solves the problem that if
you make some changes offline and then go online but noone else has
committed to the mainline then the mainline will reflect your revision
history exactly. Currently, bzr will still wrap your local changes up
into a revision in this case.

So in summary binding is just a way of doing an automatic push after
every commit (ie it is just a convenience). The user could achieve the
exact same thing without using checkout or bound branches by simply
using the push command. Theoretically, you could still achieve the same
centralised model without checkout, bind and unbind commands. Those
commands would only exist as a convenience.

Does that make sense?

Nick





More information about the bazaar mailing list