Question/idea about multiple developers committing to one branch

[Jan Hudec]

On Fri, Dec 01, 2006 at 07:21:25PM +0100, Nicholas Allen wrote:
> I was just thinking about this a bit more and the need to reorder the 
> revisions so you can push is already implemented isn't it? All you need 
> to do is bind your branch to the mainline with a bzr bind command 
> followed by a bzr update and it will do this for you won't it? So does 
> bzr even need a --to option for the merge command?

In fact the merge --to would do what update does (if it does -- I don't
use it) in presence of local commits, so maybe update on unbound branch
should do this operation.

> Another problem I see with the --to option is if you use it to merge 
> from mainline and someone else manages to push some revisions there 
> whlie you resolve conflicts you won't be able to push again anyway.

No, you won't. Just as you won't be able to commit with eg. subversion
if someone else commited between you updated and commit.

> I tried this scenario to see if it would work and it seems to. The only 
> slightly undesirable thing is that the changes made on the branch are 
> wrapped up as sub-revisions and shown as a pending merge:

There is no such thing as subrevision. There is no such thing as
subrevision.

All revisions are equal. The merge revision simply has multiple parent
revisions.

Now log prints the log on a linear media, so it has to serialize the
revisions somehow. And it chooses to print the ancestry of the non-first
parent, indented, first, on the assumption that they come from the
feature branch (and usually it's what is sumarized in the merge commit
log) and than prints the ancestry of the first parent, on the assumption
that that is the mainline.

> "Your local commits will now show as pending merges with 'bzr status', 
> and can be committed with 'bzr commit'."
> 
> What I would like is if the mainline has revision A, B and then the 
> branch has A, C that after binding and updating your branch looks like 
> A, B, C (and possibly D if conflicts needed to be resolved). What you 
> actually end up with on the branch is A, B, D with subrevision C.

Again, no, you don't. You end up with:
D
|\
B C
|/
A

It would NOT be possible to make it into:
D
|
C
|
B
|
A
In bzr (and svn, monotone, git, mercurial and arch as well) revision is
a *state* of the tree. So this C would no longer be the same C.

That being said, you CAN get this:
D (only if conflict resolution needed)
|
C'
|
B C
|/
A
There is a graft plugin that does that.

Actually, you probably DON'T want to do the conflict resolution in a
separate commit in such case, but instead want to do it as:
C' (which INCLUDES conflict resolution)
|
B C
|/
A

If you than push, it will not copy over the C revision, because it's not
in the C' ancestry. The Linux kernel folks actually often do this, but
not as a way of merging, but rather as a way of cleaning up and
reordering their changes, because Linus wants to have the changes
grouped logically rather than historically (as they were done).
It almost inevitably requires some manual patch surgery (with help of
some patch management tool like stgit).

This cleaning up patches is good for review, since you remove all blind
alleys that existed in the actual history and also makes bisect more
useful, since every changeset is correctness-preserving and thus should
compile and run.

I however don't see any reason why one should use it instead of merge,
where it can only screw up much more than 3-way merge, since it is
actually merging each revision separately and thus can make many more
conflicts. Basically (because it's created that way):

  C' = C'
  |    |\
C B    B C
 \|    |/
  A    A

Makes the multi-revision case be:

  D' = D'
  |    |\
D C' = C'D
| |    |\|
C B    B C
 \|    |/
  A    A

which is 2 merges rather than 1 in the normal case:

E
|\
| D
B |
| C
|/
A

So I would love to see a "stacked bzr" (because this cleaning up changes
sometimes makes a lot sense), but as merge tool it's not too useful.

> I know this wasn't explained well!

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb at ucw.cz>