[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge --dry-run URL1 URL2 <-> merge --dry-run URL2 URL1 ??

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-11-04 00:15:19 CET

On Nov 3, 2005, at 19:08, Gerdes, Christian (EXTERN: PLUSSY) wrote:

> i just found something that i cannot explain:
> I tried the following:
> svn merge --dry-run http://subversion-repos/tags/tag_01
> http://subversion-repos/tags/tag_02
> This gives some changes between these tags.
> But if i try to switch the urls and do this
> svn merge --dry-run http://subversion-repos/tags/tag_02
> http://subversion-repos/tags/tag_01
> i expected the same number of changes just in another direction (added
> should be deleted and vice versa)
> BUT in one case i got in one direction 36 changes and in the other 46
> changes.
> Anyone can hand me a light here?
> What is the cause ot this strange behavior?

I don't understand everyone's fascination with the --dry-run option.
My coworkers insist on using it all the time too. It causes all sorts
of weirdness that does not happen if you just run the merge, and it's
a waste of time anyway. If you don't like the merge, you can always
svn revert it. So forget the dry run and just do the merge.

Besides, there's no reason there has to be the same number of steps
to go from A to B as there are going from B to A. Example:

Steps to go from A to B:

- Create a new directory
- Copy a file into the new directory from another directory in the
- Copy another file into the new directory from somewhere else in the

Steps to go from B to A:

- Delete the new directory

> And why is it needed to be in the path of a working-copy in this case?

You always need a working copy where the result of the merge is
applied. You always need to manually test that your merge was
successful before you commit it to the repository, and the place you
do that is your working copy.

So probably the important question is: what is your working copy of?
Is it a working copy of tag_01? of tag_02? of the branch from which
one or both of those tags was made? trunk? Wherever your working copy
is from, only one of the above merges makes sense. Either the working
copy does not have the changes that occurred between tag_01 and
tag_02, in which case you might want to apply a merge from tag_01 to
tag_02, or the working copy already has those changes and you want to
remove them, in which case you want to apply a merge from tag_02 to
tag_01. But I don't think there is a case where both merges make
sense on the same working copy.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 4 00:17:22 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.