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
Received on Fri May 16 02:55:33 2003