RE: commit desing based on wc-ng

My suggestion is to keep it real simple. Simple is good.

If multiple locking is needed, perhaps the simplest solution there is to lock all WCs according to the repository path - if a lock is held on a directory, you cannot lock on a subdir; but you can create a new lock for an unrelated directory.

eg.

repo has:
  trunk/project1/subdirA

someone commits to project1, and they then try to add to subdirA whilst the commit is in-progress. This will block as subdirA is part of the lock path. (a simple comparison of the paths should be sufficient to detect this).

If they try to add to project2 however, this is fine - a new lock is created for that operation.

This doesn't solve the problem if a user has a WC embedded inside another WC - eg, they have subdirA/test/Project2 checked out. But I'd argue that this situation isn't a very common one, and isn't good practice. The worst that happens is that the unrelated embedded WC is locked for the duration of other operations.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2379940
Received on 2009-08-04 12:13:15 CEST