You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/05/18 21:49:32 UTC
RFC: Log Message Templates via new hook.
That's "RFC" as in "Request For Consensus" :-).
Discussion seems to have died down, and that may be because people
mostly agree on the way to go now. So, I'd like to get consensus on
this proposal:
A new RA method, svn_ra_get_log_message_template(), that takes a
list of paths and returns the log message template. On the server
side, this is implemented by invoking a new 'log-message-template'
hook, which takes the author as an an argument and a
newline-separated list of (UTF8) paths on stdin. Whatever the hook
prints to stdout is the log message template. If it prints
nothing, or there is no hook, then there is no log message template
and the client behaves as it does today.
The RA method is invoked only when interactive $EDITOR is used to
write a log message.
(Whether the RA method takes a static list of paths, or receives
them via repeated callback invocations, is something we will have
to work out; but this does not affect the overall proposal.)
The server would know the author because of the RA layer's
authentication; the client would not have to pass the author name
to svn_ra_get_log_message_template().
We will ship with a default 'log-message-template.tmpl' file that
just ignores the paths and prints a standard-looking template to
stdout. But the .tmpl file would document the hook's calling
discipline fully, of course.
Obviously, there are some details to be worked out here, but this is
well-specified enough to ask for consensus on the general approach.
Objections?
The strongest objections so far came from Brane, I believe, and have
been responded to on-list, so I won't repeat the details here. Brane,
I'm certainly not demanding that you give consensus against your
wishes. However, I think it's better not to pull out the "veto" card
in your second message :-)...
> Besides, suddenly you'd have an extra trip over the network
> regardless of whether you use log templates or not, and I'm very
> close to vetoing the proposal for that reason alone.
Please, let's reserve talk of vetos for after technical discussion has
failed to lead to a resolution. I realize that formally it doesn't
matter when one starts mentioning vetos; however, it raises the stakes
prematurely and can have a polarizing effect on the conversation
(although I think it didn't in this case, fortunately).
Again, that's a comment about style, not substance. Feel free to
withold consensus now, and we'll continue discussing if so.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On May 18, 2005, at 5:48 PM, C. Michael Pilato wrote:
> I've been sitting on the sidelines, mostly just to see where the list
> took this without my interference. I must say, though, that I (like
> Brane) am not thrilled about the idea of essentially asking the
> server, for each commit, to run a hook-script to conjure up a bit of
> text which itself isn't even necessarily going to be "used" (as in,
> outlive the final edits of the commit message).
It was my understanding that the roundtrip would only happen when
'svn commit' is run without passing a log message *at all*.
> And I'm a little
> disappointed that my idea for having the server simply dictate a
> static template which contains substitable regions was mostly
> overlooked (by all but Brane, it seemed, though that's my fault for
> not expressing the idea as more than a top-of-the-head thought).
I think that that idea suffers from the same problem that static log
templates suffer: All of the logic for filling out the template (and
deciding what to do in the case of multiple directories with
conflicting templates) must reside in the client.
The advantage of using the hook is that it puts the log message
template control into the hands of the system administrator (and
whatever programming language she's comfortable with).
> I appreciate that we have an opportunity here to excel beyond the
> limitations of CVS's log message template feature, and I also
> appreciate the urge to at least improve over CVS's *implementation* of
> that feature, if not the provided functionality. But I can't help but
> wonder if the proposal as it sits isn't overkill, and am not so quick
> to decide that this feature can't be cheap(ish) fallout of a generic
> server->client configuration dictation system. Such system, of
> course, does itself not exist, and so is reasonably suspect as
> suitable for the support of log message templates.
I really do think that the two are apples and sausages, but I'd be
glad to be proven wrong.
> But I think we'd
> do well to consider the requirements of both systems, examine their
> overlaps, and determine if we have a reasonably common bit of design
> work that can be leveraged to maximize simplicity -- perhaps at the
> cost of "bonus" functionality -- but without compromising the
> essentials of either system.
In that case, let's step back from implementation issues and lay out
some use cases for both log message templates and server-side
configuration options. Once we gather those, then we can start to
develop some concrete requirements before we all (especially myself)
go leaping for the implementation.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> 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?
/me faces the passive voice head on :-)
That was my doing, but my consensus probe was just that -- a probe.
As it turned out, the momentary pause in the conversation did not
indicate consensus, so now we're discussing more. Which is great (for
example, I hadn't even thought of the potential importance of template
accessibility when disconnected from the server).
If you're suggesting that premature calls for consensus can be a bad
thing, I totally agree. But don't read too much into a simple bad
call. In this case, it doesn't seem to have hurt us much, and may
even have done some good. No harm, no foul, I hope. I certainly
don't want a rushed design either.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> > A: Whose side are you on, anyway? Let's be real. Have you ever
> > seen a template like that? I haven't. They've all been pretty
> > simple things, a few fields to fill in, maybe some reminders,
> > that sort of thing. Sure, they've been *different* from project
> > to project, but I can't say that a template has ever caused a
> > drastic change in the content (as opposed to the formatting) of
> > my log message.
>
> Q: I guess you're right. Which makes me wonder why those
> Subversion guys designed such a complex
> network-turnin'-around, hook-script-generatin' system for such
> a simple, basically static result?
>
> Sorry. Couldn't resist. :-)
No, I'm glad you didn't -- I was hoping someone would say this, so I
could rebut it :-).
The simplicity and staticness of any individual template do not imply
simplicity in the *process used to produce* that template. The
production process may be arbitrarily complex. It may involve, for
example, questions of which directory's template "wins" if there is a
per-directory, or per-project-root, template system going on.
To be even more concrete:
Imagine a system whereby, if one makes a single commit across multiple
projects within a big ASF-style repository, a special log message
template is used that is specifically for multi-project commits. It
would start out with a generalized header that is *only* used when
multiple projects are being committed to at once, and then it would
include the per-project templates of each of those projects, but
perhaps modified in some special way because they're part of this
unusual kind of commit.
Notice that the resulting template is still a simple, static document.
It does not *include* any of the paths being committed. Yet those
paths were crucial in determining the content of the template.
Thus, a complex process can lead to a deceptively simple-looking
result. It is that process we are proposing to support here.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> After more consideration, I think that disconnected accessibility to
> log message templates is not all that important. I'm not trying to
> mindlessly champion the RA/hook idea here -- I just want to point out
> how one suggested drawback is not actually much of a drawback.
>
> Watch Q persuade A that disconnected template access is not important:
>
> Q: Why would accessibility to the template while disconnected from
> the server be important?
>
> A: Well, that would allow you to prepare your patch and write your
> log message while sitting in an airplane or whatever.
>
> Q: So you're saying that if you don't have access to the template,
> because you forgot to save a copy locally before the plane took
> off, that means you can't really do offline work?
>
> A: Er, okay, I guess you can. You can still write your changes,
> and write the bulk of your log message. Most log message
> templates (all the ones I've ever seen, anyway) just ask for a
> few special fields, like an issue tracker ID number, and maybe
> give some hints as to how to format the log message. While
> you're offline, you can't commit anyway. When you do finally
> commit, it's trivial to transform your log message into whatever
> the template suggests. And even that's only if you didn't save
> a copy before takeoff.
>
> Q: But, might there be templates so intricate that you basically
> have to have the template available as you write your log
> message?
>
> A: Whose side are you on, anyway? Let's be real. Have you ever
> seen a template like that? I haven't. They've all been pretty
> simple things, a few fields to fill in, maybe some reminders,
> that sort of thing. Sure, they've been *different* from project
> to project, but I can't say that a template has ever caused a
> drastic change in the content (as opposed to the formatting) of
> my log message.
Q: I guess you're right. Which makes me wonder why those
Subversion guys designed such a complex
network-turnin'-around, hook-script-generatin' system for such
a simple, basically static result?
Sorry. Couldn't resist. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
After more consideration, I think that disconnected accessibility to
log message templates is not all that important. I'm not trying to
mindlessly champion the RA/hook idea here -- I just want to point out
how one suggested drawback is not actually much of a drawback.
Watch Q persuade A that disconnected template access is not important:
Q: Why would accessibility to the template while disconnected from
the server be important?
A: Well, that would allow you to prepare your patch and write your
log message while sitting in an airplane or whatever.
Q: So you're saying that if you don't have access to the template,
because you forgot to save a copy locally before the plane took
off, that means you can't really do offline work?
A: Er, okay, I guess you can. You can still write your changes,
and write the bulk of your log message. Most log message
templates (all the ones I've ever seen, anyway) just ask for a
few special fields, like an issue tracker ID number, and maybe
give some hints as to how to format the log message. While
you're offline, you can't commit anyway. When you do finally
commit, it's trivial to transform your log message into whatever
the template suggests. And even that's only if you didn't save
a copy before takeoff.
Q: But, might there be templates so intricate that you basically
have to have the template available as you write your log
message?
A: Whose side are you on, anyway? Let's be real. Have you ever
seen a template like that? I haven't. They've all been pretty
simple things, a few fields to fill in, maybe some reminders,
that sort of thing. Sure, they've been *different* from project
to project, but I can't say that a template has ever caused a
drastic change in the content (as opposed to the formatting) of
my log message.
Q: I guess you're right, disconnected template access isn't so
important.
A: Just what I've always said.
Pseudo-Psocratically Yours,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> I have tricky things in mind with custom keywords, however, so I'd
> like to make sure that there is a possibility of other keywords which
> might be expandable during the template expansion. For example, a
> property which is being updated as part of the commit could be
> accessible to the template expansion.
I thought of that, too -- I think this would be extremely useful,
because it would create a standard way to pass information from all
kinds of "management" systems build on top of SVN and the commit info.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
Peter N. Lundblad wrote:
> This is a detail, especially in the context of this discussion's current
> state, but I don't think there is use for any keywords except files.
> Actually you don't know them before the commit is finished (atleast not
> revision, date, etc).
Mostly I was pointing out that the existing keyword expansion framework
is there in the client code already and can do this bit without any
required client-side scripting language. I hadn't gotten as far as
thinking about what other keywords might be useful, but as you point
out, most of those are only valid after the commit ($Author$ being the
sole exception).
I have tricky things in mind with custom keywords, however, so I'd like
to make sure that there is a possibility of other keywords which might
be expandable during the template expansion. For example, a property
which is being updated as part of the commit could be accessible to the
template expansion.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 19 May 2005, John Peacock wrote:
> c) automatically expanded using the normal keyword substitution rules
> (along with the $Files$ keyword) prior to starting the $EDITOR.
>
This is a detail, especially in the context of this discussion's current
state, but I don't think there is use for any keywords except files.
Actually you don't know them before the commit is finished (atleast not
revision, date, etc).
> I hate to keep carping on this, but I think the real discussion for
> server->client configuration should start with inherited properties
> (files inherit from their containing directory; the server manages
> directory inheritance on checkout). This more generic feature would
> give us a way to support autoprops, directory-based log templates, and
> other distributed property features.
>
I really like this way of looking at it and have done so for some time
now. I think using props for these things is very ellegant and inherited
props would be useful for other things as well (svn:ignore for example).
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Mark Phippard <Ma...@softlanding.com>.
John Peacock <jp...@rowman.com> wrote on 05/19/2005 09:42:12 AM:
> I hate to keep carping on this, but I think the real discussion for
> server->client configuration should start with inherited properties
> (files inherit from their containing directory; the server manages
> directory inheritance on checkout). This more generic feature would
> give us a way to support autoprops, directory-based log templates, and
> other distributed property features.
It is hard to know which message to choose to reply to. I will just lump
all my replies in this one message:
1) Using Properties for Commit Message Template
Absent any other way to achieve this feature, this is how both Subclipse
and TortoiseSVN do it. We both use a property named tsvn:logtemplate.
This works pretty well. The only problem is if you have a repository
where you do not really know where users will checkout from, you have to
set the property on every folder. As John says, if there were some form
of inherited properties, that would make this a much more viable solution.
2) Server-side hook
I do not have strong feelings on this. I just ask that you please
consider the GUI tools. We have our own UI for gathering the log message,
so we will need an API we can call to generate the template prior to the
commit. A potential problem for Subclipse and TortoiseSVN is that our
commit dialog lets you control what is being committed. So the dialog
will initially populate with all of the potential files that can be
committed (including unversioned files), but the user can then change what
will be committed via the UI. So passing the file names will be
problematic. TortoiseSVN also allows you to start typing your log
messages while the list of files to be committed is still being
calculated.
3) Server -> Client Configuration
I am sort of in agreement with some of the other comments that have been
posted. I cannot ever recall someone asking about commit message
templates. What I always here is people wanting auto-props. It could
also be used for other configuration that doesn't even currently exist. An
example, both Subclipse and TortoiseSVN support a "standard" we developed
for bug-tracking integration.
See: http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
We had to use properties to store the configuration for this. It works
OK, but has the same problems as I listed in comment #1 above. Inherited
props could solve this problem. What we were really looking for was some
way for the server to broadcast this configuration to the client.
4) Configuration conflicts
I have not seen this discussed yet, so I thought I would raise it. Setting
aside commit templates and moving on to other configuration items, when we
have server-side configuration do we just remove client-side
configuration? If we do not, then how do we deal wih the scenario where
both the server and client have the same configuration item defined, such
as auto-props?
5) Personal opinions
I like properties. They are versioned and there are good interfaces
available for manipulating them. They also exist in the WC so you do not
need a server round-trip to interrogate them. If there were just some way
to have properties automatically propogate down a tree hierarchy --
"inherited properties", then this basic feature is a very easy way to add
a lot of functionality both to the svn command line, but also GUI tools
which may want to use the same feature in ways the command line does not.
The only "problems" that cannot be solved one way or another by using
properties are the configuration items that apply to svn import since
there is no WC. That could possibly be solved by having import retrieve
properties from the server before the import.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sweet <mi...@easysw.com>.
John Peacock wrote:
> Michael Sweet wrote:
>
>> 1. Per-directory templates
>
>
>> 2. Basic substitution/expansion from a static template, e.g.:
>
>
>> I'm not too concerned about *how* this functionality is provided,
>> however it seems to me that #1 would be satisfied by a new
>> svn:log-template directory property, #2 would be satisfied by a
>> little API on the client side, and #3 would be satisfied by the
>> existing pre-commit hook.
>
>
> So the log template would be:
>
> a) a versioned directory property (so the site admin could establish one
> for each "project" or even per-directory);
A simplistic approach could even make the property per-file, but I
think that is overkill and might be confusing (i.e. "why doesn't
my new file use the same template").
> b) cached in the client WC (does not require network access to retrieve);
>
> c) automatically expanded using the normal keyword substitution rules
> (along with the $Files$ keyword) prior to starting the $EDITOR.
>
> I don't think #2 requires more than a very minimal alteration to the
> client API to do this if we support inherited properties.
Agreed.
>> I don't see how a dynamic template hook would be that useful since
>> you can bypass the template by providing the log message directly
>> in the commit...
>
>
> Agreed. It seems like we can get almost all of the clever features of
> the smart templates without requiring a very narrow API that does *only*
> that with server-side hooks.
>
> I hate to keep carping on this, but I think the real discussion for
> server->client configuration should start with inherited properties
> (files inherit from their containing directory; the server manages
> directory inheritance on checkout). This more generic feature would
> give us a way to support autoprops, directory-based log templates, and
> other distributed property features.
Yes, exactly!
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
Michael Sweet wrote:
> 1. Per-directory templates
> 2. Basic substitution/expansion from a static template, e.g.:
> I'm not too concerned about *how* this functionality is provided,
> however it seems to me that #1 would be satisfied by a new
> svn:log-template directory property, #2 would be satisfied by a
> little API on the client side, and #3 would be satisfied by the
> existing pre-commit hook.
So the log template would be:
a) a versioned directory property (so the site admin could establish one
for each "project" or even per-directory);
b) cached in the client WC (does not require network access to retrieve);
c) automatically expanded using the normal keyword substitution rules
(along with the $Files$ keyword) prior to starting the $EDITOR.
I don't think #2 requires more than a very minimal alteration to the
client API to do this if we support inherited properties.
> I don't see how a dynamic template hook would be that useful since
> you can bypass the template by providing the log message directly
> in the commit...
Agreed. It seems like we can get almost all of the clever features of
the smart templates without requiring a very narrow API that does *only*
that with server-side hooks.
I hate to keep carping on this, but I think the real discussion for
server->client configuration should start with inherited properties
(files inherit from their containing directory; the server manages
directory inheritance on checkout). This more generic feature would
give us a way to support autoprops, directory-based log templates, and
other distributed property features.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sweet <mi...@easysw.com>.
As a user, I would like to see the following log message template
functionality:
1. Per-directory templates
2. Basic substitution/expansion from a static template, e.g.:
Insert your summary here, followed by details for the
following files:
$Files$
would expand to:
Insert your summary here, followed by details for the
following files:
foo/bar1.c
foo/bar2.c
foo/bar3.c
Right now the only keyword I can think of is "$File$" -
everything else (repos, rev, author, etc.) is available
in the repos.
3. Some mechanism to validate log messages and stop the
commit if the log message doesn't pass.
I'm not too concerned about *how* this functionality is provided,
however it seems to me that #1 would be satisfied by a new
svn:log-template directory property, #2 would be satisfied by a
little API on the client side, and #3 would be satisfied by the
existing pre-commit hook.
I don't see how a dynamic template hook would be that useful since
you can bypass the template by providing the log message directly
in the commit... My "vision" of templates is just a suggestion to
the user beyond what is already provided.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
> * 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>? How can
you possibly assert that this argument was "ignored as irrelevant?" I
replied with a counterargument (to which you replied with an ad hominem,
which I'm not happy about at all). Karl attempted to accomodate your
argument but backed away when I raised objections to his new proposal.
CMike seemed partly swayed by your argument. Fitz said he views log
templates and server->client configuration as apples and sausages.
Nowhere did anyone say that they were ignoring you or that it was
irrelevant.
> * 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 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.
> 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; there's no need to
attack the format of the discussion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
Osku Salerma wrote:
>On Thu, 19 May 2005, [UTF-8] Branko Ä^Libej wrote:
>
>
>
>>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.
>>
>>
>
>$ svn commit --get-log-template-only -F log PATHS
>[client gets log template for PATHS from server, stores it in 'log']
>
>
Yup. So now I can't generate a log template without contacting the
server. But I can generate a diff without contacting the server.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Osku Salerma <os...@iki.fi>.
On Thu, 19 May 2005, [UTF-8] Branko Ä^Libej wrote:
> 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.
$ svn commit --get-log-template-only -F log PATHS
[client gets log template for PATHS from server, stores it in 'log']
$ [editing log etc]
$ ...
$ svn commit -F log PATHS
--
Osku Salerma - osku@iki.fi - http://www.iki.fi/osku/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>I've been sitting on the sidelines, mostly just to see where the list
>took this without my interference. I must say, though, that I (like
>Brane) am not thrilled about the idea of essentially asking the
>server, for each commit, to run a hook-script to conjure up a bit of
>text which itself isn't even necessarily going to be "used" (as in,
>outlive the final edits of the commit message). And I'm a little
>disappointed that my idea for having the server simply dictate a
>static template which contains substitable regions was mostly
>overlooked (by all but Brane, it seemed, though that's my fault for
>not expressing the idea as more than a top-of-the-head thought).
>
>I appreciate that we have an opportunity here to excel beyond the
>limitations of CVS's log message template feature, and I also
>appreciate the urge to at least improve over CVS's *implementation* of
>that feature, if not the provided functionality. But I can't help but
>wonder if the proposal as it sits isn't overkill, and am not so quick
>to decide that this feature can't be cheap(ish) fallout of a generic
>server->client configuration dictation system. Such system, of
>course, does itself not exist, and so is reasonably suspect as
>suitable for the support of log message templates. But I think we'd
>do well to consider the requirements of both systems, examine their
>overlaps, and determine if we have a reasonably common bit of design
>work that can be leveraged to maximize simplicity -- perhaps at the
>cost of "bonus" functionality -- but without compromising the
>essentials of either system.
>
>
I agree 100% with Mike, couldn't have said it better (and /could/ have
said it a lot worse, but you know me... :)
The feeling I got from this discussion is that it's not really a
discussion at all:
* No-one answered the question whether log-message templates were
really the top priority, compared to, e.g., server-side autoprops.
* The overlap between log templates and server-side config was
mentioned, then completely ignored as irrelevant.
* 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."
I also find it *very* disturbing that no-one even analysed how log
tempaltes could be used. 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.
In short, what we're doing is exactly how new features should *not* be
designed. Which is a bit disappointing, because we certainly know that
we /can/ do it right -- the way we arrived at the locking design is a
case in point.
So let's please take a step back.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2005-05-18 at 17:48 -0500, C. Michael Pilato wrote:
> > I must say, though, that I (like Brane) am not thrilled about the idea
> > of essentially asking the server, for each commit, to run a
> > hook-script to conjure up a bit of text which itself isn't even
> > necessarily going to be "used" (as in, outlive the final edits of the
> > commit message).
>
> I don't understand; is this objection to the whole idea of a log message
> template feature, because the user might choose to ignore the template
> when filling out the log message?
Nono. It's simply a request to minimize effort that is very likely to
be undone. I think log message templates are a good thing. I suspect
that the most common uses for log message templates are quite
satisfied by static templates. That's all.
> > And I'm a little
> > disappointed that my idea for having the server simply dictate a
> > static template which contains substitable regions was mostly
> > overlooked (by all but Brane, it seemed, though that's my fault for
> > not expressing the idea as more than a top-of-the-head thought).
>
> I didn't overlook that idea. It came under consideration here:
>
> I like this idea because the hook script can do interesting
> things with the list of modified files.
> [...]
> Any log template mechanism where the server transmits static
> data to the client is inherently limited in this respect,
> because can't have the server telling the client to execute
> code (barring the addition of a sandboxed virtual interpreter to
> the client).
My bad -- I seem to have missed that. Thanks, Greg.
> Substitutable sections allows us to insert the list of modifiable
> files, and perhaps format it in a predefined set of ways, but it
> will always be more limited than letting the server run arbitrary
> code to process it.
Oh, absolutely. No debate there.
> A similar argument holds for deciding which log message to use
> depending on the path being committed. With static data, we could
> have the client decide based on predefined kinds of rules
> (e.g. something like what CVS has, with regexp matches), but it's
> necessarily more powerful to let the server decide any way it wants.
Nor here.
Nobody can reasonably debate the feature flexibility provided by
server-side path crunchin'. The debate (for me) is about flies and
Buicks (feature overkill), and about well apples and sausages go
together (building atop server->client config).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>Substitutable sections allows us to insert the list of modifiable files,
>and perhaps format it in a predefined set of ways, but it will always be
>more limited than letting the server run arbitrary code to process it.
>
>
Indeed it would, there's no question about that. But I've yet to see
proof that we really need that kind of flexibility.
>A similar argument holds for deciding which log message to use depending
>on the path being committed. With static data, we could have the client
>decide based on predefined kinds of rules (e.g. something like what CVS
>has, with regexp matches), but it's necessarily more powerful to let the
>server decide any way it wants.
>
>
Yes. Again, do we really need that kind of power?
Especially if it comes at the price of not being able to generate a log
message template while disconnected from the server.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-05-18 at 17:48 -0500, C. Michael Pilato wrote:
> I must say, though, that I (like Brane) am not thrilled about the idea
> of essentially asking the server, for each commit, to run a
> hook-script to conjure up a bit of text which itself isn't even
> necessarily going to be "used" (as in, outlive the final edits of the
> commit message).
I don't understand; is this objection to the whole idea of a log message
template feature, because the user might choose to ignore the template
when filling out the log message?
> And I'm a little
> disappointed that my idea for having the server simply dictate a
> static template which contains substitable regions was mostly
> overlooked (by all but Brane, it seemed, though that's my fault for
> not expressing the idea as more than a top-of-the-head thought).
I didn't overlook that idea. It came under consideration here:
I like this idea because the hook script can do interesting
things with the list of modified files.
[...]
Any log template mechanism where the server transmits static
data to the client is inherently limited in this respect,
because can't have the server telling the client to execute
code (barring the addition of a sandboxed virtual interpreter to
the client).
Substitutable sections allows us to insert the list of modifiable files,
and perhaps format it in a predefined set of ways, but it will always be
more limited than letting the server run arbitrary code to process it.
A similar argument holds for deciding which log message to use depending
on the path being committed. With static data, we could have the client
decide based on predefined kinds of rules (e.g. something like what CVS
has, with regexp matches), but it's necessarily more powerful to let the
server decide any way it wants.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "C. Michael Pilato" <cm...@collab.net>.
I've been sitting on the sidelines, mostly just to see where the list
took this without my interference. I must say, though, that I (like
Brane) am not thrilled about the idea of essentially asking the
server, for each commit, to run a hook-script to conjure up a bit of
text which itself isn't even necessarily going to be "used" (as in,
outlive the final edits of the commit message). And I'm a little
disappointed that my idea for having the server simply dictate a
static template which contains substitable regions was mostly
overlooked (by all but Brane, it seemed, though that's my fault for
not expressing the idea as more than a top-of-the-head thought).
I appreciate that we have an opportunity here to excel beyond the
limitations of CVS's log message template feature, and I also
appreciate the urge to at least improve over CVS's *implementation* of
that feature, if not the provided functionality. But I can't help but
wonder if the proposal as it sits isn't overkill, and am not so quick
to decide that this feature can't be cheap(ish) fallout of a generic
server->client configuration dictation system. Such system, of
course, does itself not exist, and so is reasonably suspect as
suitable for the support of log message templates. But I think we'd
do well to consider the requirements of both systems, examine their
overlaps, and determine if we have a reasonably common bit of design
work that can be leveraged to maximize simplicity -- perhaps at the
cost of "bonus" functionality -- but without compromising the
essentials of either system.
kfogel@collab.net writes:
> That's "RFC" as in "Request For Consensus" :-).
>
> Discussion seems to have died down, and that may be because people
> mostly agree on the way to go now. So, I'd like to get consensus on
> this proposal:
>
> A new RA method, svn_ra_get_log_message_template(), that takes a
> list of paths and returns the log message template. On the server
> side, this is implemented by invoking a new 'log-message-template'
> hook, which takes the author as an an argument and a
> newline-separated list of (UTF8) paths on stdin. Whatever the hook
> prints to stdout is the log message template. If it prints
> nothing, or there is no hook, then there is no log message template
> and the client behaves as it does today.
>
> The RA method is invoked only when interactive $EDITOR is used to
> write a log message.
>
> (Whether the RA method takes a static list of paths, or receives
> them via repeated callback invocations, is something we will have
> to work out; but this does not affect the overall proposal.)
>
> The server would know the author because of the RA layer's
> authentication; the client would not have to pass the author name
> to svn_ra_get_log_message_template().
>
> We will ship with a default 'log-message-template.tmpl' file that
> just ignores the paths and prints a standard-looking template to
> stdout. But the .tmpl file would document the hook's calling
> discipline fully, of course.
>
> Obviously, there are some details to be worked out here, but this is
> well-specified enough to ask for consensus on the general approach.
>
> Objections?
>
> The strongest objections so far came from Brane, I believe, and have
> been responded to on-list, so I won't repeat the details here. Brane,
> I'm certainly not demanding that you give consensus against your
> wishes. However, I think it's better not to pull out the "veto" card
> in your second message :-)...
>
> > Besides, suddenly you'd have an extra trip over the network
> > regardless of whether you use log templates or not, and I'm very
> > close to vetoing the proposal for that reason alone.
>
> Please, let's reserve talk of vetos for after technical discussion has
> failed to lead to a resolution. I realize that formally it doesn't
> matter when one starts mentioning vetos; however, it raises the stakes
> prematurely and can have a polarizing effect on the conversation
> (although I think it didn't in this case, fortunately).
>
> Again, that's a comment about style, not substance. Feel free to
> withold consensus now, and we'll continue discussing if so.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote (regarding iprops):
> It might be a bit worrying that all your existing tags can be affected
> by changing iprops on their *parent* folders, however..
Wait a minute.
That's not worrying at all. In fact it's easy to avoid.
The repo admin can just make a pre-commit hook that disallows setting
iprops on '/' and perhaps '/tags'.
Sorry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Molle Bestefich <mo...@gmail.com>.
Michael Sinz wrote:
> John Peacock wrote:
> > Michael Sinz wrote:
> > > 1) When I make a branch (the pre-release lock-down branch)
> > > I want to have the template be different (include manager signoff
> > > or bug ticket requirement). But the branch was created by svn cp
> > > from another branch/trunk which had a different template. How
> > > does this work? [To me this gets back to the fact that svn really
> > > needs to know the difference between "cp" and "branch" and "tag"
> > > even if they are mostly not different.]
> >
> > I can see a couple of ways that this could be accomplished; it really
> > depends on how you have your repository organized:
> >
> > a) Standard project/trunk, project/branch, project/tag format - in this
> > case, you would set a log-template iprop on trunk and branch; any
> > branches would inherit the special branch template immediately upon
> > copying (I'm assuming the trivial path-based inheritance).
[snip]
>
> I have no problem with the directory structure - it is how inherited properties
> get moved/copied that is the big messy question.
>
> See, the problem is a "tag" should copy all of the properties as
> I want the tag to be a "frozen in time marker" yet certain branches
> (not normal, but pre-release branches) I don't want the properties
> copied, or at least not some of them.
Since it's a branch not a tag, it's open to changes. Go ahead and
remove any iprops you dislike after copying?
> This is where the whole iprops
> thing gets to be hairy. All properties need to be copied some of the
> time but not all of the time. But some properties need to be copied
> all of the time (mime-type, needs-lock, etc)
All iprops, as well as all regular properties that reside directly on
an object should be copied all of the time. Parent's iprops should
never be copied. Anything else would be inconsistent and impossible
to explain to users.
If you have a need to branch-then-remove-iprop as above, you've
probably applied the iprop to a wrong item in the first place? Move
it up a few layers in your tree. If you find that another tag wrongly
applies to tags or branches you create, it should probably be moved a
few notches down the tree.
It might be a bit worrying that all your existing tags can be affected
by changing iprops on their *parent* folders, however..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sinz <mi...@gmail.com>.
On 5/20/05, Branko Čibej <br...@xbc.nu> wrote:> Michael Sinz wrote:> > >1) When I make a branch (the pre-release lock-down branch)> >I want to have the template be different (include manager signoff> >or bug ticket requirement). But the branch was created by svn cp> >from another branch/trunk which had a different template. How> >does this work? [To me this gets back to the fact that svn really> >needs to know the difference between "cp" and "branch" and "tag"> >even if they are mostly not different.]> >> In fact, "copy" and "branch" are *significantly* different. But they're> different in ways that don't have much bearing on the behaviour of> inherited properties.
Well, yes and no - copy and branch and tag and rename are all verydifferent operations by a semantic point of view even if they havesome mechanical similarities.
The problem is defining the difference with respect to things thatare not directly within the current tree but affect that tree.
For example, a tag would want to make the new tree just like thecurrent tree is - including any behaviors that are maybe not directlydefined in the tree but from its parent. (Not that one would normallycommit to a "tag" but that is a different story)
So, the question is how does this get handled without too much"user surprise" (the "least astonishment" principle)
If I knew the "perfect" (or even close) answer, I would not be asking :-)
-- Michael Sinz Technology and Engineering Director/Consultant"Starting Startups" mailto:Michael.Sinz@sinz.orgMy place on the web http://www.sinz.org/Michael.Sinz
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
Michael Sinz wrote:
> See, the problem is a "tag" should copy all of the properties as
> I want the tag to be a "frozen in time marker" yet certain branches
> (not normal, but pre-release branches) I don't want the properties
> copied, or at least not some of them. This is where the whole iprops
> thing gets to be hairy. All properties need to be copied some of the
> time but not all of the time. But some properties need to be copied
> all of the time (mime-type, needs-lock, etc)
From the discussion so far, it certainly seems to me like the kinds of
properties that you are talking about copying are the kinds of
properties that are likely to be repository defaults (or at the very
least project defaults). In other words, the properties likely to be
important to maintain are going to be higher in the tree (and hence
inherited anyways); anything else can be set manually (or through the
use of a post-commit hook).
I was thinking about this on the drive to work this morning and it
occurs to me that a simple inheritance/no copy model probably gets us
very far without introducing any big suprises along the way. What I am
suggesting is that iprops are strictly based on the path within the
repository; copying a directory node from one location to another does
not copy any inherited properties (though if there are iprops associated
with the actual directory being copied, those would of course be copied).
For example, think of this tree:
/ - repository root, contains iprops for svn:mime-types
and any other repository-wide properties; all directories
below inherit them (though they can also override).
/project1
/project2 - all overrides to the above, plus any project specific
additional properties (this is where custom keyword definitions
would probably live). For example svn:ignore might be project
specific.
/project1/trunk
/project1/tag
/project1/branches - each of these three could have individual
overrides of the above, as well as additional custom props. If
a different log-template was used for tags or branches, that
would be stored in the parent directory those subtrees.
The only time you would have to worry about setting iprops is if you
copied a directory outside of its original subtree, so it would no
longer be under the original inherited properties.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sinz <Mi...@sinz.org>.
John Peacock wrote:
> Michael Sinz wrote:
>
>>
>> 1) When I make a branch (the pre-release lock-down branch)
>> I want to have the template be different (include manager signoff
>> or bug ticket requirement). But the branch was created by svn cp
>> from another branch/trunk which had a different template. How
>> does this work? [To me this gets back to the fact that svn really
>> needs to know the difference between "cp" and "branch" and "tag"
>> even if they are mostly not different.]
>
>
> I can see a couple of ways that this could be accomplished; it really
> depends on how you have your repository organized:
>
> a) Standard project/trunk, project/branch, project/tag format - in this
> case, you would set a log-template iprop on trunk and branch; any
> branches would inherit the special branch template immediately upon
> copying (I'm assuming the trivial path-based inheritance).
>
> b) All projects under a common folder and all branches under a different
> common folder - if you only had two templates, you would again apply
> them to the highest directory which contains all of the folders which
> that template should apply to.
>
> c) Some mixed style repository - you are always free to create the log
> template iprop immediately after the copy (in fact you could probably do
> this in a post-commit hook).
I have no problem with the directory structure - it is how inherited properties
get moved/copied that is the big messy question.
See, the problem is a "tag" should copy all of the properties as
I want the tag to be a "frozen in time marker" yet certain branches
(not normal, but pre-release branches) I don't want the properties
copied, or at least not some of them. This is where the whole iprops
thing gets to be hairy. All properties need to be copied some of the
time but not all of the time. But some properties need to be copied
all of the time (mime-type, needs-lock, etc)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
Michael Sinz wrote:
>
> 1) When I make a branch (the pre-release lock-down branch)
> I want to have the template be different (include manager signoff
> or bug ticket requirement). But the branch was created by svn cp
> from another branch/trunk which had a different template. How
> does this work? [To me this gets back to the fact that svn really
> needs to know the difference between "cp" and "branch" and "tag"
> even if they are mostly not different.]
I can see a couple of ways that this could be accomplished; it really depends on
how you have your repository organized:
a) Standard project/trunk, project/branch, project/tag format - in this case,
you would set a log-template iprop on trunk and branch; any branches would
inherit the special branch template immediately upon copying (I'm assuming the
trivial path-based inheritance).
b) All projects under a common folder and all branches under a different common
folder - if you only had two templates, you would again apply them to the
highest directory which contains all of the folders which that template should
apply to.
c) Some mixed style repository - you are always free to create the log template
iprop immediately after the copy (in fact you could probably do this in a
post-commit hook).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
Michael Sinz wrote:
>1) When I make a branch (the pre-release lock-down branch)
>I want to have the template be different (include manager signoff
>or bug ticket requirement). But the branch was created by svn cp
>from another branch/trunk which had a different template. How
>does this work? [To me this gets back to the fact that svn really
>needs to know the difference between "cp" and "branch" and "tag"
>even if they are mostly not different.]
>
>
In fact, "copy" and "branch" are *significantly* different. But they're
different in ways that don't have much bearing on the behaviour of
inherited properties.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sinz <mi...@gmail.com>.
Ok, having stuck my nose into this early on and saying that I liked
the "server template hook" idea, I think that I have come around to
a different view.
The annoying thing is that I still like the concept of the server-side
hook but in actual use, I can not see it as a major benefit.
The directory properties (more specifically iprops) sounds like a
winner, but I have some concerns:
1) When I make a branch (the pre-release lock-down branch)
I want to have the template be different (include manager signoff
or bug ticket requirement). But the branch was created by svn cp
from another branch/trunk which had a different template. How
does this work? [To me this gets back to the fact that svn really
needs to know the difference between "cp" and "branch" and "tag"
even if they are mostly not different.]
2) This now would depend on server->client config or iprops.
That is fine by me since I really want server-controlled auto-props
but simple template work is a "good thing" as many have used
it with CVS and to good effect.
3) If we don't do ipops, do we just say that the template is not
there for you if you checked out just a sub part of the tree which
does not have a template property? Maybe that is the correct
answer until we can figure out the "maze of trwisty iprop" issues
out. (Or does that add yet another twisty mess?)
> John Peacock <jp...@rowman.com> writes:
>
> > Here's a couple of ideas for dealing with conflicts (straight from my
> > brain to your eyes, no thought to complexity of implementation):
> >
> > 1) Highest One Wins - the template in force for the shortest path that
> > contains all committed file paths.
Well, other than strange command line commit operations where the
parent does not exist locally (which is possible??) this is the correct
behavior IMHO.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Fri, 2005-05-20 at 12:43 -0400, Greg Hudson wrote:
> On Fri, 2005-05-20 at 10:31 -0500, Brian W. Fitzpatrick wrote:
> > Agreed. However, I think that if we want to do inherited properties
> > right we're going to have to look long and hard at how important it is
> > to support detachable directories in working copies. This seems to the
> > be a wc feature that some folks are unwilling to sacrifice, but it also
> > seems to the biggest obstacle to doing inherited properties in a non-
> > kludgey manner.
>
> We can get all the usage benefits of inherited properties without
> sacrificing severability; it just means we get none of the performance
> benefits on the client side.
Thus the "kludgey manner" I was referring to.
> I'm not sure anyone is wedded to working copy severability, but I
> suspect there are several of us (certainly, myself included) who would
> consider it very poor form to drop that feature during 1.x.
I'm not advocating that we drop severability. I am, however, willing to
entertain the thought of inheritable properties only working in non-
severed working copies (but the more I think about this, the less
elegant it looks. *sigh*)
> We could virtualize the working copy library and design a new working
> copy format which isn't severable, to be used optionally at checkout
> time, but that's an even more major undertaking than inheritable
> properties since there are a bunch of other improvements we'd want to
> design in at the same time. Also, if we virtualize the working copy
> library we have to figure out how we will detect what kind of working
> copy we're operating on when a user does something like "svn update".
> And we'd be constrained to the current libsvn_wc API, which may be
> simply too constraining.
Egads, I don't want to go there.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-05-20 at 10:31 -0500, Brian W. Fitzpatrick wrote:
> Agreed. However, I think that if we want to do inherited properties
> right we're going to have to look long and hard at how important it is
> to support detachable directories in working copies. This seems to the
> be a wc feature that some folks are unwilling to sacrifice, but it also
> seems to the biggest obstacle to doing inherited properties in a non-
> kludgey manner.
We can get all the usage benefits of inherited properties without
sacrificing severability; it just means we get none of the performance
benefits on the client side.
I'm not sure anyone is wedded to working copy severability, but I
suspect there are several of us (certainly, myself included) who would
consider it very poor form to drop that feature during 1.x.
We could virtualize the working copy library and design a new working
copy format which isn't severable, to be used optionally at checkout
time, but that's an even more major undertaking than inheritable
properties since there are a bunch of other improvements we'd want to
design in at the same time. Also, if we virtualize the working copy
library we have to figure out how we will detect what kind of working
copy we're operating on when a user does something like "svn update".
And we'd be constrained to the current libsvn_wc API, which may be
simply too constraining.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Fri, 2005-05-20 at 05:57 -0400, John Peacock wrote:
> However, when I was thinking about how to answer your e-mail, I finally figured
> out what was really bothering me about the server-hook: it requires maintaining
> meta-data about the contents of the repository outside of the repository itself.
>
> Let me preface this by saying I know it is possible to version the hooks folder;
> that's not what I am talking about. What I am talking about is specifically
> that, in the more complicated scenarios above, the paths to which certain
> log-templates apply must be hard-coded in the hook script itself. Rather than
> having the template emerge directly from the repository itself, that metadata
> must be manually encoded into the hook script, which can lend itself to mistakes
> (e.g. after a major reorganization).
Hmm. This is an excellent point.
> I think that it is far too early to abandon inherited properties as "too hard"
> since it permits a number of valuable emergent behaviors, not only for log
> templates but for many of the other "server-resident" config features which
> people have been longing for. I just don't think we should close off discussion
> of a more general solution in favor of a simple solution for log-templates
> (which may or may not be the first order of business for 1.3 in any case).
Agreed. However, I think that if we want to do inherited properties
right we're going to have to look long and hard at how important it is
to support detachable directories in working copies. This seems to the
be a wc feature that some folks are unwilling to sacrifice, but it also
seems to the biggest obstacle to doing inherited properties in a non-
kludgey manner.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Pybus <jo...@pybus.org>.
John Peacock wrote:
<SNIP> various scenarios for
>
> The server hook provides exactly the same assistance to site admins for
> each of those scenarios, which is to say, none. The site admin is
> completely free to implement as baroque or simple a hook as they desire,
> but we don't really do anything to facilitate that.
I'm assuming subversion would be distributed with sample scripts that
implement some basic resolution schemes. This would be equivalent to
having the same resolution capability built into the client, but with
greater scope for the admin to tweak/replace the policy if they wish to.
In my mind, the less functionality is embedded in the client the better.
It makes it harder to extend; any expanded functionality would require
all clients on the project to upgrade at the same time. Also, this is
open source and a project can change the server to suit themselves and
this is easier and safer than distributing project-specific customised
clients.
> Let me preface this by saying I know it is possible to version the hooks
> folder; that's not what I am talking about. What I am talking about is
> specifically that, in the more complicated scenarios above, the paths to
> which certain log-templates apply must be hard-coded in the hook script
> itself.
I don't buy that. Why shouldn't the hook script look into the
repository to grab the metadata it uses for log templates? It's
perfectly possible to only implement logic in the hook, and for it to
retrieve path specific parts from any other SCM component not limited to
the repos.
> I think that it is far too early to abandon inherited properties as "too
> hard" since it permits a number of valuable emergent behaviors, not only
> for log templates but for many of the other "server-resident" config
> features which people have been longing for. I just don't think we
> should close off discussion of a more general solution in favor of a
> simple solution for log-templates (which may or may not be the first
> order of business for 1.3 in any case).
Greg made an argument comparing inherited props to symlinks which
totally sold me (though maybe not in the way he intended). Despite
their occasional weirdness I can't imagine *nix filesystems without
symlinks; they're far to useful. I don't think subversion should punt
on this idea.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Mark Phippard <Ma...@softlanding.com>.
John Peacock <jp...@rowman.com> wrote on 05/20/2005 12:08:09 PM:
> kfogel@collab.net wrote:
> > Not at all. If the repository convention is to attach a special
> > property to each project directory, and have the hook code look for
> > that property, that's fine. Or whatever. Nothing about this system
> > requires that metadata be stored outside the repository...
>
> You're right; a sufficiently advanced hook script could query the
> repository for more information. Would we include an example script
> which would do this data-diving or expect that to be a lesson for the
> admin (I'm not being completely facetious)?
My feeling is that Subversion has to provide a script like this. Why?
Hosting providers. I do not believe that they generally provide users
with access to the hook scripts, and they are not going to want to be
constantly tweaking the script as needs change. By making a script that
is driven by properties it will allow a hosting provider to simply enable
the script and then let the repository owners control it by setting
properties.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> As for whether the freedom is actually worth anything, my reply to
> Mike Pilato earlier was partially a justification:
>
> > Imagine a system whereby, if one makes a single commit across
> > multiple projects within a big ASF-style repository, a special
> > log message template is used that is specifically for
> > multi-project commits. It would start out with a generalized
> > header that is *only* used when multiple projects are being
> > committed to at once, and then it would include the per-project
> > templates of each of those projects, but perhaps modified in some
> > special way because they're part of this unusual kind of commit.
> >
> > Notice that the resulting template is still a simple, static
> > document. It does not *include* any of the paths being
> > committed. Yet those paths were crucial in determining the
> > content of the template.
>
> Now, that's only one example, I realize. But it seems a very
> plausible one to me... and it didn't take very long to come up with.
And I'm sure that the clever people on this list can come up with more.
But my challenge still stands: how common is that scenario? Is it
worth it to design this feature based on the extraordinary or should we
focus on the most common case (which is probably more like a single site
log-template or a per project template)?
FWIW, I can replicate that behavior (a little less intelligently) by the
use of inherited properties:
1) each project in that ASF-style repository has a log-template stored
at the top of the project subtree, so commits within the tree get that
template by normal inheritance;
2) the root that repository of contains a log-template with the special
header introducing the cross project commit, then a copy of each log
template from all of the projects and special instructions to delete any
sub-templates which are not involved in this commit.
This assumes that the "Highest One Wins" scheme for negotiating template
conflicts is used. If instead we did a "All for One" scheme (where all
affected log-templates are concatenated together and the user has to
make the intelligent choices about what goes where), then we would get
the same behavior that your hook performed.
Sure, it isn't as smart as the server hook, and it requires that the top
level log-template be manually kept in sync when the project templates
are changed. I don't think it is too outrageous to assume that log
templates are probably fairly slow moving targets in the majority of
projects. I would expect at most large sites, the log templates are
likely to be tightly controlled anyways (once we get in-tree ACL's)
<DUCK>...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> You're right; a sufficiently advanced hook script could query the
> repository for more information. Would we include an example script
> which would do this data-diving or expect that to be a lesson for the
> admin (I'm not being completely facetious)?
Yes, I think we should do that. This stuff isn't necessarily obvious.
A little support from us could save admins a lot of time!
> I still think that emergent behavior is more robust than an external
> program which would have to retrieve information to build the
> template. We have to ask if the added freedom for the hook script
> outweighs the possible complexity of the [re]implementation by each
> site admin.
Absolutely; that's a worthwhile question.
First of all, like you said above, we should prevent the
re-implementation issue by shipping some common template hook scripts
with Subversion itself. When I say "we", I really expect that these
things would be contributed, in the natural course of things, but in
any case we should see to it that it happens.
As for whether the freedom is actually worth anything, my reply to
Mike Pilato earlier was partially a justification:
> Imagine a system whereby, if one makes a single commit across
> multiple projects within a big ASF-style repository, a special
> log message template is used that is specifically for
> multi-project commits. It would start out with a generalized
> header that is *only* used when multiple projects are being
> committed to at once, and then it would include the per-project
> templates of each of those projects, but perhaps modified in some
> special way because they're part of this unusual kind of commit.
>
> Notice that the resulting template is still a simple, static
> document. It does not *include* any of the paths being
> committed. Yet those paths were crucial in determining the
> content of the template.
Now, that's only one example, I realize. But it seems a very
plausible one to me... and it didn't take very long to come up with.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> Not at all. If the repository convention is to attach a special
> property to each project directory, and have the hook code look for
> that property, that's fine. Or whatever. Nothing about this system
> requires that metadata be stored outside the repository...
You're right; a sufficiently advanced hook script could query the
repository for more information. Would we include an example script
which would do this data-diving or expect that to be a lesson for the
admin (I'm not being completely facetious)?
I still think that emergent behavior is more robust than an external
program which would have to retrieve information to build the template.
We have to ask if the added freedom for the hook script outweighs
the possible complexity of the [re]implementation by each site admin.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> Let me preface this by saying I know it is possible to version the
> hooks folder; that's not what I am talking about. What I am talking
> about is specifically that, in the more complicated scenarios above,
> the paths to which certain log-templates apply must be hard-coded in
> the hook script itself. Rather than having the template emerge
> directly from the repository itself, that metadata must be manually
> encoded into the hook script, which can lend itself to mistakes
> (e.g. after a major reorganization).
Not at all. If the repository convention is to attach a special
property to each project directory, and have the hook code look for
that property, that's fine. Or whatever. Nothing about this system
requires that metadata be stored outside the repository...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> John, your scenario assumes that the server admin has *already*
> implemented some sort of per-directory template association. Let's
> remember that they don't have to do that at all. They can just ignore
> all those paths, or do something else with them.
Not exactly. I was looking at the worst-case scenario (complicated multiple log
templates) and seeing how the server hook idea gives us anything special and it
*doesn't* help the most complicated case any more than the simplest case.
There are a number of different use-cases for log templates that I can imagine
(and probably some I can't ;-):
0 - there is no site specific template
1 - there is a single site specific template
10 - there is a specific template for each project
100 - there is a different template for different portions of each project
(numbers not intended to be anything but representatives of real-world complexity).
The server hook provides exactly the same assistance to site admins for each of
those scenarios, which is to say, none. The site admin is completely free to
implement as baroque or simple a hook as they desire, but we don't really do
anything to facilitate that.
However, when I was thinking about how to answer your e-mail, I finally figured
out what was really bothering me about the server-hook: it requires maintaining
meta-data about the contents of the repository outside of the repository itself.
Let me preface this by saying I know it is possible to version the hooks folder;
that's not what I am talking about. What I am talking about is specifically
that, in the more complicated scenarios above, the paths to which certain
log-templates apply must be hard-coded in the hook script itself. Rather than
having the template emerge directly from the repository itself, that metadata
must be manually encoded into the hook script, which can lend itself to mistakes
(e.g. after a major reorganization).
I think that it is far too early to abandon inherited properties as "too hard"
since it permits a number of valuable emergent behaviors, not only for log
templates but for many of the other "server-resident" config features which
people have been longing for. I just don't think we should close off discussion
of a more general solution in favor of a simple solution for log-templates
(which may or may not be the first order of business for 1.3 in any case).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> And I cannot tell why placing the burden of determining primacy on the
> server hook solves the problem in any way either. Some process still
> has to determine which competing log-template gets used; by punting
> completely, you place *all* of the burden on the site admin to take
> this [possibly marginal in real life] use-case into consideration when
> writing the hook script.
>
> Here's a couple of ideas for dealing with conflicts (straight from my
> brain to your eyes, no thought to complexity of implementation):
>
> 1) Highest One Wins - the template in force for the shortest path that
> contains all committed file paths.
>
> 2) To Each His Own - If those 20 files are covered by 3 log-templates
> (for example), then the client splits the commit into 3 seperate
> commits, each with it's own custom template. We should be able to
> assume that if a site has that many templates scattered about their
> tree, then that should be taken as a significant factor and we should
> respect the effort and not impose a single template.
>
> Of course, in both cases a --no-log-template switch to the client
> should shut off all special processing and lead to the existing "dumb"
> template. Any site wishing to require specific formatting has to use
> the pre-commit hook to validate the text anyways.
John, your scenario assumes that the server admin has *already*
implemented some sort of per-directory template association. Let's
remember that they don't have to do that at all. They can just ignore
all those paths, or do something else with them.
If the admin has implemented per-directory associations, and needs to
come up with a resolution policy, then consider the possibilities:
1. It's trivial. In which case, we have not burdened the admin
overmuch by asking them to do it.
2. It's complex. In which case, since it's already going to be
difficult for the site admin to implement, with all her
site-specific knowledge, then there's no *way* we could ever
have gotten it right with some pre-determined algorithm!
In short, while there are some arguments against Fitz's hook proposal,
I don't think this is a convincing one. The problems raised here feel
like either non-problems, or problems that are so complex that they
are precisely why Fitz came up with the flexibility of the generic
hook in the first place.
Note that we can easily ship a contrib/ script that implements your
highest-wins scenario. Meanwhile, splitting 1 commit into N commits
sounds very unfriendly to me; if a site wants such drastic behavior,
it can enforce it in pre-commit. SVN shouldn't be doing it as a
matter of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> John Peacock <jp...@rowman.com> writes:
>
> > Here's a couple of ideas for dealing with conflicts (straight from my
> > brain to your eyes, no thought to complexity of implementation):
> >
> > 1) Highest One Wins - the template in force for the shortest path that
> > contains all committed file paths.
>
> This is sane, and can be implemented off the bat by simply having
> svn_ra_get_commit_editor() return the log message template of the
> session URL which is used as the anchor of the commit.
Hrm. Scratch that. svn_ra_get_commit_editor() takes a log message as
one of it's *inputs*. Would work so well for it to be providing an
unfinalized log message as an *output*.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>>2) To Each His Own - If those 20 files are covered by 3 log-templates
>>(for example), then the client splits the commit into 3 seperate
>>commits, each with it's own custom template. We should be able to
>>assume that if a site has that many templates scattered about their
>>tree, then that should be taken as a significant factor and we should
>>respect the effort and not impose a single template.
>>
>>
>
>This is *not* sane. Atomicity of commits is one of our super-clear
>wins over CVS. Let's never forsake that, please.
>
>
Who said we can't create three revisions in one atomic commit? :)
Especially if they're disjunct subtrees.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> John Peacock <jp...@rowman.com> writes:
>
>>2) To Each His Own -
>
> This is *not* sane. Atomicity of commits is one of our super-clear
> wins over CVS. Let's never forsake that, please.
Fair enough; as I said, straight from by brain to your eyes... ;-)
And I actually forgot my third possible scheme:
3) Do No Harm - if any single commit would require negotiating which
log-template to use, fail the commit. If a site has established such a
web of conflicting templates, then there must be a reason for it, so the
client code should respect that. The user can then commit in as many
seperate chunks as required (the client code could even be nice and
print out a table of which log-template applied to which files). And
always, the user could use --no-log-template to get around this stricture.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> Here's a couple of ideas for dealing with conflicts (straight from my
> brain to your eyes, no thought to complexity of implementation):
>
> 1) Highest One Wins - the template in force for the shortest path that
> contains all committed file paths.
This is sane, and can be implemented off the bat by simply having
svn_ra_get_commit_editor() return the log message template of the
session URL which is used as the anchor of the commit.
> 2) To Each His Own - If those 20 files are covered by 3 log-templates
> (for example), then the client splits the commit into 3 seperate
> commits, each with it's own custom template. We should be able to
> assume that if a site has that many templates scattered about their
> tree, then that should be taken as a significant factor and we should
> respect the effort and not impose a single template.
This is *not* sane. Atomicity of commits is one of our super-clear
wins over CVS. Let's never forsake that, please.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> I commit twenty files in ten widely separated directories. Which
> directory's template gets used?
>
> This is one of the questions Karl initially started out trying to
> answer, and he found that the answer wasn't obvious, which led him to
> the idea of punting to a server hook. Yet you and four other of this
> morning's contributors to the conversation seem to have simply glossed
> over the question, instead considering issues like how the user might
> easily set the same template for many directories. Perhaps you all have
> some simple, adequate idea in mind ("the template for the anchor of the
> commit", perhaps), but I really can't tell.
And I cannot tell why placing the burden of determining primacy on the
server hook solves the problem in any way either. Some process still
has to determine which competing log-template gets used; by punting
completely, you place *all* of the burden on the site admin to take this
[possibly marginal in real life] use-case into consideration when
writing the hook script.
Here's a couple of ideas for dealing with conflicts (straight from my
brain to your eyes, no thought to complexity of implementation):
1) Highest One Wins - the template in force for the shortest path that
contains all committed file paths.
2) To Each His Own - If those 20 files are covered by 3 log-templates
(for example), then the client splits the commit into 3 seperate
commits, each with it's own custom template. We should be able to
assume that if a site has that many templates scattered about their
tree, then that should be taken as a significant factor and we should
respect the effort and not impose a single template.
Of course, in both cases a --no-log-template switch to the client should
shut off all special processing and lead to the existing "dumb"
template. Any site wishing to require specific formatting has to use
the pre-commit hook to validate the text anyways.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Mark Phippard <Ma...@softlanding.com>.
Greg Hudson <gh...@MIT.EDU> wrote on 05/19/2005 12:01:53 PM:
> On Thu, 2005-05-19 at 11:45 +0200, Erik Huelsmann wrote:
> > Also, we seem to (mostly) forget that a network turnaround may not
> > always be a http or svn connection: setting up svn+ssh connections -
> > if not reused - may be a major annoyance to users when they don't have
> > ssh-agent set up.
>
> In the simple case of "svn commit" with no provided log message, I
> assume Karl envisioned using the same RA session to fetch the template
> and to perform the commit.
>
> In the case of "svn commit --template-only" followed by "svn commit -F
> file", there would obviously be two RA sessions.
>
> > If these are the underlying assumptions, then why won't the
> > per-directory static template work?
>
> I commit twenty files in ten widely separated directories. Which
> directory's template gets used?
>
> This is one of the questions Karl initially started out trying to
> answer, and he found that the answer wasn't obvious, which led him to
> the idea of punting to a server hook. Yet you and four other of this
> morning's contributors to the conversation seem to have simply glossed
> over the question, instead considering issues like how the user might
> easily set the same template for many directories. Perhaps you all have
> some simple, adequate idea in mind ("the template for the anchor of the
> commit", perhaps), but I really can't tell.
Yes, you are right, we did gloss over this. In Subclipse we would use the
anchor of the commit, although since we do not have inherited properties,
we will start with the anchor of the commit and then move up the WC
hierarchy if necessary to find the property. Using Subversion as an
example, if the property were only set on the trunk folder and that is
what you checked out in your WC, you can do a commit at a lower level,
such as the libsvn_fsfs folder and we will walk up the WC to find the
property if necessary.
If we had inherited properties, we would just use the anchor of the
commit.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Michael Sweet <mi...@easysw.com>.
Greg Hudson wrote:
> ...
>>If these are the underlying assumptions, then why won't the
>>per-directory static template work?
>
>
> I commit twenty files in ten widely separated directories. Which
> directory's template gets used?
>
> This is one of the questions Karl initially started out trying to
> answer, and he found that the answer wasn't obvious, which led him to
> the idea of punting to a server hook. Yet you and four other of this
> morning's contributors to the conversation seem to have simply glossed
> over the question, instead considering issues like how the user might
> easily set the same template for many directories. Perhaps you all have
> some simple, adequate idea in mind ("the template for the anchor of the
> commit", perhaps), but I really can't tell.
Well, I for one missed this issue in all of the discussions... :)
I, for one, would never use a different template for the same
project, however it is conceivable that I might commit from a
top-level directory to apply changes to multiple projects in one
go, say to update a copyright or license file that is common.
In that case, I think I would want the top-level directory's
log template to take precedence. The alternative is to ask for
several log messages, which means the commit would no longer be
atomic.
So, for the proposed svn:log-template iprop, the client would use
iprop for the directory you are committing from. If you specify
the directories by hand, e.g.:
svn ci foo/bar1 foo/bar2 foo/bar3/bla
then the common root directory ("foo" in this case) would be used
to grab the svn:log-template iprop.
If a project does not want to allow multi-project commits, then
they can use the pre-commit hook to reject them (right? :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-05-19 at 11:45 +0200, Erik Huelsmann wrote:
> Also, we seem to (mostly) forget that a network turnaround may not
> always be a http or svn connection: setting up svn+ssh connections -
> if not reused - may be a major annoyance to users when they don't have
> ssh-agent set up.
In the simple case of "svn commit" with no provided log message, I
assume Karl envisioned using the same RA session to fetch the template
and to perform the commit.
In the case of "svn commit --template-only" followed by "svn commit -F
file", there would obviously be two RA sessions.
> If these are the underlying assumptions, then why won't the
> per-directory static template work?
I commit twenty files in ten widely separated directories. Which
directory's template gets used?
This is one of the questions Karl initially started out trying to
answer, and he found that the answer wasn't obvious, which led him to
the idea of punting to a server hook. Yet you and four other of this
morning's contributors to the conversation seem to have simply glossed
over the question, instead considering issues like how the user might
easily set the same template for many directories. Perhaps you all have
some simple, adequate idea in mind ("the template for the anchor of the
commit", perhaps), but I really can't tell.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Log Message Templates via new hook.
Posted by Erik Huelsmann <eh...@gmail.com>.
On 18 May 2005 16:49:32 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> That's "RFC" as in "Request For Consensus" :-).
>
> Discussion seems to have died down, and that may be because people
> mostly agree on the way to go now. So, I'd like to get consensus on
> this proposal:
>
> A new RA method, svn_ra_get_log_message_template(), that takes a
> list of paths and returns the log message template. On the server
> side, this is implemented by invoking a new 'log-message-template'
> hook, which takes the author as an an argument and a
> newline-separated list of (UTF8) paths on stdin. Whatever the hook
> prints to stdout is the log message template. If it prints
> nothing, or there is no hook, then there is no log message template
> and the client behaves as it does today.
>
> The RA method is invoked only when interactive $EDITOR is used to
> write a log message.
>
> (Whether the RA method takes a static list of paths, or receives
> them via repeated callback invocations, is something we will have
> to work out; but this does not affect the overall proposal.)
>
> The server would know the author because of the RA layer's
> authentication; the client would not have to pass the author name
> to svn_ra_get_log_message_template().
>
> We will ship with a default 'log-message-template.tmpl' file that
> just ignores the paths and prints a standard-looking template to
> stdout. But the .tmpl file would document the hook's calling
> discipline fully, of course.
>
> Obviously, there are some details to be worked out here, but this is
> well-specified enough to ask for consensus on the general approach.
I really like the idea, but want to summarize the underlying
assumptions anyway. You seem to be assuming that:
* A template will only be requested when no log message has been
provided for the commit (ie when we need to pop up an editor)
* The per-directory approach won't work, since some repositories hold
more than one project (example: ASF)
* The extra network turn-around is something to be discussed when it
turns out to be a real problem
* The per-directory template with substituteable values is not an
option, because the loss in flexibility can't be accepted and the
solution to that (implementing a client-side interpreter) is not an
option
Am I correct so far? If I am, I have a few questions:
If these are the underlying assumptions, then why won't the
per-directory static template work? If every project has its own
template, I'd expect it to work, since people will have checked out a
working copy per project (and thus have one template per commit). The
fact that CVS needs the directory matching algorithm could be because
a CVS module can be a separate project - needing its own template.
Also, we seem to (mostly) forget that a network turnaround may not
always be a http or svn connection: setting up svn+ssh connections -
if not reused - may be a major annoyance to users when they don't have
ssh-agent set up. Although this is probably one of the implementation
details you were talking about, it's an important one IMO.
If we can assume one template for a complete project, then wouldn't
substituting values into log message templates - without a server hook
script - be a *big* improvement over what CVS supplies?
Would having the possibility to generate a log template offline be
considered a benefit? (Without taking into account which limitations
it might imply.)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org