You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by HuiHuang <ye...@yahoo.com.cn> on 2009/07/29 09:36:12 UTC
commit desing based on wc-ng
Hey,
1. Detect different working copies sensibly.
For each path following commit command, we find its corresponding base node
in sqlite database and then we could use repos_id to identify whether the
paths are from the same repository.
2. Lock commit items smartly.
I find the following comments about the lock mechanism in
notes/wc-ng-design:
* Single working copy lock. Should we have one lock which locks the
entire working copy, disabling any parallel actions on disjoint
parts of the working copy?
* The lock strategy requires writing a file in every directory of a working,
which severely reduces our performance in several environments. (Windows,
NFS). Testing showed that in some cases we used more than 50 seconds on
writing 8000 lockfiles before we even started looking what to update. A new
lock strategy should reduce the number of writes necessary for locking with
depth infinity.
The second issue can be avoid because we use a central database to store
lock information. So I think there could be three kinds of lock strategies:
2.1 Single working copy lock. Every lock action just needs to mark/check
the working copy root. The fault is that it disables any parallel
action. But I think it is not a big problem since that we usually are
one-wc-per-people and there are few parallel actions, agree? And it is
easy to implement. Maybe it is too simple for us.
2.2 We can use the lock mechanism used in database(share lock/ exclusive
lock/ intent share lock/ intent exclisive lock/ share intent exclusive
lock). In this case the *depth* option may be useless. It will save us
a lot of time to detect whether a subdir is locked and can support
parallel action well.
2.3 Use the current lock strategy. It can lock the working copy according
depth, but it will take more time than 2.2.
*The following parts I have no ideas right now and I will complement it soon.
And any suggestions are welcomed, thank you:)*
3. Collect commit items.
4. Do commit.
5. Post commit.
Best Regards
Huihuang
--------------
yellow.flying
2009-07-29
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2376535
RE: commit desing based on wc-ng
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: dinsdag 4 augustus 2009 12:31
> To: Andy Bolstridge
> Cc: dev@subversion.tigris.org
> Subject: Re: commit desing based on wc-ng
>
> 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.
Note that committing externals with a parent working copy sometimes works,
because some checks in the commit runner are not strict enough. (You can
check this behavior with depth empty; then pass the individual files you
like to commit.. All selected files and the common parent must be in the
same repository.)
At least this works with 1.4.x-1.6.x. And because depth is not infinity some
types of changes (e.g. deletes of directories) don't work.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2379959
Re: commit desing based on wc-ng
Posted by Stefan Sperling <st...@elego.de>.
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
RE: commit desing based on wc-ng
Posted by Andy Bolstridge <an...@bolstridge.plus.com>.
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