I have read all Eric's notes on using source control and the stickies on branches, but I'm still confused.
I'll lay out what we have and someone can point me in the right direction.
For simplicity I'll say that we are developing one application. We have three programmers. Any of the three may be working on the main line app doing bug fixes or may be working on future enhancements.
The current repository is fouled up. What was the trunk is now an experimental future version. What was one of the branches is the real production version, but it also has additional changes. Not sure I know how to fix it.
Here's what I think I know, related to the repository...
The trunk should be where production releases come from and what gets labeled.
When we put out a release we should create a branch for bug fixes.
But where do the three programmers keep their experimental versions?
And how do they resolve changes as they're generally working on code from a version or two prior to the latest release.
Thanks
Kyle
Need help understanding trunk, branches, versions, etc.
Moderator: SourceGear
-
kjedrusiak
- Posts: 37
- Joined: Wed Nov 15, 2006 3:46 pm
I don't believe there's an "official" way of dealing with this, but here's an option.
Let's say you have a trunk. Also, let's say that you have code for version 4.x, and version 5.x, and and version 6.x all being worked on at the same time. You could branch your trunk 3 times; one for 4.x, one for 5.x and one for 6.x.
When your version 4.x code finishes, you merge that code into the trunk, then merge it into the branch 5.x, and merge it into the branch of 6.x. At that point, everyone has the completed 4.x code. The 4.x branch now will be seen as being the "maintenance" branch even though it was being used for development as well. As bugs are fixed in 4.x, those are merged into the other branches.
When your version 5.x code finishes, you will merge that into the trunk and the version 6.x branch, but NOT the 4.x branch. Then that branch becomes "maintenance" mode (really, this part is just happening in your head and requires no actual action).
Let's say that you now have the ideas for version 7.x. You can now create a branch of the trunk for that version and it will have the version 4.x and 5.x stuff, but not the 6.x stuff.
When 6.x completes, you will merge it to trunk and to branch 7.x.
This appears like it could become complex, so you will want to make sure you document everything very well in the beginning until you are used to the process you create. Pay special attention to the exact changes you merge into other areas and note that down somewhere.
Another option might be if you have a way to hide the features from version 5.x-7.x so that the customers only see 4.x. If you do it that way, you can keep everything in the truck until release, but that might have it's own complications.
Let's say you have a trunk. Also, let's say that you have code for version 4.x, and version 5.x, and and version 6.x all being worked on at the same time. You could branch your trunk 3 times; one for 4.x, one for 5.x and one for 6.x.
When your version 4.x code finishes, you merge that code into the trunk, then merge it into the branch 5.x, and merge it into the branch of 6.x. At that point, everyone has the completed 4.x code. The 4.x branch now will be seen as being the "maintenance" branch even though it was being used for development as well. As bugs are fixed in 4.x, those are merged into the other branches.
When your version 5.x code finishes, you will merge that into the trunk and the version 6.x branch, but NOT the 4.x branch. Then that branch becomes "maintenance" mode (really, this part is just happening in your head and requires no actual action).
Let's say that you now have the ideas for version 7.x. You can now create a branch of the trunk for that version and it will have the version 4.x and 5.x stuff, but not the 6.x stuff.
When 6.x completes, you will merge it to trunk and to branch 7.x.
This appears like it could become complex, so you will want to make sure you document everything very well in the beginning until you are used to the process you create. Pay special attention to the exact changes you merge into other areas and note that down somewhere.
Another option might be if you have a way to hide the features from version 5.x-7.x so that the customers only see 4.x. If you do it that way, you can keep everything in the truck until release, but that might have it's own complications.