On Mittwoch, 28. November 2007, Ben Collins-Sussman wrote:
...
> The problem here is how to deal with long-lived feature branches that
> are kept up-to-date with trunk, then eventually re-merged back to
> trunk. In our simple example, we imagine a scenario where the user
> merges /trunk:1-100 to the branch and gets some conflicts. She then
> resolves the conflicts, and commits r101 to the branch. After a few
> more branch commits, she merges back to trunk. What should our
> merge-tracking feature do?
...
Sorry for intruding as an outsider that isn't really involved, and neither can
claim any real understanding of the issues ...
But if r101 is marked as "merged to trunk:1-100", then r102-105 are changes to
the trunk, what's the problem of using the diffs trunk@100:branch@101 and
branch@102:branch@105 and applying those?
Similarly, if there are changes against both trunk and branch, and trunk gets
merged to branch, then the diff trunk@101:trunk@200 (as r100 has already been
merged) gets applied to branch, resolved and committed as r201.
Then, a later merge of branch to trunk takes trunk@200:branch@201 and
branch@201:branch@HEAD, and applies these changes ...
To me this problem sounds just like symbolic addition and subtraction; even if
some special revision wants to be excluded (ie. merge 1-100, but exclude 50).
Please excuse my ignorance on these matters ... just wanted to share ideas.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 29 08:25:24 2007