On Wed, Jan 23, 2002 at 06:06:20PM +0000, peter.westlake@arm.com wrote:
> The docstring thing was just an example, surely.
I realize that it was just an example and a poor one at that. That's
why I also explained that my company has actually run a project using
bitkeeper which has this functionality and decided that while it
sounds nice in theory in practice we had no use for it in the
overwhelming majority of cases.
> Where would you put that information?
In my experience we've had two kinds of cases. One is we know what
the defect is and what to know what was done to resolve it. We look
to log messages for this.
> The kind of change comment you're talking about might say something
> like "fix bug 1234", and maybe have some details of the bug,
Actually our change comments say neither. perforce's changespec
clearly shows which job (i.e. defect report) was closed with this
commit. And the defect report contains a description of the problem.
Placing this information in the change comment is putting it in the
wrong place, IMHO. The change comment describes the change.
The second case is where we have a piece of code sitting in front of
us and we want to know how that code came to exist in its present
form. As my previous message said, we use p4pr.pl to examine which
lines were changed when and by whom.
We've never had any complaints with not being able to describe
per-file changes separately and after investigating bitkeeper we
decided it wasn't functionality we missed. Like I said before,
perhaps this is unique to the way our company partitions and documents
work, I don't know.
> For that matter, where do CVS users put it now? I've started to use
> CVS here at work, so I would really like to know :-)
When I've used CVS and wanted file-specific comments I've checked in
just the file in question. I say what has changed and mention that
this change is part of a larger development effort. Since CVS doesn't
have any meaningful way of grouping changes other than branching I
didn't feel I was losing anything by doing this. We would often use
branches to separate out even medium sized work efforts.
Justus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006