Re: Logging granularity

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

Thanks

Maru

-----Original Message-----
From: Branko ÄŒibej <brane@xbc.nu>
Date: Fri, 16 May 2003 02:54:44
To:maru <maru@mobile.rogers.com>
Cc:cmpilato@collab.net, kfogel@collab.net, dev@subversion.tigris.org
Subject: Re: Logging granularity

maru wrote:

>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.
>
Well, it may be a religious issue, at that. It doesn't feel that way to
me, but since I'm a convert, my opinion is hardly unbiased. :-)

>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 personal experience has been with RCS, CVS, Visual SourceSafe,
ClearCase and Enabler (that last was a project I worked on "during the
day"). Despite being very different systems, in terms of size,
functionality and working models, they all offer per-file (or rather,
per-object-version) logging, and per-object-version revision numbering.
So when I came in touch with Subversion, I was completely baffled by the
idea of global revision numbers and per-commit log messages.

My first reaction was, "this is nuts, I have years of experience with
other tools and they all do this differently". However, I quickly came
to realise that it makes perfect sense, given the assumption that the
natural granularity of commits is not a single file, but a logically
complete change (bugfix, feature, what have you). A change may affect a
single file (this is the common case with, e.g., design documents), or
many files (the common case with program source code). It makes more
sense to attach the log to the changeset, rather than to its individual
parts, because that way it's easier to understand what the commit was
all about.

For example, let's say you have a C program, and you change the
signature of a function that's used in several modules. This change will
typically affect a header and several implementation files. In a
per-file logging system, you might describe the reason for the change in
the header's log, but in the other files', you'd just note that the
function signature changed.

Later, someone looking at the history of one of the implementation files
would see that signature change mentioned in the log, but would have no
idea about a) why it was necessary, and b) what other parts of the code
were affected.

On the other hand, in Subversion's model it's trivial to group such
logical changes; you'd just commit all the files together, and in the
log, you'd only have to explain why the signature changed and how. A
user browsing the history of any file would immediately see both what
the change was, and the reason for the change, /and/ what other files
were affected by it. All this information is immensely useful for
tracking down bugs, tracking the state of development, etc. etc.

I believe many, many people have come in touch with Subversion and had
the same first reaction as I did; then, after gaining some experience
with the model and understanding its benefits, most of us never looked back.

> 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.
>
>
I only hope my explanation helps you to understand the reason why
Subversion behaves the way it does, and what the benefits are. The
drawback is that you can't bundle several unrelated changes into a
single commit, and still keep the log contents in a sensible shape.
That's where the "user education" bit comes in -- starting with the
question, why would you want to combine unrelated changes, or break up
related ones?

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