> On Tue, Jan 22, 2002 at 02:32:12PM -0500, Garrett Rooney wrote:
> > On Tue, Jan 22, 2002 at 02:24:45PM -0500, Mark Benedetto King wrote:
> >
> > > > As for ideas, the only thing I really want is for the default message
> > > > to start with a list of files changed in the format we currently use.
> > > > Something like this:
> > > >
> > > > * subversion/foo/bar.c
> > > > * subversion/includes/bar.h
> > > >
> > >
> > > One thing that I remember perforce doing right:
> > >
> > > It noticed when you deleted items from the changed-file-list. That way
> > > you could easily commit some, but not all, of your changes. A potentially
> > > unsafe practice, but handy nonetheless.
> >
> > annother thing perforce does wrong with regard to this, just for the
> > record.
> >
> > the parser for their commit log form is notoriously picky. all lines
> > that you add have to start with a tab, or it will not commit. this
> > annoys the hell out of me, and if we're going to parse the commit
> > message to do something with it, i suggest avoiding that kind of
> > behavior.
> >
> > in any event, i don't think we should be parsing the list of files and
> > changing behavior based on them. we have the command line to do that,
> > and having multiple places to change the behavior just seems like an
> > interface mistake. plus, it ties us to one format for the log
> > messages, and i don't think we should be doing that. if a project
> > doesn't want their logs to have the files listed, it shouldn't have to,
> > and if we're parsing the file looking for that, how do we know if they
> > just decided no to have that, or if they deleted all the lines? it's
> > just ugly.
> >
>
> What usually happens to me is that I've changed N files in M different
> directories distributed all over the filesystem, and I want to check in
> N-1 of them. Maybe I don't know how to use CVS well enough, but I
> usually resort to doing "cvs -n update" to see a list of the changes,
> and then using X11-selection to paste together a "cvs commit foo bar baz"
> style command line. Of course, eventually my command-line gets
> full, so I have to break it into multiple commits. The pasting and
> multi-committing is a lose in CVS, but since cvs doesn't guarantee
> atomicity, it's not *that* big a lose (it hurts the user experience, but
> not the functionality). With atomic commits, there's a difference
> between "svn commit foo bar" and "svn commit foo; svn commit bar".
>
> I agree that some projects might not want their logs to have the files
> listed, and that they shouldn't have to. I also agree that bad parsers
> turn good features into bad ones. I'm suggesting that the file that is
> created would look something like:
>
> Put your log message here.
> # The list of files to be included as part of the commit are:
> file-1
> file-2
> file-3
Hmmm, ok, I have a suggestion. Can we generate a log message by default
that has SVN: prepended to each line? Then list all the files in the
commit on lines with such a prefix (on per line)?
We can let the pre-commit hook strip the log msg of these lines.
This way you get all the info, but you don't _have_ to use it.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006