kfogel@collab.net wrote:
> Dan Allen <dan@mojavelinux.com> writes:
>
>>If you run `svn commit`, record a log and then the merge fails
>>(because your local copy was not updated), it would be nice if the
>>next time you go to commit, it loads up this log so that you don't
>>have to retype it or play file king getting the comments back into
>>the current log window. Ideally, I believe that the merge check
>>should occur before the log is requested so you don't waste time
>>writing a log comment when it is just going to fail anyway. Either
>>way, it is rather inconvient in the current state of things.
>
> 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.
>
> 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.
>
> In other words, this is a less-than-ideal user experience, but not a
> horrible one -- and the solutions seem like more complexity than the
> problem is worth. IMHO, of course.
Since it can take significant effort to write a good log message, it is
quite important to avoid losing it or even giving the appearance of
having lost it (because in that case inexperienced users would assume
that it was lost). I am guessing from Dan's comment ("retype it or play
file king") that in the present implementation the previous message is
recoverable but hard to find, i.e. it appears to have been lost. If
that's not the case, please ignore the reast of this e-mail :-)
I would suggest an appropriate level of support would be this:
During the second log message editing session (i.e. during the next
attempt to commit after the attempt that failed), ensure that the text
of the previously abandoned log message is available where the user can
fairly easily retrieve it.
This could be achieved fairly easily. Possible implementations:
- Use a descriptive and documented (but not fixed) pathname for the
temporary log message file (e.g. /tmp/svn-log-message-N where N
changes). Retain the file if the commit fails.
- If the commit fails, copy the abandoned log message to a descriptive
and documented pathname (e.g. ~/.subversion/previous-log-message.txt).
- In the log message default text, include the pathname (and/or full
text) of any previously abandoned log message (e.g. /tmp/tmp12345),
without trying to establish whether it was for a similar commit.
In short, I support Dan's request for better handling of this situation
(though I haven't verified that the current handling is how I infer it
to be) and I believe that there are some low-cost solutions.
Finally, what does CVS do?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 01:53:09 2003