> From: kfogel@collab.net [mailto:kfogel@collab.net]
> Sent: 23 October 2001 00:02
> Let's talk about behavior first. Here are some log commands:
>
> $ svn log
> $ svn log -r 20
> $ svn log -r 20:30
> $ svn log foo.c
> $ svn log -r 20 foo.c
> $ svn log -r 20:30 foo.c
>
> The output of these would be similar to what you see now at
>
> http://svn.collab.net/svn-log.cgi
>
> .... that is, a straight commit-by-commit report of repository
> activity, going backwards in time, i.e., most recent commits first.
> (Notice how some of those commands were invoked on a specific file or
> set of files. I'm assuming that does the obvious thing: show just the
> commits in which that particular file(s) was involved.)
>
> Each commit's log message contains the revision number, author, date,
> and the actual log comment. Should each message also contain all the
> changed paths for that commit? (That is, all files on which text or
> props have been changed, and all dirs on which props have been changed
> or entries added or deleted.)
Not when svn log was invoked on a specific set of files. If looking for
a specific change commited somewhere down the line, it seems logical to
do a svn log -r <revision of change> to get the touched paths/files.
> This can get expensive to compute, since it requires delta_dirs-style
> walk through each revision for which the log is being generated.
>
> Should the format for commit messages be the same whether or not "svn
> log" was invoked on a specific set of files? That is, if "svn log"
> typically shows the paths involved in each commit, then would "svn log
> foo.c" as well? (Note that in any given commit involving foo.c, other
> files might be involved too -- the question is should they be shown in
> the report for that commit, even though you ran "svn log foo.c" not
> "svn log").
Isn't this a bit the same question as above?
> Since I never do very well pretending to objectivity, let me say that
> I think the format of log output should always be the same, and should
> always include the changed files of each commit (and if that's
> expensive to compute, it's worth some effort to make it cheaper,
> whether through caching, or suppressing deltification of directories,
> or other means). Would like to hear thoughts from others on this,
> though.
:) Lets take an example: Kevins big commit (#261). Do we really want to see
all changed files when we do a svn log <some file in the big commit>?
Especially when that commit wasn't really the one we were interested in...
[ofcourse, the subversion policy on log messages makes sure all those files
are listed anyway, but you get my point... I hope]
> Let's talk about implementation:
[...]
> Make it quick, I'd like to start right away. :-)
>
> -K
Sander
---------------------------------------------------------------------
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:45 2006