Re: Newbie CVS commitinfo question
Greg A. [EMAIL PROTECTED] (Greg A. Woods; Planix, Inc.) writes: > > [ On Friday, July 12, 2002 at 16:54:15 (-0700), Bryan Bunch wrote: ] > > > > 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. > > What does user identity have to do with repository integrity? The > repoisitory is not likely in a consistent state when it's locked. It > doesn't matter who locked it or who's trying to access it. Exactly. The "right" solution to the problem is to enhance CVS's locking to allow read locks to be "upgraded" to write locks and write locks "downgraded" to read locks. That way, long-running processes can take out read locks to ensure the tree stays consistent without locking out other users except when actively updating RCS files. -Larry Jones I think grown-ups just ACT like they know what they're doing. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newbie CVS commitinfo question
[ On Friday, July 12, 2002 at 16:54:15 (-0700), Bryan Bunch wrote: ] > Subject: Newbie CVS commitinfo question > > 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: No, you really do want to be using Aegis. http://www.canb.auug.org.au/~millerp/aegis.html Trying to do what you want to do with CVS is only going to end up being a bad hack. > 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. What does user identity have to do with repository integrity? The repoisitory is not likely in a consistent state when it's locked. It doesn't matter who locked it or who's trying to access it. -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Newbie CVS commitinfo question
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 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 "). 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 worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
