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

Re: Issue 1493 - property merges should use libsvn_diff

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 30 Oct 2009 00:26:24 +0100

David Glasser wrote:
> On Thu, Oct 29, 2009 at 4:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Daniel Näslund wrote:
>>> On Wed, Oct 28, 2009 at 11:37:48PM +0100, C. Michael Pilato wrote:
>>>> Why not change the message to simply refer to files in the working copy
>>>> where the user can examine the various property values for themselves?
>>>>
>>>> Trying to the value of property 'NAME', but there appears to already
>>>> be a property 'NAME' with the same final value. See NAME.prej.mine
>>>> (or NAME.prej.theirs) for the property value.
>>>>
>>>> That kinda thing?
>> [...]
>>
>>> My only concern is for adding extra prej.{mine,theirs} to the directory.
>>> But if they would be automatically cleaned up when the conflict is
>>> resolved then there would be no harm done.
>> Hrm... yeah, I would, too.
>>
>>> I would feel even better if there was a way to use plain diff3-format
>>> in .prej-files but maybe there is too little to win? How often
>>> do we have long properties spanning multiple lines?
>> svn:mergeinfo and svn:ignores are the only of our own properties that do right?
>
> And svn:externals. (I can think of a few other tools that use
> multi-line properties.)

It might be overkill, but what if we attempted the diff and, if the result
would be a simple "Binary files differ" type result, fallback to the
mine/theirs file drops?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412862

Received on 2009-10-30 00:26:32 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.