Re: text that pops up in your $EDITOR (fwd)

This is dev list material, no need to hide it from the crowds.

-- 
      Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------- Forwarded message ----------
Date: Thu, 24 Jan 2002 00:35:48 -0800
From: Mark D. Baushke <mdb@juniper.net>
To: Daniel Stenberg <daniel@haxx.se>
Cc: Ben Collins-Sussman <sussman@collab.net>, Greg Stein <gstein@lyra.org>,
     Greg Hudson <ghudson@MIT.EDU>, Justus Pendleton <subversion@ryoohki.net>,
     Sander Striker <striker@apache.org>
Subject: Re: text that pops up in your $EDITOR
Hi Folks,
Feel free to share this message with the dev@subversion.tigris.org
list as a whole if you think it would be useful. I just included users
that had commented on the "text that pops up in your $EDITOR" thread...
A point I'd like to make about log messages... CVS has a way to put a
structured template into the $EDITOR text file. It might be useful for
the new
SVN: <char>      <pathname>
entries to have a way to be incorporated into such a template at the
BEGINNING or the END of the text file depending on the configuraiton
used by the repository maintainer... (For that matter, a keyword and
paragraph method as in perforce is also not horrible method, but
assumes a template structure that may not be as easily extended....)
Also on the topic of commit log messages, it would be nice to allow
for a 'cvs commit' to have a way to query the user about a 'defect-id'
to be used in conjunction with the commit. At present this may done in
CVS by assuming that the template provided by the rcsinfo trigger is
used by the editinfo trigger to populate the text file that $EDITOR
uses and that the CVS editinfo trigger or the CVS verifyinfo trigger
will then have to validate the user's "structured" log message to
determine if the information desired is valid or not.
However, the verifylog message can only fail (rather than being able
to enter into a dialogue with the user about the problem) if the
template is not properly filled with information. It would be nice to
be able to prompt the user with a notice that the information appears
missing or incorrect and allow them to re-enter the $EDITOR to fix it
or to abort the commit if they do not wish to fix it.
Does the svn system allow for this extra set of interactions?
(Apologies if this is obvious to everyone else already, as I have not
been paying close enough attention to the protocol steps of the commit).
I'd like to be able to configure a repository such that all 'svn
commit' actions might require a few additional pieces of information
that may need to talk to a server for validation. The pieces of
additional information are: the 'defect-id' or 'problem-report-id' or
'case-id' or whatever you want to call it. I'd also like to have a
'reviewed by:' (or 'approved by:' or some other way to indicate the
authorizing authority) that has approved this change. Typically this
level of formalism is only needed in a more 'protected' environment
such as prior to a 'release' when only critical changes are being
accepted in order to help stabalize the software.
In general terms, consider the need to bolt a tracking system of some
kind onto the source control system so that users may determine if
changes they desire have been made to the source base to fix a
particular problem or so that code maintainers may more eficiently
describe user visble fixes that may be getting tracked via some kind
of a problem-report sytem.
I hope that the above makes sense...
Thanks for listening.
	-- Mark
> Date: Thu, 24 Jan 2002 08:14:48 +0100 (MET)
> From: Daniel Stenberg <daniel@haxx.se>
>
> On 23 Jan 2002, Ben Collins-Sussman wrote:
>
> > > SVN: Status report on the targets just about to get committed:
> > > SVN:
> > > SVN: M    ./file1
>
> > +1, looks good to me.  But:  I should warn you that we're planning on
> > implementing 'svn commit' slightly differently in the current milestone
> > work.  In particular, we're going to effectively be running 'svn status'
> > before beginning the drive of the commit-editor.  Since this information
> > will be in memory anyway, your code may want to take advantage of it.
>
> Too late, already implemented it! ;-)
>
> Anyway, it was very quickly done as I could borrow lots from status*.c.
>
> (~20K patch is pending...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org