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

Re: [Patch] prompt string for client

From: Tom Gordon <tgordon_at_motricity.com>
Date: 2005-09-28 17:31:22 CEST

Thank you both for responding.

Our organization previously used CVS which has a template process to
prompt users, which we used to aid our auditing process.

My apologies for not finding "issue 1973" ... thank you for not sending
a rtfm message ... great to know the progress to date.

I would be interested in an approach for implementing Ben's standard
solution below. That is, send an additional message from the client to
the server after the authorization to get a template. This could be an
argument passed to svn commit (e.g. -t template_name).

Thanks,

Tom Gordon

Ben Collins-Sussman wrote:

The standard solution to this problem is to make 'svn commit' use a
server-defined log-message template, one which has custom fields of
your choice. Then you can install a pre-commit hook which demands
that all the fields are filled out in the log-message (else the commit
is rejected.)

Enforcement pre-commit hook is certainly doable right now, but we're
still discussing a design for broadcasting log-message templates.
You'll need to find some other workaround for that -- either educate
the developers (make them remember the string), or pass out templates
by hand for folks to use. Also, remember that the pre-commit hook can
reject the commit with a specific error message:

  "Commit rejected: I didn't find a 'Bug ID:' field in the log message."

That will certainly remind the developer exactly which string to use.

Malcolm Rowe wrote:

>On Wed, Sep 28, 2005 at 09:36:01AM -0400, Tom Gordon wrote:
>
>
>>I would like to prompt the user to enter a Bug Id and who reviewed the
>>code on the client, before sending the commit to the server.
>>
>>
>
>This is issue 1973, log message templates. Your patch is fine for your
>users, but obviously isn't appropriate in the general case.
>
>The last time this came up, there was a long discussion, but I don't
>think there was any concrete conclusion. Summarising from memory:
>
>* Log message templates could be per-project, which might not be the
> same thing as per-repository.
>
>* It seemed to be a foregone conclusion that you'd want to store the
> template in the repository (is this a CVS parity issue? I'm not familiar
> with CVS).
>
>* Given that, how and when would you communicate the template from the
> server to the client?
>
>* One suggestion was via a property set on a parent directory, but
> that would require inheritable properties, and runs into problems when
> you commit across two directories with different templates (although,
> as someone pointed out, you may _already_ be in trouble in that case,
> unless you can use a log message that's a superset of both).
>
>* Another suggestion was that the client could call a hook to generate
> the template (giving maximum flexibility), but that would mean that you
> had to be online to start a checkin (at the moment, you can run 'svn ci'
> and use the default template), and the performance probably wouldn't be
> great (an extra round-trip before every checkin). Another big problem
> with this suggestion was that GUI clients want to be able to present a
> comment box before they've finished working out which files are
> affected, which wouldn't be possible with this change.
>
>
>You probably didn't need to know all that, but it might be useful if
>we're going to restart the discussion at some point.
>
>I'm not sure what the current plans are for this issue (if any), though
>at one point it was on a roadmap for post-1.3 development. Karl?
>
>In short:
> * It's a known issue.
> * It's quite complex.
> * No-one seems to be working on it at the moment.
>
>Regards,
>Malcolm
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 28 17:35:58 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.