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

Re: Changed handling of conflict file extensions is a usability regression in some situations

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-04-26 19:16:10 CEST

Mark Phippard wrote:
> On 4/26/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> C. Michael Pilato wrote:
>> > Justin Erenkrantz wrote:
>> >> On 4/25/07, Daniel Rall <dlr@collab.net> wrote:
>> >>>> As a result, I think the new conflict filename behaviour should be
>> >>>> deactivated by default.
>> >>> Yeah, or removed entirely.
>> >> +1.
>> >>
>> >> (I think the new scheme is far far worse than what we had before.)
>> >
>> > Yeah, those are bad side-effects. I'm not emotionally tied to the new
>> > scheme -- I just banged the code out. I'll revert the change(s) at
>> first
>> > real opportunity. But if someone else wants to jump on the task
>> sooner,
>> > just speak up and go for it.
>> >
>>
>> Actually, I've changed my mind. I'm going to add this as a runtime
>> configuration option: conflict_files_keep_extension
>
> What do you think of making the setting take three values?
>
> yes/true
> no/false
> yes (binaries only)
>
> I am not sure what the right terms to use would be, but this should
> give the idea. I think people mainly want this for files that have
> custom editors, like Word docs, or graphics.

This division seems somewhat arbitrary to me. The reason folks are seeing
problems with the feature so far is that now the conflict files are matching
globs meant for versioned files (*.c, *.java). Globs don't care about file
contents or line-based merge algorithms.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Thu Apr 26 19:16:18 2007

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.