Greg Hudson <ghudson@MIT.EDU> writes:
> On Tue, 2005-05-17 at 21:36 +0200, Branko Čibej wrote:
> > According to Karl's proposal, we'd have a special RA function to get the
> > log template... then later on, we'd find something else for the client
> > to pull from the server, and add a second RA function... and a third...
> > That's nuts; even more so because it costs almost nothing to have the
> > function take an additional parameter that identifies the data to be sent.
>
> But log templates require a specific kind of input (the directories to
> be committed) which makes no sense for other kinds of server-to-client
> configuration under discussion.
Don't assign me to a "side" in this debate, yet -- I'm just handing
out info.
Log templates in CVS do not require that specific kind of input. CVS
just tacks the file list onto the end of the template. We could do
better than that, for sure, by, say, defining our log message
templates such that special keyword-ish things get substituted with
known data. For example, a log message template like:
Issue Number:
Reviewed By:
* * * *
Changes:
[paths]
Might get transformed to:
Issue Number:
Reviewed By:
* * * *
Changes:
A /trunk/foo
A /trunk/foo/bar.txt
...
Or something like that.
> > Just for the record. IMHO we don't need it for log templates, either. It
> > may be sexy to have them generated based on the set of paths to be
> > committed, but that /is/ overkill IMNSHO.
>
> I don't think it's at all overkill for situations like the ASF
> repository. If a single repository-wide log template were good enough
> for the vast majority of cases, I don't think we'd have seen the
> per-directory functionality in CVS.
I think there's no doubt that we want per-directory-tree log message
templates. But then, I also want per-directory-tree generic
server->client configuration dictations, for things like auto-props
and ignores and such.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 22:50:33 2005