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

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 18 Jan 2013 11:53:58 +0100

On Fri, Jan 18, 2013 at 11:29 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 18.01.2013 11:20, Johan Corveleyn wrote:
>> On Thu, Jan 17, 2013 at 10:59 PM, Ben Reser <ben_at_reser.org> wrote:
>>> On Thu, Jan 17, 2013 at 1:14 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>>> I think
>>>> $ svn mv A B
>>>> $ svn mv B A
>>>>
>>>> Will now store moved_from and moved_to in the same record, at the op-depth of A.
>>>> (Or copy_tests.py move_file_back_and_forth wouldn't show moved_from and moved_to on a single node using status using the code snippet here)
>>> This seems really ugly to me:
>>> $ svn status
>>> R + A
>>> > moved to A
>>> > moved from A
>> Yeah, pretty ugly ... but perhaps it's not much uglier than the
>> solution in 1.7 (without move tracking):
>>
>> $ svn status
>> R + A
>>
>> Ideally svn should see that this "self-replacement with history" is
>> perhaps better represented as a simple Modification.
>
> In fact it's not even a modification, the second move just undoes the
> first one and "svn status" should show nothing at all in this case.

Ah yes, of course, forgot about it not being modified. So it should
show nothing if it wasn't modified, or show a modification if the file
content has been modified in the meantime (which is usually so in most
real-life cases, with refactoring going on, making changes, and then
somewhat later the user moves the file back to the original location
because he changed his mind).

-- 
Johan
Received on 2013-01-18 11:54:53 CET

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.