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

Working copy permissions problems Take 2 (was: Re: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x)

From: Steve Bakke <steven.bakke_at_amd.com>
Date: 2006-12-20 19:04:47 CET

Hi all,

The original problem that I posted about had to do with permissions problems
when trying to do Œsvn lock¹ on a file that somebody else owns. On that
subject, I still think that subversion should work properly under those
conditions. I would like to submit a bug for that one. As somebody
suggested below, code could first check to see if the file is owned by the
person locking ­ if not, assume ownership first and then lock.

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:

% svn commit ­m ³New stuff commit² newdir
Adding newdir
Adding newdir/layout
Adding (bin) newdir/layout/layout.cdb
Adding newdir/layout/master.tag
Adding newdir/layout/pc.db
Transmitting file data ...svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory '/.../newdir/layout'
svn: Error processing command 'committed' in '/.../newdir/layout'
svn: Error replacing text-base of 'layout.cdb'
svn: Can't change perms of file '/.../newdir/layout/layout.cdb': Operation
not permitted

Similar to the Œsvn lock¹ command, it failed to change the file permissions
(to read-only) on the file that has the needs-lock property. The worst part
about this is that it succeeds in committing the data into the repository,
but it leaves the working copy in a strange state:

% svn status /.../newdir/layout/layout.cdb
A /.../newdir/layout/layout.cdb
% svn ls svn+ssh://(repos_url)/newdir/layout/

So now the data is in the repository, yet it shows up with status of ŒA¹ in
the working copy. Reverting isn¹t the right answer as all this does is to
change the status to ³?². It isn¹t under revision control at that point.
The only fix that I see is to delete the local working copy Œlayout¹
directory and run Œsvn up newdir/layout¹.

This seems to clearly be a bug and it is not something I want to workaround
in a wrapper script.

Any thoughts?


On 12/14/06 7:45 PM, "Steve Bakke" <steven.bakke@amd.com> wrote:

