Hello,
On Feb 5, 2:56 pm, jwezel <jwe..._at_compumaster.de> wrote:
[...]
> CURRENT (WRONG) BEHAVIOUR:
> 1. tortoise will tell the svn server to delete folder project1
no, neither TortoiseSVN nor SVN delete "project1".
TortoiseSVN lists the missing folder in the commit dialog and puts
"missing" next to it. When checking the checkbox next to that missing
folder TortoiseSVN or SVN interpret this as "user decided that this
needs to be a delete operation for the respective item(s)".
(Maybe it could be made clearer in the TortoiseSVN UI that checking
that checkbox leads to a "delete" operation.)
> 2. tortoise doesn't realize the new folder project-master since there
But where to stop the search for this renamed folder? If indeed it
only got renamed in the same parent folder, it may be possible to find
it quickly. But if it has been moved, it isn't so easy anymore.
Will you not give the user only partial functionality if you guess his
intention for a simple rename correctly, but not for a move of that
same folder? What if the folder got moved somewhere completely else,
outside the initial checkout directory? What about file renames and
moves? What about new files?
Also, TortoiseSVN or SVN would need to put information into folder
"project1" to know at a later point where this folder got initially
checked out to under what name (to be able to recognize the rename).
But having this information can just as well be misleading to
TortoiseSVN/SVN again, if the folder gets moved to another computer,
or a completely different checkout, etc. Not putting this information
into the folder would require TortoiseSVN to scan upwards until the
top-most folder of the checkout to know whether the folder-with-the-
new-name got there by way of a rename or by way of an svn:external.
As has been said, some checkouts are several GB in size. The disk I/O
and delays caused by the (absolutely nice but "costly") icon overlay
state cache for such checkouts is considerable already. Adding to that
- causing more noticable delays - is probably something many people
would frown upon.
I think what you are trying to suggest is to make TortoiseSVN more
accessible to the "unwashed masses", to users who need versioning,
confict management and file sharing as well as an interface to that
functionality that will recognize as many of the less-tech-savvy
user's intentions as possible (such as interpreting the rename in this
example as intentional), but that may be a different specialization
than what TortoiseSVN aims to do (or could do well enough to satisfy
you or these other types of users eventually, given its different
specialization).
(Maybe look at TeamDrive (www.teamdrive.net), which tries to do
exactly that, guessing what the user wants to be performed in the
"repository" based on his file system activity, plus offering
versioning and conflict management. (But note that TeamDrive has
nothing whatsoever to do with SVN.)
With best regards
Clemens Anhuth
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1128311
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-02-09 09:52:04 CET