Regimented or wiki wild west? (source control)
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
I've always found edit-merge-commit to be far, far preferable, particularly as my work is rarely localised to a small area of the source tree...I often get called on to do major UI refactoring "in place", which involves working on large numbers of files simultaneously (and for extended periods of time), while allowing others access to the same files. When a team member is doing that sort of work, an exclusive checkout environment becomes irritating very quickly! One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. If your SCC tool supports changesets (Vault and Hatteras do, for example) even better. :cool: I can honestly say that in nearly 10 years of using SourceSafe with multiple checkouts I've never had a serious merge problem. :) That said, one company I've come across recently is absolutely terrified of it. I guess they just don't think their developers could cope... Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I've always found edit-merge-commit to be far, far preferable, particularly as my work is rarely localised to a small area of the source tree...I often get called on to do major UI refactoring "in place", which involves working on large numbers of files simultaneously (and for extended periods of time), while allowing others access to the same files. When a team member is doing that sort of work, an exclusive checkout environment becomes irritating very quickly! One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. If your SCC tool supports changesets (Vault and Hatteras do, for example) even better. :cool: I can honestly say that in nearly 10 years of using SourceSafe with multiple checkouts I've never had a serious merge problem. :) That said, one company I've come across recently is absolutely terrified of it. I guess they just don't think their developers could cope... Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote: One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. I think this really highlights the concerns that I raised in my post (just before yours): you *rely* on developers to do the right thing, I *force* them :-)
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
Paul Watson wrote: The strict checkout-edit-checkin school or the wilder edit-merge-commit style? Wilder? Bah. You aren't truly "living on the edge" until you've got two months of work stored locally, unable to check it in because you're waiting on other developers to get their changes in, trying to coordinate it all by email. Checkout-edit-checkin is a false security - that by forcing your developers to use source control a certain way, they'll actually work that way. In my experience, it falls apart for projects or teams larger than a couple people (and is damn annoying for two-person teams also). Of course, edit-merge-commit takes a bit more diligence on the part of your developers - but if you can't trust them to be careful checking in the code, how can you trust them to write it?!
-
Paul Watson wrote: The strict checkout-edit-checkin school or the wilder edit-merge-commit style? Wilder? Bah. You aren't truly "living on the edge" until you've got two months of work stored locally, unable to check it in because you're waiting on other developers to get their changes in, trying to coordinate it all by email. Checkout-edit-checkin is a false security - that by forcing your developers to use source control a certain way, they'll actually work that way. In my experience, it falls apart for projects or teams larger than a couple people (and is damn annoying for two-person teams also). Of course, edit-merge-commit takes a bit more diligence on the part of your developers - but if you can't trust them to be careful checking in the code, how can you trust them to write it?!
>until you've got two months of work stored locally, Bah! Someone isn't doing agile dev... :P Thanks Shog9 from outer space, good comments. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
Anna-Jayne Metcalfe wrote: One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. I think this really highlights the concerns that I raised in my post (just before yours): you *rely* on developers to do the right thing, I *force* them :-)
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
I think what Shog9 from outer space said below is relevant. That if you can't trust your devs to get SCM right then you should be worrying about other things first, like their coding capabilities. And forcing them? Sounds a bit harsh. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
I've always found edit-merge-commit to be far, far preferable, particularly as my work is rarely localised to a small area of the source tree...I often get called on to do major UI refactoring "in place", which involves working on large numbers of files simultaneously (and for extended periods of time), while allowing others access to the same files. When a team member is doing that sort of work, an exclusive checkout environment becomes irritating very quickly! One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. If your SCC tool supports changesets (Vault and Hatteras do, for example) even better. :cool: I can honestly say that in nearly 10 years of using SourceSafe with multiple checkouts I've never had a serious merge problem. :) That said, one company I've come across recently is absolutely terrified of it. I guess they just don't think their developers could cope... Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
It seems like this all goes hand in hand with unit testing and continous integration. Ensuring what you check-in builds and passes the tests before committing and then having CI running on your repository with reports going out if a checkin breaks the revision's build. What SCM do you use, Anna-Jayne? Vault, Hatteras (not heard of that one), Subversion (that is what I am using), CVS? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
I've never understood how people can trust automatically-merged code, no matter how convenient it might be. Semantics of code, what it's supposed to do, what it *means* needs much more than a simple lexical analysis of the characters in the file to grok. Just because you seem to get away with it most of the time doesn't mean that it's right. Not being able to work on a file because it's checked out by somebody else forces those two programmers to talk to each other and co-ordinate their work. God forbid we should have that :-) What I always end up doing is making writable local copies of the file(s) I need, working on them until I'm ready to check in and then co-ordinate with the other wrt our respective changes. Maybe the process of comparing changes is similar to having your source control system do it for you but because it's more cumbersome to do manually, it means you tend to be more careful about it.
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
That was my initial impression too but these articles[^] are giving me pause to think that edit-merge-commit is not the scary thing it seems to be. For instance it mentions that the auto-merge tools are conservative, the slightest conflict it is unsure about and it will drop you into a manual diff tool. So you won't find it buldozing over other peoples checked-in code. Also the merge does not commit, not straight away. So once you have merged you can run your build and unit tests locally and then if everything passes, commit. I certainly see the advantage when there is a big file with two coders working on separate parts of it. Why lock the file to one person when the code changes won't affect each other? Though yes, properly structured apps (classes in separate files, well refactored methods etc.) with well controlled project tasks should limit programmers from bumping heads on the same file. But it can happen. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
We use strict checkouts, and use alienbrain[^] for our SCC - as do loads of other games companies, as it's designed for handling all sorts of media files as well as source I've used CSS in the past on my own projects, and to be honest I found it somewhat scary - much happier with it being strict. I haven't used VSS for quite a while, so don't know if it offers it too, but one thing I love in alienbrain is it's change sets[^] feature (that let you group your changes together, so when you check in, the whole set is considered one atom - that way if you check in a hundred files, then quickly need to roll back, you can roll back the whole set in one go) -- Help me! I'm turning into a grapefruit! Buzzwords!
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
conservative. As you, I consider the automated merge scary at least. I think "Regimented" works best for small teasm with low dependencies, "wild wild west" for large distributed ones.
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen -
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
We used to use Checkout-edit-checkin and had separate projects for each release. We actually supported 8-9 releases back that way. Oy-vay, what a pain... These days, though we employ the wild and wooly edit-merge-commit method. We've had a few issues with individuals merging code incorrectly, but not due to any auto-merge utility going astray. Usually, they apply fixes to the new dev or don't merge fixes to the release in QA, or some such thing. In any case, even with the occasional mix up, I think it was a good step forward to make the change. We currently merge manually, though I do have intensions of reviewing our merge util further to get more confidence in it and have the rest of the team eventually start using it. A few people have dabbled with it here and we haven't found any real problems, so it is really a question of being comfortable with automatically changing code. BW
Meanwhile, behind the facade of this innocent looking bookstore...
-
I think what Shog9 from outer space said below is relevant. That if you can't trust your devs to get SCM right then you should be worrying about other things first, like their coding capabilities. And forcing them? Sounds a bit harsh. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
Paul Watson wrote: That if you can't trust your devs to get SCM right then you should be worrying about other things first, like their coding capabilities. I agree completely. However, as a contractor, I get the pleasure of working in a lot of different shops and it's been my experience that this is indeed a real issue. I once worked at a place that had maybe 20 developers writing financial software that handled millions of dollars each year. All the source files were stored on a server and their idea of source control was you temporarily put your name at the top of the file when you started editing it to alert anyone else opening the file :omg: You usually don't have the option of firing people (even though they may sometimes deserve it) so all you can do is try to institute procedures that will help raise the level of quality, as best you can. Paul Watson wrote: And forcing them? Maybe. But why do some shops require you to set the warning level to 5 or set compiler options such as "treat warnings as errors"? Because it *forces* the developer to fix the problem instead of just brushing it under the carpet. With automatic merge and commit, it's just too easy for a developer to quickly skim through the diff without *really* checking what's going on. We've all been guilty of rushing things, especially when under pressure. What is a lesser-skilled developer going to do? Any time you're relying on people to just do the right thing by themselves, you're asking for trouble :-) The day automated merge tools are smart enough to figure out if my changes clash with the other guy's changes at a level higher than simply comparing ASCII bytes, we'll have tools that are smart enough to write the code themselves. Example: I modify method1() in a class and someone else modifies method2(). They're in completely different parts of the file so the merge tool is not going to flag a problem but there is a dependency between the two methods such that each of our changes work in isolation but break when they're both there. No automated tool is ever going to find this. Forcing the two developers to talk to each other and forcing them to do the diffs raises the chance of finding this problem. Bottom line: just because it works most of the time doesn't mean it's the right thing to do. People complain exclusive checkouts are inconvenient, slow them down and are a PITA. Yeah, well so is source control in general, doing diffs, fixing compiler warnings, etc. S
-
Paul Watson wrote: The strict checkout-edit-checkin school or the wilder edit-merge-commit style? Wilder? Bah. You aren't truly "living on the edge" until you've got two months of work stored locally, unable to check it in because you're waiting on other developers to get their changes in, trying to coordinate it all by email. Checkout-edit-checkin is a false security - that by forcing your developers to use source control a certain way, they'll actually work that way. In my experience, it falls apart for projects or teams larger than a couple people (and is damn annoying for two-person teams also). Of course, edit-merge-commit takes a bit more diligence on the part of your developers - but if you can't trust them to be careful checking in the code, how can you trust them to write it?!
Hell, you're right! My previous project was a nightmare, even though the team had just 3 people. Our rules say we have to follow the checkout-edit-checkin procedure, but I was the only one who followed it. The others would 'get' the file, work on it, checkout the latest copy, then check in their version. WTF? :mad: They take the trouble of going to PVCS for the file, but why the hell can't they check it out? If somebody checked in newer code before the other bum checked out code, BOOM! X| Cheers, Vikram.
http://www.geocities.com/vpunathambekar
Google talk: binarybandit
After all is said and done, much is said and little is done.
-
It seems like this all goes hand in hand with unit testing and continous integration. Ensuring what you check-in builds and passes the tests before committing and then having CI running on your repository with reports going out if a checkin breaks the revision's build. What SCM do you use, Anna-Jayne? Vault, Hatteras (not heard of that one), Subversion (that is what I am using), CVS? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
Paul Watson wrote: It seems like this all goes hand in hand with unit testing and continous integration. Ensuring what you check-in builds and passes the tests before committing and then having CI running on your repository with reports going out if a checkin breaks the revision's build. Got it in one. :) Paul Watson wrote: What SCM do you use, Anna-Jayne? Vault, Hatteras (not heard of that one), Subversion (that is what I am using), CVS? Mostly VSS 6.0d, although once we get some sales under our belt we're quite likely to move to Vault. Hatteras is the SCC provider in VSTS, and as such it's waaaaayyyy too expensive for us to even consider. Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
I'm not a manager, just a developer with an interest in this stuff. My first problem is getting them to use source control for maintaining projects that aren't already under source control (that pre-date our purchase of Vault last year) or that are small enough/have a long enough time-scale that only a single developer works on it at one time. Everyone else works in Check-Out/Edit/Check-In mode. I work in Edit/Merge/Commit mode on my projects. The Vault option 'Require exclusive check-outs' is not set. When working with others I simply use the Check Out command to get an exclusive check out so in effect it looks like I'm working that way. I only do an edit-and-merge, when working with others, when a user has a file already checked out, and only if I can't proceed with a different task - the file is on the critical path. The difference between the modes is really only relevant when there's a conflict on the same source file. If you've divided the work up sensibly and the program structure is good, there shouldn't be too many conflicts between developers - you won't merge very often. The whole-class-in-one-file approach used by VB, VB.NET and C# (up to version 1.1) tends to cause more conflicts if you've got large classes. Even then, it's rare that two (or more) developers will modify the same function at the same time and get a collision, so the simplistic automerge usually does do the right thing - if developer A changed line 3 and inserted 3 lines between lines 6 and 7, while developer B was working around line 100, it's unlikely that A's changes will cause any problem with B's (at least from a syntactic perspective). There could be run-time problems, but that's true of the check-out model too. Vault has the right approach, IMO, in that it performs the merge on Get, if possible, is quite conservative in auto-merge, and leaves the changes in your pending change set. If a change has been made to a file in the change set since the last Get, the developer can't Commit. SourceUnSafe apparently does the merge on check-in, meaning that you can actually get code checked in that the developer never saw. In either model it's sensible to minimise your changes, to reduce problems with conflicts. In new development I try to complete a small, complete feature point with one check-in; in maintenance each bug is a single change set, even if the bugs are very close together (this makes merging the change between branches easier). Stability. What an interesting concept. --
-
That was my initial impression too but these articles[^] are giving me pause to think that edit-merge-commit is not the scary thing it seems to be. For instance it mentions that the auto-merge tools are conservative, the slightest conflict it is unsure about and it will drop you into a manual diff tool. So you won't find it buldozing over other peoples checked-in code. Also the merge does not commit, not straight away. So once you have merged you can run your build and unit tests locally and then if everything passes, commit. I certainly see the advantage when there is a big file with two coders working on separate parts of it. Why lock the file to one person when the code changes won't affect each other? Though yes, properly structured apps (classes in separate files, well refactored methods etc.) with well controlled project tasks should limit programmers from bumping heads on the same file. But it can happen. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
Paul Watson wrote: Also the merge does not commit, not straight away. So once you have merged you can run your build and unit tests locally and then if everything passes, commit. This kind of thing I have less of problem with. If your SCM is just making it easier and more convenient for you to do the diff without taking the final control away from you, that's great. But a lot of SCM tools do (or let you easily do) the diff, merge *and* check-in all at once. This I really don't like because developers *will* abuse it. Good developers will use the available tools to do their job better. Bad developers will cut corners where they can so I try to put rules in place to minimize this where I can.
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
-
What style of source control management does your team follow; The strict checkout-edit-checkin school or the wilder edit-merge-commit style? I have always been of the former religion but have been looking into the latter of late. It is damned scary sounding, relying on automatic merge algos or diff tools seems insane. But tools have progressed and a few tests show that it can actually work. Not to mention some of the major projects that already use it successfully. Those that use edit-merge-commit say that once they went to the dark side they could never regress to the quaint ways of checkout-edit-checkin. Thoughts? regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
I've done both, personally I don't really see the difference. It's sixes to me.
-
Paul Watson wrote: That if you can't trust your devs to get SCM right then you should be worrying about other things first, like their coding capabilities. I agree completely. However, as a contractor, I get the pleasure of working in a lot of different shops and it's been my experience that this is indeed a real issue. I once worked at a place that had maybe 20 developers writing financial software that handled millions of dollars each year. All the source files were stored on a server and their idea of source control was you temporarily put your name at the top of the file when you started editing it to alert anyone else opening the file :omg: You usually don't have the option of firing people (even though they may sometimes deserve it) so all you can do is try to institute procedures that will help raise the level of quality, as best you can. Paul Watson wrote: And forcing them? Maybe. But why do some shops require you to set the warning level to 5 or set compiler options such as "treat warnings as errors"? Because it *forces* the developer to fix the problem instead of just brushing it under the carpet. With automatic merge and commit, it's just too easy for a developer to quickly skim through the diff without *really* checking what's going on. We've all been guilty of rushing things, especially when under pressure. What is a lesser-skilled developer going to do? Any time you're relying on people to just do the right thing by themselves, you're asking for trouble :-) The day automated merge tools are smart enough to figure out if my changes clash with the other guy's changes at a level higher than simply comparing ASCII bytes, we'll have tools that are smart enough to write the code themselves. Example: I modify method1() in a class and someone else modifies method2(). They're in completely different parts of the file so the merge tool is not going to flag a problem but there is a dependency between the two methods such that each of our changes work in isolation but break when they're both there. No automated tool is ever going to find this. Forcing the two developers to talk to each other and forcing them to do the diffs raises the chance of finding this problem. Bottom line: just because it works most of the time doesn't mean it's the right thing to do. People complain exclusive checkouts are inconvenient, slow them down and are a PITA. Yeah, well so is source control in general, doing diffs, fixing compiler warnings, etc. S
Fair enough and you are quite right, real world conditions often include coders you have no control over. Though in part this is what integration/regression testing and continous integration help to solve, that of unaware changes breaking other bits of code. Best to catch it before it hits the repository though as you say. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
Anna-Jayne Metcalfe wrote: One thing I have learnt is never to check files in blindly. Always diff the local file first, and do a "Get Latest" to merge any changes into your local source before proceeding. If any changes are made by this process, build them locally first before checking in, and you should have no problems. I think this really highlights the concerns that I raised in my post (just before yours): you *rely* on developers to do the right thing, I *force* them :-)
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison Awasu 2.1.2 [^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: I think this really highlights the concerns that I raised in my post (just before yours): you *rely* on developers to do the right thing, I *force* them Not exactly...I'm just suggesting that you should be aware of what's going on in the database before you check anything in. That applies equally to exclusive check-out scenarios, too (remember the changes you are about to check in could have been compromised by changes to other files in the database, or vice-versa). Whatever environment you work in, it pays to look before you commit yourself to changing the database. In a multiple check-out environment the SCC tools will do their best to ensure you don't screw it up. For example, when you attempt a check-in under VSS, it will always check to see if any changes have been made since you checked out the file. If that is the case, it will scan for merge conflict and will not check in your changes without you resolving any that are found. In my experience merge conflicts are rare, and usually limited to .rc and resource.h files. Although merging those is a pain, it's eminently doable (WinDiff is great for this kind of stuff), and you can still check out selected files exclusively if you really need to. I've rarely found the need to do that myself, but it's there if I need it. Most of the time all you need to do is a "Get" before you merge to synchronise your local source tree and test against the current baseline before checking in. I assume you do that anyway, so there's not exactly a lot of extra work or risk involved... Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I'm not a manager, just a developer with an interest in this stuff. My first problem is getting them to use source control for maintaining projects that aren't already under source control (that pre-date our purchase of Vault last year) or that are small enough/have a long enough time-scale that only a single developer works on it at one time. Everyone else works in Check-Out/Edit/Check-In mode. I work in Edit/Merge/Commit mode on my projects. The Vault option 'Require exclusive check-outs' is not set. When working with others I simply use the Check Out command to get an exclusive check out so in effect it looks like I'm working that way. I only do an edit-and-merge, when working with others, when a user has a file already checked out, and only if I can't proceed with a different task - the file is on the critical path. The difference between the modes is really only relevant when there's a conflict on the same source file. If you've divided the work up sensibly and the program structure is good, there shouldn't be too many conflicts between developers - you won't merge very often. The whole-class-in-one-file approach used by VB, VB.NET and C# (up to version 1.1) tends to cause more conflicts if you've got large classes. Even then, it's rare that two (or more) developers will modify the same function at the same time and get a collision, so the simplistic automerge usually does do the right thing - if developer A changed line 3 and inserted 3 lines between lines 6 and 7, while developer B was working around line 100, it's unlikely that A's changes will cause any problem with B's (at least from a syntactic perspective). There could be run-time problems, but that's true of the check-out model too. Vault has the right approach, IMO, in that it performs the merge on Get, if possible, is quite conservative in auto-merge, and leaves the changes in your pending change set. If a change has been made to a file in the change set since the last Get, the developer can't Commit. SourceUnSafe apparently does the merge on check-in, meaning that you can actually get code checked in that the developer never saw. In either model it's sensible to minimise your changes, to reduce problems with conflicts. In new development I try to complete a small, complete feature point with one check-in; in maintenance each bug is a single change set, even if the bugs are very close together (this makes merging the change between branches easier). Stability. What an interesting concept. --
Comprehensive and useful reply, thanks Mike. What you said about partial classes coming up in 2.0 is a good point. regards, Paul Watson South Africa Colib and WebTwoZero. K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
-
I'm not a manager, just a developer with an interest in this stuff. My first problem is getting them to use source control for maintaining projects that aren't already under source control (that pre-date our purchase of Vault last year) or that are small enough/have a long enough time-scale that only a single developer works on it at one time. Everyone else works in Check-Out/Edit/Check-In mode. I work in Edit/Merge/Commit mode on my projects. The Vault option 'Require exclusive check-outs' is not set. When working with others I simply use the Check Out command to get an exclusive check out so in effect it looks like I'm working that way. I only do an edit-and-merge, when working with others, when a user has a file already checked out, and only if I can't proceed with a different task - the file is on the critical path. The difference between the modes is really only relevant when there's a conflict on the same source file. If you've divided the work up sensibly and the program structure is good, there shouldn't be too many conflicts between developers - you won't merge very often. The whole-class-in-one-file approach used by VB, VB.NET and C# (up to version 1.1) tends to cause more conflicts if you've got large classes. Even then, it's rare that two (or more) developers will modify the same function at the same time and get a collision, so the simplistic automerge usually does do the right thing - if developer A changed line 3 and inserted 3 lines between lines 6 and 7, while developer B was working around line 100, it's unlikely that A's changes will cause any problem with B's (at least from a syntactic perspective). There could be run-time problems, but that's true of the check-out model too. Vault has the right approach, IMO, in that it performs the merge on Get, if possible, is quite conservative in auto-merge, and leaves the changes in your pending change set. If a change has been made to a file in the change set since the last Get, the developer can't Commit. SourceUnSafe apparently does the merge on check-in, meaning that you can actually get code checked in that the developer never saw. In either model it's sensible to minimise your changes, to reduce problems with conflicts. In new development I try to complete a small, complete feature point with one check-in; in maintenance each bug is a single change set, even if the bugs are very close together (this makes merging the change between branches easier). Stability. What an interesting concept. --
Well put. You've got my 5 hun. :) Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.