> It¹s not my choice whether or not to have a shared working copy. Whether or
> not this is the best working model isn¹t really the question. The reasons for
> choosing a central working model are mainly so that the current state of
> things are visible. In reality, only a small number of people would be
> working in the same working directory.
> I¹d rather not get caught up in a philosophical discussion on that issue,
> since that part is out of my control. Does this or does this not seem to be
> a bug in subversion 1.4.x? I believe that it is. My problem is that I may be
> the only person to care about it. It is a clear change in behavior from
> previous versions that I don¹t think was intentional.
> -Steve
> On 12/14/06 7:02 PM, "Tim Hill" <drtimhill@comcast.net> wrote:
>> I'm with Garrett on this one -- I think you should carefully think about if
>> what you're doing is the correct approach. Basically, by sharing a working
>> copy you are moving outside of the "comfort zone" for Subversion workflows,
>> and this is really why you are seeing this problem.
>> That aside, it does look like you have identified a change in behavior in
>> 1.4.x, though I'm not sure if I would class this as a bug or a bug fix <g>.
>> You might try opening a bug or checking the bug database to see if this was a
>> "by design" change.
>> --Tim
>> On Dec 14, 2006, at 12:43 PM, Garrett McGrath wrote:
>>> These btw should be getting cc'd to the subversion user list.  and that
>>> sounds like what versions vs. trunks are used for really...
>>> -Garrett
>>> From: Steve Bakke [mailto:steven.bakke@amd.com]
>>> Sent: Thursday, December 14, 2006 3:34 PM
>>> To: Garrett McGrath
>>> Subject: Re: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x
>>> No, the repository is the method for checkpointing revisions just as with
>>> private working copies.  We also publish releases in a different area which
>>> are tied to tagged versions in the repository.  The only difference is that
>>> there may be multiple people editing data in the same working copy.
>>> Our central working copy (we actually have at least two separate ones) only
>>> has the latest version of things.  It doesn¹t contain all revisions.  When
>>> we need to work with stable data such as to do a build, we checkout data
>>> into a private working copy (either from tag or trunk).
>>> -Steve
>>> On 12/14/06 3:07 PM, "Garrett McGrath" <gmcgrath@Princeton.EDU> wrote:
>>>> yes but what your trying to do seems counter intuitive to the way
>>>> subversion is setup to operate is what it appears like to me.  That's all
>>>> i'm really saying.  Basically you take subversion put it 'somewhere'
>>>> using svnserve or apache, then everyone checks out a copy locally that they
>>>> work on.  When you lock a file that lock is actually done in the svn
>>>> repository not the working directory.  People who don't own the lock
>>>> can't commit a file involved with that lock to the repository because it's
>>>> locked not based on the permission system that's in place.  when you
>>>> check out a copy from the repository all files become 'yours' (to my
>>>> understanding at least).  So you should under this model be replacing the
>>>> shared working area with the physical repository (because that's what it is
>>>> anyway) and then have the people involved check out thier copies locally to
>>>> work on them.
>>>> This is just my understanding as to how subversion is 'supposed' to work.
>>>>  If this was working for you before hand then i dunno what i can say to
>>>> help you there but it's not really a bug if it's not part of the way
>>>> subversion is supposed to work in the first place.
>>>> -Garrett
>>>> From: Steve Bakke [mailto:steven.bakke@amd.com]
>>>> Sent: Thursday, December 14, 2006 2:46 PM
>>>> To: Garrett McGrath
>>>> Subject: Re: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x
>>>> That decision wasn¹t mine. :^)  I would prefer to have private work
>>>> areas.  Subversion just happened to be the choice that I made to use for
>>>> revision control.
>>>> I mainly want subversion as a better CVS that handles binary data nicely.
>>>> -Steve
>>>> On 12/14/06 2:41 PM, "Garrett McGrath" <gmcgrath@Princeton.EDU> wrote:
>>>>> Steve,
>>>>> umm... i'm confused as to 'why' your doing this.  I  mean i've used a
>>>>> single working copy to handle my server config file backups,  but in
>>>>> development it seems more practical that the developer just check out
>>>>> a  copy for him self as sharing a working copy seemingly eliminates
>>>>> what svn is  actually designed to be used for.
>>>>> -Garrett
>>>>> From: Steve Bakke [mailto:steven.bakke@amd.com]  
>>>>> Sent: Thursday, December 14, 2006 2:31 PM
>>>>> To:  users@subversion.tigris.org
>>>>> Subject: File permissions behavior  change from 1.2.3/1.3.0 to 1.4.x
>>>>> I attempted to first raise this issue on  the subversion users¹
>>>>> mailing list a week or two ago, but got no response.   I¹m pretty
>>>>> confident that this is a bug or at least it is an  undocumented change
>>>>> in behavior from prior releases.
>>>>> We have a setup  where there is a centralized working copy accessed by
>>>>> multiple users.  As  a result, having the correct permissions set on
>>>>> things makes or breaks this  working model.  Our working copy
>>>>> directories are all set up to have  read+write user and group
>>>>> permissions.
>>>>> We are working with a number of  binary files that we have set up to
>>>>> have needs-lock properties.    Prior to subversion 1.4.0, the behavior
>>>>> of the Œsvn lock¹ command  was such that the user executing the
>>>>> command would assume ownership of the  file and get write permissions.
>>>>>  Effectively, it would delete the  original file in the working copy
>>>>> and then copy a fresh version in place. (at  least this is what it
>>>>> appears to do)  It works this way in both 1.2.3 and  1.3.0.
>>>>>  Meanwhile, svn unlock leaves the file read-only across the board.  
>>>>> With 1.4.0, it now reports an error that it can¹t change the file
>>>>>  permissions. (I believe it is also the same with 1.4.2)  This is a
>>>>> pretty  significant change in behavior.  I imagine that most people
>>>>> haven¹t  noticed since most people use private working copies.
>>>>> Can somebody  confirm that this is a bug?  It is very easy to
>>>>> reproduce. We managed to  work around the issue, but it¹s an ugly hack
>>>>> to a wrapper script to move the  file and copy it back so that the
>>>>> user can assume ownership and call Œsvn  lock¹.  If somebody wants to
>>>>> lock a large number of files, it takes a lot  longer now.
>>>>> Thanks,
>>>>> Steve Bakke
Received on Wed Dec 20 19:06:25 2006

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