netbeans-netcat mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <>
Subject Re: [vcs] Subversion - Checkout
Date Thu, 05 Apr 2018 21:28:54 GMT
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
> 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:

> 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/
> Username does not match lock owner
> svn: Unlock of '' 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

For further information about the NetBeans mailing lists, visit:

View raw message