On 8/6/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Updating from the commit dialog? That's a very bad idea! Because an
> update can change the status of files, which are already shown in the
> commit dialog. And that would mean either *guess* the new status or do a
> full status fetching again - and then you could just do the update
> outside the commit dialog and hit F5 afterwards.
Why would a full Update or Status fetch be necessary? Via the Commit
dialog selection list, you know what specific paths are to be updated,
so just update refresh status on those. Usually a commit set amounts
to a small set of files in a large set of directories, so checking the
status on unrelated files and sub-directories is a huge waste of time.
There is no need to do a slow update or status re-walk on every
unrelated little path. That is the whole point -- to be able to limit
both Updates and Status Refresh to those paths you intend to work with
-- rather than wasting time with everything else.
> Are you saying you want to lock a file to *prepare* for a commit?
> That's just the wrong way to work with Subversion. Seriously!
Yes, that's what I'm saying. Have you read the rest of this thread --
seriously? :)
Your "right way" doesn't work very well for us, and I see no valid
reason for anyone to impose their "right way" on us. And what is the
point of limiting this use? Why do you feel the need to "save the
users from themselves"? We can already do this now, even though the
interface makes it harder and slower than necessary.
> > 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.
>
> Bad idea! You will understand the problem as soon as someone resolves
> such a conflict, commits and breaks the build with it.
> Resolving a conflict is not an easy task. And speaking for myself I
> would forcefully explain to all users that after resolving a conflict, a
> build is in order to check if the resolving really is ok. *Then* you can
> commit again. But if you haven't resolved the conflict when you fire up
> the commit dialog, that means you haven't built your project yet and you
> shouldn't commit in the first place.
What you describe is close to what we do on a first-pass commit, but
doesn't make any sense for subsequent commit attemps on the same set,
especially when other users want to commit to a subset of the same
paths at around the same time. I have resolved many conflicts in this
project alone, and the situation you describe simply doesn't affect
our particular workflow. What *does affect our workflow* is having to
wait for slow NTFS directory-walk style updates and status refreshes
every time we want to re-start a commit cycle, and having a commit
fail suddenly because another user managed to sneak in a smaller
sub-set commit in the time it took for the Status to display.
Even if everybody strictly follows the conflict resolution steps
you describe (which I sincerely believe does not fit every use case as
absolutely as you seem to think), there is no reason the user
shouldn't be able to initiate some of these steps from the Commit
dialog directly, and to leave the dialog open for later use, while
they go through their local build/test cycle. Why should they be
forced to update or refresh status on files that they absolutely know
have nothing to do with the commit at hand? Even the F5 refresh forces
them to wait for a full Status refresh on totally unrelated paths, and
wastes a huge amount of time on large WC directories.
All this comes down to allowing the user to determine their commit
cycle as they see fit, and trying to waste a minimum of their time.
Perhaps these options could be taken away on projects where
Administrators see them as being against internal policies, via ini
config file options. There is no reason to assume all use cases will
be the same, and to force all users to use the "slow and safe" route
if it doesn't fit their production cycle. Let the users deal with the
consequences, and stop trying to coddle us, as if we don't know what
we're doing! That's what documentation is for -- not artificial
interface limits.
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 8 00:00:31 2006