Re: Logging granularity

maru wrote:

>(shh, don't tell - I have used bitkeeper for some of my projects!)
>
:-/ I hope it's not the "free" copy; if it is, the license forbids you
to contribute to Subversion development, and these discussions might be
construed as such.

>The strongest single argument for per-file PLUS per-revision logs is bitkeeper. It provides all the power of per-revision logging, which you argue for very convincingly. And believe me, despite my vitriol, I do agree with all of your arguments. But I do not believe that they invalidate the usefulness of having optional per-file comments _in addtion to_ the per-revision comments. Bitkeeper supports this, and I found it very useful to have an over-arching revision comment like 'changed interface in encoder.h and updated dependants' and then optionally comment on each file where functional changes were required. This offers all the benefits of per-revision logging that you have lauded, with the added benefit of providing specific file comments where necessary - tied to the file instead of lumped in a general comment. I find this to be a more elegant solution to cvs's logging shortcomings than the svn way.
>
>I don't question your preference for the svn way, but neither can you question my preference for the bk way. I still think it's a religious issue.
>
Ah, actually it's a religious issue only if we don't question
preferences. :-)

>That said, I have been provided a number of suggestions to add per-file revision support to svn. It is a great product and I enjoy using it despite this minor issue.
>
Yes. Subversion has (almost) all the features that are required to
support this model (I say almost, because I still believe there should
be a way to change committed log messages, and svn's properties
currently don't allow that. Whether they should or not is a thorny issue).

So it comes down to UI issues, and the API that is needed to support a
UI for per-file log messages. If someone came up with a good design, and
preferably a patch, I'd be quite happy to spend some time reviewing it.
I still don't think we'd want to put it in 1.0, if nothing else then
because of the prop change dilemma; but it would certainly be fun to
have something like that in 1.1.

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