You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lele Gaifax <le...@seldati.it> on 2003/01/17 01:07:15 UTC
Understanding move & merge
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
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.
Am I missing something, or the move operation, on either sides,
doesn't fit merge capabilities?
Thanx for this great software, and in advance for any hint :)
bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Karl Fogel kf...@newton.ch.collab.net.
Greg Ward gward@mems-exchange.org writes:
* I can view the log of old.c up to the point of the rename with cvs
log old.c, at any point in the future. The name old.c lives on
forever to CVS, but the file no longer exists. Apparently
Subversion will never be able to do this, because it requires
guessing the URL for old.c.
Well, you have to know its name in CVS too, as your example states
above :-). But Subversion can trace from the new file through to the
old one, too (modulo bugs in the current code)
* I can use cvs diff to get diffs from before the rename, or even
across the rename. Subversion cannot do this, but I gather this
is a bug that will be fixed.
Check.
* Since I can diff before/across/after the rename, I *assume*
merging (cvs up -j) works, but I haven't tried it and I very
rarely merge with CVS. But I know it doesn't work with Subversion.
See Kevin's earlier mail. This is sometimes a bug, and sometimes a
more fundamental problem, in Subversion.
* If I check out my project using a pre-rename tag, I will get
old.c and not new.c. If I check out my project using a post-rename
tag, I will get new.c and not old.c. (Of course, this only holds
if I remember to remove tags from new.c, which is why that's an
important step.)
Yes. That's true in Subversion too; except that you don't have to
remember to remove tags.
When I say file rename currently works better with CVS than it does with
Subversion, I'm really talking about how things look after the rename
has been done. Once the complicated, error-prone, non-atomic, direct
repository fiddling is done, file renames Just Work with CVS. That's
not currently the case with Subversion.
Granted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Greg Ward gw...@mems-exchange.org.
On 20 January 2003, Lele Gaifax said:
As it stands, given the bugs Karl mentioned, they have the same
behaviour from the user point of view, but at least with SVN it's not
a manual tricky hack inside the repository, and neither a dark
combination of command line options.
To clarify, here's how I rename a file with CVS. Say I'm in ~/project,
the CVS repository dir is $CVSROOT/project, and I want to rename 'old.c'
to 'new.c'.
cd $CVSROOT/project
cp -p old.c,v new.c,v
cd ~/project
cvs up
for tag in mumble ; do
cvs tag -d $tag new.c
done
rm old.c ; cvs rm old.c
cvs ci -f -mRename old.c to new.c. old.c new.c
mumble is some shell magic that gets the list of all tags present in
new.c. This is the step I often forget, but it's important!
Advantages:
* I can view the log of old.c up to the point of the rename with cvs
log old.c, at any point in the future. The name old.c lives on
forever to CVS, but the file no longer exists. Apparently
Subversion will never be able to do this, because it requires
guessing the URL for old.c.
* When viewing the history of new.c, I will see its entire history up
to, including, and after the rename. Subversion can do this.
* I can use cvs diff to get diffs from before the rename, or even
across the rename. Subversion cannot do this, but I gather this
is a bug that will be fixed.
* Since I can diff before/across/after the rename, I *assume*
merging (cvs up -j) works, but I haven't tried it and I very
rarely merge with CVS. But I know it doesn't work with Subversion.
* If I check out my project using a pre-rename tag, I will get
old.c and not new.c. If I check out my project using a post-rename
tag, I will get new.c and not old.c. (Of course, this only holds
if I remember to remove tags from new.c, which is why that's an
important step.)
* I understand exactly what's going on in the above snippet, and
so do lots of other heavy CVS users out there
Disadvantages:
* complicated, error-prone, easy to forget steps
* not atomic: if anyone checks in changes to foo.c while I'm doing
my rename, one of us will get ticked off at the other.
* requires direct repository access
When I say file rename currently works better with CVS than it does with
Subversion, I'm really talking about how things look after the rename
has been done. Once the complicated, error-prone, non-atomic, direct
repository fiddling is done, file renames Just Work with CVS. That's
not currently the case with Subversion.
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
David Waite <ma...@akuma.org> writes:
> > users *get* those changes when they update. If you move an RCS
> > file, then this completely breaks all existing CVS
> >working copies. Don't tell me that's better than Subversion. :-)
> >
> Even worse, with moving RCS files you change the location of a file
> for past revisions. This more often than not will leave earlier
> revisions in CVS unbuildable.
Carful, though -- he didn't say move, he said copy :-). That does
work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Karl Fogel kf...@newton.ch.collab.net.
David Waite mass@akuma.org writes:
users *get* those changes when they update. If you move an RCS
file, then this completely breaks all existing CVS
working copies. Don't tell me that's better than Subversion. :-)
Even worse, with moving RCS files you change the location of a file
for past revisions. This more often than not will leave earlier
revisions in CVS unbuildable.
Carful, though -- he didn't say move, he said copy :-). That does
work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by David Waite ma...@akuma.org.
Ben Collins-Sussman wrote:
And when somebody does an 'svn mv' or 'svn cp' of a file, the other
users *get* those changes when they update.
If you move an RCS file, then this completely breaks all existing CVS
working copies. Don't tell me that's better than Subversion. :-)
Even worse, with moving RCS files you change the location of a file for
past revisions. This more often than not will leave earlier revisions in
CVS unbuildable.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by David Waite <ma...@akuma.org>.
Ben Collins-Sussman wrote:
>And when somebody does an 'svn mv' or 'svn cp' of a file, the other
>users *get* those changes when they update.
>
>If you move an RCS file, then this completely breaks all existing CVS
>working copies. Don't tell me that's better than Subversion. :-)
>
>
Even worse, with moving RCS files you change the location of a file for
past revisions. This more often than not will leave earlier revisions in
CVS unbuildable.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Ben Collins-Sussman su...@collab.net.
Lele Gaifax lele@seldati.it writes:
On Mon, 20 Jan 2003 10:51:07 -0500, Greg Ward gward@mems-exchange.org said:
GW I've been using Subversion for less than a week, and it's
GW already clear to me that file renaming has to be distinct from
GW copy+delete. As things stand, file renaming works *better*
GW with CVS than with Subversion.
Well, those are *huge* words to say :)
As it stands, given the bugs Karl mentioned, they have the same
behaviour from the user point of view, but at least with SVN it's not
a manual tricky hack inside the repository, and neither a dark
combination of command line options.
And when somebody does an 'svn mv' or 'svn cp' of a file, the other
users *get* those changes when they update.
If you move an RCS file, then this completely breaks all existing CVS
working copies. Don't tell me that's better than Subversion. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Ben Collins-Sussman <su...@collab.net>.
Lele Gaifax <le...@seldati.it> writes:
> >>>>> On Mon, 20 Jan 2003 10:51:07 -0500, Greg Ward <gw...@mems-exchange.org> said:
>
> GW> I've been using Subversion for less than a week, and it's
> GW> already clear to me that file renaming has to be distinct from
> GW> copy+delete. As things stand, file renaming works *better*
> GW> with CVS than with Subversion.
>
> Well, those are *huge* words to say :)
>
> As it stands, given the "bugs" Karl mentioned, they have the same
> behaviour from the user point of view, but at least with SVN it's not
> a manual tricky hack inside the repository, and neither a dark
> combination of command line options.
And when somebody does an 'svn mv' or 'svn cp' of a file, the other
users *get* those changes when they update.
If you move an RCS file, then this completely breaks all existing CVS
working copies. Don't tell me that's better than Subversion. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Karl Fogel kf...@newton.ch.collab.net.
Kevin Pilch-Bisson kevin@pilch-bisson.net writes:
Now I probably do want the changes to be applied. As Kazinator
pointed out on IRC, copy is to create a new, but related item in the
fs, whereas move/rename should not change the object, just it's
location as far as operations like merge are concerned.
Ooooh, nice example. Yes, you have a point. I think we'll remember
this example when we get around to fixing renames... but if you find
an appropriate issue to add this note to, that would be great.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Kevin Pilch-Bisson ke...@pilch-bisson.net.
On Mon, Jan 20, 2003 at 12:18:36PM -0600, Karl Fogel wrote:
Lele Gaifax lele@seldati.it writes:
KF It turns out that there are some complexities involved in
KF implementing true renames that are actually quite difficult to
KF deal with, so we've simply postponed dealing with it till
KF after 1.0.
Are those documented somewhere?
Yes, in the code and in some issues, I believe.
KF In Subversion there are still a few bugs about certain
KF commands not following copy history correctly
Uhm, I missed this! Am I wrong understanding this as it's not the
copy+delete implementation that prevents this to happen, but it's a
bug in the merge command?
Well, the bugs are about following history, so they'd be present
whether the history was a copy or an atomic rename. (The nature
of the historical traces is the same -- there's an ancestor, and then
a new thing based on that ancestor.)
In other words, no, it's not the copy+delete implementation.
Actually it could be. Consider the following.
svn cp http://server/trunk http://server/branch
svn co http://server/branch
cd branch
svn cp template.c foo.c
svn ci
edit foo.c
svn ci
cd ../trunk
edit template.c
svn ci
Now I want to merge the changes back and forth. I probably don't want to
merge both sets of changes together, because this was a copy.
However, if I do the exact same thing, but with a mv instead of cp, I DO want
to merge the changes in.
svn cp http://server/trunk http://server/branch
svn co http://server/branch
cd branch
svn mv template.c foo.c
svn ci
edit foo.c
svn ci
cd ../trunk
edit template.c
svn ci
Now I probably do want the changes to be applied. As Kazinator pointed out on
IRC, copy is to create a new, but related item in the fs, whereas move/rename
should not change the object, just it's location as far as operations like
merge are concerned.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
Historically speaking, the presences of wheels in Unix
has never precluded their reinvention. - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Understanding move merge
Posted by Karl Fogel kf...@newton.ch.collab.net.
Lele Gaifax lele@seldati.it writes:
KF It turns out that there are some complexities involved in
KF implementing true renames that are actually quite difficult to
KF deal with, so we've simply postponed dealing with it till
KF after 1.0.
Are those documented somewhere?
Yes, in the code and in some issues, I believe.
KF In Subversion there are still a few bugs about certain
KF commands not following copy history correctly
Uhm, I missed this! Am I wrong understanding this as it's not the
copy+delete implementation that prevents this to happen, but it's a
bug in the merge command?
Well, the bugs are about following history, so they'd be present
whether the history was a copy or an atomic rename. (The nature
of the historical traces is the same -- there's an ancestor, and then
a new thing based on that ancestor.)
In other words, no, it's not the copy+delete implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Lele Gaifax <le...@seldati.it> writes:
> KF> It turns out that there are some complexities involved in
> KF> implementing true renames that are actually quite difficult to
> KF> deal with, so we've simply postponed dealing with it till
> KF> after 1.0.
>
> Are those documented somewhere?
Yes, in the code and in some issues, I believe.
> KF> In Subversion there are still a few bugs about certain
> KF> commands not following copy history correctly
>
> Uhm, I missed this! Am I wrong understanding this as "it's not the
> copy+delete implementation that prevents this to happen, but it's a
> bug in the merge command"?
Well, the bugs are about following history, so they'd be present
whether the history was a "copy" or an atomic "rename". (The nature
of the historical traces is the same -- there's an ancestor, and then
a new thing based on that ancestor.)
In other words, no, it's not the copy+delete implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Lele Gaifax <le...@seldati.it>.
>>>>> On Mon, 20 Jan 2003 10:51:07 -0500, Greg Ward <gw...@mems-exchange.org> said:
GW> I've been using Subversion for less than a week, and it's
GW> already clear to me that file renaming has to be distinct from
GW> copy+delete. As things stand, file renaming works *better*
GW> with CVS than with Subversion.
Well, those are *huge* words to say :)
As it stands, given the "bugs" Karl mentioned, they have the same
behaviour from the user point of view, but at least with SVN it's not
a manual tricky hack inside the repository, and neither a dark
combination of command line options.
>>>>> On 20 Jan 2003 09:44:10 -0600, Karl Fogel <kf...@newton.ch.collab.net> said:
KF> It turns out that there are some complexities involved in
KF> implementing true renames that are actually quite difficult to
KF> deal with, so we've simply postponed dealing with it till
KF> after 1.0.
Are those documented somewhere?
KF> In Subversion there are still a few bugs about certain
KF> commands not following copy history correctly
Uhm, I missed this! Am I wrong understanding this as "it's not the
copy+delete implementation that prevents this to happen, but it's a
bug in the merge command"?
thanx&bye,
lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Greg Ward gw...@mems-exchange.org.
On 20 January 2003, Karl Fogel said:
Uh, if you consider that proviso liveable, you probably don't need
Subversion in the first place :-).
Well, I've been living with CVS and the nasty file-rename hack I
described for 3-4 years now, so I guess it's *liveable* (as long as you
have direct repository access!). But it sure as heck isn't very
likeable.
I think everyone agrees that true rename would be preferable than
copy+delete. It turns out that there are some complexities involved
in implementing true renames that are actually quite difficult to deal
with, so we've simply postponed dealing with it till after 1.0.
That's very good news. I wasn't really clear on whether you guys
thought this was important or not.
I'm not sure in what sense you mean CVS's support is better, even
without that proviso. As far as I can tell, the method you describe
in CVS offers exactly the same support Subversion does (oh, but with
the proviso that in Subversion there are still a few bugs about
certain commands not following copy history correctly -- but note that
the copy history *is* recorded in the repository, so these are quite
fixeable and are scheduled for pre-1.0).
I'm pretty sure the only reason that CVS+nasty rename hack is better
than Subversion w/ current limitations is due to the bugs you
described. As long as these bugs are shallow, fixable, and eventually
fixed, Subversion will have the edge. When Subversion recognizes rename
as an atomic operation, Subversion will kick ass.
Keep in mind, too, that I have a much better understanding of CVS, flaws
and all, than I do of Subversion. I know how to get what I want out of
CVS, and I know full well what it can't do. I really really *want*
Subversion to come along and magically do everything that CVS does, and
everything that CVS can't do, and do it all better. Unrealistic
expectations? Sure. But the more people you convince to take the
plunge, the more of this you're going to hear (at least, until
Subversion meets those high expectations).
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Greg Ward <gw...@mems-exchange.org>.
On 20 January 2003, Karl Fogel said:
> Uh, if you consider that "proviso" liveable, you probably don't need
> Subversion in the first place :-).
Well, I've been living with CVS and the nasty file-rename hack I
described for 3-4 years now, so I guess it's *liveable* (as long as you
have direct repository access!). But it sure as heck isn't very
likeable.
> I think everyone agrees that true rename would be preferable than
> copy+delete. It turns out that there are some complexities involved
> in implementing true renames that are actually quite difficult to deal
> with, so we've simply postponed dealing with it till after 1.0.
That's very good news. I wasn't really clear on whether you guys
thought this was important or not.
> I'm not sure in what sense you mean CVS's support is "better", even
> without that proviso. As far as I can tell, the method you describe
> in CVS offers exactly the same support Subversion does (oh, but with
> the "proviso" that in Subversion there are still a few bugs about
> certain commands not following copy history correctly -- but note that
> the copy history *is* recorded in the repository, so these are quite
> fixeable and are scheduled for pre-1.0).
I'm pretty sure the only reason that "CVS+nasty rename hack" is better
than "Subversion w/ current limitations" is due to the bugs you
described. As long as these bugs are shallow, fixable, and eventually
fixed, Subversion will have the edge. When Subversion recognizes rename
as an atomic operation, Subversion will kick ass.
Keep in mind, too, that I have a much better understanding of CVS, flaws
and all, than I do of Subversion. I know how to get what I want out of
CVS, and I know full well what it can't do. I really really *want*
Subversion to come along and magically do everything that CVS does, and
everything that CVS can't do, and do it all better. Unrealistic
expectations? Sure. But the more people you convince to take the
plunge, the more of this you're going to hear (at least, until
Subversion meets those high expectations).
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Karl Fogel kf...@newton.ch.collab.net.
Greg Ward gward@mems-exchange.org writes:
I've been using Subversion for less than a week, and it's already clear
to me that file renaming has to be distinct from copy+delete. As things
stand, file renaming works *better* with CVS than with Subversion.
(With the proviso that you have to go into the CVS repository and copy
the ,v file in order to preserve the history. And delete all tags
from the copied ,v file -- which is the step I always forget!)
Uh, if you consider that proviso liveable, you probably don't need
Subversion in the first place :-).
I think everyone agrees that true rename would be preferable than
copy+delete. It turns out that there are some complexities involved
in implementing true renames that are actually quite difficult to deal
with, so we've simply postponed dealing with it till after 1.0.
I'm not sure in what sense you mean CVS's support is better, even
without that proviso. As far as I can tell, the method you describe
in CVS offers exactly the same support Subversion does (oh, but with
the proviso that in Subversion there are still a few bugs about
certain commands not following copy history correctly -- but note that
the copy history *is* recorded in the repository, so these are quite
fixeable and are scheduled for pre-1.0).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Ward <gw...@mems-exchange.org> writes:
> I've been using Subversion for less than a week, and it's already clear
> to me that file renaming has to be distinct from copy+delete. As things
> stand, file renaming works *better* with CVS than with Subversion.
> (With the proviso that you have to go into the CVS repository and copy
> the ",v" file in order to preserve the history. And delete all tags
> from the copied ",v" file -- which is the step I always forget!)
Uh, if you consider that "proviso" liveable, you probably don't need
Subversion in the first place :-).
I think everyone agrees that true rename would be preferable than
copy+delete. It turns out that there are some complexities involved
in implementing true renames that are actually quite difficult to deal
with, so we've simply postponed dealing with it till after 1.0.
I'm not sure in what sense you mean CVS's support is "better", even
without that proviso. As far as I can tell, the method you describe
in CVS offers exactly the same support Subversion does (oh, but with
the "proviso" that in Subversion there are still a few bugs about
certain commands not following copy history correctly -- but note that
the copy history *is* recorded in the repository, so these are quite
fixeable and are scheduled for pre-1.0).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Lele Gaifax le...@seldati.it.
On Mon, 20 Jan 2003 10:51:07 -0500, Greg Ward gward@mems-exchange.org said:
GW I've been using Subversion for less than a week, and it's
GW already clear to me that file renaming has to be distinct from
GW copy+delete. As things stand, file renaming works *better*
GW with CVS than with Subversion.
Well, those are *huge* words to say :)
As it stands, given the bugs Karl mentioned, they have the same
behaviour from the user point of view, but at least with SVN it's not
a manual tricky hack inside the repository, and neither a dark
combination of command line options.
On 20 Jan 2003 09:44:10 -0600, Karl Fogel kfogel@newton.ch.collab.net said:
KF It turns out that there are some complexities involved in
KF implementing true renames that are actually quite difficult to
KF deal with, so we've simply postponed dealing with it till
KF after 1.0.
Are those documented somewhere?
KF In Subversion there are still a few bugs about certain
KF commands not following copy history correctly
Uhm, I missed this! Am I wrong understanding this as it's not the
copy+delete implementation that prevents this to happen, but it's a
bug in the merge command?
thanxbye,
lele.
--
nickname: Lele Gaifax | Quando vivr� di quello che ho pensato ieri
real: Emanuele Gaifas | comincer� ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Greg Ward <gw...@mems-exchange.org>.
On 17 January 2003, Branko ??ibej said:
> This example is exactly why I keep saying that we should make "svn mv"
> an atomic operation that *does not* generate a new node in the
> filesystem. Then moves would become pure directory changes, and "svn
> merge" has to resolve those before merging the files themselves, like
> Philip said -- and so it would know before even starting the file merge
> that it found a rename.
I've been using Subversion for less than a week, and it's already clear
to me that file renaming has to be distinct from copy+delete. As things
stand, file renaming works *better* with CVS than with Subversion.
(With the proviso that you have to go into the CVS repository and copy
the ",v" file in order to preserve the history. And delete all tags
from the copied ",v" file -- which is the step I always forget!)
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Greg Ward gw...@mems-exchange.org.
On 17 January 2003, Branko ??ibej said:
This example is exactly why I keep saying that we should make svn mv
an atomic operation that *does not* generate a new node in the
filesystem. Then moves would become pure directory changes, and svn
merge has to resolve those before merging the files themselves, like
Philip said -- and so it would know before even starting the file merge
that it found a rename.
I've been using Subversion for less than a week, and it's already clear
to me that file renaming has to be distinct from copy+delete. As things
stand, file renaming works *better* with CVS than with Subversion.
(With the proviso that you have to go into the CVS repository and copy
the ,v file in order to preserve the history. And delete all tags
from the copied ,v file -- which is the step I always forget!)
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Understanding move merge
Posted by Bill Tutt ra...@lyra.org.
From: Greg Ward [mailto:gward@mems-exchange.org]
On 21 January 2003, Branko ??ibej said:
Yes. Renaming a node should not affect its history.
But I *like* to see a log entry saying Renamed from foo to
bar or Moved from ../foo to here, even if no lines of
content changed in that revision.
The effect of a
cp+rm is to create a new branch in the node's history (and
remove an
cp+old
one); that is obviously wrong, because, under our model, a
rename does
not constitute a modification of the node, only a
modification of its
(old and new) parent directory. In simple terms, after an
svn mv in
a clean working copy, svn st should show one or two modified
directories, but no modified files.
Ahh, I understand your rationale for why a rename should not
affect the history of the renamed object. I think you're
putting purity ahead of practicality here. Renaming a file
is an important event in its history, and IMHO worthy of logging.
No he's not acutally. Logging the action is important as well. Renames
should be an atomic action, and they should be logged as such. No rocket
science there. The really annoying part with renames is in the WC half
of the equation. The other half is making sure both parts of a move get
committed at once, and branch merge file rename handling that's
efficient on the WC.
(Of course, the user would want to know that the file was moved, so
svn st should show something for usability's sake; but
what it shows
should not be a modified state but a renamed state.
That means yet
another status letter, but perhaps not.)
And here, you're putting practicality ahead of purity!
UIs are always fickle. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Greg Ward gw...@mems-exchange.org.
On 21 January 2003, Branko ??ibej said:
Yes. Renaming a node should not affect its history.
But I *like* to see a log entry saying Renamed from foo to bar or
Moved from ../foo to here, even if no lines of content changed in that
revision.
The effect of a
cp+rm is to create a new branch in the node's history (and remove an old
one); that is obviously wrong, because, under our model, a rename does
not constitute a modification of the node, only a modification of its
(old and new) parent directory. In simple terms, after an svn mv in a
clean working copy, svn st should show one or two modified
directories, but no modified files.
Ahh, I understand your rationale for why a rename should not affect the
history of the renamed object. I think you're putting purity ahead of
practicality here. Renaming a file is an important event in its
history, and IMHO worthy of logging.
(Of course, the user would want to know that the file was moved, so svn
st should show something for usability's sake; but what it shows should
not be a modified state but a renamed state. That means yet another
status letter, but perhaps not.)
And here, you're putting practicality ahead of purity!
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Philip Martin ph...@codematters.co.uk.
Branko Äibej brane@xbc.nu writes:
Then it would be distinct from copy :) Yes, that does look more like
what we want.
Hey, a convert! Welcome to the world of twisty little branches, all
alike. :-)
I've never been a non-believer, I always wanted it to work, I just
didn't see how it worked :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Branko Čibej br...@xbc.nu.
Philip Martin wrote:
Philip Martin philip@codematters.co.uk writes:
So in the move+modify case, where a new node needs to be created, I
suppose it would look like
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.1.5)
Perhaps baz (f.0.5)?
Exactly! The move does not create a new branch.
qux (q.0.4)
Will this be a problem? Does it mean that the client will be unable
to distinguish copy+delete from move+modify?
Then it would be distinct from copy :) Yes, that does look more like
what we want.
Hey, a convert! Welcome to the world of twisty little branches, all
alike. :-)
--
Brane Čibej brane@xbc.nu http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Philip Martin ph...@codematters.co.uk.
Philip Martin philip@codematters.co.uk writes:
I'll try to illustrate the point. Imagine you have two directories A
and B, that are children of the root. A contains the files foo and
bar, B contains qux. I'll tag each node with its node revision number:
/ (0.0.4)
A/ (a.0.3)
foo (f.0.2)
bar (r.0.3)
B/ (b.0.4)
qux (q.0.4)
Now see what happens when we svn rename /A/foo /B/baz:
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.0.2)
qux (q.0.4)
We created new revisions of A, B and / (because of bubble-up), and
the pointer to f.0.2 is now called baz rather than foo, but the
node itself did not change, and its immediate ancestor is still the
same, although you can't guess that ancestor's name from the current one
(note that the repository does know that name already). So we don't need
any new flags in the repository at all.
So in the move+modify case, where a new node needs to be created, I
suppose it would look like
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.1.5)
Perhaps baz (f.0.5)?
qux (q.0.4)
Will this be a problem? Does it mean that the client will be unable
to distinguish copy+delete from move+modify?
Then it would be distinct from copy :) Yes, that does look more like
what we want.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Philip Martin ph...@codematters.co.uk.
Branko Äibej brane@xbc.nu writes:
The elimination of a new node is not always possible,
consider
$ svn mv zig/foo zig/bar
$ echo stuff zig/bar
$ svn ci zig
Of course it's not possible to eliminate a new node in this case. That's
because your example isn't a move, it's a move+modify.
Move+modify is quite common, e.g. rename foo.[ch] to svn_foo.[ch] and
then modify svn_foo.c to #include svn_foo.h instead of foo.h. One
would not want to have to commit the plain move, that revision would
not compile.
[snip]
Does it involve storing a some sort of move flag in the
repository?
No, not at all. What you get is simply a change in one or two
directories' entries.
I'll try to illustrate the point. Imagine you have two directories A
and B, that are children of the root. A contains the files foo and
bar, B contains qux. I'll tag each node with its node revision number:
/ (0.0.4)
A/ (a.0.3)
foo (f.0.2)
bar (r.0.3)
B/ (b.0.4)
qux (q.0.4)
Now see what happens when we svn rename /A/foo /B/baz:
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.0.2)
qux (q.0.4)
We created new revisions of A, B and / (because of bubble-up), and
the pointer to f.0.2 is now called baz rather than foo, but the
node itself did not change, and its immediate ancestor is still the
same, although you can't guess that ancestor's name from the current one
(note that the repository does know that name already). So we don't need
any new flags in the repository at all.
So in the move+modify case, where a new node needs to be created, I
suppose it would look like
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.1.5)
qux (q.0.4)
Will this be a problem? Does it mean that the client will be unable
to distinguish copy+delete from move+modify?
It would appear that atomic move has potential benefits, the client
will be able to perform better if it can identify a move. It would be
a shame if that improvement did not apply to move+modify. I like the
idea of atomic move, I'm just worried that it is not complete.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Philip Martin ph...@codematters.co.uk.
William Uther willu@cse.unsw.edu.au writes:
The proposed move semantics need to define what happens during a
merge when one end of a merge contains only one end of a move. I was
thinking that it might just devolve to copy+delete semantics in this
case (or possibly error, but devolve with a -force tag?):
[...]
I don't think you can get away with the same approach as commits where
you simply disallow such merges. You at least need to allow them with
'-force'.
I certainly would not want atomic move to degenerate into delete/copy
by default, although I suppose it would be OK to have a flag to enable
that. Note that this sort of problem is not really new, there is a
similar problem when the merge source modifies a file that does not
exist in the merge target. At present attempting such a merge just
produces a not under revision control error, although perhaps we
ought to do better :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by William Uther wi...@cse.unsw.edu.au.
Hi all,
I like this concept of move. It makes more sense to me. I think it
might interact in interesting ways with merge though... In particular,
in the same way there is a problem with only one half of a move being
committed, there might be a problem with only one half of a move being
merged.
The current copy and delete semantics make this well defined (if a
little weird). The proposed move semantics need to define what happens
during a merge when one end of a merge contains only one end of a move.
I was thinking that it might just devolve to copy+delete semantics in
this case (or possibly error, but devolve with a -force tag?):
- A file in the merge source (eg branch, when merging from branch to
trunk) was moved from somewhere else: It gets copied from the merge
source to the merge destination with history.
- A file is no longer in the merge source as it has been moved
elsewhere: it is deleted from the merge destination (and maybe
conflicts if it has changed in the merge destination).
- A file in the merge destination was moved from somewhere else: This
is treated the same as a new file having been added.
- A file in the merge destination has been moved to somewhere else:
This is treated the same as the file having been deleted in the merge
destination (and maybe it conflicts if the file has changed in the
merge source).
I don't think you can get away with the same approach as commits where
you simply disallow such merges. You at least need to allow them with
'-force'.
Later,
Will :-}
On Wednesday, January 22, 2003, at 08:21 AM, Branko Čibej wrote:
Philip Martin wrote:
Branko Čibej brane@xbc.nu writes:
This example is exactly why I keep saying that we should make svn
mv
an atomic operation that *does not* generate a new node in the
filesystem. Then moves would become pure directory changes, and svn
merge has to resolve those before merging the files themselves, like
Philip said -- and so it would know before even starting the file
merge
that it found a rename.
[snip]
Finally what about a commit of part of the rename
$ svn mv zig/foo zag/foo
$ svn ci zig
I assume this has to be rejected by the filesystem/repository.
Now here we're talking about client-side implementation issues. If that
partial commit tells the file system to move zig, without a target,
then obviously the repository will reject the commit.
This partial-commit problem is in fact the main reason why I didn't
change the behaviour of svn mv yet. The client must be able to detect
this, which means that the working copy must record the fact that a
file
was moved (on /both/ sides of the move), and the commit editor must
check that both sides of every move are included in the commit. It
becomes obvious why we're doing a cp+rm now; the two halves of that
operation can be committed separately, which makes the commit editor
much, much simpler.
With --force, we might possibly allow this case to degenerate from a
move to a copy+delete; but by default, the client should error out when
it detects a commit of a partial move like that.
Luckily, an URL-URL move doesn't have this problem, and we don't allow
moves between an URL and a WC anyway (and a good thing, too).
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move merge
Posted by Branko Čibej br...@xbc.nu.
Philip Martin wrote:
Branko Čibej brane@xbc.nu writes:
This example is exactly why I keep saying that we should make svn mv
an atomic operation that *does not* generate a new node in the
filesystem. Then moves would become pure directory changes, and svn
merge has to resolve those before merging the files themselves, like
Philip said -- and so it would know before even starting the file merge
that it found a rename.
I'm the first to admit I'm no expert on the Subversion filesystem, the
model or the implementation. There are some things about atomic
rename that are not clear to me, perhaps you could elucidate. You
emphasise that a new node does not get created, is that simply an
optimisation? The elimination of a new node is not always possible,
consider
$ svn mv zig/foo zig/bar
$ echo stuff zig/bar
$ svn ci zig
Of course it's not possible to eliminate a new node in this case. That's
because your example isn't a move, it's a move+modify.
obviously the move has to create a new node for zig/bar as it has
changed contents. If elimination of the new node is simply an
optimisation could it not be applied to copies as well?
The elimination is not simply an optimisation, and obviously can't be
applied to copies. The intent of a copy is to create a new node from a
known ancestor. The intent of a move, on the other hand, is to change
the /name /by which a node is referred to in the file system. Because
Subversion uses a Unix-like model of the file system, node names exist
only as properties of a directory; the files do not have an intrinsic
name. Changing svn mv to only affect directory entries is a move
towards a more correct implementation of that model.
Is there something more to atomic rename than elimination of the new
node?
Yes. Renaming a node should not affect its history. The effect of a
cp+rm is to create a new branch in the node's history (and remove an old
one); that is obviously wrong, because, under our model, a rename does
not constitute a modification of the node, only a modification of its
(old and new) parent directory. In simple terms, after an svn mv in a
clean working copy, svn st should show one or two modified
directories, but no modified files.
(Of course, the user would want to know that the file was moved, so svn
st should show something for usability's sake; but what it shows should
not be a modified state but a renamed state. That means yet another
status letter, but perhaps not.)
Does it involve storing a some sort of move flag in the
repository?
No, not at all. What you get is simply a change in one or two
directories' entries.
I'll try to illustrate the point. Imagine you have two directories A
and B, that are children of the root. A contains the files foo and
bar, B contains qux. I'll tag each node with its node revision number:
/ (0.0.4)
A/ (a.0.3)
foo (f.0.2)
bar (r.0.3)
B/ (b.0.4)
qux (q.0.4)
To understand this example, you should be aware that, within the file
system, directory entries are nothing but named pointers to node
revisions (those a.0.3 triplets); the names are not a property of the
node revisions themselves.
Now see what happens when we svn rename /A/foo /B/baz:
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.0.2)
qux (q.0.4)
We created new revisions of A, B and / (because of bubble-up), and
the pointer to f.0.2 is now called baz rather than foo, but the
node itself did not change, and its immediate ancestor is still the
same, although you can't guess that ancestor's name from the current one
(note that the repository does know that name already). So we don't need
any new flags in the repository at all.
Finally what about a commit of part of the rename
$ svn mv zig/foo zag/foo
$ svn ci zig
I assume this has to be rejected by the filesystem/repository.
Now here we're talking about client-side implementation issues. If that
partial commit tells the file system to move zig, without a target,
then obviously the repository will reject the commit.
This partial-commit problem is in fact the main reason why I didn't
change the behaviour of svn mv yet. The client must be able to detect
this, which means that the working copy must record the fact that a file
was moved (on /both/ sides of the move), and the commit editor must
check that both sides of every move are included in the commit. It
becomes obvious why we're doing a cp+rm now; the two halves of that
operation can be committed separately, which makes the commit editor
much, much simpler.
With --force, we might possibly allow this case to degenerate from a
move to a copy+delete; but by default, the client should error out when
it detects a commit of a partial move like that.
Luckily, an URL-URL move doesn't have this problem, and we don't allow
moves between an URL and a WC anyway (and a good thing, too).
--
Brane Čibej brane@xbc.nu http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Lele Gaifax <le...@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!
>
Oops, careful there. Subversion doesn't need any brute-force search
heureistic, it has the file's history. However, read on...
>>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.
>
This example is exactly why I keep saying that we should make "svn mv"
an atomic operation that *does not* generate a new node in the
filesystem. Then moves would become pure directory changes, and "svn
merge" has to resolve those before merging the files themselves, like
Philip said -- and so it would know before even starting the file merge
that it found a rename.
I think that the way things stand now, "svn merge" will break horribly
on a driectory rename; it'll replace the whole subtree instead of
merging it.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Lele Gaifax <le...@seldati.it>.
>>>>> On 16 Jan 2003 20:55:35 -0600, Ben Collins-Sussman <su...@collab.net> said:
BC> There's no good solution to this problem: the diff just
BC> doesn't apply cleanly. There's no way Subversion can "guess"
BC> that some file in your directory used to be named
BC> 'main.c'... at least not without some huge brute-force search
BC> heuristic!
Uhm, this is where I thought svn could help: I wrongly assumed that
"renames" were "first-class citizen" here :)
BC> What were you expecting? :-)
BC> Perhaps you're confused about how svn does renames. Remember
BC> that a rename is an 'svn rm' + 'svn cp', and an 'svn cp' is
BC> just an 'svn add' which remembers copy-history. So that's why
BC> you're seeing the 'A' and 'D' in your merge there. It's a
BC> rename.
Yes, and here you enlightened me on the matter: as said, I was
assuming that svn was able, in some way, to distinguish between a
rename and a "replace", but evidently it cannot.
Well, I dreamed for a while... back to work :-)
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Understanding move & merge
Posted by Ben Collins-Sussman <su...@collab.net>.
Lele Gaifax <le...@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