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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
