Re: Logging granularity

Your flippancy in the face of constructive criticism of a seeming lack of respect for users is instructive. I won't belabour the point but it is always disappointing to see such arrogance among developers. Commit each file seperately indeed! If your viewpoint is representative of the svn delopment team, my arguments for more log granularity will clearly fall on deaf ears. I'll leave it at that.

As unfortunate as I find your attitude to be, I do appreciate your idea of using a wrapper script. It seems a logical extension of my parsing ideas, and will provide the functionality that I need.

Thanks

Maru
 
-----Original Message-----
From: Branko ÄŒibej <brane@xbc.nu>
Date: Thu, 15 May 2003 21:48:47
To:maru <maru@mobile.rogers.com>
Cc:cmpilato@collab.net, kfogel@collab.net, dev@subversion.tigris.org
Subject: Re: Logging granularity

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