[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] issue #3620: svn add ^/ triggers assertion failure

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 13 Jul 2010 13:00:14 -0400

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.


>> 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

This is an archived mail posted to the Subversion Dev mailing list.