[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking (was Re: CVS Transaction)

From: Paul Sander
Subject: Re: Locking (was Re: CVS Transaction)
Date: Thu, 8 Sep 2005 14:48:32 -0700

On Sep 8, 2005, at 11:18 AM, Derek Price wrote:

Paul Sander wrote:

It can be done with intent mode locks and some simple manipulation of
the RCS files.  Intent mode locks allow concurrent access by readers
while copies of the RCS files are updated.

Intent mode locks at the directory level exist on feature, but I believe the issue that was raised is that if a client started a transaction, any
file they touched would be locked against write until the user typed
"end transaction".  I don't believe your answer avoids this.

Depends on how it's implemented. If the bracketed commands are stored and the actual transaction with the server begins when the user types "end transaction" then the condition you describe is avoided. This could lead to other potential problems, e.g. if one bracketed command changes the state of the repository and subsequent commands rely on that state change to make decisions that direct further state changes. There are ways to mitigate this: One is to disallow this type of decision making, another is to allow transactions only via some batch mode where user interaction is not permitted.

But, I can  think of two other ways to add transactions, at least for a
single CVS operation at a time, and one is pretty simple and the second
is at least simpler than the major rewrite you describe.

1)  Lean on the new commitids on feature.  If a commit fails part way
through, then use the commitids to back out the successful parts of the
commit as part of cleanup.

How does this help with other state changes, e.g. the creation or migration of tags?

2) Move the archive storage (i.e. RCS files), optionally (as configured by a server admin), into a transaction-capable database like PostgresSQL
and lean on that.  All that would need to be replaced is the RCS API,
and it could be transparent to most of the program whether the "RCS"
functions it is calling reads from a file system or DB.  Then the only
new portion of the API visible to most of the program would be something
like RCS_start_transaction, RCS_end_transaction, &
RCS_abort_transaction, which would make the DB start/end/abort
transaction calls as necessary.

But then we lose the human-readable property of the repository, which some consider to be one of CVS' greatest strengths.

The method that I propose addresses both of these concerns. Thinking about it further, I think that the intent-mode and write-mode locks on module/branch pairs can be weakened further so that concurrent transactions can be permitted as long as the sets of RCS files involved in each one don't overlap. This involves yet another trade-off in which transactions don't complete in the same order in which they initiate, which has implications when fetching by timestamp. I don't have a good feel as to whether or not this would be a serious problem, though, given that other conditions provoke the same behavior. But given the sparse and distributed nature of the locks created by this method would increase throughput even further.

Another strength of fine-grain, cheap locks like what I propose is that they fix a scalability problem that arises when a sandbox is populated piecemeal from files scattered around the repository, and the repository is subsequently updated from such a sandbox. What happens is that the set of files affected by the locks is much greater than necessary. This is the very problem that tools such as meta-cvs and dcvs must solve when mapping RCS files to their counterparts in the sandbox. Those who have read info-cvs for any length of time know that CVS' inability to rename a file is one of my hot buttons. Locking using a method like the one I propose makes implementing such a feature a lot easier. Moving the repository to a relational database does, too, but I assume that such a move would be shot down by much of the user community.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]