Newbie CVS commitinfo question

[Bryan Bunch]

Hey everyone,

    I appologize in advance if this posted question appears twice on the 
list -- I initial posted it without joining (...my bad).

    I have a quick question about using the commitinfo admin file to 
perform a source-file check before commiting. Mabey the tool I should be 
using is Ageis (I've seen that project a lot in the archives), but what I 
want to do is have a script called at the beginning of the commit process 
which takes the following action:

1. Copy all submitted files from the /tmp/cvs<process-number> directory into 
a working directory on the CVS server associated with the user making the 
commit (the newly commited files would replace any files currently in that 
working directory).

2. Switch to that users working directory on the CVS server, and perform a 
"cvs update -A -d" to get the any previously submitted updates from the head 
of the repository.

3. Incrementally compile the whole project (this should result in only the 
currently submitted files and any modified files since the last commit being 
compiled).

4. Allow the commit to take place if the compile succeeds, or return a 
non-zero result and fail if the compile fails.

   This would be nice because it eliminates the problem of developers 
accidentally forgetting to add/ commit files which prevents other developers 
from being able to compile and test the project. It effectively guarantees 
that the head of the codebase will compile.

    The script to do this is straightforward -- and also doesn't work. It 
fails because trying to execute a "cvs update -A -d" command into another 
working directory on the server fails since the user trying to commit locks 
the entire repository (the command just hangs there with a message like 
..."trying to get lock from <user-name>").

    So my initial thought is "why shouldn't the same user that has a global 
lock on the whole repository also be able to execute read-only operations 
like update or checkout that don't modify the repository's state?" My guess 
is that it's simply easier to do lock management if locks aren't 
"same-user-re-entrant" and no other cvs operations are allowed once the 
commit starts.

    Anyways, if someone has a solution to this problem, I'll worship you 
like the software God/Godess you are! Also -- if for some reason I were to 
think about jumping into the code and making locks "same-user-re-entrant" 
during a commit, would anyone be interested in a source patch? Or is that a 
waste of time?

---Bryan


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com