Jeff Putsch <putsch@mxim.com> writes:
> When using a remote repository requiring authentication information, svn
> seems to store authentication information under a .snv/auth directory. This
> is nice because future commands will not require prompting or using
> the "--username" and "--password" arguments. Unfortunately "svn update"
> does not store this information in the .svn directory under newly added
> directories. This makes the next svn command that operates on an item
> under the newly added directory require either the "--username/--password"
> option or prompting of the user. Such behavior seems inconsistent and is
> fairly incompatible with using svn in scripts.
I think this is one of the things that broke when I added the access
batons, we don't have any regression tests for auth information. The
problem is that storing the auth data happens towards the end of the
operation, and the access batons do not all have the right lifetime.
> I'm using version r3316.
>
> To reproduce this behavior:
>
> 1 create a repository with two users that require passwords to even
> access it.
>
> 2 put some files and directories in the repository.
>
> 3 make sure both users are in sync with the prepostiry.
>
> 4 have user2 add a directory and file under the new directory
> to their working copy and commit it, e.g.:
>
> cd wc
> mkdir foo
> echo test > foo/test
> svn add foo foo/test
> svn commit -m'add dummy dir and file, test update & passwd' foo
>
> 5 have user1 update their working copy.
Don't you get an error at this stage? Something like
svn: Working copy not locked
svn: directory not locked (foo)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 19:32:20 2002