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