Re: Preventing "Dirty" Checkins
Robin Rosenberg <[EMAIL PROTECTED]@dewire.kom> wrote: > Pierre Asselin wrote: > > Hm, my language was ambiguous. What the loginfo would trigger is > > one script, running on the test machine, that updates the test sandbox, > > builds, runs the tests, and finally moves the tag if the tests pass. > Trigging rebuilds for every commit is insane. Well, the OP wanted to trigger a test build in the pre-commit check. I was proposing a less heavy-handed solution. Not that it's entirely free of "gatchas". > [ sane process elided ] -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Pierre Asselin wrote: > Hm, my language was ambiguous. What the loginfo would trigger is > one script, running on the test machine, that updates the test sandbox, > builds, runs the tests, and finally moves the tag if the tests pass. Trigging rebuilds for every commit is insane. I run a job for one project every 15 minutes that checks if there are any checkins since the previous build using cvs histor and also checks that non checkins happened during the last ten minutes. The ten minute check is there to lessen the risk that a build starts in the middle of a check-in, giving false negative status reports). Then the build process starts, tagging everything in the project with a unique tag, exporting from CVS using that tag and then it building the project. The compilation errors and a summary are sent via e-mail to all interested parties and an internal web is updates with a pass/fail flags and a link to the build directory for reference and retrieval of the results. It does waste disk space, but that's cheap. It is also easy to prune old directories. -- robin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Maarten de Boer <[EMAIL PROTECTED]> wrote: > > What you *could* do is trigger the build from loginfo (post-commit) > > and update a moving tag if the build is successful. > > [ ... ] > But why would you to that from the loginfo? Wouldn't it be easier to > have that tag moved by a virtual user, the dedicated test build machine, > which is building and testing in a loop, everytime the compilation is > correct? Hm, my language was ambiguous. What the loginfo would trigger is one script, running on the test machine, that updates the test sandbox, builds, runs the tests, and finally moves the tag if the tests pass. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags (Was: Preventing "dirty" checkins)
[ On Wednesday, September 29, 2004 at 08:33:40 (-0700), Yamuna Ramasubramaniyan wrote: ] > Subject: Using moving tags (Was: Preventing "dirty" checkins) > > I have a question about using moving tags. You tag > the repository with LAST_GOOD today. Someone removes > a file. This file still contains the LAST_GOOD tag. > The next person checking out the module with the > LAST_GOOD tag will get this deleted file. Do you use > a commitinfo trigger to remove the moving tag from the > deleted file? Are there any other ways to handle this > case? Create a new "feature" (or "fix") branch for every change (and clean up old feature/fix branches once they're also integrated onto a release branch). Merge the feature/fix branches to the trunk for integration into the main line of active development (and then optionally cut release branches onto which fix branches can optionally be merged to as well). You can even make a rule that only supervisors are allowed to commit to the trunk and/or to release branches and thus only supervisors will be allowed to approve changes to the baseline or to a patch release. Supervisors can further be required to do compiles and run regression tests before committing the integrated changes. However this is all extremely complicated to manage, especially without the help of some front-end/wrapper tools. CVS really is not the right tool for this style of development. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
[ On , September 28, 2004 at 12:06:18 (-0700), Ones Self wrote: ] > Subject: Preventing "Dirty" Checkins > > I'm running a CVS server which compiles and tests the current > files in CVS every hour. I would like to make new checkins > available _only_ if they compile and pass the tests. You don't want to use CVS then. You need and want to use a tool called Aegis, or else something very much like it. I.e. you need to use a version tracking system that inherently supports the concept of a two-phase commit. Aegis acutally does the regression tests on every commit (or at least it does this by default), as well as (optionally) implementing a manual second "approval" commit (so in a sense Aegis is a three-phase system). Furthermore new changes cannot be committed unless a new test is also provided to make sure the changes are not broken ever again (unless they are explicitly undone). -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing "Dirty" Checkins
>--- Forwarded mail from [EMAIL PROTECTED] >Maarten de Boer wrote: >> > One catch I can see with this approach is the platform. For >> example, our >> > development platform is Windows using Microsoft Visual >> Studio, and our >> > repository is on a Solaris machine. >> >> So, the testing machine could be Windows with Visual, which >> could compile, >> test, and move the "compiles-correctly" tag. >But that's a different approach from what was suggested. The suggested >approach was a commitinfo script. Commitinfo runs *only* on the server. >I'm not saying the suggested approach was the best, or even workable. I'm >just pointing out a potential problem with the suggestion. Another is what to do if your shop compiles on more than one platform. How do you test that the compile is successful everywhere? About the third time you do this, you start thinking that scheduled builds combined with good change control and a promotion system look pretty good. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Using moving tags (Was: Preventing "dirty" checkins)
I have a question about using moving tags. You tag the repository with LAST_GOOD today. Someone removes a file. This file still contains the LAST_GOOD tag. The next person checking out the module with the LAST_GOOD tag will get this deleted file. Do you use a commitinfo trigger to remove the moving tag from the deleted file? Are there any other ways to handle this case? -Cheers, Yamuna ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
> But that's a different approach from what was suggested. The suggested > approach was a commitinfo script. Commitinfo runs *only* on the server. > > I'm not saying the suggested approach was the best, or even workable. I'm > just pointing out a potential problem with the suggestion. Yes, yes, I know, I suggested the different approach (a dedicated test machine) in a previous mail, and saw this as another argument in favor. I should have been more clear. Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing "Dirty" Checkins
Maarten de Boer wrote: > > One catch I can see with this approach is the platform. For > example, our > > development platform is Windows using Microsoft Visual > Studio, and our > > repository is on a Solaris machine. > > So, the testing machine could be Windows with Visual, which > could compile, > test, and move the "compiles-correctly" tag. But that's a different approach from what was suggested. The suggested approach was a commitinfo script. Commitinfo runs *only* on the server. I'm not saying the suggested approach was the best, or even workable. I'm just pointing out a potential problem with the suggestion. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
> One catch I can see with this approach is the platform. For example, our > development platform is Windows using Microsoft Visual Studio, and our > repository is on a Solaris machine. So, the testing machine could be Windows with Visual, which could compile, test, and move the "compiles-correctly" tag. Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing "Dirty" Checkins
[EMAIL PROTECTED] wrote: > Yet another method is to divorce the notion of "latest > checked in" from > "eligible for build". I personally would never discourage anyone from > checking in their work, I actively encourage frequent checkins. If you have something that will (or might) break the build, then create a private, temporary branch and check it in there. The important thing is that your work is safe in the repository; I've had a few too many hard drive crashes to leave it to chance. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing "Dirty" Checkins
[EMAIL PROTECTED] wrote: > Simple question: why can't the developers do a top-level "make test" > before committing, and sidestep the question ? Sometimes ya just forget to 'cvs add' a file ;=) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing "Dirty" Checkins
Todd Denniston wrote: > you probably want to look into commitinfo in the > Administrative files section > of the manual [...] > make your command (or script) build the software and if it > fails return > nonuser. Checkin's will take a long time if you force 'make > clean world', In my case, "a long time" would be several hours ;=) One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. Despite all my writing about portable code (see URL in .sig) much of our code is extremely MSVC-centric. > The better method would be to hire engineers who > understand the > process of making good checkins, and/or use a process that > involves the > engineer doing the check before committing and dock his/her > pay for bad > commits<\opinion> I agree - that is by far the better approach. In our shop, we rarely have broken builds. We have an automated build that runs once a day, and emails every member of the team the build results in summary form, with a link to the full build log. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
> What you *could* do is trigger the build from loginfo (post-commit) > and update a moving tag if the build is successful. That way > your trunk can contain garbage, but the last successfully built > commit will have an unambiguous marker on it. Your users can > choose the unstable tip, > cvs checkout foo > > or the last known good version, > cvs checkout -rLAST_GOOD foo But why would you to that from the loginfo? Wouldn't it be easier to have that tag moved by a virtual user, the dedicated test build machine, which is building and testing in a loop, everytime the compilation is correct? Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
>--- Forwarded mail from [EMAIL PROTECTED] >Ones Self <[EMAIL PROTECTED]> wrote: >> I'm running a CVS server which compiles and tests the current >> files in CVS every hour. I would like to make new checkins >> available _only_ if they compile and pass the tests. >> So, if a user checks in something which does not compile, for >> example, other users who check out at that time will not get >> the new version until the problem is fixed. Everytime you >> do an update, you know you're getting a clean version of the >> source; one that compiles, and in which the tests pass. >I don't think you can do that. Well, you could trigger a full >recompile from commitinfo and allow the commit only if the build >succeeds, but your commits would be a bit sluggish that way. >What you *could* do is trigger the build from loginfo (post-commit) >and update a moving tag if the build is successful. That way >your trunk can contain garbage, but the last successfully built >commit will have an unambiguous marker on it. Your users can >choose the unstable tip, >cvs checkout foo >or the last known good version, >cvs checkout -rLAST_GOOD foo >but in the latter case they won't be able to commit changes. >(Well, they could start a branch, but that's taking us off-topic.) >The loginfo trigger would be asynchronous, as in >https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 >and there would be negligible delay to a commit. >Simple question: why can't the developers do a top-level "make test" >before committing, and sidestep the question ? Or do the unit tests >take that long to run ? If the latter, you'll have to guard your >build-test-retag script against multiple instances of itself. Seems like the triggers and build procedures could conspire to enforce a policy that developers complete successful builds, too. The build procedure could have a target that lists its products, one of which be a summary report. The trigger could audit the summary and make sure that the targets are all newer than the sources and fail if anything was done out of order. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
>--- Forwarded mail from [EMAIL PROTECTED] >Ones Self wrote: >> >> Hi, >> >> I'm running a CVS server which compiles and tests the current >> files in CVS every hour. I would like to make new checkins >> available _only_ if they compile and pass the tests. >> >> So, if a user checks in something which does not compile, for >> example, other users who check out at that time will not get >> the new version until the problem is fixed. Everytime you >> do an update, you know you're getting a clean version of the >> source; one that compiles, and in which the tests pass. >make your command (or script) build the software and if it fails return >nonuser. Checkin's will take a long time if you force 'make clean world', but >you can choose the implementation level that is right for you. This way only >acceptable things make it in the base line. >The better method would be to hire engineers who understand the >process of making good checkins, and/or use a process that involves the >engineer doing the check before committing and dock his/her pay for bad >commits<\opinion>, but you may implement what ever mechanisms make you or your >boss happy. Yet another method is to divorce the notion of "latest checked in" from "eligible for build". I personally would never discourage anyone from checking in their work, and I found that providing a handoff method in which the user explicitly guarantees that the code will build is a useful tool. Collecting up the bits for inclusion (or exclusion) in the next build is a simple form of change control that also improves the quality of the builds overall because changes can be undone (sometimes automatically!) under error conditions. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Ones Self <[EMAIL PROTECTED]> wrote: > I'm running a CVS server which compiles and tests the current > files in CVS every hour. I would like to make new checkins > available _only_ if they compile and pass the tests. > So, if a user checks in something which does not compile, for > example, other users who check out at that time will not get > the new version until the problem is fixed. Everytime you > do an update, you know you're getting a clean version of the > source; one that compiles, and in which the tests pass. I don't think you can do that. Well, you could trigger a full recompile from commitinfo and allow the commit only if the build succeeds, but your commits would be a bit sluggish that way. What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. That way your trunk can contain garbage, but the last successfully built commit will have an unambiguous marker on it. Your users can choose the unstable tip, cvs checkout foo or the last known good version, cvs checkout -rLAST_GOOD foo but in the latter case they won't be able to commit changes. (Well, they could start a branch, but that's taking us off-topic.) The loginfo trigger would be asynchronous, as in https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 and there would be negligible delay to a commit. Simple question: why can't the developers do a top-level "make test" before committing, and sidestep the question ? Or do the unit tests take that long to run ? If the latter, you'll have to guard your build-test-retag script against multiple instances of itself. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing "Dirty" Checkins
Ones Self wrote: > > Hi, > > I'm running a CVS server which compiles and tests the current > files in CVS every hour. I would like to make new checkins > available _only_ if they compile and pass the tests. > > So, if a user checks in something which does not compile, for > example, other users who check out at that time will not get > the new version until the problem is fixed. Everytime you > do an update, you know you're getting a clean version of the > source; one that compiles, and in which the tests pass. > you probably want to look into commitinfo in the Administrative files section of the manual Administrative files https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC158 The commit support files https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167 commitinfo https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC169 instead of preventing checkouts, it prevents check in "If the command (or script) returns a non-zero exit status the commit will be aborted." make your command (or script) build the software and if it fails return nonuser. Checkin's will take a long time if you force 'make clean world', but you can choose the implementation level that is right for you. This way only acceptable things make it in the base line. The better method would be to hire engineers who understand the process of making good checkins, and/or use a process that involves the engineer doing the check before committing and dock his/her pay for bad commits<\opinion>, but you may implement what ever mechanisms make you or your boss happy. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Preventing "Dirty" Checkins
Hi, I'm running a CVS server which compiles and tests the current files in CVS every hour. I would like to make new checkins available _only_ if they compile and pass the tests. So, if a user checks in something which does not compile, for example, other users who check out at that time will not get the new version until the problem is fixed. Everytime you do an update, you know you're getting a clean version of the source; one that compiles, and in which the tests pass. Thanks ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
