Ryan Schmidt wrote:
> On Jan 5, 2006, at 17:35, Gale, David wrote:
>
>> Also, the current system ensures that the three files are as close as
>> possible in an alphabetical listing. Putting the conflict
>> extensions in the middle breaks that behavior, which is probably not
>> a good thing.
>
> I don't think it breaks it too much...
>
> In the current behavior, the files are together:
>
> foo.c
> foo.c.r42
> foo.c.r43
> foo.c.mine
> foo.h
>
> In the proposed new scheme, it's not too much worse:
>
> foo.c
> foo.h
> foo.mine.c
> foo.r42.c
> foo.r43.c
>
> The compromise that meets both goals (the old goal of keeping files
> together and the new goal of having the correct extension) is to
> repeat the extension:
>
> foo.c
> foo.c.r42.c
> foo.c.r43.c
> foo.c.mine.c
> foo.h
What if you've compiled code, and thus have foo.o? Or are working on
something other than C code (perl and python both pop to mind), whose
extension comes between "mine" and "r[0-9]"? Worse yet, what if you've
got perl and python code in files that only differ by the extension,
leading to:
foo.mine.pl
foo.pl
foo.py
foo.r42.pl
foo.r43.pl
Not too bad, arguably, but what if the foo.py file had generated a
conflict as well? (And, please don't tell me this situation wouldn't
happen--we still have files that differ solely in the case of the file
name, and I've seen enough posts to this mailing list to know that we're
not alone!)
Or what if you just want to ls the conflicting files? Currently, 'ls
foo.c.*' works; putting the flags in the middle necessitates 'ls
foo.*.c'. And, if you're in a semi-intelligent shell, tab-completion
breaks down.
The compromise gets rid of my complaints, but is cluttered. I wouldn't
want that to be the default, either...or, again, if it were, I'd hope
that there'd be an option where I could turn it off.
Incidentally, which modern editors *can't* handle files with
"uncanonical" extensions? Or is this request just for people who want
to be able to double-click a "mine" file in Windows, and have it open in
the appropriate tool?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 5 20:19:52 2006