Jared Hardy wrote:
> 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
Just updating individual files doesn't speed up anything at all. In
fact, it can make things even worse. Fetching the status for a file
actually fetches the status for the whole folder and all files in it,
but then only the status of the asked file is returned (that's how the
Subversion function works, unfortunately).
And a full status update is necessary because you simply can't just
guess what the status of files after an update is.
>> 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.
You need to lock a file *before you start editing it*. That's the whole
point of locking a file. If you just lock it before a commit, then the
lock is useless.
Maybe an "update-and-lock" is what you meant?
>> > 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.
Just how much time are we really talking about here?
> 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.
Those are not artificial interface limits, that's how Subversion is
designed and works. To do what you ask for would mean to write an ugly
workaround to the Subversion design.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 8 18:38:07 2006