How Do You Use Source Control?
-
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.
-
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[^]
No worries at all. I'll talk to the boss, but I'm sure it will be okay. If you don't have a resx specific merge tool, then what would just as good would be a pre-checkin script that sorts the .resx file into a predictable order. This is the fundamental problem with visual studio where it can create resx files and change the order of elements seemingly at random. If the order was consistent each time, then the need for a special merge tool would be greatly diminished.
-
No worries at all. I'll talk to the boss, but I'm sure it will be okay. If you don't have a resx specific merge tool, then what would just as good would be a pre-checkin script that sorts the .resx file into a predictable order. This is the fundamental problem with visual studio where it can create resx files and change the order of elements seemingly at random. If the order was consistent each time, then the need for a special merge tool would be greatly diminished.
Seconds after I sent in an article with a solution to this to CP (I suppose it will be available before too long) I see your response :). Oh well. By the way, I was able to do the sort using LINQ with literally a single statement. Thanks again! Tom
Tom Clement Serena Software, Inc. www.serena.com articles[^]
-
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')
Hi Maxxx, I wrote an article you might be interested in concerning .resx merge. Here's the link: Solving the .resx Merge Problem [^] Tom
Tom Clement Serena Software, Inc. www.serena.com articles[^]
-
No worries at all. I'll talk to the boss, but I'm sure it will be okay. If you don't have a resx specific merge tool, then what would just as good would be a pre-checkin script that sorts the .resx file into a predictable order. This is the fundamental problem with visual studio where it can create resx files and change the order of elements seemingly at random. If the order was consistent each time, then the need for a special merge tool would be greatly diminished.
Here's the article link: [^] Tom
Tom Clement Serena Software, Inc. www.serena.com articles[^]