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.
-
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 check in as frequently as I have something new implemented and (appearing) to work properly. Generally every 1 to 3 hours; although some complex items can take longer. More than a day or two and I generally branch to minimize the loss of work risk and to have some incremental history on what I'm doing. The other big benefit of smaller checkins is that it's easier to see what was changed and match it with the checkin comment. I completely agree with creating a branch any time a stable snapshot is needed. Likewise any major monkeying on the server/mass reorganization that forces everyone off should be done after hours to avoid inconveniencing the team.
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.
I use the same philosophy, and even can help ypu, if managing a team, to actually know which members are really working on features/backlog. There are some tools that can even graph the commit rate of each dev, thinking you are using something like svn. Even with VSS, you can do as you say, commit always and commit often, if something needs to freeze just branch it!
"Whether you think you can, or you think you can't--either way, you are right." — Henry Ford
-
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.
-
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.
Cue the Eagles: "You can check-in any time you like, but you can never leave..." :-D I have two basic rules: 1. The checked-in code must build successfully. If I need to check something in that will break the build for any length of time, I confirm with the rest of the team they're not going to need a build within that interval. 2. I generally check in new features only when they're completed in their entirety. My users hate nothing quite like getting a bright shiny new button that does precisely squat.
Software Zen:
delete this; -
it is unnerving that you picked that right out. :~
-
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|
