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

Re: Understanding move & merge

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-01-17 03:55:35 CET

Lele Gaifax <lele@seldati.it> writes:

> Hi all,
> I'm trying to understand the mechanism of merge when coupled with
> renames and deletes. It seems that the merge command completely
> ignores the rename operation, giving unexpected results.
> To test the case, I supposed to have to track an external sw, the
> "third-party" model:
> /vendor
> /current
> /product-1.0
> /product-1.1
> /mine
> /current
> /enh-product-1.0
> /enh-product-1.1
> PoW A: for whatever reason, I decided to rename the source "main.c"
> to "product-main.c".
> Where "product-1.2" gets released, I do the merge: argh! they modified
> "main.c", and I obtain:
> $ svn merge svn://.../vendor/product-1.1 svn://.../vendor/product-1.2
> svn: Can't find an entry
> svn: svn_wc_merge: `main.c' not under revision control

This isn't unexpected, this is correct.

You're asking 'svn merge' to compare two trees and then apply those
differences to your working copy. So one of the differences is that
some text changed in 'main.c'... but your working copy *has* no file
by that name. So just like when you apply a patch, that 'hunk' fails.

There's no good solution to this problem: the diff just doesn't apply
cleanly. There's no way Subversion can "guess" that some file in your
directory used to be named 'main.c'... at least not without some huge
brute-force search heuristic!

> PoW B: this time, the *vendor* renamed that file, while my version
> still has "main.c", a customized version of 1.1
> At merge time, *my* changes to main.c aren't honored:
> $ svn merge svn://.../vendor/product-1.1 svn://.../vendor/product-1.2
> A product-main.c
> D main.c
> At this time, my changes are silently gone.

Sure, once again, it's applying a patch to your working copy. The
patch is to rename main.c->product-main.c, because that's exactly the
difference between the two vendor trees. No surprises here at all.

What were you expecting? :-)

Perhaps you're confused about how svn does renames. Remember that a
rename is an 'svn rm' + 'svn cp', and an 'svn cp' is just an 'svn add'
which remembers copy-history. So that's why you're seeing the 'A'
and 'D' in your merge there. It's a rename.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 17 03:58:39 2003

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

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