copy history thoughts

I have a question concerning how copy history is traversed.
For example, I've made some change in revision 72. In revision 76,
I've moved directory to a different location, and now I'm at revision
78, and want to undo the rev72 change, I run:

    svn merge -r72:71

and it gives me an error, because the current directory is now in

   /trunk/whale

but in revision 72 it was

  /whale/trunk

Okay, I can merge by specifying old paths. (Actually, at the moment I can't,
for the reasons described in "svn diff regression bug" thread).

But even if I can, it this a reasonable? Do I mean: merge the changes made in
revision
72 to the closest ansestors of files which are here now 72, or merge changes
made to
file that were here in revision 72? Probably the answer is related to whether
rename is
atomic or not.

Related question. If I run

   svn log -r 50 file.txt

but file.txt was copied to "." in revision 60, what is the right
behaviour? Should copy history be traversed or not? Now it is not,
so if revision 50 had not this file, an error is returned. I believe
this is contrary to behaviour of "log" without parameters -- it would
be reasonable if

   svn log -r 50

traversed copy history, and

   svn log --strict -r 50

returned log for files that were in current dir at revision 50.

So, what's the right way?

- Volodya

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 30 19:47:35 2002