Thanks for clarification on the cached credentials. Test case #1 file in Project 1 is locked. Test case #4 file with same name like in previous, file with same name like in previous, file with same name like in previous - is the same file as test case #1 in project 1. The menu option to even try to lock this file from Project 1 isn't available. unlock only. I got confused as to whether the file is supposed to be locked or the menu items aren't working right.
On Thu, Apr 5, 2018 at 3:28 PM, Niklas Matthies <[email protected]> wrote: > 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: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >
