automatic checkout
Hi, I want to use cvs for a directory that contains scripts. I don't want everyone to change the scripts in the directory: I won't have accountability. Thus, it is under cvs. People should check out, change, and submit. I don't want them to write to the directory itself, because they will forget to check in. I would like changes to propagate to the script directory immediately. Everytime someone commits, an update would be executed in the script directory. Is that possible? I have tried a loginfo script, but there is a problem with the locks: the cvs update runs when the commit has not released the lock yet. I have looked on the web and found some references, but nothing very satisfactory. I have seen ACU, but it seems more concerned with managing multiple machines (which is not a problem), than with the lock. I have also thought about putting a pause into the script that does the update, but that does not seem very safe, not do I know how to do it. (My shell programming is bad, and I don't know how to spawn a process from loginfo.) Is there a good solution for this? Should I consider a different setup? Thanks, Roderick Bloem ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automatic checkout
Roderick Bloem [EMAIL PROTECTED] writes: I want to use cvs for a directory that contains scripts. I don't want everyone to change the scripts in the directory: I won't have accountability. Thus, it is under cvs. People should check out, change, and submit. I don't want them to write to the directory itself, because they will forget to check in. That sounds like a people managment problem... I would like changes to propagate to the script directory immediately. Everytime someone commits, an update would be executed in the script directory. Is that possible? Not directly as the loginfo script is being run while you have all of your commit locks. I have tried a loginfo script, but there is a problem with the locks: the cvs update runs when the commit has not released the lock yet. Correct. I have looked on the web and found some references, but nothing very satisfactory. No surprise there, there is no 'magic bullet' in this case. I have seen ACU, but it seems more concerned with managing multiple machines (which is not a problem), than with the lock. I have also thought about putting a pause into the script that does the update, but that does not seem very safe, not do I know how to do it. (My shell programming is bad, and I don't know how to spawn a process from loginfo.) Spawning a process from loginfo for this purpose is a bad idea as it will wait for its children before clearing the lock. Using tricks to background a grandchild process might work, but may not be reliable in all cases. Is there a good solution for this? Should I consider a different setup? I suppose you could have e-mail notification sent to an e-mail address for which the .procmailrc (or equivalent) will always do a 'cvs update' on the script directory if it sees any mention of the script directory in the log message... Good luck, -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automatic checkout
How about a script on a cron job that periodically (whatever granularity you require from 1 minute to 1 day) checks to see if there's been any new updates and if so does an update to the production tree? Seems like a rather clunky work-arround, but it should at least get the results you're looking for. - Steve Roderick Bloem wrote: Hi, I want to use cvs for a directory that contains scripts. I don't want everyone to change the scripts in the directory: I won't have accountability. Thus, it is under cvs. People should check out, change, and submit. I don't want them to write to the directory itself, because they will forget to check in. I would like changes to propagate to the script directory immediately. Everytime someone commits, an update would be executed in the script directory. Is that possible? I have tried a loginfo script, but there is a problem with the locks: the cvs update runs when the commit has not released the lock yet. I have looked on the web and found some references, but nothing very satisfactory. I have seen ACU, but it seems more concerned with managing multiple machines (which is not a problem), than with the lock. I have also thought about putting a pause into the script that does the update, but that does not seem very safe, not do I know how to do it. (My shell programming is bad, and I don't know how to spawn a process from loginfo.) Is there a good solution for this? Should I consider a different setup? Thanks, Roderick Bloem ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automatic checkout
I would like changes to propagate to the script directory immediately. Everytime someone commits, an update would be executed in the script directory. Is that possible? http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html#SEC173 ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
WINCVS
I have just installed wincvs 1.3 following the guide cited below " Install WinCVS 1.3 Install Python 2.1.1 or later Continue on with the 1.4 and 1.3 instructions below Note: If WinCVS 1.3 crashes when you start it, try installing Python, TCL, and WinCVS 1.4 WinCVS 1.2 and 1.3 Instructions Install TCL for WinCVS (it's free) -- this enables the Macros menu in WinCVS If want to use ActiveState's TCL, run this registry fileand change HKLM/scriptics/Tcl/8.4/Root to the full path of the TCL program files directory. For WinCVS 1.3, you need to copy the TCL DLL to the WinCVS program files directory (and set the above registry setting to the WinCVS program files directory?). Copy cvsignore to c:\.cvsignore (use c:\ or where ever your HOME environment variable points to) -- this is where WinCVS looks for file types to ignore. Note that the file is called "cvsignore" but you must rename it to .cvsignore -- put a period in front of the name. Run this registry file to fix the DST problem. ---" i installed cvs in the program files folder but python and tcl at the root (C:) when i start WinCVS it complains that it can't locate python, can anyone help me with this? thanks in advance... rogerPost your free ad now! Yahoo! Canada Personals___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
updated to 1.11.6 (from 1.11.2) now have problems on windows
I'd be inclined to agree here. One particularly common use case for having files with different casings is when a file is incorrectly cased on first commit. One runs cvs rm, renames the file then re-adds it (as following the right way of doing things). In this case, there is never a sandbox conflict as to which file is meant by the particular revision. If there was to be a check on the cvs server, I would much prefer something which forced files on windows machines to be committed using the same case as an existing file on another branch. I frequently have problems with build.bat being created on one branch, and Build.bat being made on the trunk, then avoiding all the rcs_assert( != 0) errors that appear if things are not handled very sensitively. -Original Message- The existing (I think) test cares about theoretical ambigity; my proposed one cares only about the practical problem -- the impossibility of stuffing two unrelated revisions into one sandbox file. If an operation isn't trying to do that, forbidding it on theoretical grounds seems pointlessly annoying. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
Eric Siegerman [EMAIL PROTECTED] wrote: Instead, perhaps it should do something like: if the specified pathname, together with the usual other criteria (-r, -D, sticky attributes, etc.), selects more than one *revision*, complain. The existing (I think) test cares about theoretical ambigity; my proposed one cares only about the practical problem -- the impossibility of stuffing two unrelated revisions into one sandbox file. If an operation isn't trying to do that, forbidding it on theoretical grounds seems pointlessly annoying. I completely agree. I hope this is implemented for the next 1.11.x. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
Kevin Layer writes: Eric Siegerman [EMAIL PROTECTED] wrote: Instead, perhaps it should do something like: if the specified pathname, together with the usual other criteria (-r, -D, sticky attributes, etc.), selects more than one *revision*, complain. The existing (I think) test cares about theoretical ambigity; my proposed one cares only about the practical problem -- the impossibility of stuffing two unrelated revisions into one sandbox file. If an operation isn't trying to do that, forbidding it on theoretical grounds seems pointlessly annoying. I completely agree. I hope this is implemented for the next 1.11.x. Don't hold your breath. Implementing this would require such significant changes to CVS that I'd be tempted to call it 2.x. -Larry Jones Just when I thought this junk was beginning to make sense. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
On Tue, Sep 16, 2003 at 10:31:07PM -0400, Larry Jones wrote: Eric Siegerman [EMAIL PROTECTED] wrote: Instead, perhaps it should do something like: if the specified pathname, together with the usual other criteria (-r, -D, sticky attributes, etc.), selects more than one *revision*, complain. Don't hold your breath. Implementing this would require such significant changes to CVS that I'd be tempted to call it 2.x. Thanks for setting us straight. *sigh* The thought was nice while it lasted... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
