[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about bug tracking
From: |
David Turner |
Subject: |
Re: about bug tracking |
Date: |
Fri, 20 Oct 2000 14:21:38 +0200 |
Hello,
I've recently talked about the use of ChangeLog with one of my
colleagues who used to work at HelixCode. It seems it's been the
source of a few blood baths already between developers (well,
I'm certainly stretching it a bit ;-), and that there are
many ways to use such a "feature".
As I understand it, the purpose of using a ChangeLog is
related to some annoying weaknesses in CVS usage, please
let me know if I'm not correct:
- ideally, each developer should be able to commit each
"atomic" change it does to the sources, and adequately
comment it. We wouldn't need anything special, except
some clever scripts to convert a CVS commitlog to
something more pleasing to the eye :-)
- Unfortunately, remote cvs server latencies and dial-up
internet access practically forces us to group our
commits. As CVS only accepts one message per commit,
we usually lose a lot of information on why specific
files were modified.
- Werner seems to use a ChangeLog file to record each
"atomic" file(s) modifications and its appropriate
comment. He then runs a Unix script to commit its changes.
the script barely parses the new ChangeLog entries,
sorts the changed files and performs several commits
itself with the appropriate file list + comments.
his ChangeLog is used as a "commit cache"
- other people tend to exclusively use the CVS commit log,
and automatically generate a ChangeLog file in the source
repository. After all, it still gives a clear idea of
what's going on in the project to all developers,
including those that simple download snapshots.
of course, it needs that you keep on performing
"atomic" commits to be meaningful, which seems
a bit inadequate in the case of a dialup accounts..
- my opinion is that I'd rather like to see this problem
managed by CVS itself, with some sort of two-level commits.
However, it seems clear that this is not an easy addition
to the program, given that it's not designed to keep local
commit information.
I have no definitive opinion on this topic. For now, we could do
without a ChangeLog file, but it's clear that we would benefit
greatly from it. The question is to know wether we can all agree
to use the same tool/convention.
I believe the "commit cache" method is actually a very good idea,
though it only runs on Unix for now. Basically, do we have a
volunteer with enough time to rewrite it to something more
portable (my favor goes to Python, as you now, but this is
not a requirement.. anything that works on Windows, Unix and
Mac will go..) ??
Regards,
- David
Pavel Kankovsky a écrit :
>
> On Thu, 19 Oct 2000, Werner LEMBERG wrote:
>
> > But isn't it better to edit the `visible' file instead of the
> > `invisible' ones?
>
> I do not know. I myself find one way more convenient (one can write the
> comments in the most stupid editor like Notepad in Windows (I have to do
> quite a lot of multiplatform development) and CVS itself makes sure the
> change entry gets a meaningful timestamp and the correct list of affected
> files) but I do not say it is the best way for everyone.
>
> --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
> "Resistance is futile. Open your source code and prepare for assimilation."
- Re: positive descender with type1 fonts, David Turner, 2000/10/03
- Re: positive descender with type1 fonts, Werner LEMBERG, 2000/10/04
- Re: positive descender with type1 fonts, David Turner, 2000/10/11
- Re: about bug tracking, Pavel Kankovsky, 2000/10/19
- Re: about bug tracking, Werner LEMBERG, 2000/10/19
- Re: about bug tracking, Pavel Kankovsky, 2000/10/20
- Re: about bug tracking,
David Turner <=
- Re: about bug tracking, Werner LEMBERG, 2000/10/21