Mark Phippard wrote:
[snip]
> The common dev response has always been that the behavior you see is the
> exact same behavior you see when using the cp command of the operating
> system, at least on Unix. I believe Windows works the same way.
Yes, when you use the 'move' or 'copy' command in a windows console it
works the same way (just tested).
But the problem I have now is that the windows explorer doesn't work
that way. And I guess you can imagine that most windows users don't use
the console at all and therefore aren't used to such a behaviour.
An example:
if you move the folder testwc\currentdir\dir1 into the folder
testwc\targetdir (where another 'dir1' is located), then the explorer
first asks you if you want to overwrite 'dir1', and if you click yes,
then the folder is overwritten, but the files in it are still there. So
you end up with
testwc\targetdir\dir1
testwc\targetdir\dir1\file1
testwc\targetdir\dir1\fileA
So that's what windows people are used to. And since the behaviour isn't
just in the command line client but in the library API, there's nothing
that TSVN can do to change that behaviour.
I would like to have the library API (svn_client_move(),
svn_client_copy()) throw an error if the target exists, and maybe have a
'--force' argument the command line client could use to have the same
behaviour as before.
I think even konqueror and other explorer-like tools on Linux behave the
same way as the windows explorer in this case. In that case GUI clients
on those system will face the same problems as TSVN does now with that
behaviour: users just don't understand why there's a completely
unexpected folder structure after a move.
> Sorry if I missed some subtlety in your recipe, but reading it, it just
> looks like the common case that is asked regularly. I personally remember
> being burned by this and asking the question 6 months ago. It is not too
> hard to deal with once you are used to it.
Yes, now that you mention it I recall that this was mentioned before. At
that time I thought it wasn't a problem. But now that I see how this
behaviour is against all what windows (explorer) users are used to and I
can't work around it in TSVN it starts to bother me.
At least, I haven't had an idea yet on how I could work around that (not
without scanning the whole target folder structure first, which would
annoy the users a lot because of the big delay).
> I am also on the TSVN list. It didn't occur to me that this was the
> problem when the person posted it. Now that we have an inkling that it is,
Well, the problem reported first was a different one. But then the user
reported what might be the reason for his problems which was exactly the
wrong folder structure after the move. I guess he then moved the files
again (a double move) which of course failed and then tried to 'fix'
things manually.
The problem with the additional /trunk in a tag occured a few weeks ago,
but I just remembered it because it looked so similar than the problem
the user reported yesterday.
> it makes their basic scenario that they wanted to accomplish seem kind of
> difficult to do properly. Perhaps you should encourage that poster to
> repost what they wanted to achieve on the users@subversion list and see
> what others have done?
Sometimes I tell people to ask on the users@subversion list to ask for
further help. But in this case I don't think it will help much. No
offense, but for such problems the answer on that list is usually "write
a script" or maybe someone posts a script which does the job. But
windows users aren't used to even use scripts, most of the time the
scripting language isn't installed, or can't be installed because it
only runs on Linux. And whenever that happens, they come back to the
TSVN list (more annoyed than before) and request that TSVN must have a
workaround for that.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 18 15:50:16 2004