[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Newbie CVS commitinfo question

From: Bryan Bunch
Subject: Newbie CVS commitinfo question
Date: Fri, 12 Jul 2002 16:54:15 -0700

Hey everyone,

I appologize in advance if this posted question appears twice on the list -- I initial posted it without joining ( 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?


Join the worldÂ’s largest e-mail service with MSN Hotmail.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]