Re: [Monotone-devel] Making 'log' show affected files

[Julio M. Merino Vidal]

On Mon, 27 Dec 2004 11:56:33 -0700
Derek Scherger <address@hidden> wrote:

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

I wholeheartedly agree.

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

This might be good.

> > 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?

I could, probably.  But I thought this was not useful because log is using
cout already, and I'm just adding some more stuff to it (the auxiliary
function is just to avoid crowing the log function command too much).

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

Hmm yes, showing them separatedly is exactly what the history says, but
makes them a bit more difficult to understand.  Consider a merge revision,
for example:

The merge log message says which revisions are being merged.  So, if you
want to see the two changesets separatedly, you can easily look for that
specific revisions and see what happened there.

However, when you are looking at the merge revision exactly, you are
interested in the global thing that happened there, i.e., which files
were modified, which ones added, etc.  all together, not separated,
because the resulting tree will be a merge of the two revisions.

So I felt that having all changes shown at once was a good thing.
Otherwise I couldn't have coded all the extra stuff required to merge
them ;)

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

Me too, specially because they come from different certs.

Thanks,

-- 
Julio M. Merino Vidal <address@hidden>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/