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)?
> > The requirement has always been there (ie the 2 users must be in the
> > same group and have group write perms), but with the working copy
> > optimizations in 1.4, the issue has become more visible. I don't feel
> > this is a bug, even though your use-case may have worked with 1.3: we
> > fixed many (but surely not all) performance problems in our working
> > copy code even though we remain slow from a users perspective. I don't
> > think that your use case is sufficiently common enough (or even
> > sufficiently compatible with Subversion philosophy of 'everybody his
> > own work(ing copy)') enough to revert these performance optimizations
> > and go back to the old days.
> I'm not suggesting that we go back to the old days. However, I
> believe that
> subversion should handle the situation gracefully. The problem with
> 'svn lock'
> and 'svn unlock' at least doesn't hose the working copy.
Ok, but, then the question above becomes important: why isn't svn
allowed to change the permissions? I mean, it's not the lock/unlock
operation itself, because that is a repository/server side operation.
[ snip the symptoms for now ]
I'm sorry if I'm being dense...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 21 00:27:36 2006