On Tue, Aug 04, 2009 at 03:09:48AM -0700, Andy Bolstridge wrote:
> My suggestion is to keep it real simple. Simple is good.
Yes.
> 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.
Embedded WCs happen all the time when people switch subtrees to different
branches, or when they use externals. Committing to switched subtrees
at the same time as their parent working copy does already work today,
so we cannot break this. Committing to externals at the same time as
their parent directory does not work right now, but I don't see why we
should not fix this with WC-NG.
So while I think one lock per WC is good enough, I don't think comparing
paths is a good strategy for managing the locks. We should be using the
working copy DB handles to key our locks.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2379945
Received on 2009-08-04 12:31:31 CEST