On 12/20/06 6:26 PM, "Erik Huelsmann" <ehuels@gmail.com> wrote:
> On 12/20/06, Steven Bakke <steven.bakke@amd.com> wrote:
>>
>> On Dec 20, 2006, at 3:02 PM, Erik Huelsmann wrote:
>>>> Hi all,
>>>
>>> Hi Steve,
>>>
>>>> The new problem I am having is related, but it is more
>>> important. This one
>>>> is related to 'svn add'. We have auto-props set to apply needs-
>>> lock for a
>>>> particular type of binary files we are working with. If user 'A'
>>> attempts
>>>> to run 'svn add' on a set of files that are owned by user 'B', we
>>> have a
>>>> problem when user 'A' tries to commit the add:
>>>
>>> The assumption in the working copy code is that the user using the
>>> working copy at least has write access to perform the operations he
>>> requests. What you describe here looks like you're (partially) not
>>> satisfying that requirement.
>>>
>> All users always have read/write permissions on the directories
>> within the
>> working copy. The only reason I run into this issue is that file
>> locking
>> involves changing permissions back and forth from writeable to read-
>> only.
>
> Ok. I must have misunderstood the situation. Why is Subversion unable
> to change the permissions, if the user has read+write access? Are you
> using Windows (which has an ACL system for read-only vs read-write)?
Sorry, I should have mentioned that I am working on Linux.
All directories in the working copy have user+group read/write/execute
permissions. This means that even if a user doesn't own a particular file
or have write permissions, they can move it or delete it if necessary.
The problem with lock/unlock is that the 'chmod' operation won't let you add
group write permissions if you don't own a file.(in the case of lock)
Similarly, it won't let you subtract group write permission if you don't own
the file. (in the case of unlock)
The problems occur when at the end of the commit operation, svn tries to
change permissions and fails. The only way I've found around this is to
move the file, copy it back, change the permissions on the newly owned copy
and then delete the moved file.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 21 03:09:46 2006