Strategies for push/merge problem?

[Adrian Buehlmann]

On 15.07.2008 16:23, Paul Moore wrote:
> On 15/07/2008, Adrian Buehlmann <adrian at cadifra.com> wrote:
>>> No, that is just one point of view. I love that commits are cheap and
>>> fast. It means I can have several "fallback" positions to which I can
>>> retreat and take off in a different direction. commit != push.
>> That doesn't mean your commits are allowed to break the tests.
>>
>> "Cheap" commits doesn't mean they are allowed to be brain damaged.
> 
> I dispute the phrase "brain damaged". If I take a personal clone to do
> some work on, I expect to be able to handle it how I like - commit
> when I need to. That, after all, is the point of a DVCS. Personally, I
> sometimes need to commit to my personal repo on a USB stick, simply to
> take the current state of my work home with me.
> 
> The fact that there is no simple way of pushing (or pulling, whatever)
> my changes to a central repo which omits such entirely administrative
> commits, doesn't mean I shouldn't be allowed to do it.

Oh well, *I* don't care what you do in your private repos.

But I wonder if a project e.g. like Mercurial would accept a changeset
like this:

"This is what I achieved until 5pm. Currently, the testsuite is
broken, but if I manually set variable x to an illegal value z, I
can almost do feature X. I will continue tomorrow morning, but I had
to commit this state in order to being able to take it home on my
USB stick RIGHT NOW (need to run!)".

Who wants to see such a changeset in the eternal history of any non-toy,
non-hobby, non-single-developer, non-throw-away project?

And yes, *I* for one don't, also not on a "personal" branch
that gets pulled into the history of a project.

> Sometimes, having *all* history can be less than ideal.
> 
> I can publish my changes as a single entity, either by using diff, or
> mq to manage the patches, or even by creating some sort of "collapse"
> extension to merge all my changes into one, but that encourages
> working in isolation and then dropping a huge patch on the mainline
> when I'm "finished" (in my view). That approach is generally
> considered to be counterproductive.
> 
>>>> Having piles of changesets which break tests is really bad for
>>>> bisecting.
>>> Sounds like you want to have intermediate commits collapsed before
>>> they are pushed.
>> Not at all. I just wouldn't want to see your test suite breaking
>> odyssey in the central repo, if we would ever happen to work on the
>> same project.
> 
> So you want to dictate how others commit in their personal feature
> branch. That's possibly a reasonable policy in a *very* strictly
> controlled environment, but seems to me better suited to a centralised
> VCS.

Huh?

I dictate nothing, really. All I said is you will get into troubles if
you have changesets in a project repo that do *not* pass the testsuite,
which I got the impression of you were talking about when I read this:

On 15.07.2008 13:46, Paul Moore wrote:
> > 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.

By reading this, I got the impression, that only your "pushed"
changesets should be seen as relevant points in history and no
one should in fact look at how exactly you got to these "pushed" ones,
because the changesets in-between back to your previous last good
"pushed" changeset may do anything wild, including but not limited
to breaking the testsuite.

You really have to separate your personal need to go back and forth
in micro steps and recording relevant project history which is meant
to be read, pulled, tested, analyzed, reviewed and understood
*and* bisected by others.

The former might be done by using Mercurial to track .hg/patches
produced by mq.

The latter is meant for *interesting* steps, not for arbitrary
"I'm saving my current state right now, because I have to go home now".
For example like: "Refactoring: moving function X to Y",
"Fixing bug X", "Adding new function Z", etc., which can all
be done *without* knowingly breaking a testsuite.

Assume you have a repo, which contains 80% of such "I-needed-to-go
home-csets that unfortunately currently break the testsuite", so let's say you
typically have 4 such vanilla csets and one good "pushed" one.

Now let's assume one morning a developer discovers: "ouch, the
testsuite doesn't pass anymore". What do you do now?

Assuming you would like to know which change introduced the
problem. So you try a few last csets, but with no luck.
All don't pass the testsuite (*hit happens).

Now what? Ok, you go back some 100 csets, to a cset which you sure
know was good and start bisecting. Now bisect will present you
some cset X in between and you have to say whether that one is ok
or not.

So, was that cset X a vanilla one, which you didn't care about whether
the tests pass at all or was it a "deemed good", "pushed" one? If it's the
former, you might say: I simply assume, this one was ok and say so to bisect.
Do you even know that?

Needless horror, I'd say.

But please don't assume I would want to enforce anything on projects
I don't care about.