Re: [vcs] Subversion - Checkout
On Thu 2018-04-05 at 16:03h, Leo Donahue wrote on netcat: > 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. Test case #3 steals the lock from Project1 to Project2, but Projec1 still believes it has the lock. I now agree there is a problem with test case #4. Project1 needs to be updated first so that it notices that its lock was stolen. Then the lock action is available again and the test case can proceed as described. Maybe you could amend the test case accordingly. There is an actual issue when trying to unlock a lock that has been stolen away. SVN output indicates that the lock isn't valid [1], but NetBeans ignores this and doesn't notify the user that the action failed and that the working copy needs an update. I'll create a Jira issue for that tomorrow (have to leave now). Niklas [1] unlock Filesystem has no such lock svn: No lock on path '' (400 Bad Request) - 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
Re: [vcs] Subversion - Checkout
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 Matthieswrote: > 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 > >
Re: [vcs] Subversion - Checkout
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
Re: [vcs] Subversion - Checkout
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" All of the files in .subversion/auth on my workstation and subversion server are empty. I thought those were used for svnserve? Lock Feature test suite doesn't indicate what kind of repository to use. I closed NetBeans, leaving these two projects in the state they were when I emailed. I re-opened NetBeans. File in Project1 shows "Unlock" in Team menu. Attempting Unlock says authentication failed with log message: ==[IDE]== Apr 5, 2018 12:01:27 PM Unlocking Files... unlock /home/leo/workspace/netbeans/test1/Project1/src/project1/Main.java Authentication failed svn: No more credentials or we tried too many times. Authentication failed 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) ==[IDE]== Apr 5, 2018 12:09:40 PM Unlocking Files... finished. Double check (some info redacted): ~/workspace/netbeans/test1/Project1/src/project1$ sudo svn status Main.java K Main.java ~/workspace/netbeans/test1/Project1/src/project1$ sudo svn info Main.java Path: Main.java Name: Main.java Working Copy Root Path: /home/leo/workspace/netbeans/test1/Project1 URL: http://subversion.domain.com/svn/repo1/Project1/src/project1/Main.java Relative URL: ^/Project1/src/project1/Main.java Repository Root: http://subversion.domain.com/svn/repo1 Repository UUID: Revision: 12 Node Kind: file Schedule: normal Last Changed Author: user1 Last Changed Rev: 12 Last Changed Date: 2018-04-04 19:40:42 -0600 (Wed, 04 Apr 2018) Text Last Updated: 2018-04-04 19:42:29 -0600 (Wed, 04 Apr 2018) Checksum: Lock Token: opaquelocktoken: *Lock Owner: user2* Lock Created: 2018-04-04 19:44:27 -0600 (Wed, 04 Apr 2018) Lock Comment (1 line): Lock Project1 Main.java in test1 workspace. No Force. 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? Before I mark test cases as failed, I want to make sure I am following the spirit of the test case. On Thu, Apr 5, 2018 at 7:44 AM, Niklas Matthieswrote: > SVN does not store the username in the working copy. Unless a username is > explicitly specified in an SVN command, SVN uses the last cached > credentials for the given repository (usually stored under > $HOME/.subversion/auth on Unix). > > After checking out Project1 as user2, the last-cached credentials are > those of user2, so if you then perform a lock, it uses user2 regardless of > the working copy. > > Niklas > > > On Wed 2018-04-04 at 19:54h, Leo Donahue wrote on netcat: > > Hi, > > > > I have been testing the Lock Feature test suite and noticed some things > > about the IDE and I'm not sure whether these things contribute to my test > > cases failing. > > > > The setup for Lock Features say: > > Checkout a Java project using subversion (Project 1) > > Checkout the same Java project using subversion again into a different > > directory (Project 2) > > Two different working copies of the same project should be opened in IDE. > > > > The setup does not indicate whether the same project should be checked > out > > using different subversion user accounts. > > > > I checked out the same subversion project using different user accounts > > into different workspaces. > > > > Project1 was checked out initially as "user1" > > Project1 was checked out a second time as "user2" > > > > When I lock a file in Project1 that was checked out as "user1", the > > subversion tab says it is locked by "user2". > > > > Is that right? It should be locked by "user1". > > - > 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 > >