"C. Michael Pilato" <cmpilato@collab.net> writes:
> Greg Hudson <ghudson@MIT.EDU> writes:
>
>> On Fri, 2005-04-22 at 23:23, Philip Martin wrote:
>> > So you don't want atomic rename per se, you really want local mods to
>> > move within the working copy. Atomic rename is probably one way to
>> > achieve that, but I don't think it's the only way, I think the
>> > copyfrom information recieved during an update could be used to copy
>> > local mods within the working copy. In cases where the tree change
>> > really is a copy, rather than a move, the copyfrom solution might be
>> > superior.
>>
>> On the contrary, the copyfrom solution seems like a botch unless all
>> copies are really renames. Just because b is a copy of a doesn't mean
>> that b should receive copies of modifications to a.
I don't see it as a botch, sometimes it will be appropriate to copy
the modifications and sometimes not. Saying that modifications should
never be copied is a bit like saying modifications should never be
preserved when a file is updated. Why is it appropriate to copy
modifications from one revision to another, but not to copy them from
one name to another? If it turns out that the modifications are
inappropriate the file can simply be reverted (for update anyway,
merge might be more of a problem). I suppose you could argue that the
user can manually transfer the modifications, but once the update is
complete that's not so easy.
> Besides all that fun stuff, I'm pretty sure we don't actually ever
> *get* copyfrom information during an update.
That is more of a problem, although it might be simpler to fix
copyfrom than to implment svn_fs_rename :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 06:02:42 2005