[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user

[Jesse Hopkins]

Follow-up Comment #3, bug #23370 (project cvs):

This is severely impacting our workflow.  Our group does a lot of development
in graphical, model-based software tools, and those files cannot be merged
easily.  We rely heavily on cvs-edit commands, and the fact the the edits are
being cleared is causing us lots of grief.

I have attempted to create a workaround using the CVS scripting hooks, and
I've got a solution that almost works, but doesn't quite make the cut.

Here is an overview of what I've attempted so far.  CVS stores the edit/watch
info inside the repository in CVS/fileattr files for each directory in CVS. 
The "notify" administrative file allows programs to be run whenever a user
performs cvs-edit or cvs-unedit.  I was able to create a perl-script that was
run via notify that created a copy of all fileattr files affected by the
unedit or edit command.  The fileattr files were copied into a
"fileattribbackup" subdirectory of CVSROOT, which mimics the directory
structure of the actual repository.

The next step is to then copy the "backup" fileattr files stored in CVSROOT
into the repository whenever a user performs a checkout, which can be
performed by specifying the perl script to run in the "modules" file.

Now, the problem I'm facing is that when my script is called from "notify",
CVS has not yet modified the fileattr files, so the files that get copied into
the CVSROOT backup area are basically 1-rev behind.  This is my major
roadblock at this point.  Does anyone have better ideas of how to handle
this?

Another idea I was throwing around was to monitor all of the "fileattr" files
for changes in a continuously running process, which would copy them to the
backup location when they change.  Then the checkout script could run as
before.  This seems like asking for trouble (at least more than the previous
solution), because then I need to deal with cvs locks and such.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?23370>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/