> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_at_hyrumwright.org]
> Sent: woensdag 30 september 2009 23:09
> To: Greg Stein
> Cc: dev_at_subversion.tigris.org
> Subject: [PATCH] Move .svn/lock files into the sdb
>
> Greg, et. al.,
> The attached patch is an attempt to move the .svn/lock files into a
> separate table in .svn/wc.db. The reason to do this is so that we can
> use the sdb to manage the locked status of a directory, particularly
> as we start using svn_wc__entry_modify2(), which currently does *not*
> do a write check on the access baton. Eventually, I plan to add a
> member to pdh->wcroot which moves the in-memory state from the access
> baton to wc_db.
This patch doesn't solve the issues with svn_wc__entry_modify2().
This patch answers the question: "Is there a lock on X?" while we have to
check "Am I the owner of an existing lock on X?" or simpler "Do I own a lock
that allows me to update X?"
This ownership question is the only important bit when updating a working
copy.
We are not interested in whether another client has it locked in this case..
We simply can't do an exclusive update without being the lock owner.
If an exclusive update in Process 1 does a recursive switch on the entire
working copy from one branch to another, you don't want another svn (Process
2) performing a move of a file below that same root at the same time..
The "Is there a lock?" will just return TRUE... so the revert might be
perfectly valid after this patch, but it could very well corrupt your
working copy.
A "Am I the lock owner?" check will return FALSE, so the revert will not
happen.
Your recent changes replaced a few of the "Am I the lock owner?" questions
with "Is there a lock?" and this new api makes it easier to do the WRONG
THING.
Moving the lock files in the DB is a completely different thing, that is
unrelated to this question, and something that should+could happen
independently
If we want multiple locks on a working copy later we could just write the
locked roots in a db table and keep a record on the locks we own. Every path
below a locked path is locked by the wc_db. (Very cheap to check as we
usually just lock one path.. so one dirent_is_ancestor() check is enough).
(A proper transaction around inserting the lock can handle parent and child
locks without the extreme penalty we have in WC-1.0)
We could write a process identifier + workstation name or something with the
lock in the db to specify who owns it for better error messages, but the
real knowledge is in owning the lock itself... which is currently only
handled via the flag in the access batons. And you can't just put that
knowledge in the database and think you're done with that.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402423
Received on 2009-10-01 11:51:34 CEST