On Sep 11, 2005, at 4:44 AM, Kalin KOZHUHAROV wrote:
> Can you give a reason why only god can read the
> test:/trunk/closed-directory ?
> I perfectly understand why only he can write, but putting it "ro" is
> normal, IMHO.
> So far I cannot think of a case like that...
Sure -- here's an easy one: some directories are simply not suitable
for public access.
For example, the specific repository that I'm thinking of is an
academic project that is available for anonymous / read-only access.
However, given the "publish [first] or perish" survival strategy in
academia, sometimes we want to be able to do something new in a tree
that the public cannot [yet] access. That is, in order to be "first"
in academia, sometimes to have to operate in stealth mode for a little
while, and when you finally have reportable results, open it to the
world for public inspection, etc.
I can think of a number of related scenarios for vendor-based SVN
repositories, too.
What it boils down to is: every project has different requirements.
Now that one can have technology-enforced permissions in a source code
repository (i.e., authz), you can bet that someone will have a scenario
where locking out users from certain trees is a requirement (you could
hack up similar scenarios in CVS, IIRC). This is just like the normal
filesystem -- it's perfectly normal to have some users have limited (or
no) access in a given tree. Why shouldn't that also apply to a
repository?
More specifically -- why *wouldn't* it be reasonable to have this kind
of scenario?
</philosophical_rant>
>> [snipped]
>> In one sense, you can see why the copy failed -- the "human" user was
>> not able to read the full source tree (i.e., human couldn't read
>> closed-directory).
>> But on the other hand, human *was* able to successfully check out the
>> trunk without error. So why shouldn't human be able to cp as well?
>> The flip side of that argument, though, is that if any user
>> (including a restricted user such as "human") is allowed to cp any
>> tree regardless of permissions, then the results of that copy are
>> dependent on who made the copy.
>
> What about having a working directory?
>
> svn co -N --username human https://svn.example.com/svn/test-repo/
> svn co --username human https://svn.example.com/svn/test-repo/trunk
> test-repo/trunk
> svn co -N --username human https://svn.example.com/svn/test-repo/tags
> test-repo/tags
> cd test-repo
> svn cp trunk tags/tag1
> svn commit --username human -m "make a tag"
>
> Can this be done? Please try, as I just have this in my head, not
> tested.
Unfortunately, I get the same results (I took a shortcut from what you
typed above -- since I have a simple/small test repository explicitly
for the purposes of this thread, I just checked the whole thing out as
"human"):
% svn co --username human https://svn.example.com/svn/test human-full
A human-full/trunk
A human-full/trunk/open-directory
A human-full/trunk/open-directory/file
A human-full/branches
A human-full/tags
Checked out revision 509.
% cd human-full/
% l
total 24
drwxrwxr-x 3 jsquyres research 4096 Sep 12 05:58 branches/
drwxrwxr-x 3 jsquyres research 4096 Sep 12 05:58 tags/
drwxrwxr-x 4 jsquyres research 4096 Sep 12 05:58 trunk/
% svn cp trunk tags/human-v1
A tags/human-v1
% svn ci --username human -m "foo"
Adding tags/human-v1
Authentication realm: <https://svn.example.com:443> Test Access
Password for 'human':
Authentication realm: <https://svn.example.com:443> Test Access
Username: human
Password for 'human':
Authentication realm: <https://svn.example.com:443> Test Access
Username: human
Password for 'human':
svn: Commit failed (details follow):
svn: COPY of human-v1: authorization failed (https://svn.osl.iu.edu)
svn: Your commit message was left in a temporary file:
svn: '/blah/jsquyres/svn/test/human-full/svn-commit.tmp'
>> But then again, this is just like normal unix filesystem permissions
>> -- the contents of a "cp -rf" are dependent on who executed the
>> command.
>> ... this argument goes on ad nauseam. Each side has valid points.
>> This difference in permission semantics confused us for a while
>> before we figured out what was going on. It actually is somewhat
>> painful -- it means that we cannot have restricted-access directories
>> within our source tree, because then *only* developers with full
>> access to the entire /trunk can make branches (we're in the habit of
>> making lots of developer-private temporary branches when someone
>> needs to go off and break the trunk for a while; they merge back up
>> to the trunk when they're done).
>> More specifically, it would be fine (from our perspective) if the
>> results of a "cp" are dependent upon the permissions of the user who
>> executed it. To ground this in the concrete example from above: it
>> would be fine for human to have a copy of the trunk in /tags that
>> does not have the closed-directory.
>> Comments?
>
> Hmm, very interesting... I haven't run into this (and I didn't bother
> testing
> it - I trust you :-) but I don't like this behaviour as well. Which
> side
> is better is also a difficult argument, but something has to be done.
> A first step might be to print warning MSG on `svn co`:
>
> WARNING: Directory bla-bla skipped. Access denied
>
> or similar. The next step might be implementing a new command option,
> say
> --fail-on-error that will abort the chekout on such warnings.
>
> Any other comments?
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.
Just my $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 13:13:38 2005