C. Michael Pilato wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
>
>>I'm not saying it's never useful to know what copies of a node were made
>>in the past or the future. But the purpose of this function is to aid
>>commands like "svn cat -r N filename", and that should not traverse
>>copies going forward.
if you do not traverse copies forward,
will you be able to skip over files that
are deleted from a revision but resurrected
through a copy at a later time?
echo foo >file.txt
svn add file.txt
svn commit -m "initial" # rev 1
svn rm file.txt
svn commit -m "deleted" # rev 2
svn cp file.txt -r1 (reposurl)/file.txt (reposurl)/
this is a very common case.
also consider copies from branches back into trunk.
-
why should a new copy of a file be handled differently
than a rename of the file or a cp/rm pair?
isn't it equal to say
echo foo >file1.txt
cp file1.txt file2.txt
or to say
echo foo >file1.txt
mv file2.txt file1.txt
cp file2.txt file1.txt
?
from a users point of view the result is the same
in both cases: two identical files with equal history.
but now you say svn would treat them different,
depending on how they were created...
I'd much prefer if both cases would be equal and
svn reports and follows both copies.
(yes I know there are no forward pointers in the db yet...)
:-)
=====
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 09:20:05 2004