preparing migration from baz to bzr

[John Arbash Meinel]

Aldrik KLEBER wrote:
> Le Mardi 18 Octobre 2005 12:06, David Allouche a écrit :
> 
>>On Tue, 2005-10-18 at 10:52 +0200, Aldrik KLEBER wrote:
>>
>>>Hello,
>>>
>>>I'm preparing a migration for my company from baz to bzr.
>>>Actually, developpers are working on a single archive, at office, but
>>>when they work at home, during the WE etc ... they use their own archive
>>>on their laptops.
>>>
>>>It seems that bzr work only in a decentralized approach, what advice
>>>could you give to help me to migrate ?
>>
>>      * Use pqm, which is a mail-driven robot which executes merge
>>        requests. You can find about pqm there:
>>        http://bazaar.canonical.com/BzrUsefulTools
>>        Though Robert Collins says he would not recommend it to people
>>        which are not interested in its process control functionality
>>        (like only committing a merge if the test suite passes).
>>
>>      * Or better, have somebody implement "bzr push" that actually does
>>        the right thing for centralised development.
> 
> 
> bzr push work like baz update no ?
> we can't have concurrent commits ?
> 

Right now, there is no official "bzr push". It has been waiting on a few
things.

The two current plugin implementations (bzrtools "bzr push", and my
bzr-rsync "bzr rpush") both use rsync to push your changes to the remote
branch. Both of them check the remote history, to make sure you aren't
overwriting a branch which isn't the same as this one. So when you push,
you must have all the local entries. So at present, it really only works
for a single developer (if someone pushed and you had committed and
wanted to push, your branches have diverged, which push does'nt
currently support).

To get a native push, we needed to be able to abstract the code to allow
writing to something other than the local filesystem (which my Transport
work was designed to enable). Now that we have it, we need to be able to
actually have implemented certain filesystems (such as sftp). I'm
planning on doing that, but I'm waiting until we decide to integrate
Twisted, since it has native sftp support (rather than a wrapper around
the sftp executable, or paramiko which is an sftp library).

So it is on the way, just not here yet.

Also, after we get writeable remote branches, I'm planning on working on
"bound branches" such that when you run "bzr commit" if the branch is
bound, it commits to the remote branch first, and then to the local
branch. The idea is that when you *are* connected to the network, you
get automatic remote replication. If you go offline, you can unbind, and
 still commit locally. Then when you bind again, it should try to
synchronize the two branches.

This should help make centralized branches a little bit easier. At least
it would tell you that you need to "bzr pull" before you can "bzr commit".

The hard part is figuring out how to handle a diverged branch when you
go to bind, but I think we have solved it for other cases.

All this to say, probably exactly what you want is coming, but it isn't
quite here yet.

John
=:->


> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051018/3b44e482/attachment.pgp