How often should we checkin?
-
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