Otik wrote:
> 1. What about show last canceled show message, but marked it, so after
> start typing it will be replaced by typed text. When you want to keep,
> just move by cursor, or do anything to unmark it.
>
> 2. Is something of this message memory in ChangeList ? Is there way for
> describing ChangeSet ? - I don't test ...
Apart from messages from cancelled checkins appearing in the message
history, the existing implementation works fairly well and has some nice
touches if you're happy to write your commit messages after a round of
edits. There are some timesaving enhancements that could be made, such as
automatically showing the diffs when you choose to commit because as the
first poster noted, this will tend to be the next action to perform. This
could be selected via a preference, or perhaps a "commit and diff" menu
option as well as the regular "commit". Being able to enter the log
message via the diff dialog, or in some way linking the two so that then
actioning the commit also disposed of the diff dialog would be a further
time saver. Alternatively the diff dialog could be reused when you select
a diff rather than displaying multiple diff windows. But even as things
are now, the mechanism is not bad if you want to leave it until commit
time to recall the changes and are happy with the current "change and try
to remember" style as opposed to the much less onerous proposed "record
and forget" style.
The problem is that often one doesn't want to leave it until commit time
to record the log message as it's resource intensive to reverse engineer
diffs back to a log reason after the fact, as opposed to recording what is
about to done *first* and then being able to forget the reason and
concentrate on the change itself. I estimate that as much as 15 to 30
minutes of a day could be wasted doing a sequence of diffs and commits,
whereas it could take just 30 seconds. Half an hour lost to Tortoise is
half an hour less development time, which could easily translate into lost
revenue if there is a commercial aspect to a project. Being able to code
right up until the last minute, and then being able to start a mass commit
at the end of the day and walk away knowing that everything will be
committed with meaningful messages would be awesome.
A further new concept could be to indicate whether changes are partially
completed or not. This would work by allowing review of the set of log
messages that are attached to pending commits, compressing duplicate
messages and an option to see what files the messages relate to, and being
able to select whether each change is fully implemented or not. All
messages would get recorded with the commit, but partial changes would
remain attached to the working copy and recorded as partial in the log
history. Not all users would want to commit partial implementations, but
some would perhaps as a backup, or so that they can checkout at another
location to continue work etc.
Once it's easier and less painful to record accurate log messages with
commits, it then becomes feasible to autogenerate change log documents
that would be acceptable to distribute externally. As not every commit
message would be necessary for a change log, log messages might be tagged
to indicate whether they should be visible in the Change Log or not. This
is a further time saver as it's then unnecessary to maintain a change log
and record changes there as well as in Tortoise. This could be done quite
easily now by prefixing messages for the change log with a tag and
grepping for such messages, but T could add value by natively providing
such a feature and concept. (This may be done already in tools that I'm
unaware of so apologies if that's the case.)
So I can see first adding value by evolving Tortoise so that it's possible
to more easily record accurate change log information, removing the
current mental and time burden that exists, and then add further value by
leveraging the availability of a more accurate and useful commit history
in the form of a feature such as auto-change log generation.
N.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Feb 23 13:04:08 2007