2008/6/18 Gleason, Todd <tgleason_at_impac.com>:
> It seems like the race condition is then not against when you click OK, but against when you do any editing. It's still unpredictable what you'll end up with if you aren't paying attention, spend some amount of time to change the target URL, and then proceed. Maybe it has picked a WC revision, maybe it has left it at HEAD.
>
> I don't agree with the suggestions as to what to use for the default, either. In some cases you want what's in your working copy, and in some cases you don't. I don't see how you can statically choose a good default, or dynamically with a race condition in the mix.
>
> Also, if I understand correctly (and I may not), the default doesn't seem to make a lot of sense with respect to what the command line does. The svn book's documentation on svn copy doesn't say what default revision it uses for URLs or for WCs, but I'd guess that it's HEAD for URLs and BASE for WCs. In other words, the default is effectively chosen after you pick your source and destination. (Did I miss anything?)
>
> To emulate this, I'd think you'd leave the radio buttons unchecked, and check something (if nothing is already checked) when the user changes the target URL. If it needs to be the WC, then you could let the scanning thread finish and pull that revision--although I gather that TSVN is trying to be smarter than svn copy here and perhaps choose a revision higher than the BASE for the collective directory structure. I don't know if this is a good or bad idea because again it sounds different from what I expect svn copy does.
>
> -----Original Message-----
> From: Bernhard Merkle [mailto:bernhard.merkle_at_googlemail.com]
> Sent: Wednesday, June 18, 2008 1:42 PM
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: default of tag operation is HEAD revision of repository ?
>
>
>
> On 18 Jun., 19:36, Stefan Küng <tortoise..._at_gmail.com> wrote:
>> Gleason, Todd wrote:
>> > Cool as that sounds, it seems like a race condition. If you're
>> > expecting the HEAD to get tagged regardless of your WC, and you go
>> > ahead with the operation right as it changes to denote your working
>> > copy, it sounds like you get your working copy's version instead of
>> > HEAD.
>>
>> Well, you have to edit the target url first. And any edit on that dialog
>> discards the thread.
>
> well, I think the behaviour is not obvious for the user. please keep
> things simple. Why not offer tag working copy by default ?
>
> the current implemented solution seem a bit overcomplicated for me.
> changing the gui behind the scenes (or when the thread has finished)
> is definitely irritating for the user. I do not know much GUI apps
> which do this.

First to clear up some confusion, copy-from-WC is not the same as
copy-from-WC-rev.

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.

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
dialog.