Andreas Schnederle-Wagner - Futureweb.at wrote:
> found a bug regarding adding new files.
> The following scenario:
> User A adds „dir/testfile.sql“ and commit it
> User B at the same Time creates „dir/testfile.sql“ without adding it to
> the repository
> At a later time User B updates his working copy – the lokal
> „dir/testfile.sql“ is now „auto-added“ without any error message – at
> the next commit (User B) – the „dir/testfile.sql“ will be uploaded with
> the content of User B – everything User A wrote into this file is gone.
That's not correct.
User B has the file already, but unversioned. The update will therefor
*merge* the contents of testfile.sql from user A with the local one of
user B. Changes user A has made are still in the file, and if you check
you will see that the file is shown with the 'modified' overlay.
Also, during the update the file will be shown in green (and the
'action' shown as 'merged' instead of 'updated') because of the merge.
Sure, no *error* message, but enough information to see that the file
When user B commits the next time, he'll see that testfile.sql has local
modifications (and the diff shows that these are exactly the diffs
between his local file and the file user A has committed).
> Shouldn‘t there normaly be an error when I update my working copy and
> there is already a local file named the same as one in the repository?
It worked that way in < 1.5.x clients. And it does still in the command
line client if the --force flag isn't passed when updating.
But AFAIK all Subversion UI clients pass that flag automatically to
prevent interrupted updates due to 'already existing' files (something
many users complained about before).
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-01-12 18:43:23 CET