Re: Re: "Retrieve Revision as..." default file name

Am 15.12.2003 um 15:38 schrieb Oliver Giesen:

>> If Java folks have problems with this, they can always point the file
>> browser to a different location in the "Retrieve Revision as..."
>> command...?
>
> Sure. When I added the RetrieveAs functionality I simply extended the
> existing Retrieve functionality with the Save dialog, thus it also uses
> the same naming convention. I can see that it doesn't necessarily make
> sense to use that convention as a default if the user is likely to save
> to a different directory or otherwise affect the target filename 
> anyway.
>
> I definitely do not think however that we should change the naming
> convention of the dialog-less Retrieve functionality, at least not in a
> way that will leave the extension intact. Java development is 
> definitely
> not the only environment where the sheer existence of a file with a
> certain extension has an effect. Another example I could think of off
> the top of my head for illustration would be CvsGui macros: I've got 
> the
> Macros subfolder of my WinCvs installation under version control
> (pointing to my own "intermediate" repository, in order not to annoy 
> you
> folks too much... ;) ). Every file ending in .py or .tcl will
> automatically be loaded on next reload/restart... I'm dead sure there
> are tons of environments similarly affected by the existence of files
> with known extensions.

O.k., looks like about everything that's not C-related would like the 
extension to be hidden ;-)
Anyway, for the "Retrieve Revision" command (i.e. the one without the 
destination chooser), it's o.k. to have the revision appended. It's 
certainly the less error-prone solution.
For "Retrieve Revision As...", I would choose another scheme (see below)

> BTW: the reason that ViewRevision uses a different naming convention is
> that it is intended for passing files to an associated application that
> might potentially reject the passed file if it doesn't have the 
> expected
> extension, or if it doesn't reject it it might refuse to handle it
> correctly in some other way (e.g. missing syntax highlighting, etc.).

Exactly for that reason, I suggested using the same naming scheme for 
"Retrieve Revision as...". (I didn't originally talk about the 
"Retrieve Revision" command, which just saves into the same location as 
the original file)
>
> Thinking about it, using the ViewRevision naming convention for the
> RetrieveAs mechanism is probably not a bad idea at all...

Yes (see above).

>
>
>> To make things [over-?] perfect, this could be a configurable option
>> where we could specify three placeholders for ORIGINAL_NAME, REVISION
>> and ORIGINAL_EXTENSION. (Might be a bit overkill to have a pref for
>> this, though...)
>> Or maybe a simpler option that allows to choose between
>> "foo.#.rev.extension" and "foo.extension.#.revision" would be
>> sufficient (should be a per-sandbox setting)?
>
> I *do* think that this would be overkill indeed. ;)

As usually, when engineering can't cut a UI decision, it would like to 
make it an option for the user - resulting in bad UI experience due to 
an excessive list of adjustable options  ;-)

</jum>


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/