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
Ennis Ray Lynch, Jr. wrote:
The real question is why don't more developers comment their check-ins?
Out of the 5 coworkers who check in code to the same repository as me, I've only seen one of them add comments to check-ins. :sigh:
-
Chris Meech wrote:
I checkin to the Lounge pretty frequently throughout the day
You have to check-in to the Lounge? I just wander in and out whenever it suits me. No checks, only some gazes when I forget to knock the dirt off my shoes after sneaking about Q&A :)
"I love deadlines. I like the whooshing sound they make as they fly by." (DNA)
I just lurk on the outside, and shout the odd comment through the door
Steve Jowett ------------------------- Real Programmers don't need comments -- the code is obvious.
-
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.
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.
-
Ennis Ray Lynch, Jr. wrote:
The real question is why don't more developers comment their check-ins?
Out of the 5 coworkers who check in code to the same repository as me, I've only seen one of them add comments to check-ins. :sigh:
Nothing like forcing a checkin policy in that case :)
-
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.
:thumbsup: I wish I had coworkers like you.
-
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:
Ideally, we would have a distributed SCS with private branches, and then I would check-in much more often.
Why not just use a local GIT repo? Then just reconcile the changes when you have chance to checkin some task.
-
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.
Source Control and I have a love hate relationship. Sometimes it loves me sometimes it hates me, sometimes it just eats my code and it wont let me have it back... I check in whenever I have something working or over the weekend and we have "no-check in" times like during a push. Fallenangyl ~It's not my fault you suck.- Happy Bunny~
-
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:
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|
-
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.
Yes source control is a very important tool, not just for developers but project managers, testers and more. I have no set rule but when I've completed functionality and tested it I'll check in. On my projects I always establish the rule that no code will remain checked out beyond the end of the day. I've had cases where a developers machine crashed, or their laptop was stolen from home and it isn't pretty to rebuild several days worth of work. Before a build the code should be labeled at the very least or migrated to a build repository. I don't see the need. or wisdom, for a no check in policy during builds.
I know the language. I've read a book. - _Madmatt
-
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.
That's a lot more than me, although if I did 10-20 checkins per day I would probably get in trouble. I'm generally very good. I always comment the checkins, and rarely break the build.
-
Nemanja Trifunovic wrote:
Ideally, we would have a distributed SCS with private branches, and then I would check-in much more often.
Why not just use a local GIT repo? Then just reconcile the changes when you have chance to checkin some task.
Ah, but there are alredy two "justs" in your sentence :)
-
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
