Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Sat, 12 Jun 2004 08:01:30 +0000 (UTC), "guastatore" <guastatore1870 at hotmail.com> wrote: >Hi all, > >I followed the good hint by Bo Berglund about to branch my actual >project in two version: OOP branch and normal development on my trunk. >Now I cannot understand how to come back to my trunk. Let's me explain >again. > >I'm arrived at a point in my project where I have to do a big >refactoring but this project is actually used, so I don't want to have >loosing the operativity that my software now is offering. >Well, I splitted a successful branch and can work on it very well, and >I can apply it to repository without problem. >Now, my problem is that I cannot understand how to come back to actual >trunk. I tried to apply a tag to the trunk and I'm able to come back to >it but I have 2 problems >1. if I go on to develope the trunk when I'll come back to it from >branch I can to retrieve the old tag and not the actual tip of trunk. >2. I cannot apply the trunk to the repository because it's a sticky tag. > >I used to split the branch using Update in the same directory rather >than checkout to a new dir. > >Hope I explained well what is my problem. > >Thanks >Antonio Procedure: 1) Develop something on TRUNK. Apply tags etc as needed 2) Decide that new stuff needs to be added but not interfering with TRUNK development. 3) Create branch tag on TRUNK (at HEAD position). "cvs tag Branch_101" 4) Update sandbox to created branch tag. "cvs update -r Branch_101" 5) Continue development, now on branch. Files get committed to branch. "cvs commit -m"Committing on branch"" 6) Ready to move developments on branch to trunk 7) Update sandbox with "remove sticky tags" option. This moves sandbox to HEAD. "cvs update -A" 8) Update sandbox again, but now specify merging with the branch that holds the files with the new stuff. "cvs update -j Branch_101" 9) This merges in all of the changes done on branch to the sandbox files. 10) Examine all files that changed during the update and check that they are OK. They probably are, but you must check yourself. 11) Especially important is to examine the files that have been flagged as "Conflict" because they have both the branch and trunk data in them and you must manually edit them and remove the data that should not be there. 12) Recompile and check your application 13) Finally when all of this has been done, commit the modified files. It is good practice to tag the module at two (or even 3) points so that the situation can be restored: - Before the update to the branch tag (before step 4 above) - Before the merge operation at step 8 - After the commit in step 13 - Optionally also after updating to the branch in step 4 These extra tags make it possible to go back to the state before the branch was created, before the branch data were merged to the trunk and after the merge was successfully performed. Tagging is standard procedure to do this. /Bo (Bo Berglund, developer in Sweden)