Re: Logging granularity
From: maru <maru_at_mobile.rogers.com>
Date: 2003-05-16 03:18:56 CEST
(shh, don't tell - I have used bitkeeper for some of my projects!)
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.
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. Keep up the good work!
>Beyond implementation challenges or bad cvs memories, the exclusion of per-file logging from svn appears to be largely one of svn developer preference. Logging granularity is clearly a religious issue - I wish I had realized this earlier. There is little I can do to pursuade die-hard fans of revision-only logging that per-file logging has any merit.
>There is little you can do to convince me that bad experiences with one revision system - cvs - justify the exclusion of per-file logging from svn.
My first reaction was, "this is nuts, I have years of experience with
For example, let's say you have a C program, and you change the
Later, someone looking at the history of one of the implementation files
On the other hand, in Subversion's model it's trivial to group such
I believe many, many people have come in touch with Subversion and had
> I hope we can just agree to disagree on this. I'm sure you have better things to do than argue with feature-whiners such as myself.
-- 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 Fri May 16 03:20:28 2003
This is an archived mail posted to the Subversion Dev mailing list.