How often should we checkin?
-
When your source control is tied to change tickets and you check-in based on work assignments you create a beautiful system of code management. The real question is why don't more developers comment their check-ins?
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Comment: "Ennis told me to fix this."
-
Comment: "Ennis told me to fix this."
-
How often should we checkin? I try to checkin as often as possible (although I don't go OTT), and I thought that was considered to be the best practice, but a lot of people seem to disagree. I find it so much easier to work with a small number of files checked out, and the more often I checkin, the less likely it is that I'll get a conflict. The other thing that I think is REALLY bad is when we have periods where we aren't allowed to checkin eg. no checkins while a build is done. Is this normal or is it really as bad as it feels? If people need to have the code stable at a certain point then shouldn't they should either label it or branch it? I see source control as being a very imporant tool that shouldn't ever be taken away from developers. As well as making things difficult (ie. moving onto other things while having other things checked out) I think it would discourage developers from using source control correctly.
Do you develop and build on the same codeline? Perhaps a little more elaborate a strategy is in order: MSDN[^]
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
How often should we checkin? I try to checkin as often as possible (although I don't go OTT), and I thought that was considered to be the best practice, but a lot of people seem to disagree. I find it so much easier to work with a small number of files checked out, and the more often I checkin, the less likely it is that I'll get a conflict. The other thing that I think is REALLY bad is when we have periods where we aren't allowed to checkin eg. no checkins while a build is done. Is this normal or is it really as bad as it feels? If people need to have the code stable at a certain point then shouldn't they should either label it or branch it? I see source control as being a very imporant tool that shouldn't ever be taken away from developers. As well as making things difficult (ie. moving onto other things while having other things checked out) I think it would discourage developers from using source control correctly.
I limit my check-ins to pieces of completed functionality (or fixes). This makes it much easier to undo a piece of work if necessary. However, I shelve[^] my code frequently (several times a day) to reduce the risk of losing my work due to a hardware or software glitch on my workstation. Shelving also enables us to safely do code reviews that require executing someone else's changes. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
