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
proposal.
[...]
>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
templates.
>> 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
>>things.
>>
>>
>
>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