[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Logging granularity

From: maru <maru_at_mobile.rogers.com>
Date: 2003-05-16 02:10:03 CEST

My first responsibility is to apologize for my previous remarks. You are correct, my comments can only be construed as a personal attack. I've let my frustration over the intractibility of this issue get the better of me, and I hope you'll forgive me.

My original intent in questioning the subversion approach to logging was to try to find a compelling argument as to why per-commit logging should supplant per-file+per-commit logging. I was more than a little dismayed to find that per-file logging is seen as a 'bad' feature based largely on developer experience with it in cvs (thanks to Karl for the clarification). I would argue that there are other scm systems that provide this functionality (re: bk) and whose users (probably) appreciate it.

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

Thanks

Maru
-----Original Message-----
From: Branko ─Œibej <brane@xbc.nu>
Date: Thu, 15 May 2003 23:40:05
To:maru <maru@mobile.rogers.com>
Cc:cmpilato@collab.net, kfogel@collab.net, dev@subversion.tigris.org
Subject: Re: Logging granularity

maru wrote:

>Your flippancy in the face of constructive criticism of a seeming lack of respect for users is instructive. I won't belabour the point but it is always disappointing to see such arrogance among developers. Commit each file seperately indeed! If your viewpoint is representative of the svn delopment team, my arguments for more log granularity will clearly fall on deaf ears. I'll leave it at that.
>
First, you "categorically disagree" with the current approach, which
shows how much you're prepared to swap arguments. Then you accuse me of
elitism because I happen to voice the opinion that users should learn to
use tools the way they were designed to be used; this you call
"constructive criticism". Then I propose an alternative which I say
explicitly is not elegant, and so that's flippancy. Don't you think
you're a bit inconsistent?

As to "lack of respect for users" and "arrogance": Did I "categorically
disagree" with your idea? I did not. I tried to explain why I think the
current way is better, and why yours is not as trivial and obvious as
you seem to believe. But did you take the time to think about my
arguments against it? You did not; you stared to pile on the abuse.

Well, if you think I should quietly accede to your demands, you can damn
well pay me for working on Subversion for you. Otherwise you'll just
have to learn that your opinions are not made holy by the fact that you
you're a User and I'm just a lowly developer.

By the bye, your "arguments for more granularity" have been, in order of
appearance:

>I see value in [this] approach
>
>I believe it is valuable to have per-commit-item logs
>
>I would be surprised if I am the only one finding this limitation frustrating.
>

These aren't arguments, they're opinions. You'll have to try harder.

-- 
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:12:00 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.