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 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 #2. It's easier to read history when all features / bug fixes are "brought in". That said, I think it's important for developers working on large projects to rebase their work branch fairly often, to avoid the problems inherent in merging changes based on a very old revision.
-
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 because "svn merge" sucks. With SVN, it's usually better not to branch. So we normally use release branches and feature branches only for destabilizing changes (when you would prevent other developers from testing their features). Just yesterday I spent several hours trying to merge a feature branch back to trunk. That branch had synchronized with other trunk changes earlier (trunk was merged to the branch), so I wanted to use 'svn merge --reintegrate' as suggested by the SVN manual (since the normal SVN merge is too dumb for merging between two branches in both directions). But one of the files in trunk got moved and renamed; and for some reason its svn:mergeinfo got incorrectly set when trunk was merged to the branch; leaving me unable to use --reintegrate. SVN would just display an error message that I needed to merge the renamed file to the branch first, even though it already was merged there. I tried recording the missing mergeinfo, but things went downhill from there. In the end (several hours later), I found some combination of flags for the old (pre-SVN 1.5) merge command that finally did what I expected. Since I experimented with git[^] earlier, I tried the same merge on the git repository I imported from our SVN repository. The merge took a mere 8 seconds and succeeded right away. svn merge took more than two minutes - and I had to run it several times with different options until it worked. If "svn merge" was sane (correctly supporting merging changes in both directions between two branches, even when files get renamed; just like "git merge" does), I'd use option 2.
modified on Monday, June 1, 2009 2:38 AM
-
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 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.
-
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')
The reason for choosing option 1 is pretty simple in my opinion. Merging can be quite a harsh job, since the changesets for whole new features can get very big. And it becomes even harder when working with multiple branches. I've used option 2, but it was a complete nightmare!
WM. My blog
-
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 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
-
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')
#2 is a nice idea, but merging is never "free", whereas creating a branch is.
Help me! I'm turning into a grapefruit! Buzzwords!
-
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.
-
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 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