multiple developers commit different files to same bound branch

[Jeff Licquia]

Vaclav Bilek wrote:
> Thank you for your comment.
> 
> You are right that I am coming from CVS (and later SVN) world.
> The reason why I look for the solution I described is folowing:
> - my development team is about 5 to 7 people
> - we process working trees of sizes about:
>    - 1000-20000 files (structured in balanced directory tree)
>    - the total disk space occupied (by working tree) is about 15GB
>    - every project has about 3 working trees in parallel (three developers)
> - there are about 5 projects like this per year
> - the number of commits in each project vary from 300 to 2000 per project
> 
> And that is the reason why is very hard (because of the disk space and
> the time) to have for each developer his own branch.

I don't think you save anything on disk space by avoiding branches.  And
on time, the savings is minimal at best.

As long as you don't create working trees in your central repository,
branches take nearly zero disk space.  Here's a repo I use to maintain
my web site:

44K	./licquia.org
44K	./upstream-2.1
44K	./upstream-2.2
44K	./upstream-2.0
44K	./upstream-2.3
44K	./upstream-2.5
40K	./upstream-2.6
40K	./upstream-2.7
19M	.

So that's about 40K per branch on a repository with 19M worth of changes.

Then, of course, a lightweight checkout of a developer branch takes no
more space than a lightweight checkout of a master branch.

Also, you don't have to check out a working tree of the master branch to
merge to it.  The workflow is something like this:

bzr branch /repo/project/master /repo/project/mybranch
bzr checkout --lightweight /repo/project/mybranch
cd mybranch
[edit files, compile, etc.]
bzr commit -m 'My last change; time to merge.'
bzr merge /repo/project/master
bzr commit -m 'Merge from master.'
bzr push /repo/project/master
bzr pull /repo/project/master

The only step here that creates a new working tree is the initial
lightweight checkout.

This is a little more work than just committing directly to master.  But
you can make the "merge-commit-push-pull" part into a script, if you like.

If your developers never make a mistake and edit the same file at the
same time, the merge-commit-push-pull will work every time with no
hassle.  But if they do make a mistake, one of them may get a conflict
at merge time, which they'd get anyway when committing their changes.

Here's where you save time and hassle: a conflict in a single shared
branch means one developer can't commit at all, and has uncommitted
changes in his/her working tree.  That developer is out of action until
the conflict is resolved, which could be a while if the other developer
needs to help and is unavailable (out sick, say).  With separate
branches, no one's working tree contains uncommitted changes, and the
developer can elect to revert the merge and deal with the conflict later.