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

Re: RFC: Log Message Templates via new hook.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-05-19 21:04:31 CEST

Greg Hudson wrote:

>On Thu, 2005-05-19 at 07:03 +0200, Branko Čibej wrote:
>> * No-one answered the question whether log-message templates were
>> really the top priority, compared to, e.g., server-side autoprops.
>Who's supposed to "answer the question"? The discussion ended
>inconclusively. Perhaps Karl should have called for a vote rather than
>forging ahead; I don't know.
A vote all by itself doesn't mean much. At least a statement as to why
log file tempaltes are more important than (say) server-side autoprops
would have been welcome.

(For the record, I'm not 100% sure why I'm treating these two features a
group where order could be important. Perhaps it's just my beleif that
the two are connected implementation-wise that's skewing my perception.

>> * The overlap between log templates and server-side config was
>> mentioned, then completely ignored as irrelevant.
>You mean <http://svn.haxx.se/dev/archive-2005-05/0795.shtml>?
No, what I had in mind were the first two paragraphs of Karl's original

>to which you replied with an ad hominem
Yes. Sorry about that.

>> * An awsomely sexy implementation was proposed to dynamically
>> generate templates (and it can't possibly be reused for
>> server-side configuration, but this fact was ignored as per
>> above), but no-one even showed a pressing need for the sort of
>> flexibility being offered. It's boiled down to a case of "let's do
>> it because we can."
>Being able to dynamically generate templates was listed as a side bonus.
>Being able to *choose* templates using any desired logic, rather than a
>fixed set of rules, was the primary motivation behind Karl's proposal.
>And Karl arrived at the need for this flexibility by looking at what CVS
>did, and deciding that its fixed ruleset was lacking and that it wasn't
>clear how to make it better.
I meant the term "dynamically generated" in the generic sense. Obviously
that can include "choice using any desired logic"

>>I also find it *very* disturbing that no-one even analysed how log
>>tempaltes could be used.
>To me, this is pretty elementary, and it isn't disturbing at all that
>people would skip past it.
I find it hard to accept that it's elementary given that we haven't
expored the possibilities.

For example, one of the arguments for a server-side hook was that it
would allow the server admin to define how to handle the case where a
single commit contained paths from different "projects" that would
require different log templates.

Now, that's certainly a generic solution, but it's not necessarily the
*reasonable* solution. I the projects in the repository are so different
that they need different log templates, you might be better off by
refusing the commit. Or you could simply concatenate the different

>> The implicit assumption is, "have SVN provide a
>>tempalte for a commit log message". Based on this very general
>>requirement, we have on the table a proposal doesn't address the case
>>where you'd want to generate the template and write the log _before_
>>running "svn commit". Which, at least for me, is the natural order of
>No reason we couldn't provide an interface to produce the log template
>without performing the commit. Then you'd edit the template and commit
>with the -F flag, which wouldn't fetch a template at all.
>You might argue that client-side template generation, using static data
>obtained at checkout/update time, is better because it means you can
>produce the template without being able to contact the server. If
>that's the argument you want to make, just make it;
To tell the truth, I only thought of this issue afterwards. But yes, I
think disconnected log template generation would be a bonus.

> there's no need to
>attack the format of the discussion.
I was questioning the content, not attacking the format. I don't buy the
idea that this is a simple feature, that's why I'd like to see more
discussion about alternatives. And I found it "interesting" that there
was talk of a consensus less then 48 hours after the original proposal
was posted. What's the rush?

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 21:05:35 2005

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.