Sorry about taking so long to reply, I got diverted onto a bunch of other
I am well aware that requiring locks on all file types is not using
Subversion as is intended, but based on the way our company works on
projects, and the technical proficiency of some of the users, I made the
decision to add locking. The way our projects and workstreams are structured
and run means that in general, only one person works on a particular
workstream/code base at a time. I intend to relax the restrictions to allow
merging on code files at a later date, but for the initial implementation, I
wanted to keep things fairly straight forward for the users. I am not
concerned about people stealing each other's locks, if they need to do so,
they can, and should sort out the issue with the user who had the files
locked, and do a manual merge if neccessary.
In my experience, you cannot delete a file if you do not own the lock on the
file, and I have deleted/re-added many files without hitting the problem I
described. I would like to know why it happened though, so it can be
prevented from happening in future. I'm not sure if it's a bug or user
error, but if I get more information on the problem, I'll report it. I do
think however, that it's a situation that shouldn't be allowed to come into
existance. If a file is deleted, I would think that any locks on the file
should be released?
*Ivan*: Thanks for the pointers, I'll look into those commands and see if
they help to unlock the deleted files.
On Wed, Dec 3, 2008 at 6:16 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> On Tue, Dec 2, 2008 at 5:29 AM, Giulio Troccoli <
> Giulio.Troccoli_at_uk.linedata.com> wrote:
>> I don't completely agree with you.
>> It's true, Subversion uses a different, maybe more modern, approach to
>> version control. But since it implements a sort of locking mechanism, then
>> it should work correctly.
> I'm not arguing against the concept of locking. Locks are perfect for file
> types that cannot be merged. It prevents someone else from editing a file
> while you are working on it. If you can't merge changes, being unable to
> lock a file means losing your work when someone beats you to a commit.
> However, requiring a lock before deleting doesn't do this. By definition,
> deleting a file means you're not making changes to a file that I might have
> to merge my changes into. I can always get the file back, so there's no
> reason to prevent someone from deleting a file without first locking it. If
> I am working on a file that someone else deletes, I can recreate that file,
> and put in my changes without worrying about merging.
> David Weintraub
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2008-12-19 20:43:05 CET