We could just work with revision numbers and
remember each one for future reference, but tags make the process friendly and give
a feeling of accomplishment. Without tags the code will seem in a constant state of
flux, whereas with them we have solid points of reference.
Creating a tag has the same process as branching, which was described in Chapter 6,
except that we place them in the tags path rather than branches. Tag names should
correspond to the milestones we have defined in Trac.
Fixing a Bug
We need to follow a slightly different work flow for fixing a bug. Bugs??”or defects
in Trac terminology??”should always start with a ticket, even if it is one of the
developers who discovers it. New bugs should be processed on a regular basis??”an
activity commonly referred to as triage??”with the frequency being anything from
the moment each bug is reported to hourly, daily, or even weekly but we should
not have a processing cycle longer than that. This process aims to answer a few
immediate questions:
Has it been reported before?
Is the report valid?
Is it reproducible?
How severe is it?
Different projects may have different questions, but if we can answer these then we
have a good start. The benefit of asking the first question is obvious: if a ticket for
a similar bug already exists we can resolve this one as a duplicate within Trac and
move on.
Pages:
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109