How about on the client side, a named list of files/folders that can be
kept (instead of just last one)?
The file set that is repeatedly committed may often be one of several
sets the programmer is responsible for even though others may be locally
modified.
Doesn't perforce's client have something like this?
I know other clients (eg StarTeam) also have something similar.
A little complex perhaps, but something to consider...
Peter
-----Original Message-----
From: Nathan Kidd [mailto:nathan-svn@spicycrypto.ca]
Sent: Wednesday, November 10, 2004 10:38 PM
To: dev@tortoisesvn.tigris.org
Subject: Re: [TSVN] Commit Dialog Behaviour
Nathan Creek wrote:
> Nathan Kidd wrote:
>
>> If the main commit dialog didn't close when clicking "Commit", but
>> rather had the "progress commit" dialog as a child, and only closed
>> if the commit was successful it would be a big improvement.
>> <snip>
>> Thoughts?
>
> A problem i see happening is that a commit dialog in the background
> could end up with an out-of-date file list.
> If the commit dialog stays in the background and the Commit fails due
> to needing to update. Then you do an update on the trunk and one of
> the files that got updated causes build errors and you modify
> previously unmodified files to fix it. Now the Commit dialog in the
> background won't have the files you've just changed listed, you'd have
> to close it and open it again to make it rescan.
Hmmm, that's something I hadn't considered. It will only affect when
the user has *not* selected a special list of files to commit and
expects the whole tree to be commited -- otherwise I think it's obvious
to the user that their specially selected list of files to commit won't
include any new modified files. Perhaps the commit dialog could keep
track of what revision the tree was at when it scanned for commits. If
the user tries to commit again from the same dialog (with a potentially
stale file-list) it will ask if you want to check for additional
modified files. Saying "Yes" would ensure nothing is missed. Saying
"no" lets you just commit what you had selected.
> I'd suggest an alternative would be to save a list of the files that
> are selected when the dialog is cancelled, and then the next time
> Commit is brought up have a button or something to load the previous
selections.
> Or maybe a better option would be to save the files that aren't
> selected and have a button restore previously unselected files. This
> way if there are new files in the list they will be selected by
> default. I don't know if that is desirable, but considering all
> modified files are selected by default to begin with it's probably
consistent behaviour.
Perhaps saving the list of specially de-selected files is easier. It
would only need to be from the last commit (attempt) -- that kind of
info is only useful till your (recently killed) commit finally works
(which presumably is done right away).
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Nov 11 18:30:15 2004