Question/idea about multiple developers committing to one branch

[David Allouche]

Jan Hudec wrote:
> On Wed, Nov 29, 2006 at 08:56:19AM -0500, Aaron Bentley wrote:
>> Nicholas Allen wrote:
>>> What I think would be cool is if the smart server could enforce that all
>>> commits coming into it are through bound branches or checkouts.
>> I can see why that has some merit.  There's no way of knowing whether a
>> commit is coming from a checkout or not, though.
>>
>> I think it would be simpler to enforce just the rule that no one can
>> change the revision ordering.
> 
> ... and have the advantage that than merge could have an argument
> (--to), that would cause the parents to be recorded in reverse order, so
> than the developer would just 'bzr merge --to mainline; bzr commit; bzr
> push mainline' This would change their local revnos(*), but would properly
> reflect the project structure in log structure (and revnos on the
> mainline).

I would love this.

There's a use case I frequently encounter in Launchpad development, that
I presented to Martin a while ago (about 6 months ago, I think):

 * A mainline with very active development
 * A feature branch with a medium life span (a few weeks)
 * The feature only merges mainline to resolve conflicts

mainline  A -- TONS
           \
feature     `- B - C


Currently, when feature merges from mainline, the diff is unusably large
because it includes the work for the whole team on the whole project, so
it's effectively impossible to review before committing. One must just
blindly trust the merge code.

(Actually it is possible to review the merge by manually diffing against
a tree of the mainline revision being merged, but it is too difficult to
bother with for anybody but the most anal retentive).

mainline  A ----- TONS
           \          \
feature     `- B - C - D

Here, the diff displayed before committing D is unusably large.

With "merge --to", this situation would become something like this:

mainline  A -- TONS -.
           \          \
feature     `- B - C   `- D
                    \    /
                     `--'

In this case, the diff before committing D shows the changes introduced
by B+C, which is just what I want to see to review the merge.

In my initial suggestion, I asked for an option to diff, like "diff
--merge", to get the diff against the merged parent, instead of the diff
against the leftmost parent. These two solutions produce very different
logs, but both fix the review problem equally well.

-- 
                                                            -- ddaa

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