Quoth Tobias Schäfer:
> This is my proposal based on your ideas:
> /command:update /pathfile="%temp%\svn1234.tmp" /deletepathfile
>
> This change will break all calls which currently don't specify /notempfile.
> All calls from the shell extension will be changed to reflect this new
> interface.
If /path still exists and /notempfile is completely ignored then it
won't break anything (documented) -- the only change of behaviour will
be for those who are relying on the undocumented quirk that /path
changes meaning when you didn't specify /notempfile. Which hopefully is
only the shell extension :)
But yep, that looks good.
> What should tortoiseproc do if both /path and /pathfile are given? I would
> add both path lists to a single path list internally.
I agree. It's probably not going to be too common, but there's no
reason why this shouldn't be supported -- they don't have to be mutually
exclusive.
Though care will need to be taken if the order of parameters is
significant (eg. for a merge) -- they'll need to be processed in the
passed order, not eg. always doing /path first regardless of order.
(For that matter, a construct such as '/path="foo" /pathfile="bar"
/path="baz*bob"' ought to be legal as well, and should result in the
internal path list containing "foo", all the paths named in the file
"bar", then "baz" and "bob", in that order.)
This could get tricky depending on how you're currently parsing the
parameters :)
I'm also a little dubious about the use of * as a separator -- it would
have made more sense to use ;, and save * for use as a wildcard. But
it's probably too late to change that now.
> Pathfile is currently a file in unicode encoding. To make it easier to pass
> a list of files we should also support simple ascii encoding. This is a
> different issue though. This is to support what you proposed with the
> parameter /listfile
I guess it depends on how you're reading the file, whether you're just
assuming a given encoding or whether you're doing something more
intelligent.... ideally it should be able to accept a file in any
encoding, by detecting the byte order marks (or failing that, if it
detects bytes that don't make sense in ASCII [such as nulls] then it
should assume Unicode).
If that's too much of a hassle then requiring it to be Unicode is
probably fair enough. As Stefan said, since files may not have names
representable in ASCII then Unicode is really the only choice if you
have to pick a single encoding to use.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue Oct 3 23:59:04 2006