Sorry, but my first paragraph got chopped off somehow... Continueing the
last sentence.
It is probably only in a minority of setups that people would use file
lock/unlock. The way that subversion has been set up to work, a lock
operation makes a file writeable and the unlock operation makes it
read-only. The presence or absence of a lock is intended to communicate
when somebody is editing in a different work area. It really ought to
handle file ownership and permissions properly if it is going to be changing
permissions in the first place.
-Steve
On 1/12/07 11:06 AM, "Steve Bakke" <steven.bakke@amd.com> wrote:
> Hi all,
>
> In a previous set of posts, I described problems I was having with svn
> lock/unlock not handling file ownership in version 1.4.x. Because you need to
> own a file in order to make it read-only, subversion will not unlock or lock a
> file that is owned by another user. This is in a case where all of the
> directories have proper group Œrwxą permissions. The consensus of the few who
> responded was that my usage model is flawed. My response to that is that in
> the case you are using file lock/unlock,
>
> I have now run into another problem related to the same issue. This time, it
> is related to committing files which have been locally added with the
> needs-lock property. Here is the sequence of events:
> 1. User A copies some new files into a working copy.
> 2. User B runs Œsvn addą on these. So far so good...
> 3. User B tries to run Œsvn commitą on the added files.
>
> Step three actually goes through 95% of the commit process and actually sends
> the data to the server. Finally, when the svn client attempts to change the
> file permissions on the files with needs-lock, the whole commit fails because
> it can't change permissions. User A owned the file.
>
> Correct me if I'm wrong, but commits are supposed to be atomic, correct? If
> my commit fails, I would have thought that the repository should not have a
> new committed revision. However, if I try to have User B commit these
> results, it then fails because it says the files already exist in the
> repository. Now my working copy is seemingly corrupted since all of the files
> have 'A' status, yet they actually got checked in.
>
> Could somebody please help me here?
>
> I would really like to file a bug on the file lock/unlock ownership issue.
> Why should this not be fixed? I believe it could be done without impacting
> working copy performance of those who don't have mixed file ownerships in the
> working copy.
>
> Thanks,
>
> Steve Bakke
>
> p.s. At what point can I just go ahead and submit a bug on an issue? Just
> because people donąt agree with my particular usage model doesnąt mean that
> there isnąt a bug in subversion. It At a minimum, I think it would be useful
> to document real bugs even if the development team chooses not to fix the
> problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 12 17:15:08 2007