Re: commit comments after failure

> I'm not sure it's worth it to do the merge check before writing the
> log message -- things could still get out of date while you're writing
> it, after all.
Good point, I agree.

> I like the idea of reloading the previous failed message on the retry,
> but it's hard for Subversion to know whether the next commit _is_ a
> retry or not. Maybe you're committing an entirely different set of
> files. Anyway, Subversion keeps no record of how many failed attempts
> at commit have happened recently, and I'm not sure it should. Any
> time we start recording more state, we're increasing the number of
> ways to get into trouble.
Let's put it this way, 9 times out of 10, if a commit fails, you run
svn update or whatever and then turn back around and do svn commit.
If developers are anything like me, their anal nature will lead them
to delete any tmp files immediately after they are created (I also
delete any svn-commit.tmp as soon as I see it after any commits just
because I like to keep things clean, I also run svn status ritually
and it shows a ? by these files). So, let's assume that if one
exists, it was probably just created. It is more likely that the
svn-commit.tmp file sitting there is relevant to the current commit
then not. If it isn't, it is far easier to wipe out the lines that
were automatically loaded then to have to bring up a file browser
to import the message from the svn-commit.tmp file.

Maybe a good setting for .subversion/config but how about

autoloadFailCommit=1

I think most people would enjoy the convenience it adds, or they
would get into the habit of cleaning up svn-commit.tmp files after
they finished committing.

Dan

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <dan@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
'One Microsoft Way' is more than just an address.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org