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?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 19 21:05:35 2005