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:09:59 2007