Re: Logging granularity
From: maru <maru_at_mobile.rogers.com>
Date: 2003-05-15 21:24:55 CEST
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?
>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.
One of the reasons why we only have per-commit logs is to, let's say,
>So, any answers to my original question? :-)
OTOH, you could easily change a custom "change-description" property on
Another issue is one of performance. It's quite a bit more expensive to
-- Brane ─îibej <brane_at_xbc.nu> http://www.xbc.nu/brane/ --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Thu May 15 21:29:08 2003
This is an archived mail posted to the Subversion Dev mailing list.