On Fri, May 4, 2018 at 1:21 AM, Evan J <maps.this.address_at_gmail.com> wrote:
> Here is a scenario I am working with:
Hi Evan,
I noticed that nobody answered your question yet. I think that's
partly because your explanation is a bit confusing, so it's not easy
to follow along. I'll give it a go, see below ...
> I have a trunk with several revisions that are committed after the branch is
> created. Let's assume the trunk is currently at revision 140. And let's
> assume the branch was created from the trunk from revision 100, and
> currently the HEAD revision in that branch is 136.
That's confusing. There is only one HEAD revision for the entire
repository. If the latest commit was 140 (doesn't matter if it was in
trunk or in a branch), the HEAD revision of the repository is 140.
So, I assume you mean that the latest commit to the branch was 136 (or
put otherwise: the "last changed revision" of the branch is 136).
> What do I need to do to merge up to a specific revision from the branch,
> e.g. 120 (not the latest -- 136), into the main trunk that contains an up-to
> some older revision, say, 117 -- not the latest (the three revisions from
> 118 - 120 are assumed to be commits from the branch)? What I am basically
> planning to do is to update the trunk to a specific revision from the
> branch, and discard all the other changes that have been made to the trunk.
Let me get this straight: you want to do two things to trunk:
1) Discard / undo some commits from its own history
2) Merge some commits from branch to trunk (not the entire branch
history, but part of it)
Right?
> Does reverting the local copy of trunk to revision 117 and merging it to
> that specific branch revision (in this case, 120) work, or should I revert
> the trunk to pre-branch creation (in this case, 100), then merge the branch
> (revision 120) into the trunk?
Reverting a local copy to an older version of trunk won't help. I
assume you're using "reverting" in a semantic sense, i.e. rolling
trunk back to some previous point in history. Because in svn jargon,
the 'revert' command is used for discarding uncommitted local changes
(not for going back to a previous point in history).
There are a couple of options I think, but it's important to
understand that you can't really go back in time and pretend that
anything after 117 didn't happen on trunk. So if you want to "undo"
the commits on trunk made after 117, you have to create another commit
(say 141) to trunk that effectively undoes those changes after 117.
That's where the reverse merge comes in. See this chapter in the svn
book:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo
Basically, in a clean working copy from trunk_at_HEAD, you'd do:
svn merge -r HEAD:117 $URL/trunk .
# verify the contents of your working copy ...
svn commit
(Note the "reverse revision range" given to the merge command. That
effectively instructs svn to apply the "inverse" of that range of
revisions.)
Then to bring over the relevant commits from your branch to the
trunk-rolled-back-to-117, again in your clean working copy of trunk
(can be the same working copy, after you did the previous thing):
# Either do some cherrypick merges, picking out specific commits
svn merge -c 118,119,120 $URL/branches/branch .
# or, equivalently: svn merge -r 117:120 $URL/branches/branch .
# Verify the result
svn commit
Or:
# Perform a '2-URL' merge:
svn merge $URL/branches/branch_at_117 $URL/branches/branch_at_120 .
# Verify the result
svn commit
To learn a bit more about these merging techniques, take a look at the
output of 'svn help merge'. The two techniques above are usages 2.
(cherry-pick merge) and 3. (2-URL merge) of the 'svn merge' command.
HTH
--
Johan
Received on 2018-05-18 09:43:43 CEST