Hi,
I'm a solo developer at my company, doing everything from database to deployment. I have two "versions" of the applications I work on; development and production (maintanence).
I'm at a point now where I'd like to make my break again, so that I can have the maintanence bug-fix only branch, and the main development trunk. What I had been doing is deleting the $/maint branch, and then branching my $/devel folder.
I'd just like to check if this is the right way to go, or should I merge changes from $/devel to $/maint? I started to do that, but then somethings don't seem to transalate, like new files don't get added to $/maint. Also, I get the entire history to choose to merge, so I'd need to find exactly where I branched previously it seems.
What's the best way to do this? I just need my development version and one maintance version... all users are forced to use the same production version of my software, they don't get a choice.
Thanks
Andy
Recommended approach?
Moderator: SourceGear
You may wish to look at our Branching Best Practices KB article.
You don't need to delete your branch, though you will want to keep track of which changes had already been merged in. Merging changes is not the same as finding all the differences and merging. It looks at the actual changes checked in, and if the wrong ones are selected, a user could miss changes. Each time you perform a merge, it may be good to add a comment or a label that lists what changes were merged in. Until you are used to it, it could be a good thing to do more documentation of your changes rather than less. Once you know what to expect, it will go faster.
Since we have a lot of things going on at once, we perform a check after doing a merge branches.
You don't need to delete your branch, though you will want to keep track of which changes had already been merged in. Merging changes is not the same as finding all the differences and merging. It looks at the actual changes checked in, and if the wrong ones are selected, a user could miss changes. Each time you perform a merge, it may be good to add a comment or a label that lists what changes were merged in. Until you are used to it, it could be a good thing to do more documentation of your changes rather than less. Once you know what to expect, it will go faster.
Since we have a lot of things going on at once, we perform a check after doing a merge branches.
HI,
That was helpful. I just have one clarification.
I did the label, then merged the trunk to the branch, and things went fine.
Now, I sometimes use merge from the branch back into the truck so that bug fixes from the branch get included in my development truck. When I do my next relese, will it be safe to include everything to the label from the previous release, even though there's been some "back and forth" merging in the mean time?
Thanks
Andy
That was helpful. I just have one clarification.
I did the label, then merged the trunk to the branch, and things went fine.
Now, I sometimes use merge from the branch back into the truck so that bug fixes from the branch get included in my development truck. When I do my next relese, will it be safe to include everything to the label from the previous release, even though there's been some "back and forth" merging in the mean time?
Thanks
Andy
It's best if you keep track of the change sets merged and include that in comments. Most times when I try this, I don't have a problem. If the change though is the last line of the file, it could be reapplied. That one has been logged as a bug to be fixed.
It's usually best to have your code be only mergable one way to avoid confusion.
It's usually best to have your code be only mergable one way to avoid confusion.