Re: advisory locks patch

[Matthew M. Ogilvie]

Derek Price,
     I've made a minor update to the advisory lock patch.  See
notes below, and the link:

http://sourceforge.net/tracker/index.php?func=detail&aid=822306&group_id=20011&atid=320011

--
Matthew Ogilvie

================================

August 2004:
Compared to February version below:

- Updated to work against the current development version of CVS.
- The two semi-related bug fixes have already been incorporated
  into CVS.  They are no longer included in the patch.

Although these have been this way for a long time, the things most
likely to prevent incorporating this patch at this time are:

- "cvs edit file" will now intentionally output information about
  pre-existing edits for "file", even if the "-c" option is not used.
  It means that two of the pre-existing test cases (watch4-11 and
  unedit-without-baserev-11) had to be modified.
      It is conceivable someone will not like this change, but I
  think it is best.  It could probably be put back, but this
  change is intermingled with the rest of the advisory lock patch
  and can't be realistically separated without removing it
  completely.
- Internally, remote "cvs edit" has a somewhat hackish way of
  looking for pre-existing edits, based on overriding handling of
  "M" messages in the client-server protocol parser.
      It might be better to switch to something based on
  tagging the response to "cvs editors" with one or more "MT" messages
  instead.  But the current version allows "cvs edit -c"
  (but not "cvs commit -c") to work even if the server does not have
  this patch.

================================
February 2004:

This is a new version of the advisory-lock (edit -c) patch, updated
to work with the current main CVS source tree as of 21 Feb 2004.

The previous version was dated 2 years ago (25 Feb 2002), and in the
past it eventually derives from Yap Noel's edit-check/reservations
patch.

This patch includes documentation and test cases.

It is broken into various sub-patches, clearly seperated with
big blocks of hash marks ("##..."):

- Two small fixes to sanity.sh to fix some problems in some unusual
  environments.  These fixes are rather independent of the advisory
  lock patch itself, and can be left out if desired.
- Fix a subtle problem with (client/server) "cvs release" where it
  sometimes overwrites the CVS/Entries file in the current
  (invocation) directory with data from a subdirectory.
- Remove item 180 from the TODO list, since the advisory lock
  patch implements it as a side effect.
- The main part of the advisory lock patch, with documentation
  and test cases.

At the present time (21 Feb 2004), test "taginfo-examine-1" fails on
my machine both with and without this patch (working from current
development source code).  It is clearly not related to what I am doing,
and the intent of the test is not immediately obvious, so I am ignoring
the problem.

For additional comments, see notes from the 25 Feb 2002 version of
this patch.

############
Links:

  # Current version:
http://sourceforge.net/tracker/index.php?func=detail&aid=822306&group_id=20011&atid=320011
  # Ancient original version:
http://sourceforge.net/tracker/index.php?func=detail&aid=822337&group_id=20011&atid=320011

  # If the direct links fail, follow the "patches" link from:
http://sourceforge.net/projects/cvsenhancements/

================================
> Date: Tue, 24 Aug 2004 23:06:03 -0400
> From: Derek Robert Price <derek@ximbiot.com>
> To: "Paul Gelderblom (ptok)" <paulg.xlbspam@xs4all.nl>
> Cc: "Matthew M. Ogilvie" <mmo9317bd@mailcan.com>, bug-cvs@gnu.org
> Subject: Re: advisory locks patch
> 
> Hi Paul,
> 
> I finally found some time to spend with this patch again and it
> wouldn't apply to the trunk.  (I've applied everything except the
> major portion - the edit -c portion itself).  The patch did not apply
> cleanly to the trunk and after I resolved the conflicts as I thought
> appeared obvious, I ran `make check' to get a failure in watch4-11.
> 
> If you could solve the conflicts in such a way that the patch applies
> cleanly to the trunk and the tests pass, then send me a new patch, it
> would be very helpful.  I would really like to see this in 1.12.10,
> but I don't know if I will have the time to get to the root of the
> problem myself.   If you can't, I will get back to this as soon as I can.
> 
> Cheers,
> 
> Derek