[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locking (was Re: CVS Transaction)
From: |
Russ Sherk |
Subject: |
Re: Locking (was Re: CVS Transaction) |
Date: |
Thu, 8 Sep 2005 15:48:01 -0400 |
On 9/8/05, Derek Price <address@hidden> 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.
Is the OP asking for a locking transaction or a shortcut for:
----------------------
cvs co sandbox
cvs tag -b trans-br sandbox
cvs up -rtrans-br sandbox
<edit>
test : cvs ci sandbox?rm -rf sandbox
[test :cvs up -A sandbox; cvs up -jtrans-br sandbox]
----------------------
in which case it is not absolutely necessary to lock and writeability
is not compromised any more than usual.
>
> It is one thing to put the repository's writabilty at the mercy of a
> server working as fast as it can to finish a single task, but to put it
> at the mercy of a user who might be interrupted by a phone call and
> leave their office while still logged in is quite another. Still, I
> suppose this could be solved with configurable transaction timeouts or
> ways admins could break a stalled transaction.
>
> 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.
Yes. How about:
start transaction <generate commitid/transid (1234)>
<edit>
<commit> - commitid=1234
<edit>
<commit> - commitid=1234
end transaction (clear commitid)
instead of 1 id per 'cvs ci'
and:
start transaction <user specified commt/trans-id (5678)>
<edit>
<commit> - commitid=5678
end transaction
instead of always generating an id. (this one is tougher because of
possible id confilcts).
Regards,
--Russ
>
> 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.
>
> Regards,
>
> Derek
>
> --
> Derek R. Price
> CVS Solutions Architect
> Ximbiot <http://ximbiot.com>
> v: +1 717.579.6168
> f: +1 717.234.3125
> <mailto:address@hidden>
>
>
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/info-cvs
>
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