source code check ins
-
We only check in code when it's been tested and is ready to move to the production server.
Yeah that's kind of what I thought. Projects I've worked on, checkins only happened after some initial testing and *after* it was confirmed that they at least didn't break the build.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
I usually check in a few times per day. Reasons I check in: I reached a major milestone, I am adding something to a project (I add it and check it in before it's implemented to avoid having to merge project conflicts), I finished what I was doing (even if it was a quick fix for a comment), or it's the end of the day. I will avoid checkins if:
-2147483648. The code doesn't compile.
-2147483647. The code will break something that is on production.Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
When using centralized SCS (TFS, SourceSafe, SVN) I normally checkin after a unit of work has been completed. This is basically a small feature or a fix. When using distributed SCS (GIT and mercurial), I check in as often as I can sometimes even after modification of a single file. Of course, I push it to the centralized build server only after a unit has been completed.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
We can check the code in whenever we want - the code is only put into production once the developer has tested it, the QA tester has tested it and the relevant documentation has been filled in(Zzzzz snore!). We have one administrator who publishes the checked in code to production once all the above has been signed off. In practise however the devs only check in once the code is fully tested just before the sign off - so we can see who has the flag so to speak.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
-
I usually check in a few times per day. Reasons I check in: I reached a major milestone, I am adding something to a project (I add it and check it in before it's implemented to avoid having to merge project conflicts), I finished what I was doing (even if it was a quick fix for a comment), or it's the end of the day. I will avoid checkins if:
-2147483648. The code doesn't compile.
-2147483647. The code will break something that is on production.Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Your friend's friends needs DVCS (i.e. Mercurial / GIT), so that they can check-in as many times they want without breaking the built, and still get the statisfaction of check-ins. and once their code works then, they can push it to the server.
Jim Crafton wrote:
Has anyone else heard of this?
No, looks like a bad habit to me.
Jim Crafton wrote:
How often do you check in?
When the issue / work item I am working is done with minor functional testing.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
At work, for bugs, a check-in is usually the full fix for a specific bug. For new functionality, a check-in is usually a tested, wont-break-build version that represents a sub-unit of the whole functionality.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
We only check in code when it's been tested and is ready to move to the production server.
This should only be true if you're working on the main development trunk... otherwise, why would you move your code so sparingly? What if your machine crashes or gets a virus? Work on a branch and check in as often as necessary.
-
When using centralized SCS (TFS, SourceSafe, SVN) I normally checkin after a unit of work has been completed. This is basically a small feature or a fix. When using distributed SCS (GIT and mercurial), I check in as often as I can sometimes even after modification of a single file. Of course, I push it to the centralized build server only after a unit has been completed.
Rama Krishna Vavilala wrote:
When using centralized SCS (TFS, SourceSafe, SVN) I normally checkin after a unit of work has been completed. This is basically a small feature or a fix.
You can do frequent check-ins on centralized servers too, just need to branch your work so you don't affect the main source trunk.
-
Your friend's friends needs DVCS (i.e. Mercurial / GIT), so that they can check-in as many times they want without breaking the built, and still get the statisfaction of check-ins. and once their code works then, they can push it to the server.
Jim Crafton wrote:
Has anyone else heard of this?
No, looks like a bad habit to me.
Jim Crafton wrote:
How often do you check in?
When the issue / work item I am working is done with minor functional testing.
See my comment above in regards to branching.
-
This should only be true if you're working on the main development trunk... otherwise, why would you move your code so sparingly? What if your machine crashes or gets a virus? Work on a branch and check in as often as necessary.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
We have used IBM Rational Unified Change Management, which is very overwhelming at first, and a bit heavy on process. In a large organization, I think it's the only way to go. Each developer gets their own "view" of the source. I can check-out and check-in my source all I want in my view. After I am done developing, testing I "deliver" to the integration stream that everyone on my team is working on for the current project. Before I finalize the delivery, I can actually build from the integration stream to verify that I didn't break the build. If anyone tries to update their source during that period, they will get the code at the point before I deliver. If I find I have made a mistake, I can easily back-out the check-in, and try again once I have resolved the issue. Finally, the changes from the integration stream can be delivered up the chain to the base stream.
-
Rama Krishna Vavilala wrote:
When using centralized SCS (TFS, SourceSafe, SVN) I normally checkin after a unit of work has been completed. This is basically a small feature or a fix.
You can do frequent check-ins on centralized servers too, just need to branch your work so you don't affect the main source trunk.
Branches are easy to create, very easy... the problem is Merging which almost all the SVN / CVS lacks (It's the design flaw). and it requires lot of manual work. :)
-
We have used IBM Rational Unified Change Management, which is very overwhelming at first, and a bit heavy on process. In a large organization, I think it's the only way to go. Each developer gets their own "view" of the source. I can check-out and check-in my source all I want in my view. After I am done developing, testing I "deliver" to the integration stream that everyone on my team is working on for the current project. Before I finalize the delivery, I can actually build from the integration stream to verify that I didn't break the build. If anyone tries to update their source during that period, they will get the code at the point before I deliver. If I find I have made a mistake, I can easily back-out the check-in, and try again once I have resolved the issue. Finally, the changes from the integration stream can be delivered up the chain to the base stream.
Oooh - the days of ClearCase (I think this is what this used to be called). I remember all that now! Yeah it was a bit over blown, but it did have a lot of nice features once it was all set up correctly. But I think all the developers bitched about the amount of time it took to get used to it. It was also a nearly full time job to babysit the server to keep it up and running and happy :)
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
Branches are easy to create, very easy... the problem is Merging which almost all the SVN / CVS lacks (It's the design flaw). and it requires lot of manual work. :)
I've found merging in SVN less hassle than CVS. But it's still a bit of a PITA.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
I've found merging in SVN less hassle than CVS. But it's still a bit of a PITA.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
For me even TFS failed many times to merge automatically after adding few lines on the file which someone else is also working. It will get confused if you move a block of code, because SVN/TFS/CVS doent keep track of changes, they keep copies of files.
-
Mostly intentional. It starts at Int32.MinValue :)
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
Branches are easy to create, very easy... the problem is Merging which almost all the SVN / CVS lacks (It's the design flaw). and it requires lot of manual work. :)
I use svn... Once you get the hang of doing merges... Not very hard at all...
-
looks like bug to me, if you are on the post above and press ctrl + ->, they are messed up but if you are on the post below and press ctrl + <-, then looks ok.