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:41:27 2006