[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 20:11:42 CEST

Mark Phippard wrote:
> On 4/26/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> Mark Phippard wrote:
>> > On 4/26/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> >> 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.
>> >
>> > True, but so far the examples provided where this was a problem were
>> > an IDE that built .java files automatically and a make script that
>> > built .c files automatically. Neither of these type tools would have
>> > a problem with an extra .jpg file or .doc file lying around.
>> >
>> > If this was not a global setting, I would not bring it up. But if I
>> > mainly want this feature for Word documents, but I do most of my
>> > development in Java, I am kind of stuck. I pretty much have to turn
>> > the feature off. If this were a per-project setting I might turn it
>> > on for my project/repository where my Word docs are stored and leave
>> > it off everywhere else.
>> >
>> > So my thought was to attempt a compromise setting.
>> This feature request, fulfilled by tweaking a single function in
>> update_editor.c, is starting to get out of hand.
>> I understand the reasoning for a compromise setting, but it's the wrong
>> compromise line to draw. A better one might be to make the feature just
>> take a list of file extensions you want to preserve. I was just about to
>> commit the boolean on/off code change (it's done and tested). I can
>> pretty
>> easily do the list-of-extensions-to-preserve thing (small change from
>> where
>> my patch already sits).
>> But I'm not going to code on this any more until there's some
>> consensus in
>> this thread. Okey dokey? :-)
> Please do not interpret my suggestions as lack of consensus. I am
> just trying to help think through this so we get it right. Your
> suggestion of a list of extensions sounds find to me and a lot safer.
> I am assuming if the boolean value were on, then the file extension
> would have to be in the list? Otherwise it would use current
> behavior? That sounds pretty good to me.

Well, there'd be no boolean value any more. The feature becomes always-on,
but if the extensions list is empty, then of course, it's effectively off.

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

Received on Thu Apr 26 20:11:51 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.