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:and...@online-solutions.ru
