Cherrypick without merge needed

[Erik Bågfors]

On Tue, Jul 1, 2008 at 7:45 PM, JetMark <extrapic at extrapic.com> wrote:
>
>>I lied slightly. just because the modified versions of 2 files is fine, and
> the unmodified versions are fine, does not mean that unmodified will always
> work with modified.
>
> What you say Erik can certainly be true, but in most cases is not, so does
> not invalidate the argument.

In my opinion, this is like saying we don't need seat belts because in
most cases we do not crash the car :)

> The quote above is meant to allow of this
> possibility.  Developers after all have a good idea what files affect their
> bugs, but when a merge generates a conflict that is caused by the merge
> process, that is a problem for me (The CM), not the developer.  And my point
> is that weather or not you get a conflict can depend on what order you merge
> in. Weather you are at risk or not from this can be worked out in advance. I
> can even write code to do it. But Bazaa does not help with this. At all. By
> doing it the CVS way its simplified, but the issue is still there. (And, not
> I am not sugesting that CVS is better or that this is the right way to do
> it.)
>
> The bottom line is that if developers have to look at the CM's merge
> problems as well as their own then this is more work for them. (Even the CM
> cannot decide really what order to merge bugs in as this is determined by
> release schedule. What he would like is to able to say a particular
> combination of change sets is unsafe.)

You have missed one of the nice things about real merge tracking. I
recommend you to watch Linus Torwald's google talk presentation where
he talks about this exact thing.

Basically, solving merge issues, is something that the individual
developers can solve for you, and there should simply not be ANY CM
merge problems anymore.

Basically, this is how it should work.  Say that you have bugfix A, B,
C and D.  All in their own branches from different (or the same)
developers.

Your job is to integrate C and A into the main branch "trunk".

You merge C into trunk, you run your tests, are happy that the bug is
fixed, and commits the merge. You then move on to A, and when you
merge it, you get a conflict.   At this time, you tell the developer
for A to "update from trunk and solve conflicts", he does that and you
can now merge from A without problems.

(now I just realized I didn't need B and D for this example :) )

Hey.. I might just have made your job easier :)

> And thank you Erik for responding to this discussion. I am trying to get my
> head round this and understand why the Bazaar writers and others do not see
> this as important. Possibly point out something they have missied because
> this is not the way they do things. But to me it looks close to being a show
> stopper.
>

No worries :)

Disclaimer: I am not trying to be rude here. So please do not take
anything as criticism. Just trying to show my view on the details.

I'm sorry that I don't really have much to add to this. I think the
way you are trying to do things in a bad way to do it, and it's caused
by you using a inferior tool (CVS) in which this bad behavior is
encouraged (or perhaps even needed to work around the tool).

I think you should take one step back, look the problem and not the
solution, and check if any of the existing tools can solve the
problem, using a different solution than what you have used in the
past.  The problem (getting individual bugfixes into your code) is not
uncommon and is one of the things that the new line of VCSs does very
well. (They could do it even better if they could track cherrypicks
*hint* :) ).

Regards,
Erik