Re: Bug fixing and CVS tagging

[Pierre Asselin]

Mateusz [PEYN] Adamus <address@hidden> wrote:

> Lately I read a book about CVS "Pragmatic Version Control" by David 
> Thomas and Abdrew Hunt and it was said in that book not to use to many 
> branches, not to complicate to much. So how many branches is to much? 
> (I'm talking about recurent branches ofcourse).

When you lose track of which branch is for what, that was one branch
too many.

What really doesn't work is long-lived branches that grow in parallel
and carry variants of your product.  This is partly because cvs is not
good at merging back and forth between branches;  other tools do that
better, but still it can get confusing.

Branches should be short (if possible) and have a clear purpose.
When you create one, you should know how it will end.  Usually
by being abandoned or by being merged back into the trunk and closed.


> Pierre Asselin napisa?(a):
> > [ about merging a barnch to the trunk and updating a moving tag ]
> > If you run a team you have to be a little careful about others
> > committing stuff while you're doing this.  Post again if you
> > need details --but it seems you're working solo ?

> I'm working with 4 other guys. It's a small company. We're all sitting 
> in one room so we can talk to each other. Although, we are trying not to 
>   distract one another to often

Ah, very good.  All you have to do is tell them: "hey, don't commit
to branch xxx for a while, I'm merging it to the trunk".  That's
not a permanent solution, so here is something more fool-proof.

The scenario is:  you're in a sandbox on a release branch and you've
fixed a bug.  So you
    cvs commit

to the branch.  If that goes through, fine.  If not, it's because
someone else was working on the same branch and committed something
ahead of you.  In that case, you have to "cvs update", resolve any
conflicts and re-test your bugfix before trying to commit again.
All this is normal cvs work.  Eventually one of your commits will
succeed.

You now have a sandbox that's in sync with some snapshot of the
repository (i.e. no locally modified files) and you know exactly
what that snapshot is because the revisions are listed in your
CVS/Entries files.  You create a personal tag,

    cvs tag tmp_Mateusz

using some pre-agreed naming convention to avoid collisions.

Now you merge to the trunk.  You go to a trunk sandbox, or
check out a new one.

    cvs update -A       # to be on the safe side
    cvs update -j the_branch-MERGED -j tmp_Mateusz

Here I assume that the branch had a "...-MERGED" tag to indicate
the last time it was merged to the trunk.  If this is the first
merge, you use the branch point instead.  So now your sandbox
has the trunk, plus all the changes between the last merge
and your bugfix.  It doesn't matter if someone else added stuff
to the tip of the branch, because of your use of "tmp_Mateusz"
as the terminal point of the merge.

You fix any conflicts, test the merged files, etc.  Now you
can commit the merge to the trunk.  Jim Hyslop would probably
tell you to tag before and after the commit.  He has a point.
Too many tags is not nearly as confusing as too many branches
and recreating a missing tag after the fact is a major pain.

    cvs tag Mateusz_before_merge
    cvs commit
    cvs tag Mateusz_after_merge

Now you move your -MERGED tag.

    cvs tag -F -r tmp_Mateusz the_branch-MERGED

Again, it doesn't matter if the release branch has grown
while you were doing this, because the -MERGED tag is moved
to the placeholder tmp_Mateusz.  You can then delete the latter,

    cvs tag -d tmp_Mateusz

That's about it.

-- 
pa at panix dot com