Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
jml at nykredit.dk wrote: > Dear John > > First: sometimes a message from somebody (say you) will cross a message > from someone else (say me), and someone may not have had a chance to read > the message from somebody! I have been posting since yesterday that the proposed solution only works under *nix because of the sequence of of events that have to occur (see below for even more details). I'm sorry, I was just feeling frustrated that the same suggestions kept coming up, even though I thought I was explaining why they won't work. An additional problem is that half of the commands used in the *nix solution don't even exist under NT (and the most important one, sleep, doesn't). > > Second: you declare "won't work" without any explanation why the suggested > solution won't work. That doesn't make any of us any wiser. I don't see why > this won't work. Please state your arguments, so we can learn from your > expertize (which i do not challenge!). Here is the sequence of events (simplified as I understand it) under a *nix system: 1) user requests a file be committed (each file is handled individually even if the user tries to commit an entire directory). 2) CVS a) locks the file in the repository b) performs the necessary operations (updates the repository) c) checks to see if there are any loginfo events to fire 3) CVS tries to fire the loginfo event a) the loginfo even spawns a background shell process b) exits with no error 4) CVS a) unlocks the file b) exits with no error 5) The background shell sleeps for 2 seconds and then a) cd's to the sandbox b) runs a new CVS process to do the update c) exits with no error The sandbox is now updated. Under NT, step 3a is not possible (not really) and there is no way to use START to create a new process that waits for the first CVS to exit before starting the second. The problem is that the loginfo line must exit with no error *before* the CVS commit process can unlock the and exit itself. The inner CVS must wait until the outer CVS exits before it can sucessfully update the sandbox. The important sequence is that the repository copy of the file is locked in step 2a but not unlocked until 4a; it is not possible to do anything between those two points that involves accessing that file in the repository. I know, I have tried everything I could think of, but I could not get around this. My solution (based on suggestions that others gave me) was to use the NT AT program to schedule a new CVS instance as my step 3a. Then this process fires (something less than 1 minute later due to the limitations of the Scheduler) and performs steps 5a-c. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 _______________________________________________ Cvsnt mailing list Cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs