Strategies for push/merge problem?

[Adrian Buehlmann]

On 15.07.2008 13:46, Paul Moore wrote:
> On 15/07/2008, Benjamin Smedberg <bsmedberg at mozilla.com> wrote:
>> Yes, but for a project with thousands of active developers, merges are
>> mentally much more complex. What most of our developers care about is the
>> history of what our tinderboxes built, which was "the tip of
>> mozilla-central". When branch/merges are pushed, it's not always clear where
>> mozilla-central was, and reading diffs between revisions becomes more
>> complicated.
> 
> Agreed, this seems to me to be a relevant distinction with a DVCS. For
> a given repository, there are changesets which, in a sense, never
> existed as independent states in that repo - they were pulled and
> merged as a group. Combine that with the fact that the commit message
> on the final merge is often "merge from XXX" and the linear history
> can be quite challenging to follow.
> 
> As a particular case, a release repository cannot enforce an "all
> revisions must pass the test suite" policy, because the individual
> work-in-progress changesets remain visible. But an "all revisions
> which were tip" (needs a better description) must pass the test suite"
> policy is viable - as long as those revisions are easy enough to
> discover/list.

Not sure what you are talking about here.

Are you talking about deliberately committing states of the tree
that fail the testsuite? Committing such states is bad.

Having piles of changesets which break tests is really bad for
bisecting.

Even more if "release repository" = "stable repository" (not sure what
you mean by the term "release repository" either).

For example, if you do refactorings, passing the testsuite is
the invariant.

>> We have work underway to remedy this situation, see e.g.
>> http://developer.mozilla.org/en/docs/Mercurial/Desired_Features#hgweb_requirements
> 
> I don't think it's exclusive to hgweb. hg log at least should display
> this, and arguably a revision spec which lets you go back N "tip
> revisions" would be useful as well.
> 
> However, my view is entirely theoretical at the moment - I have no
> real-world use to base this opinion on. (So take it with a substantial
> pinch of salt :-) ).