You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2007/04/25 21:20:17 UTC
Changed handling of conflict file extensions is a usability regression
in some situations
I just got my first conflict in a Java project using recent trunk code.
Subversion propagated a .java extension on the conflict files. Which
caused Eclipse to try to compile them. This is bad, because it meant
that I couldn't test the compilation of my resolution of the conflict
until after I'd removed the conflict files.
As a result, I think the new conflict filename behaviour should be
deactivated by default.
Max.
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Rall wrote:
> On Thu, 26 Apr 2007, C. Michael Pilato wrote:
>
>> C. Michael Pilato wrote:
>>> Justin Erenkrantz wrote:
>>>> On 4/25/07, Daniel Rall <dl...@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
>>
>> Thoughts?
>
> s/keep/preserve/;
Yeah, I like preserve better, too. Was just trying to keep a single option
name from wrapping in my editor. :-) I'll use 'preserve'.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 26 Apr 2007, C. Michael Pilato wrote:
> C. Michael Pilato wrote:
> > Justin Erenkrantz wrote:
> >> On 4/25/07, Daniel Rall <dl...@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
>
> Thoughts?
s/keep/preserve/;
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Mark Phippard <ma...@gmail.com>.
On 4/26/07, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
OK, makes sense.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 4/26/07, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>> > On 4/26/07, C. Michael Pilato <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Mark Phippard <ma...@gmail.com>.
On 4/26/07, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
> > On 4/26/07, C. Michael Pilato <cm...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Mark Phippard <ma...@gmail.com>.
On 4/27/07, C. Michael Pilato <cm...@collab.net> wrote:
> C. Michael Pilato wrote:
> > I can pretty easily do the list-of-extensions-to-preserve thing (small
> > change from where my patch already sits).
>
> But of course, "small changes" are never so.
>
> You see, there's a problem with list-of-extensions-to-preserve -- there's no
> way to say "all of them".
>
> So I started toward list-of-extension-patterns-to-preserve:
>
> do[ct] - Word docs and templates
> od? - OpenOffice documents
> ...
>
> But that might be confusing to folks since the global-ignores is file
> patterns, whereas this is just file extension patterns. So do I want
> list-of-file-patterns-for-which-to-preserve-extensions?
>
> *.do[ct]
> *.od?
Sorry, I cannot say that I have a strong opinion. I'd be fine with
either approach.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> I can pretty easily do the list-of-extensions-to-preserve thing (small
> change from where my patch already sits).
But of course, "small changes" are never so.
You see, there's a problem with list-of-extensions-to-preserve -- there's no
way to say "all of them".
So I started toward list-of-extension-patterns-to-preserve:
do[ct] - Word docs and templates
od? - OpenOffice documents
...
But that might be confusing to folks since the global-ignores is file
patterns, whereas this is just file extension patterns. So do I want
list-of-file-patterns-for-which-to-preserve-extensions?
*.do[ct]
*.od?
...
(You may all issue a collective "Good grief..." now.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 4/26/07, C. Michael Pilato <cm...@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? :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Mark Phippard <ma...@gmail.com>.
On 4/26/07, C. Michael Pilato <cm...@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.
Personally, I think we should just roll the code back and not add a
setting. It just brings up another case where global settings do not
really cut it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 4/26/07, C. Michael Pilato <cm...@collab.net> wrote:
>> C. Michael Pilato wrote:
>> > Justin Erenkrantz wrote:
>> >> On 4/25/07, Daniel Rall <dl...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Mark Phippard <ma...@gmail.com>.
On 4/26/07, C. Michael Pilato <cm...@collab.net> wrote:
> C. Michael Pilato wrote:
> > Justin Erenkrantz wrote:
> >> On 4/25/07, Daniel Rall <dl...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Justin Erenkrantz wrote:
>> On 4/25/07, Daniel Rall <dl...@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
Thoughts?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression
in some situations
Posted by "C. Michael Pilato" <cm...@collab.net>.
Justin Erenkrantz wrote:
> On 4/25/07, Daniel Rall <dl...@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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/25/07, Daniel Rall <dl...@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.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Changed handling of conflict file extensions is a usability regression in some situations
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 25 Apr 2007, Max Bowsher wrote:
> I just got my first conflict in a Java project using recent trunk code.
> Subversion propagated a .java extension on the conflict files. Which
> caused Eclipse to try to compile them. This is bad, because it meant
> that I couldn't test the compilation of my resolution of the conflict
> until after I'd removed the conflict files.
Here's a similar one from Subversion's own development:
make: *** No rule to make target `subversion/libsvn_client/log.c.mine.c', needed by `subversion/libsvn_client/log.c.mine.lo'. Stop.
I think I triggered this by running gen-make.py while I had a
conflict. Yuck.
> As a result, I think the new conflict filename behaviour should be
> deactivated by default.
Yeah, or removed entirely.