Re: Logging granularity

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.

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.

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?

Thanks

Maru
-----Original Message-----
From: Branko ÄŒibej <brane@xbc.nu>
Date: Thu, 15 May 2003 20:54:26
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 my imprecise language, but cmpilato has it right. I believe it is valuable to have per-commit-item logs in _addition_ to per-commit logs. The per-commit log should describe the overall functional changes of the commit, while the per-commit-item logs can describe the changes made to the individual item to achieve the functional changes described in the per-commit log.
>
>Currently I find myself using the per-commit log to describe both functional changes and file changes. I would be surprised if I am the only one finding this limitation frustrating.
>

One of the reasons why we only have per-commit logs is to, let's say,
"edcate" users to group logically related changes into a single commit,
and use separate commits for different changes. If you look at
Subversion's own commit log, you'll see that we follow this guideline
99% of the time; so the logs describe a changeset, and descriptions of
changes to indivitual files in the changeset come naturally from there.
They aren't frustrating at all.

>So, any answers to my original question? :-)
>
Well, the first question that comes to mind is how to handle this in the
user interface. It would be a real pain if "svn commit" required a -m or
-F option (or started the editor) for every file that was part of the
commit, and once for the whole commit itself.

OTOH, you could easily change a custom "change-description" property on
the files before you commit them. It's not the most elegant way, but it
works. The only problem with this is that you can't change prop values
on committed files; this means that, unlike the revision's "svn:log"
property, you wouldn't be able to fix the change description on
individual files, which means you'd always have to get it right the
first time.

Another issue is one of performance. It's quite a bit more expensive to
fetch file properties for all versions of a file than it is to fetch
revision properties for all revisions in which a file changed. That's
actually an artifact of our repository schema, but I don't see a
compelling reason (or possibility, to be quite frank) for changing the
schema now.

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