How Do You Use Source Control?
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
You use branches then merge to the trunk and apply pre SQA then post SQA labels for release. Developers use snapshots rater than dynamic views. I worked at one place where different developers checked stuff into the trunk whenever they liked so the tip was usually broken. X|
Visit http://www.notreadytogiveup.com/[^] and do something special today.
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
I've used both options, and I prefer option 2, but not necessarily with SVN. Where I work now we've all agreed to a variation on option 2. If you use CVS or SVN, you pretty much need all of these things to happen: - your source control manager needs to be very diligent in their job in tracking when merges and branches are done, and do the appropriate tagging - You need strong communication between people doing disparate work. They need to know what other people are doing so if major features do overlap areas of code. - People be aware of exactly what their IDE's and tools do to their source files. Keep changes to a minimum. Text only diffs/merges aren't always the best tool. We wrote an in house .resx merge tool to solve this particular problem it was so nightmarish for us. The variation on option 2 I mentioned is a couple of things: - We sometimes have one or a few staging branches where possible related large scale feature branches are created. We do bursts of work for a week or so, committing to our own work branches which are automatically and continuously built and tested. When the involved people agree that the code is good enough and the quality is high enough it gets promoted to the staging branch. - Alternatively to make things simpler, if there is a large overlap, or work is staggered by different developers, we often just branch of a coworkers branch so we can benefit from their feature changes, but still have our own sand box. To me this is where systems like Mercurial and Git come in to play. They are exceedingly good at large numbers of branches and merges. So the answer is pretty much the same as everything else, it all comes down to your needs what approach best solves them.
-
I prefer 2. Part of my current role is reviewing and merging branches. While your point about conflicts when multiple branches touch the same area of code is valid, the same problem exists in option 1 but is easier to deal with with option 2. In option 1) what happens when the file is unlocked and all the other guys do an update? They get a conflict and attempt to resolve it in a may that suits them. The end result may be that you pay the time & effort to resolve that conflict multiple times and those individual resolutions may result in yet more conflicts. Merging and conflict resolution should be limited to a small number of people that have a good understand of the code base and an overview of all the work going on. The trick to option 2 is to merge regularly. If you plan a release with 5 features and those features are all in different branches don't wait till the day before the release is due to start merging. Merge each when they are ready and do your regression testing between each merge. Another tip is to perform (what we call) rebaselining regularly. This is where changes from the trunk (since the branch was taken) are merged to the branch, conflicts resolved & everything tested. This should be done with the aid of a senior developer if necessary. The final merge of the branch to trunk is trivial once this is done. Having said all that there are other teams here that use option 1 and do well with it.
Thanks for the feedback -I agree with pretty much all you say & that's the way I'd like to go (I think - I haven't read teh other responses yet!) But with the locking you don't get the issues you describe in option 1 because we have the rule that no changes are made while a file is locked - all of the Gui files (the designer and resource file) are attributed so they can't be change dwithout locking (sure, it jsut makes them read only, but our rules say we don't change them unless we can lock them) so we don't get merge conflicts as no changes can be made until the first person has completed their work. Of course, that's a problem itself so we aim to have stuff locked only for short periods.
___________________________________________ .\\axxx (That's an 'M')
-
I've used both options, and I prefer option 2, but not necessarily with SVN. Where I work now we've all agreed to a variation on option 2. If you use CVS or SVN, you pretty much need all of these things to happen: - your source control manager needs to be very diligent in their job in tracking when merges and branches are done, and do the appropriate tagging - You need strong communication between people doing disparate work. They need to know what other people are doing so if major features do overlap areas of code. - People be aware of exactly what their IDE's and tools do to their source files. Keep changes to a minimum. Text only diffs/merges aren't always the best tool. We wrote an in house .resx merge tool to solve this particular problem it was so nightmarish for us. The variation on option 2 I mentioned is a couple of things: - We sometimes have one or a few staging branches where possible related large scale feature branches are created. We do bursts of work for a week or so, committing to our own work branches which are automatically and continuously built and tested. When the involved people agree that the code is good enough and the quality is high enough it gets promoted to the staging branch. - Alternatively to make things simpler, if there is a large overlap, or work is staggered by different developers, we often just branch of a coworkers branch so we can benefit from their feature changes, but still have our own sand box. To me this is where systems like Mercurial and Git come in to play. They are exceedingly good at large numbers of branches and merges. So the answer is pretty much the same as everything else, it all comes down to your needs what approach best solves them.
Thanks! That's great info - always better to talk to someone who has actually done this stuff than it is to read theoretical articles.
Phil Martin... wrote:
your source control manager needs to be very diligent in their job in tracking when merges and branches are done, and do the appropriate tagging
In my mind I had the source control manager (Hah! if only we had someone who could manage their way out of a wet paper bag!) manuall documenting each branch in a spreadsheet, or on a whiteboard - so that the development team always knew what branches existed, and how they may relate to what they are working on. The resx merge tool sounds interesting - any change of writing an article here about it? we have one particular person who is constantly just making minor gui changes (and it's unlikely to change) competely outside the scope of what is being worked on - and that has led to some real merge hell in the past (we got around it now by ensuring these files require locking so can't be worked on by 2 people simultaneously - but that dosnt work in scenario 2 (I don't think)) I'll have to take a look at Mercurial and the intriguingly named 'Git' - never heard of the first and came across the latter only this evening.
___________________________________________ .\\axxx (That's an 'M')
-
You use branches then merge to the trunk and apply pre SQA then post SQA labels for release. Developers use snapshots rater than dynamic views. I worked at one place where different developers checked stuff into the trunk whenever they liked so the tip was usually broken. X|
Visit http://www.notreadytogiveup.com/[^] and do something special today.
OK Trolly (hope you don't mind the term of endearment :)) I'm going to have to admit my ignorance here... I don't think snapshot or dynamic views are SVN terms - and I'm not sure what you mean in this context...
Trollslayer wrote:
I worked at one place where different developers checked stuff into the trunk whenever they liked so the tip was usually broken.
welcome to my world!
___________________________________________ .\\axxx (That's an 'M')
-
I prefer option 1. Developers can continue implementing the next set of features without disruption Eg they don't have to wait for someone to create a new branch for them to switch to. Theoretically when you have made the release branch you would hope that there are only minor bug fixes and not major re-factorings this will allow easier merging back to the trunk. The possible downside I see with option 2 is that you have a lot of branches to manage, and also merge. However for big features/fixes that will take a long time to implement a branch is recommended. David
Thanks. I can see your point - and I'm beginning to see that the different options do rather depend upon the structure of the dev team - Option 2 takes good strong management and planning to make it work.
___________________________________________ .\\axxx (That's an 'M')
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
We use option #1, essentially because of engineering documentation control requirements here. It's a hardware company, which means configuration management follows hardware practices, whether it makes sense for software or not. Our internal 'legal' requirements include exact reproducability for each released version, and maintenance from each released version. That means separate and distinct branches for each release. Our 'trunk' is therefore dedicated to the bleeding-edge development version.
Software Zen:
delete this; -
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
Don't trust merge. Never branch. Branching is a cry for help.
-
OK Trolly (hope you don't mind the term of endearment :)) I'm going to have to admit my ignorance here... I don't think snapshot or dynamic views are SVN terms - and I'm not sure what you mean in this context...
Trollslayer wrote:
I worked at one place where different developers checked stuff into the trunk whenever they liked so the tip was usually broken.
welcome to my world!
___________________________________________ .\\axxx (That's an 'M')
clearcase uses those terms. A snapshot view is one that needs to be manually updated to get the most recent version of the files, a dynamic view automatically has the most recent version of everything provided by a background process or the server (depending on if the files are local or on the server).
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
I've always done 1 because my main project uses rational clearcase, and setting up/using branches in it is a pain. Also since we only have a single end user with a monolith deployment process for the app and a waterfallish development process releasing patches for one version while working on the next has never been an issue.
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
I prefer #1, especially with Subversion. But, it really depends on how releases are viewed. I prefer 1 because if correctly done, there are VERY few merges back to the trunk. In a product with several hundred projects (yes, projects), there should be fewer than one or two dozen files needing to be merged back to the trunk; if there are more, then your selection of features for release is flawed. Another thing to note is that when you branch for release, you can definitely pick and choose features you want to release in that version. In fact, it is essential to only pick the stable features that are ready for release. Once you brach for release, you should have the majority of bugs returned from the QA process (and fixed) in a couple of weeks. Then you merge the fixes back into the trunk as soon as possible. Sometimes you can't directly merge back to the trunk for features that have been worked on heavily before the branch, but were not chosen for the release because they weren't ready. These fixes are made manually, and usually are quite small, or no longer are a problem in the new version of the feature. My rule of thumb on branching and merging is to merge as little as possible, and do it within two weeks. Any project under heavy development will be very hard to merge on a timeline longer than this.
-
You have a project being worked on by several developers. It's being developed in a very slapdash manner, with little control. You're going to use Subversion (but this, I think, applies to any version control). As I see it there are two main ways you can use subversion: 1. The Trunk is the development node. All developers regularly get the latest version, and apply their changes. At some point, a branch will be made which is a releaseable version. Bugs fixed in the branch are applied also to the root - where development of the next release continues. 2. The Trunk is the pristine, release only node. Any change or feature request is implemented in a branch for that change. Each branch is then QAd before merging with the Trunk prior to a test and release. Bugs discovered post release are fixed in a branch before being merged with the trunk A quick Bing[^] shows that lots of developers seem to prefer 1. over 2. but I don't quite see why. I am interested in the advantages / disadvantages you find in whatever method you choose - be it one of the above or some other solution. Making changes here is like pulling the teeth of a wererabbit so I want to choose the best solution for us. To put my cards on the table, I think I prefer 2. over 1. because of the separation - I can deceide to build a release by picking and choosing which features I think are ready (or, more accurately, omitting those I think are not) rather than being committed to releaseing whatever is in the trunk at the time I come to build a release... but I'm very open to persuasion! The main disadvantage of 2. that has been brought to my attention (by a certain bad-tempered bunny) is that if several changes are made in different branches to the same code (especially Gui code) then merge conflicts will need to be resolved frequently - using a single Trunk for all dev work means you can lock the source while you're working on it to prevent anyone else changing it while you are.
___________________________________________ .\\axxx (That's an 'M')
I use Surround SCM, which has decent merging, but still do #1. The mainline/trunk is the product line. Once you start branching, you end up with a convoluted, hard to track system. There are several very good white papers on this subject available at various SCM vendor web sites.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
clearcase uses those terms. A snapshot view is one that needs to be manually updated to get the most recent version of the files, a dynamic view automatically has the most recent version of everything provided by a background process or the server (depending on if the files are local or on the server).
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
I've used both options, and I prefer option 2, but not necessarily with SVN. Where I work now we've all agreed to a variation on option 2. If you use CVS or SVN, you pretty much need all of these things to happen: - your source control manager needs to be very diligent in their job in tracking when merges and branches are done, and do the appropriate tagging - You need strong communication between people doing disparate work. They need to know what other people are doing so if major features do overlap areas of code. - People be aware of exactly what their IDE's and tools do to their source files. Keep changes to a minimum. Text only diffs/merges aren't always the best tool. We wrote an in house .resx merge tool to solve this particular problem it was so nightmarish for us. The variation on option 2 I mentioned is a couple of things: - We sometimes have one or a few staging branches where possible related large scale feature branches are created. We do bursts of work for a week or so, committing to our own work branches which are automatically and continuously built and tested. When the involved people agree that the code is good enough and the quality is high enough it gets promoted to the staging branch. - Alternatively to make things simpler, if there is a large overlap, or work is staggered by different developers, we often just branch of a coworkers branch so we can benefit from their feature changes, but still have our own sand box. To me this is where systems like Mercurial and Git come in to play. They are exceedingly good at large numbers of branches and merges. So the answer is pretty much the same as everything else, it all comes down to your needs what approach best solves them.
I've been thinking about writing an in-house tool for Resx merge too, but would love to borrow instead of recreate one. It strikes me as bizarre that there isn't a commercial solution. I'd think that anyone who uses reasonably sophisticated source control (e.g. branching) along with .NET WinForms would run into this brick wall. If you're willing to share, either as a CP article, or personally, that would be really great. Tom
Tom Clement Serena Software, Inc. www.serena.com articles[^]
-
I prefer #1, especially with Subversion. But, it really depends on how releases are viewed. I prefer 1 because if correctly done, there are VERY few merges back to the trunk. In a product with several hundred projects (yes, projects), there should be fewer than one or two dozen files needing to be merged back to the trunk; if there are more, then your selection of features for release is flawed. Another thing to note is that when you branch for release, you can definitely pick and choose features you want to release in that version. In fact, it is essential to only pick the stable features that are ready for release. Once you brach for release, you should have the majority of bugs returned from the QA process (and fixed) in a couple of weeks. Then you merge the fixes back into the trunk as soon as possible. Sometimes you can't directly merge back to the trunk for features that have been worked on heavily before the branch, but were not chosen for the release because they weren't ready. These fixes are made manually, and usually are quite small, or no longer are a problem in the new version of the feature. My rule of thumb on branching and merging is to merge as little as possible, and do it within two weeks. Any project under heavy development will be very hard to merge on a timeline longer than this.
Scott Serl wrote:
when you branch for release, you can definitely pick and choose features you want to release in that version
I don't understand how you can do this? If all changes are being done in the trunk, then you branch prior to release but want to omit some of those changes, how do you do it? From reading around I also think your two week merge maximum is generous! Many articles recommend daily merges to avoid conflicts.
___________________________________________ .\\axxx (That's an 'M')
-
Don't trust merge. Never branch. Branching is a cry for help.
-
clearcase uses those terms. A snapshot view is one that needs to be manually updated to get the most recent version of the files, a dynamic view automatically has the most recent version of everything provided by a background process or the server (depending on if the files are local or on the server).
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
Thanks! That's great info - always better to talk to someone who has actually done this stuff than it is to read theoretical articles.
Phil Martin... wrote:
your source control manager needs to be very diligent in their job in tracking when merges and branches are done, and do the appropriate tagging
In my mind I had the source control manager (Hah! if only we had someone who could manage their way out of a wet paper bag!) manuall documenting each branch in a spreadsheet, or on a whiteboard - so that the development team always knew what branches existed, and how they may relate to what they are working on. The resx merge tool sounds interesting - any change of writing an article here about it? we have one particular person who is constantly just making minor gui changes (and it's unlikely to change) competely outside the scope of what is being worked on - and that has led to some real merge hell in the past (we got around it now by ensuring these files require locking so can't be worked on by 2 people simultaneously - but that dosnt work in scenario 2 (I don't think)) I'll have to take a look at Mercurial and the intriguingly named 'Git' - never heard of the first and came across the latter only this evening.
___________________________________________ .\\axxx (That's an 'M')
Take a look at Mercurial first - even though it doesn't handle N-way merging as well as Git, it is far far far friendlier to set up on Windows than Git. Git is only a real option if you are very familiar with Cygwin. On the topic of Resx stuff - I'll ask the boss to see if he's cool with it, I can't see why it wouldn't be. However, after a long couple of years thinkinga bout it, I'm not sure that it is the complete solution. What would be better for me is if as a pre-checkin automated ste, there was a tool that sorted the enties in the .resx file in a predictable manner. Something Visual Studio realy should be doing. Changing the team dynamic (limited editing of certain files) based on a very lame limitation of Visual Studio makes me a little irate. So I found ways around it :)
-
Thanks for the feedback -I agree with pretty much all you say & that's the way I'd like to go (I think - I haven't read teh other responses yet!) But with the locking you don't get the issues you describe in option 1 because we have the rule that no changes are made while a file is locked - all of the Gui files (the designer and resource file) are attributed so they can't be change dwithout locking (sure, it jsut makes them read only, but our rules say we don't change them unless we can lock them) so we don't get merge conflicts as no changes can be made until the first person has completed their work. Of course, that's a problem itself so we aim to have stuff locked only for short periods.
___________________________________________ .\\axxx (That's an 'M')
Maxxx_ wrote:
But with the locking you don't get the issues you describe in option 1 because we have the rule that no changes are made while a file is locked - all of the Gui files (the designer and resource file) are attributed so they can't be change dwithout locking (sure, it jsut makes them read only, but our rules say we don't change them unless we can lock them) so we don't get merge conflicts as no changes can be made until the first person has completed their work.
Yeah that'll work but probably wont scale well in the future which may or may not be an issue for you. I've no odea about "attributed" designer or resource files, my projects are all cross platform c++. One other thing I'd say is don't be scared of merging. I use the tortoise merge tool and even the oldest, crustiest branches can be merged to the trunk with relatively little pain. It can go pear shaped however if you're not strict about recording revision ranges merged in the check in comment.
-
I use Surround SCM, which has decent merging, but still do #1. The mainline/trunk is the product line. Once you start branching, you end up with a convoluted, hard to track system. There are several very good white papers on this subject available at various SCM vendor web sites.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
We use SurroundSCM, but I find the merging pretty average compared to others. The lack of cross branch merging can be sometimes troublesome. However the super easy UI has made it heaps simpler for us to track all out work, so overall it's been a big win. We still use method 2. The known-stable (or hopefully stable :) ) branch has individual code change branches coming off of it where all bug fixing and feature work takes place. After the work is notionally done, that code is automatically built and given to the testers to make sure it's all okay, and someone else to review. Only after it passes both of those does the code get promoted in the known stable branch for future release. But overall, it just all comes down to whatever works.