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
--ben
---------------------------------------------------------------------
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