[cvsnt] Re: Problems going back to the trunk

[Bo Berglund]

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)