Hello.
>> We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a
>> really big problems, because SVN v1.7.0 is not working as previous SVN
>> versions and incorrectly working with restrictions for some
>> directories in authz.
>>
>> A simple example of the issue:
>>
>> Let's assume this authz file:
>> ===================================================
>> [repos:/PROJECT/trunk/Sample]
>> ax = rw
>> mh = rw
>> lk = rw
>> sa = r
>> ep = rw
>>
>> [repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir]
>> ax = rw
>> mh = rw
>> * =
>> ===================================================
>>
>> SVN v1.6.5 and all clients worked with it in the following manner:
>> 1. They are allowed to use 'svn update' command on the "Sample" directory.
>> 2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser
>> (TortoiseSVN GUI), but did not allowed to update/commit or view
>> content of this directory.
>> 3. There are no any problems to make svn update in any part of the
>> "/Sample" dir and subdirs using svn client (command line) or any
>> other (GUI) client.
>>
>> After upgrading our server to SVN v1.7.0 we had a really big problems,
>> because now when we try to make update in the root directory (/Sample)
>> we see something like:
>>
>> ==========================================================
>> ==============
>> Updating '.': 13:5
>> Restored 'Sample\AnyDir\RestrictedDir'
>> svn: E155000: Failed to mark
>> 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
>> absent: item of the same name is already scheduled for addition
>> ==========================================================
>> ==============
>>
>> So, SVN update failed!
>>
>> No we cannot use our BUILD SERVER, also coders are unable to make SVN
>> UPDATE locally with the same problem!
>>
>> We have a complicated access rules for different users. Now it does
>> not work AT ALL! Because if some directory is available for user to
>> see that it is exist (it is made to give a possibility to make a
>> commits in a root directory, and do not split commits to a few dirs),
>> he will unable to make svn update in the root -- svn will fail on this
>> directory, that must be easly skipped, as SVN v1.6.5 server/clients
>> done before!
>>
>> This is a really serious problem for us, we can't work now.
BH> Can you post a simple walkthrough script that describes your exact problem.
BH> By just reading your mail I would guess the script is:
BH> As user lk do:
BH> $ svn co http://server/repos/PROJECT/trunk/Sample sample
BH> $ svn up sample
BH> (repeat the update)
BH> But this simple scenario appears to work correctly for me as it doesn't
BH> check out AnyDir/RestrictedDir in my tests.
BH> The ouput of svn says that you update the directory above 'Sample'.
Users, who have no access to "RestrictedDir" have such local copies
(just sample):
C:/PROJECT/trunk/Sample
C:/PROJECT/trunk/Sample/SomeDirForEveryone
C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.txt
C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.bin
C:/PROJECT/trunk/Sample/AnotherDir
C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.cpp
C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.h
C:/PROJECT/trunk/Sample/AnyDir
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.txt
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.bin
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.txt
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.bin
C:/PROJECT/trunk/Sample/AnotherDir3
C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.cpp
C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.h
Users (who are restricted to access RestrictedDir) does not have local
copy of
C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir
Previous behaviour (SVN v1.6.5 CollabNet / TortoiseSVN v1.6.15/16/other, prior v1.7.0):
When user use svn update into C:/PROJECT/trunk/Sample directory, it
receives updates for any files/directories of this
directory/subdirectories, EXCLUDING anything, that are subdir/subfiles
for
C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir
Users can see that this directory exist (through repo-browser of
TortoiseSVN, for example), because they have access for RW to /Sample
dir, but most of them (except 'ax' and 'mh') CANNOT list or receive
(read/write) files from/to this directory, because it is restricted by
"* =" rule.
So, it is a perfect way to allow for most users do update and commits
from a root directory (/Sample) (we providing a 'powerful' rights on
root, but removing some rights for restricted dirs only).
But when we using SVN v1.7.0 (console client from the same build as
server; or TortoiseSVN), we had a problem. When user (who is
restricted to access /RestrictedDir) tries to make svn update on the
root dir (/Sample), he got error as I described above.
Updating '.'
Restored 'Sample\AnyDir\RestrictedDir'
svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
absent: item of the same name is already scheduled for addition
SVN does not skip this directory, it creates is locally(!) as empty
directory(!) and stop/fail on svn update after this.
That's all.
(Previous versions just skipped this directory, because they are
checked that user have no access to this directory; they did not
created an empty dirs; just skipped without any errors).
BH> Things I'm interested in are like:
BH> * Do multiple users share a single working copy?
No.
BH> So AnyDir/restricteddir is checked out by one user, but wouldn't be by the
BH> user updating. Or the other way around.
BH> * Is the configuration changed between updates?
No.
BH> Is some change in a specific location required between updates?
BH> E.g. one in AnyDir, RestrictedDir, etc.
BH> I can see some problems, which might need fixing but I'm still not sure what
BH> your specific problem is.
BH> (I'm not sure if the problems I currently see are regressions. Still looking
BH> into that)
BH> The error you see would only make sense if the working copy doesn't know
BH> about RestrictedDir, except that it is a locally added file or directory.
BH> When the server then tells that there should be a restricted path there you
BH> get this error.
BH> But giving a working copy with a single user, that is +- impossible to read
BH> in your mail.
--
С уважением,
Andrey mailto:andrey_at_online-solutions.ru
Received on 2011-10-18 15:11:11 CEST