Considering all we have talked about in this thread, I just thought of
a relatively simple Feature Request, which I hope would be trivial to
implement, if you have a working solution environment (I'm working on
getting funding to upgrade to VS.NET 2005 Pro now).
In the Commit dialog now, once the list of modified files is
populated, you can select one or more paths from the list, and have
the right-click options of "Revert...", "Delete", and "Get Lock". I
would also like the option of "Update", to help prevent the situations
where a Commit fails simply because a file is not up to date, but not
conflicted with HEAD. Files that are conflicted after the Update could
be revised in the Commit dialog list after update, if necessary. In
fact, I would like an option to "Lock and Update", where the default
Lock message would be "Attempting Commit" or something similar, and
thus not require a Lock dialog spawn. This feature assumes the "Keep
locks" is unchecked, so maybe it would become "Lock and Update..."
with a Lock dialog spawn, in cases where it *is* checked.
This may already be the case now, but if a conflicted file appears
in the Commit path list, it would be nice if right-click gave the
options "Revert", "Resolve", and "Diff". That way conflicts could be
resolved without leaving the Commit dialog, and the dialog may be able
to update the status once an Exit condition on the spawned sub-dialog
is detected. Maybe this functionality already exists -- I'm not sure.
The purpose of these options collectively, other than extending
the existing functionality of the right-click menus in the Commit
dialog, would be to prevent the need to load the Commit dialog many
times in succession, which incurs a big time-hit if a lengthy
recursive Status search takes place every time the dialog is loaded.
It would help enable the user prevent errors that cause Commits to
fail. Additionally, it may help to cache the status of any commit
attempt, for subsequent Commit dialog requests on the same folder, to
have something to show and interact with immediately. The user would
have the option to wait for more current Status information to be
populated, or just act on the cached Status information at hand. This
would do wonders in the speed perceptions of users for all Commit
So what do you say? Can I add this as a Feature Request to
Flyspray? I can split the requests from each paragraph into a separate
Feature Request, if desired, though they all have the same overall
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Aug 5 02:06:37 2006