Understood. You refer to this as a "reverse merge" because I'm going trunk to
branch, rather then branch to trunk?
Thanks.
Quoting Ryan Schmidt <subversion-2006Q1@ryandesign.com>:
> On Jan 4, 2006, at 23:53, Rob Brandt wrote:
>
>> I am (still) new to svn and am doing a merge between branches for the first
>> time. I am using TortioseSVN as a client. I also reviewed the thread from
>> today "Merge from trunk head". I am doing something similar, but it's not
>> working out.
>
> Understanding merging can be confusing at first, and once you do
> understand it, it can be hard to explain to someone else, which is
> why sometimes even reading the documentation doesn't help. But here's
> an explanation I've used before, which I've been told was helpful:
>
> Think of "svn merge" like this. It operates on three places, A, B and
> C. It makes a list of steps to transform A into B (or: transform
> "from" A "to" B, to match it up with TortoiseSVN's dialog), and then
> performs that list of steps on C. C is a working copy, and A and B
> are often different revisions of a URL in the repository, or two
> different URLs in the repository (two tag directories, for instance).
>
>
>> I have a project in /repository/trunk that I previously branched to
>> repository/branches/sub1/trunk at rev. 7 and made cosmetic
>> revisions to, ending
>> at revision 42. At that time, functional changes to the project that would
>> apply to both branches needed to be made, and I made those on
>> repository/trunk
>> ending at rev. 54. I now want to merge the changes there to sub1/
>> trunk so that
>> the functional changes are incorporated, and (or course) retain the
>> cosmetic
>> changes already there. It is my intention to merge into a working
>> copy, and
>> then once I review it commit the sub1/ changes, as the Tortoise manual
>> suggests.
>>
>> Using the merge function in Tortoise, I specify From as the URL to
>> repository/trunk, revision 54. For "to:", I check the "Use From
>> URL" box, and
>> specify Revision 42. The dialog does show that it is pointing to
>> the correct
>> working copy path.
>
> So when you execute this merge, you are instructing Subversion to do
> the following: Make a list of steps to transform revision 54 of
> repository/trunk into revision 42 of repository/trunk (a list of
> steps that basically undoes your functional changes), and perform
> those steps on the working copy of sub1/trunk. But those changes had
> never been made on sub1/trunk in the first place, so the merge
> doesn't make sense. You should be listing the revisions in the other
> order: from 42 to 54.
>
>
>> When I do a "dry run", all the files that I anticipate need changes
>> are listed
>> as "updated" except for 3 files listed as "missing". First
>> question: It seems
>> like (to me) this is a change from "nothing's here" to "something's
>> here" and
>> the new file should be "updated" as well, but the message suggests
>> otherwise.
>> What do I need to do to get the new file into the working copy of
>> my branch?
>> Other than that, the dry run looks good. However when I actually
>> do the merge,
>> all those listed files are not, in fact, updated, even though the
>> same list of
>> "updated" files roll by. Second question: Why?
>
> Presumably, between revisions 42 and 54 of repository/trunk, you
> added those three files. A merge in the correct direction would tell
> Subversion to create those three files in the working copy. But since
> you specified that the merge should go in the other direction,
> you're effectively asking Subversion to delete those three files in
> the working copy. But they don't exist in the working copy, hence
> the message that they're missing.
>
> I've never found the "dry run" option particularly useful. When
> merging changes into a working copy, it's considered best to then
> commit those changes by themselves, so that the log message can read
> something like "Merged revisions 42 to 54 of repository/trunk into
> sub1/trunk," and the commit contains the merge, the whole merge and
> nothing but the merge, if you will. So it makes sense to have no
> other pending changes in your working copy (or at least the relevant
> subset of your working copy) before beginning the merge. This means
> that, if you merge and decide before committing it that you don't
> like it, you can easily "svn revert -R ." to undo it. And in the
> generally likely event that the merge was good and you want to commit
> it, it'll be ready for you to do that. There are even some cases
> where a dry run will report errors that a real merge will not
> encounter, so I prefer simply never to use that option.
>
>
> By the way, the way you were trying to do the merge is what's often
> called a "reverse merge" and is what you'd use to back out changes
> inadvertently committed to the repository, or changes later found to
> be inaccurate. If, say, I commit some changes in revision 90 that are
> supposed to fix a bug, but later I find that the fix was totally
> wrong and I just want to undo it and start over on the fix, I can
> back it out by doing a reverse merge: from revision 90 to 89 (think:
> "make a list of steps to transform revision 90 back into revision
> 89...").
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 5 01:46:36 2006