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

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-15 01:45:01 CET

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 Fri Dec 15 01:48:58 2006

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