I've a question to this behaviour. In case a merge is not possible because it's a binary file. This results in a conflict, right? Which status has the file (my private changed file or file from repository) afterwards? Is there a possibility to check the real file contents but trying them out?
Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 428. VAT ID / USt-IdNr.: DE 811127087
Management / Geschäftsführung: Dr. Wolfgang Kalsbach, Chairman / Vorsitzender, Hans-Jürgen Désor, Klaus Heberle,
Nikolaus V. Kaeppeler, Wilfried Lowinski, Dirk Wieberneit - Chairman of Supervisory Board / Vorsitzender des Aufsichtsrats: Heinrich W. Kreutzer
Bitte denken Sie an die Umwelt, bevor Sie diese e-Mail ausdrucken.
Please consider the environment before printing this e-mail.
From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
Sent: 18 July 2008 16:09
Subject: Re: Failed to add 'XXX': object of the same name already already exists not working on Tortoise 1.5.0
Gottfried Chen wrote:
> I tried a test with a colleague at work. When I create a file test.txt
> locally in our project, he does the same in the same project location,
> adds the file and commits it. Then I do an update via svn command line
> -> I get "Failed to add 'XXX': object of the same name already already
> exists" which is the desired behaviour as SVN should never overwrite
> local files. But with Tortoise 1.5.0 it simply says "merged", but
> actually didn't merge the files, instead it thinks that the file is up
> to date, but when I do a diff I see that the local file is different
> to the repository version, when I do a commit then my version
> overwrites his changes!
> That behaviour has already caused some hard to track bugs. So I wanted
> to know whether this is a settings that can be changed in Tortoise
> 1.5.0 or if this is actually a bug.
> Related to this we also had the case in the past where rarely Tortoise
> (then still in version 1.3.2) said that the working copy is up to
> date, but some files again were not merged correctly and some changes
> were not put into the local version. After a commit one programmer
> would then have overwritten some changes from another colleague with
> the old version.
> Any help would be greatly appreciated as people start to lose their trust in SVN
Subversion 1.5 introduced a new feature where an update would *not* fail
if an unversioned file is in the way of a new file the update has to
add. It now simply merges the file (or creates a conflict if merging is
not possible). That's the desired behaviour and we won't change this in
The problem you described is not really a problem with Subversion or
TSVN, it's a clear problem with your team communication. Two people
creating the same file at the same time indicates that clearly.
Also, it's not TSVN/Subversions fault if you don't check your changes
before you commit them: your previously unversioned file clearly shows
its 'modified' status - it you don't check what those modifications are
you will of course run into problems. But you will also run into the
very same problems if you modify a file and someone else modifies the
same file and then you do an update - that file will also get merged.
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-07-21 09:23:55 CEST