On Thu 2018-04-05 at 12:44h, Leo Donahue wrote on netcat: > Thank you Niklas, > > >> SVN does not store the username in the working copy > http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html > > The svn redbook seems misleading. > "The fact that the *svn info* command, which does not contact the > repository when run against working copy paths, can display the lock token > reveals an important piece of information about those tokens: they are > cached in the working copy"
Not sure what is misleading here. The lock token is the result of creating a lock. The username used for creating a lock is taken from cached credentials. Cached credentials are independent of working copy and not stored in the working copy. Only the resulting lock token and the lock owner (username who created the lock) is stored in the working copy. The lock owner username is not used for general SVN authentication, only for authorization of operations relating to that specific lock. See also: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.creds http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html > All of the files in .subversion/auth on my workstation and subversion > server are empty. I thought those were used for svnserve? Ah, NetBeans sets it to ${netbeans-userdir}/config/svn/config/auth it seems. In any case, it's not saved per-working copy. > Lock Feature test suite doesn't indicate what kind of repository to use. The kind of repository should not be relevant for this. > I closed NetBeans, leaving these two projects in the state they were when I > emailed. : > The dialog that opened asking me for user credentials, I supply "user1" > credentials and get this error in log: > > unlock /home/leo/workspace/netbeans/test1/Project1/src/project1/Main.java > Username does not match lock owner > svn: Unlock of 'Main.java' failed (403 Forbidden) That seems correct to me, since the lock was created by user2 and you are trying to unlock it as user1. > For Lock Features test suite, if I use the same single user credentials to > lock a file in test case #1, why would test case #4 even have the option to > "Lock" the same file again? And Lock it again in test case #5? It's the same file, but in a different working copy (Project1 vs Project2). Locks are working-copy specific (by means of the lock token stored in the working copy). Test cases #3 and #4 are testing that you can "steal" a lock owned by one working copy to another working copy using the "force" option. Test case #5 says "select some Java file" in step 1. It is implicit that this should be a file that isn't locked yet, although I agree it would be better if the test case made this explicit. Test case #5 is testing that the lock is actually doing its job, namely preventing commits from another working copy to the locked file. Niklas --------------------------------------------------------------------- To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org For additional commands, e-mail: netcat-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
