You are not logged in.
Hi, I'm about to merge a bug fixing branch of my code into the mainline development branch in my CVS repository. Since I'm quite a CVS branch-and-merge noob, I'd like to know if, after the merge, I will still be able to commit to modify the bug fixing branch and eventually merge again later with the mainline, or if the branch would disappear and left me with only the HEAD mainline.
Thanks.
Offline
The branch would still be there. But the question is, once you merge into the HEAD, why do you still want to work in the branch (which is most likely older code - as long as the principle that all new coding should be done in HEAD was followed).
After the merge, you can create a new branch, which will have the latest code and work off of there.
I normally create a branch whenever we release to production and keep that branch intact for any bugfixes. New features go into the HEAD. every so often, I will merge the branch into the HEAD to get all the bugfixes into the main development line.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Thanks Inxsible. I know what I want to do is a bit unusual, but here's why. Apart from my code, my team produces a library; the rest of the people use the library and the code to work on some data. Recently, the dataset and the library had major upgrade, so the problem was to let the people work with both the old and new dataset and library for a smooth transition. Unfortunately my code cannot be compatible with both the library versions, so I branched it to continue developing the old version for people who still wanted it; HEAD instead has been modified to work with the new library. So I cannot branch again after merge, since the new code will be incompatible with the old library due to the modifications made in HEAD after the branch to achieve compatibility with the new one.
Now I'd like to merge since the transition period is almost finished, but there is the possibility that some other fixing or development has to be done in the branch, and that's the reason for my question. BTW, do you know if there is a smarter way to do this with CVS? (I know that there's plenty of better alternatives to CVS, but sadly it's not in my power to decide which version control to use...)
Last edited by snack (2010-07-08 12:30:54)
Offline
Well the branch would stay on. So you can still tinker around in it for bugfixes for the old version of the library.
Just merge the branch into HEAD and you should be good. Then for every bugfix in the branch, you would have to remember to fix it in the HEAD as well.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Just merge the branch into HEAD and you should be good. Then for every bugfix in the branch, you would have to remember to fix it in the HEAD as well.
Yes, that's what I did. I'm planning to merge regularly until finally the branch can be closed. BTW, merging was very smooth, even if the branching point was about 4 months ago and I did a lot of development in the meanwhile
Thank you very much Inxsible for your help!
Offline
Glad everything worked out. I think the branching and merging is quite useful if you use it correctly. I have known many programmers that tend to shy away from branching/merging either thru cvs or svn because they think its too difficult and error prone. But if proper cycles are maintained as to when to branch and when to merge, its pretty useful.
I haven't used anything but cvs and svn in an enterprise enviroment. Do not know how git or mecurial etc cope with this. I am assuming it would be the same as cvs/svn
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I know, in my collaboration nobody use branches but me (and the repository master got very angry when I opened the branch... : ) ). My colleagues barely know how to tag, and production software remains "as is" (read: no bugfixes) until a new production version is tagged and released, which happens once a year, usually. Quite crazy, don't you think?
I'm using CVS since my collaboration use it, but for my personal software I switched to git. I find it much more easy to manage than CVS, command are a bit different but much more simple once you learned them. There's plenty of graphical tools to show the repository structure, and branch and merge are very fast and intuitive. In my opinion it's worth a try for a CVS user...
Offline
I know, in my collaboration nobody use branches but me (and the repository master got very angry when I opened the branch... : ) ). My colleagues barely know how to tag, and production software remains "as is" (read: no bugfixes) until a new production version is tagged and released, which happens once a year, usually. Quite crazy, don't you think?
As them italians say ....Mamma Mia !!!!!
I'm using CVS since my collaboration use it, but for my personal software I switched to git. I find it much more easy to manage than CVS, command are a bit different but much more simple once you learned them. There's plenty of graphical tools to show the repository structure, and branch and merge are very fast and intuitive. In my opinion it's worth a try for a CVS user...
I might give it a whirl someday. Thanks.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline