[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Making 'log' show affected files
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] Making 'log' show affected files |
Date: |
Mon, 27 Dec 2004 11:56:33 -0700 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20041108) |
Julio M. Merino Vidal wrote:
Hi all,
a lot of people don't use changelog files in their projects (I'm one of
them). Or even if they do, they don't stick the changelog entry in their
commit messages.
The manual effort of recording affected files in the ChangeLog certainly
does seem to me to be rather pointless and error prone, particularly
when the vcs knows exactly what files where changed.
So, what happens? 'monotone log' output can look quite ambiguous, and one
needs to manually 'cat revision' to see what happened at each point.
I agree, and I wonder if log should have perhaps 4 volume/verbosity
levels. i.e. (quiet) list revisions briefly using the describe_revision
format as heads does; (current) list somewhat more information like the
current format; (files) list the details from the revision, add_file,
etc. as you have done; (diffs) list the details of the revision as well
as the actual diffs between files allowing one to "read" the revision graph.
I would like to get some review on the patch. It works, but I may be doing
things in an "incorrect" way. That is, maybe I should be using
basic_io::printer (though I don't think so, given that 'log' directly writes
Can you not use basic_io:::printer to a stringstream and then send that
to cout, or even just print directly to the cout stream?
to cout). Or maybe there is another way to "merge" information from all
change_sets (what I'm doing now with the changes_summary structure). Or
maybe anything else I'm missing... ;)
Why bother merging them at all, how about just listing the two (or N)
changesets separately. This might actually be a good thing, as you
aren't losing any information. In most cases there will only be one
changeset anyway.
As a data point: Arch and Subversion do this, so it looks like many other
people fins it useful. Plus maybe you haven't found a need for this yet
since almost all commit messages are in changelog form (but some of them
aren't).
I also think I like the multiple Author: and Date: lines in log, rather
than several entries per line. The is a slight problem either way with
these though. The only way of associating an Author: with a Date: is
through the signing key, but with things like the changeset migration
most certs have been signed by the same key and this is no longer
possible. I wonder whether author and date should be inherent in
revisions? The same problem exists for changelog certs too but we
probably really don't want these as part of the revision itsself.
Cheers,
Derek