[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: permissions and "object of the same name already exists"

From: Garret Wilson <garret_at_globalmentor.com>
Date: Sun, 11 May 2008 16:49:13 -0700

The only way to fix this seems to be to remove all the offending
directories. Make sure the root repository is *not* public, or that will
cause all sorts of problems:

[repo:/]
@developers=rw

Then after removing each offending directory, do a "svn up".

The bad thing seems to be setting the root of the repository to allow
anonymous access if there are subtrees that are not public. Still it
seems like the contortions that the repository can get into, in which
the user can't easily be specified and where local directories aren't
seen as being in the repository (even though they have .svn information)
and then when the user changes are seen as blocking updates, could be
improved upon.

Garret

Garret Wilson wrote:
> ..and just to show you how bad this is, I go to
> C:\repo\src\example\secret and do a "svn status", and I get just what
> I would expect (only one file is modified in the entire secret subtree):
>
> M Example.java
>
> But then I do a "cd .." to move to C:\repo\src\example (the parent of
> the secret subdirectory), and I get:
>
> ? secret
> ! .
>
> I'm stuck; how can I fix this?
>
> Garret
>
> Garret Wilson wrote:
>> I've used Subversion since the beta days, and I've never ran into
>> such a problem as this. I open-sourced part of my repository tree so
>> I changed the permissions to:
>>
>> [repo:/]
>> @developers=rw
>> *=r
>>
>> There are still some subtrees I don't want to be seen by the world.
>>
>> [repo:/src/com/example/secret]
>> @developers=rw
>> *=
>>
>> (Several other permissions combinations were tried in the process.)
>>
>> So I go to Subclipse and do an update. Somehow Subclipse now thinks
>> that it can check out the whole repository anonymously, which means
>> that it no longer sees src/com/example/secret on the server, so it
>> thinks the local copies are unversioned (even though they still have
>> their .svn directories)! So when I try to commit, it shows all the
>> secret directories as need to be added and checked in!
>>
>> Going to the svn command line, I do a "svn --username myuser up" to
>> try to get it to switch back to my user and recognize that the secret
>> directories are already in the repository. It seems to do an update,
>> but Subversion thinks that all the secret directories are still
>> unversioned.
>>
>> So I decide to remove public access to *everything* and force
>> Subversion to use my username and see the private user-based view
>> instead of the anonymous view:
>>
>> [repo:/]
>> @developers=rw
>>
>> I do another "svn --username myuser up". The situation is now worse:
>> I get:
>>
>> "svn: Failed to add directory 'src\com\example\secret': object of the
>> same name already exists."
>>
>> So it thinks it will overwrite my local versioned information with
>> the information of the same version on the server!
>>
>> How can I un-hose my local repository? And how can I set up my
>> repository for read access except for certain secret subdirectories,
>> and still allow myuser to do commits to the secret subdirectories?
>>
>> Garret
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-12 01:49:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.