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