[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Failed to add 'XXX': object of the same name already already exists not working on Tortoise 1.5.0

From: Boldt Sven <Sven.Boldt_at_Micronas.com>
Date: Mon, 21 Jul 2008 09:23:34 +0200

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?

Gruss regards
Sven Boldt

Micronas GmbH
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.

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
Sent: 18 July 2008 16:09
To: users_at_tortoisesvn.tigris.org
Subject: Re: Failed to add 'XXX': object of the same name already already exists not working on Tortoise 1.5.0

Gottfried Chen wrote:
> Hi,
> 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

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.