Re: about bug tracking

[David Turner]

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."