[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Logging granularity

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-15 21:48:47 CEST

maru wrote:

>Sorry for quoting everything, it's a limitation of my mail client (rim bb).
>I have to categorically disagree with the approach of forcing users to use per-commit logging as an 'education'. That seems pretty elitist (we only allow the 'right' way of doing things) and discounts the possibility that other approaches might have utility.
Well, people can always commit one file at a time; we don't make any
restrictions about that. As for "elitist" -- bah. Users have to learn to
use all sorts of tools, and every tool was written with a "right" way of
using it in mind, which makes other ways a bit less elegant. I believe
most of the SVN developers happen to like this way of granulating commits.

>That said, I can't discount the technical issues that may have influenced this design decision. I do have a suggestion that might work with minimal overhead and little in the way of ui changes.
>Add a switch to svn commit to provide a pre-formatted template with blocks for each file in the changeset and an overarching commit block. Parse it back, strip any unused comment blocks out, and save it as the regular log. Users who don't want per-commit-item logs don't have to use this switch. Commit logs themselves would be stored in the repository exacly the same. Viewing logs could be the same as well, with the bonus that one or more command line switches could make the log command display only the per-commit log and/or per-file logs valid for that invocation of svn log.
Oh yuck. This is so error-prone, and it's not a "simple" parser at all.

>Since this implementation relies on existing features and only introduces minor parsing overhead (and then only on the frontend), can anyone tell me why it would not be feasible or desireable to do this?
It's feasible, but it's not minor parsing overhead, and not in the
front-end; if we added a feature like this, we'd have to make sure that
_all_ Subversion clients can use it. Which means supporting it on the
API level.

On the other hand, it's quite easy to write a wrapper script around "svn
log" that filters the log output like this, and you can then educate
your users about the correct log message format. This seems like a
site-specific thing that can easily use a site-specific solution,
without touching Subversion code at all.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 21:49:45 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.