Ryan Thompson
2013-06-18 00:49:40 UTC
Hello,
I have a verifymsg script that runs the changed source code hunks
through a series of checks, exiting with an error if any of those checks
fail. In order to determine what has been changed, the verifymsg script
runs "cvs diff" (without any filename arguments) and parses that output.
I'm aware that locking is already enabled by the time verifymsg is run.
However, if a plain "cvs commit" or "cvs commit -m 'message'" is run,
the diff works fine without any errors or warnings. If instead "cvs
commit file.c" is run (even if file.c was the same file that would have
been implicitly checked in by the plain "cvs commit"), the whole thing
deadlocks with the usual message:
cvs diff: [00:32:20] waiting for username's lock in
/path/to/repo/module
I'm not surprised by this, but I am surprised that it works when no
explicit filenames are given to commit.
More to the point, how can I circumvent the locking for this use case so
I can get cvs diff output in verifymsg?
Thanks,
- R
I have a verifymsg script that runs the changed source code hunks
through a series of checks, exiting with an error if any of those checks
fail. In order to determine what has been changed, the verifymsg script
runs "cvs diff" (without any filename arguments) and parses that output.
I'm aware that locking is already enabled by the time verifymsg is run.
However, if a plain "cvs commit" or "cvs commit -m 'message'" is run,
the diff works fine without any errors or warnings. If instead "cvs
commit file.c" is run (even if file.c was the same file that would have
been implicitly checked in by the plain "cvs commit"), the whole thing
deadlocks with the usual message:
cvs diff: [00:32:20] waiting for username's lock in
/path/to/repo/module
I'm not surprised by this, but I am surprised that it works when no
explicit filenames are given to commit.
More to the point, how can I circumvent the locking for this use case so
I can get cvs diff output in verifymsg?
Thanks,
- R