multiple developers commit different files to same bound branch

John Arbash Meinel john at arbash-meinel.com
Tue Jan 6 15:18:27 GMT 2009


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

Vaclav Bilek wrote:
> Hi
> 
> I have some newbie question I did not find answer for in other sources.
> 
> Imagine following situation -  centralized model:
> 
> I  have shared repository without trees - SHARED_REPO.
> In this repository I have branch MY_BRANCH
> From this repository you I have checked out two working trees A and B.
> Each of this working tree is used by two different developers.
> I do change in both working trees in different files.
> Now I commit changes in working tree A.
> And after that I commit my changes in working tree B - now the problem
> occurs.
> Based on what I know I must first update the whole working tree B and
> than do the commit - and that is what I don't want.
> The other symptom of this "feature" is that it is not easy to get the
> list of changes what has been done by other developers in the main
> branch (the branch my working tree is bound to).
> 
> I enclosed bash shell script what can test what I described above. It
> will fail in the step 9.
> 
> I am new to bazaar and I like it very much but this is critical feature
> for me and my team so I would be happy if someone could explain me what
> am I doing wrong.
> 

The basic issue is that you are using a shared branch, when you don't
want the branch to be shared.

If you don't want to have to update in order to commit, then the
developers should be working on separate branches.

I would guess your background is either SVN or CVS which does not
enforce the 'whole-tree' being consistent. (Which means that if you
commit to file a & b, and they commit to files c & d then you don't have
to update first. And you only have to update if you both of you commit
to file a.)

However, we believe that is actually a mis-feature in SVN, because it
means that if someone else grabs the branch, then they get something
that did not exist when *you* committed, nor when the other person
committed. Because the new tree has the changes to all of a,b,c,d.


I'm not sure exactly what you mean by "list of changes what has been
done by other developers". I have some ideas, but I'm wondering what you
expected to work or how you expected to get that information.

If I was to give a recommendation, I would say that you should work on
independent branches, and then you can use things like "bzr missing
OTHER_DEVELOPERS_BRANCH" to see what is different, and then "bzr merge
OTHER_DEVELOPERS_BRANCH" to incorporate their changes into yours.

> 
> Best regards
> Vaclav Bilek
> 

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

iEYEARECAAYFAkljdkMACgkQJdeBCYSNAAMX9ACeKc/eQAfSJIslcJoHEUOB1VZ1
6BoAniquPRwBEZXaQ/ByP2n0apwIyN06
=0HAp
-----END PGP SIGNATURE-----



More information about the bazaar mailing list