[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.
Message not available
- Re: CVS Transaction, Mateusz [PEYN] Adamus, 2005/09/08
- Re: CVS Transaction, Andy Jones, 2005/09/08
- Re: CVS Transaction, Mark D. Baushke, 2005/09/08
- Re: CVS Transaction, Andy Jones, 2005/09/08
- Re: CVS Transaction, Todd Denniston, 2005/09/08
- Re: CVS Transaction, Larry Jones, 2005/09/08
- Re: CVS Transaction, Paul Sander, 2005/09/08
- Re: CVS Transaction, Mark D. Baushke, 2005/09/08
- Re: CVS Transaction, Paul Sander, 2005/09/08
Re: CVS Transaction, Larry Jones, 2005/09/08