[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

commit desing based on wc-ng

From: HuiHuang <yellow.flying_at_yahoo.com.cn>
Date: Wed, 29 Jul 2009 17:36:12 +0800


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
 * 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


Received on 2009-07-29 11:38:06 CEST

This is an archived mail posted to the Subversion Dev mailing list.