How often should we checkin?
-
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.
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
-
it is unnerving that you picked that right out. :~
I think the word you are looking for is "liquor". ;)
-
Hans Dietrich wrote:
checkin whenever I checkout.
No wonder you get done before everyone else and nobody can see what you did. :laugh:
-
I think the word you are looking for is "liquor". ;)
No one can spell that after they leave 'Big Fancy Club'
-
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.
Reminds me of the roach motel commercial: Roaches check in, they never check out. :-D
-
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.
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.
-
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.
