RE: Bug tracking.

[Zieg, Mark]

> > 3. How can I apply those ten files very precisely from Dev branch to
Trunk
> > then to another branch?
>
> The ideal way would be to create a tag before the bug fixes were
committed:
>
>   $ cvs tag Bugfixes-123-Before
>
> Then commit the fixes...
>
>   $ cvs tag Bugfixes-123-Fixed
>
> Then you can apply that set of changes to any branch using...
>
>   $ cvs update -j Bugfixes-123-Before -j Bugfixes-123-After
>
B> Zieg, I have seen this approach before. Is it hard to implement in real day
B> to day operation? It seems like, in order to check-in and out one change,
B> two extra lines of commands need to be used. I dont think developer will
B> like this approach. Any comments from the developers using this approach?

I very, very rarely bother with the above in day-to-day operations.

In reality, people apply their bugfixes to the main trunk all day, every day.  
Whether they develop directly on the main trunk, or whether they create and 
test the bugfixes on side branches is irrelevant.  Once the fixes are complete, 
they get merged into the main trunk regardless.

There is no reason to "manually" re-apply every individual set of fixes to 
other branches.  If for some reason you decide to maintain several active 
branches, then those branches need to be synchronized with the bugfixes from 
the main trunk on a regular basis.  

When you do that resynchronization, there is no reason to individually merge 
specific sets of fixes; you merge the entire branch.  That is, you pull in ALL 
the bugfixes which have been committed since the last synchronization.

You can do that easily with "cvs update -j ... -j ..." as long as you create a 
tag each time you do the synchronization, or you can use something like my 
<http://www.zieg.com/pub/cvsWhoWhatWhen> to extract a patchfile after-the-fact.

But if you're going to do lots of funky branch stuff, and you want to keep it 
automated, you're going to need to learn to write your own scripts.