2008/6/19 Stefan Küng <tortoisesvn_at_gmail.com>:
> Simon Large wrote:
>> First to clear up some confusion, copy-from-WC is not the same as
>> When you use the 'create branch from WC' the branch contains your
>> exact WC state, local mods and all. It's not a pure server-side copy.
>> Mostly you don't want to do that.
>> When you 'create branch from HEAD' the branch is created from what the
>> server knows as HEAD, which may be different from what you can see in
>> your WC if someone else committed after you last looked. That is also
>> potentially incorrect.
>> What you normally want is to create a branch from the revision your WC
>> is updated to, so you know exactly which rev it is based on before you
>> commit, and that's what Stefan's thread is doing.
>> As far as the worry about race conditions and the TSVN changing things
>> while you are not paying attention, I like Todd's suggestion. Start
>> out with none of the radio buttons checked. When the crawler thread
>> completes it can fill out the specific revision box, assuming the user
>> has not focussed on that box, fill in the rev and select that radio
>> button. If the user sets focus on the rev box or selects any radio
>> button then stop the thread.
> The radio button is on HEAD when the dialog starts.
> if the user *really* doesn't change one single thing in that dialog and
> clicks "ok" to tag, the only race condition would be if the thread changes
> the options from HEAD to revision-where-WC-was-last-updated-to.
> If nobody did a commit in the meantime, that's not really a race condition
> because it will be the very same.
There is always a race condition, but the results may (or may not) be
the same. Just to clarify, the window is between when you last updated
and when you press OK in the branch dialog, not the window between
opening the dialog and pressing OK, so it may be a large window.
> If however someone else made a commit in between, the changed option from
> HEAD to revision-where-WC-was-last-updated-to will even benefit the user.
I agree with what you are trying to do here. The issue is that if the
WC was updated to some old rev (for whatever reason) and the user
wants to branch from HEAD, then the race condition could be a problem.
By starting with no buttons checked, you force the user to choose,
rather than having something change in the GUI when you don't expect
Another alternative would be a 4th radio button for 'WC update
revision'. If you select that option then the rev box is greyed out
and filled in by the crawler thread. Again, you force the user to
think what they really want. You could make that button the default,
as it is the most sensible option anyway.
>> If that is still too much magic, then a separate button to check the
>> WC revision and fill in the rev box would be another solution.
>> BTW, what happens if the thread detects a mixed rev WC on its crawl,
>> or local modifications? Should there be a warning about that? Maybe if
>> the crawl is initiated by button there could be a warning dialog, or
>> just a yellow triangle like there is for externals in the commit
> Define "mixed rev WC" please. Almost every file has a different revision
> (the 'last committed rev'), unless you've changed every single file in your
> working copy for the last commit.
Mixed update revisions, not commit revisions. And yes I know that a WC
will have mixed update revs after commit until you update it. I'm not
sure if this warning is worth having, it was just me thinking out
Another condition that might ring alarms is a WC with switched paths
in it, and maybe a partial checkout.
> For local modifications, a warning is shown if the radio button is still on
> HEAD when the thread finishes.
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-06-19 13:30:35 CEST