On Nov 28, 2007 4:07 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> 1) When you merge a BRANCH to TRUNK, don't merge back revisions
> which had previously been ported from TRUNK to BRANCH.
>
> 2) Don't lose conflict resolution work (where "lose" can mean
> "mistakenly lump it in with purely merged changes").
I'm not sure it makes sense to talk about these as "issues" or "bugs"
to be fixed, or even talk about how they depend on one another.
They're more like independent first-principles that must obeyed if
anyone is to take even a 'basic' merge-tracking feature seriously. I
mean, it all just boils down to:
(1) "Don't merge the same change twice, anywhere."
(2) "Don't accidentally forget to merge a change."
In our particular scenario of a long-lived feature branch, we have a
situation where it's common for a single revision to contain *two*
changes that need to be treated independently. One of the embedded
changes needs to follow rule 1; the other embedded change is truly
new, and needs to follow rule 2.
>
> My understanding -- based on nothing but instinct, and perhaps totally
> wrong -- was that the issue #2987 branch is to solve (1), because
> that's a prerequisite to solving (2). I'm reviewing the change that
> solves (1) partly in order to understand what we have to do for (2),
> though I hadn't thought we'd do (2) for 1.5. We could, though.
>
> However, your mail makes me wonder if we all have the same
> understanding of what the problem is. I'd love to do (1) and (2), and
> both seem feasible. I'm not sure they should be thought of as the
> same issue, though.
I don't think they're inherently the same issue, nor do I think one
must be solved before the other: I'm just saying that in our
particular scenario, we must obey both rules at once. We must either
dissect a revision into two changes and treat them differently, or, as
your IRC transcript suggests, do what other VC systems do and "force"
the changes to live in two separate revisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 28 23:23:52 2007