Question

Part of the development I have done on a project can not be deployed, and should have been done in a separate branch. I have merged in the backwards changes (via tortoise’s “revert changes from this revision” and careful editing), undoing the work that should have been in a separate branch, and committed this inverse patch to the trunk. I would now like to create a branch that includes the changes that were undone in the aforementioned patch. Here is what I did:

I created a new branch for the new development at the revision prior to the undo revision.

I merged the undo revision into the new branch via merge a range of revisions in tortoise SVN.

I opened the change log, selected “Include merged revisions”, and “revert changes from this revision”. This reverted these changes in my working copy. It is now what I would like the branch to be like. I committed these changes. This commit lists the undo patch under “include merged revisions”; I do not believe it should do so; there seems to be a problem here. The key is probably to record this patch (the inverse squared, or the product of the original modifications) in such a way that subversion is ignorant of the operation performed to create it.

I then merged all of the changes from trunk into the new branch via the same method (merging a range of revisions). This included the original undo patch a second time, making my branch identical to trunk (listing it now thrice as an included merged revision). This is not the desired result.

<Edit – Solution>

The following is the desired behavior, and works correctly:

First I created an empty repository with folders tags, trunk, branch. In trunk I created a file file.txt with the content (rev1):

one
two
three

Then edit the file to

one
two_edit
three

And checked in (rev2). Then I selected rev2 in the log and picked revert changes from this revision and checked in (rev3). The file now looks like this again:

one
two
three

I then created a branch of trunk from rev3 to branches\b1 (rev4, was5; this step does both). In branches\b1 the file looks like this:

one
two
three

I then reverse merge rev2 from trunk into branches/b1 ignoring ancestry (rev5). The branch now looks like this, and it is now sheer coincidence that the history contains something similar:

one
two_edit
three

I edit the trunk (rev6) to look as follows:

one
two
three
four

I merge all changes from the trunk into branches/b1 (rev7). branches/b1 now correctly looks like:

one
two_edit
three
four

</Edit – Solution>

<Edit>

How it should work

The following is the desired behavior, and works correctly if the italicized step is performed as follows:

First I created an empty repository with folders tags, trunk, branch. In trunk I created a file file.txt with the content (rev1):

one
two
three

Then edit the file to

one
two_edit
three

And checked in (rev2). Then I selected rev2 in the log and picked revert changes from this revision and checked in (rev3). The file now looks like this again:

one
two
three

I then created a branch of trunk from rev2 to branches\b1 (rev4). In branches\b1 the file looks like this:

one
two_edit
three

I then merge rev3 from trunk into branches\b1 (rev5), the branch now looks like this:

one
two
three

I edit branch 3 (rev6) as if I were branching at this point. It is now sheer coincidence that the history contains something similar:

one
two_edit
three

I edit the trunk (rev7) to look as follows:

one
two
three
four

I merge all changes from the trunk into branches/b1 (rev8). branches/b1 now looks like:

one
two_edit
three
four

How it does work

The following is the actual behaviour; it works incorrectly if the italicized step is performed, which is necessary because of the complexity of the retroactive branch. The error is in the second line of the final step.

First I created an empty repository with folders tags, trunk, branch. In trunk I created a file file.txt with the content (rev1):

one
two
three

Then edit the file to

one
two_edit
three

And checked in (rev2). Then I selected rev2 in the log and picked revert changes from this revision and checked in (rev3). The file now looks like this again:

one
two
three

I then created a branch of trunk from rev2 to branches\b1 (rev4). In branches\b1 the file looks like this:

one
two_edit
three

I then merge rev3 from trunk into branches\b1 (rev5), the branch now looks like this:

one
two
three

In branches\b1 I selected rev5 in the log and picked revert changes from this revision and checked in (rev6). The file now looks like this again:

one
two_edit
three

I edit the trunk (rev7) to look as follows:

one
two
three
four

I merge all changes from the trunk into branches/b1 (rev8). branches/b1 now looks like:

one
two
three
four

</Edit>

Answer 1

The key is probably to record this patch (the inverse squared, or the product of the original modifications) in such a way that subversion is ignorant of the operation performed to create it.

I think you are talking about trying to block merge tracking, a.k.a. mergeinfo, from being recorded in the branch. I think you can do this using svn diff or svn merge --ignore-ancestry. Read the SVN Redbook on Advanced Merging, specifically Merges Without Mergeinfo and Noticing or Ignoring Ancestry.

Rather than branching from rev2, it might be easier to create a branch off the trunk from rev3, and then apply/capture the changes from rev1 to rev2 in the branch of rev3 using svn diff or svn merge --ignore-ancestry.

Alternatively, you could look at svn merge --record-only to fake a merge in order to block a rev from future merges, i.e. convince the branch or trunk that you already merged the undo change so it doesn’t get applied again.