[cvsnt] Branching/Tagging Best Practices
rparlee-cvsnt at flyinghippo.com
Mon May 19 15:12:45 BST 2008
That makes perfect sense. I guess I'm just not used to tracking things on a
bug by bug basis. We'll definitely start taking advantage of this. Cool
"Arthur Barrett" <arthur.barrett at march-hare.com> wrote in message
news:mailman.1054.1211179432.1277.cvsnt at cvsnt.org...
> My version of cvsnt didn't have the -B option on commit. I
> downloaded and
> installed the latest release and am beginnging to play with it.
> I don't understand, however, the purpose behind this option.
> Can you please
> tell me what this is used for and why it's important.
I thought I already had.
> internally does
> it work as any other tag except that it's just applied to the
> files which
> are committed?
> Should we be using the -B option on all commits when doing
> bug fixing on a
If you want things like TortoiseCVS history and revision graph to
automatically show which bug a change is related to then yes. If you
want to merge changesets (bugs) from one branch/trunk to another
branch/trunk then yes. If you want to do query reports based on
changesets/bugs then yes (eg: average number of commits/changes per bug,
average number of files changed per bug, average number of developers
Also using the bug id also makes it very easy to write an integration to
a job/issue/defect system like Bugzilla/Mantis/Jira (which is what we
provide in the commercial editions of CVS Suite Server).
More information about the cvsnt