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

Re: "svn cp" has different permissions semantics than "svn co"

From: Jeff Squyres <jsquyres_at_open-mpi.org>
Date: 2005-09-12 20:04:49 CEST

On Sep 12, 2005, at 10:11 AM, Joshua Varner wrote:

>> I would agree -- printing warnings would be a good first step (in both
>> cases -- co and cp). But it would be quite preferable to allow the cp
>> to complete without erroring out. If you don't, it would be pretty
>> hard for a user to complete the "cp" operation without a fairly
>> complicated script that checks for which trees were fully copied,
>> re-performs a subset of the cp, etc. Even worse, this would lead to
>> lots of commits rather than a single, atomic commit.
> Printed warnings are a form of security leak though. If a user does
> not have access to the data, you may not want them to even know
> it exists, so these warnings need to be a server side configuration
> option.

Not a bad idea. I can definitely see how silent rejection is good in
some cases.

But I think that the default configuration should follow the Law of
Least Surprise. If something is deliberately not being done (e.g., not
getting a directory on a checkout, or skipping a directory in a cp), a
warning should be printed so that the user knows. E.g.:

svn checkout: no authorization for "/trunk/foo/bar"; skipping and

Someone obviously thought about this when they implemented "co" that
will silently skip directories that you don't have permission for --
but perhaps it would be better to:

a) print a warning (perhaps only the first time you "svn co" or "svn
up" and get a restricted directory -- I can see how it could get
annoying if you got that warning *every* time you did a "svn ci" or
"svn diff" [or whatever] and it told you that there was a directory you
couldn't access)


b) leave an empty directory there as a token (e.g., so that the user
doesn't try to add another directory of the same name, which will
currently fail with mysterious errors), and if the the user tries to
svn add/commit/update/whatever inside that directory, the svn client
should say, "Sorry, you don't have access in here".

Just another $0.02...

{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 12 20:09:53 2005

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