How often should we checkin?
-
Depends on the process in your organization and the SCS you are using. At my workplace, checking in requires so much overhead (code reviews, etc) that I am lucky if I check in once a week. That's a bad situation however, and not the best use of source control. Ideally, we would have a distributed SCS with private branches, and then I would check-in much more often.
Nemanja Trifunovic wrote:
At my workplace, checking in requires so much overhead (code reviews, etc) that I am lucky if I check in once a week. That's a bad situation however, and not the best use of source control
This would really bug me. It sounds like there is something wrong with the process.
-
I checkin to the Lounge pretty frequently throughout the day. There are some that never leave. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
You beat me to it.
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeist -
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.
Member 4487083 wrote:
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,
New release I check in once I have something that builds and has some functional coherence. So it might not 'work' but at least it makes sense. For bug/rfe I check in when it is complete including unit test code. And just to validate - you are not using version control as a back up system - correct?
Member 4487083 wrote:
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?
Yes. But it depends on the size of the code base, the deliverables and the number of people involved. For example a 2 person shop should need to do that. But a shop with 300 people is wasting money if they do that.
-
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
-
Really good question. I'm very religious about source control: I check-in VERY frequently, 10-20 times per day. Any atomic change of code needs a separate check-in. Even if it's been a couple hours since my last check-in and I bring up the Commit.. dialog, I will pick apart the individual atomic changes and do several different "sub"-check-ins at that moment. In my view, there is very little reason NOT to do it this way. If you want to see the net change between any two revisions, just Ctrl-Click them in the Log view and diff those two revisions. More generally, it is possible and very easy to "group up" a set of revisions; it is very difficult to "break down" one large commit into what its constituent atomic changes should have been. For a concrete, practical example, here is the last 24 hours for me and a co-worker: http://imagebin.org/155476[^] Note also the EVERY single check-in is documented. And almost without exception, none of our check-ins breaks the build.
Jason Hooper wrote:
Even if it's been a couple hours since my last check-in and I bring up the Commit.. dialog, I will pick apart the individual atomic changes and do several different "sub"-check-ins at that moment.
What do you use to manage that? There've been times when I wanted to split a larger checkin into smaller pieces but couldn't easily do so because each increment would contain a subset of the changes in each of several files.
3x12=36 2x12=24 1x12=12 0x12=18
-
Member 4487083 wrote:
The other thing that I think is REALLY bad is when we have periods where we aren't allowed to checkin eg
Had this happen to me many years ago when I was younger, dumber, and working in VB6. This went on for 2-3 weeks while waiting for management to OK the big changes to be checked in. Then the VB6 IDE crashed out on me and ate the file. No backup, not even a temp file to be recovered, :sigh: Guess I'll just start all over X|
thrakazog wrote:
This went on for 2-3 weeks while waiting for management to OK the big changes to be checked in.
Why would management tell you when you can and can't check in source code changes? A source repo should be a living, breathing thing. I'm guessing in your case that revisions in your source control system are more closely correlated to production/staging releases rather than just incremental changes in the logic and functionality in your code? I can understand management OK'ing the tagging of certain revisions as notable (perhaps shippable) milestones in your development. But you should be checking in code to source control in order to control your source code. :sigh:
-
thrakazog wrote:
This went on for 2-3 weeks while waiting for management to OK the big changes to be checked in.
Why would management tell you when you can and can't check in source code changes? A source repo should be a living, breathing thing. I'm guessing in your case that revisions in your source control system are more closely correlated to production/staging releases rather than just incremental changes in the logic and functionality in your code? I can understand management OK'ing the tagging of certain revisions as notable (perhaps shippable) milestones in your development. But you should be checking in code to source control in order to control your source code. :sigh:
Yeah, it was a pretty poorly run operation. But at least the pay sucked. That was the only job I've ever left without having a job to replace it. Gave my 2 weeks notice. Management was asking, "Oh, so who hired you?" Nobody, I'm just not going to work here anymore.
-
Jason Hooper wrote:
Even if it's been a couple hours since my last check-in and I bring up the Commit.. dialog, I will pick apart the individual atomic changes and do several different "sub"-check-ins at that moment.
What do you use to manage that? There've been times when I wanted to split a larger checkin into smaller pieces but couldn't easily do so because each increment would contain a subset of the changes in each of several files.
3x12=36 2x12=24 1x12=12 0x12=18
Dan Neely wrote:
There've been times when I wanted to split a larger checkin into smaller pieces but couldn't easily do so because each increment would contain a subset of the changes in each of several files.
That's the tricky part, and requires just a very attentive focus on detail. I'm sure every now and then I break a dependency, and hence the build, for one or two minutes until I have the whole thing checked in. It doesn't need to be perfect.
-
Dan Neely wrote:
There've been times when I wanted to split a larger checkin into smaller pieces but couldn't easily do so because each increment would contain a subset of the changes in each of several files.
That's the tricky part, and requires just a very attentive focus on detail. I'm sure every now and then I break a dependency, and hence the build, for one or two minutes until I have the whole thing checked in. It doesn't need to be perfect.
That's not the sort of problem I was thinking about, when the changes I would like to check in separately on in discrete files it's relatively easy to make sure you're checking in the right stuff; and as you said the worst case is the build breaking for 1 or 2 minutes. The problem is that there's no easy way to say checkin changes 2, 5-9, and 12 in foo.cs and changes 1-5, 7, 12, and 21 in bar.cs; but to keep the rest of the changes for the next checkin. You can play copy/paste or undo/redo games but it's far too easy to screw up that way and lose something entirely.
3x12=36 2x12=24 1x12=12 0x12=18
-
That's not the sort of problem I was thinking about, when the changes I would like to check in separately on in discrete files it's relatively easy to make sure you're checking in the right stuff; and as you said the worst case is the build breaking for 1 or 2 minutes. The problem is that there's no easy way to say checkin changes 2, 5-9, and 12 in foo.cs and changes 1-5, 7, 12, and 21 in bar.cs; but to keep the rest of the changes for the next checkin. You can play copy/paste or undo/redo games but it's far too easy to screw up that way and lose something entirely.
3x12=36 2x12=24 1x12=12 0x12=18
Ahh, gotcha. I wondered about this too and did some rounds of the web that day and came to the conclusion that it wasn't possible with Subversion. There's a relevant discussion here: http://stackoverflow.com/questions/75809/partial-commits-with-subversion[^]
-
Ahh, gotcha. I wondered about this too and did some rounds of the web that day and came to the conclusion that it wasn't possible with Subversion. There's a relevant discussion here: http://stackoverflow.com/questions/75809/partial-commits-with-subversion[^]
Yeah, although I tend to end up at the problem a different way than Tomayko does. My normal arghflow is: 0 Start working on new feature X. 1 Implement X. 2 Start testing X, discover old feature W is no longer working where it interacts with X. 3 Start fixing W to work with X. 4A Discover that in fact W was broken in general, not just WRT X. 4B Alternately discover that fixing W requires extensive changes and is large enough it should be kept separate from X to keep the diffs manageable. 5 AAAARGH!
3x12=36 2x12=24 1x12=12 0x12=18
-
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.
Rule number 0: Never check in anything that won't compile clean.
Member 4487083 wrote:
eg. no checkins while a build is done
That's bogus, get yourself a proper code management system. Oh, wait, I keep forgetting -- the only proper code management system (that I know of) is CMS and it's only for OpenVMS. :doh:
Member 4487083 wrote:
source control as being a very imporant tool
Yes, don't settle for second best.
Member 4487083 wrote:
think it would discourage developers from using source control correctly.
Exactly.
-
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
