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/
layout.cdb
master.tag
pc.db
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?
-Steve
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