On 07/13/2010 11:02 AM, Stefan Sperling wrote:
> On Fri, Jun 11, 2010 at 05:37:11PM +0200, Uwe Stuehler wrote:
>> Meanwhile Michael Pilato and Stefan Sperling gave me even
>> more input (thank you) and I was able to prepare a suite of tests
>> modeled after others in subversion/tests in order to check most
>> of the other commands which, like 'add' and 'status', only accept
>> paths or URLs in certain argument positions.
>
>> a) Validating all input in the libsvn_client library and gracefully
>> handling any errors instead of triggering an assertion allows the
>> client to recover. I think everyone agreed that this is good.
>
> Yes, I think so, too.
>
>> b) Checking the arguments in the CLI commands before calling
>> libsvn_client functions makes it possible to abort early and not
>> in the middle of processing the command.
>
> I agree we should check at both layers.
As do I. Mostly. Today, at least. (So act now!)
> The CLI client needs to canonicalise paths it passes to the client library.
Yup.
>> d) With consistent expansion of ^/ to the repository URL and consistent
>> parsing of @peg-revisions in all target arguments, and behavioral
>> differences depending on the kind of target given, I could understand
>> a policy that treats pathnames which look like URLs as syntactically
>> incorrect and rejects them where only local pathnames are expected
>> and vice versa.
>
> If we enforce a certain syntax for certain types of arguments, we should
> probably provide a way to relax the checks in case someone really
> wants to version files or directories called http://www.example.com.
> We don't currently impose restrictions on names of versioned nodes,
> and I don't think we should do so.
Is it legal to have a forward-slash character in path components on any
modern OS? I thought that both Windows and Unix disallowed that character.
Certainly various levels of our own codebase already do. So I don't see
the point in trying to support dealing with looks-like-a-URL-but-ain't types
of paths.
> I'd like to move forward with this.
> Any objections regarding the above points? Else I will try to finish
> this work myself, unless Uwe finds time to continue it soon.
Sorry, Uwe, that I never got back to you on this one. Truth told, I
flip-flopped on my preferred solution so many times that there was never
anything consistent I could have told you. :-(
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-07-13 19:01:18 CEST