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

AW: Automatically merge of new binary file.

From: Walser Markus <MarkusWalser_at_schleuniger.ch>
Date: Mon, 10 May 2010 14:56:15 +0200

Hi Bert

Sorry I forgot this important information:

It was Tortoise 1.6.8 Build 19260 (SVN 1.6.11).

Regards,

Markus

-----Ursprüngliche Nachricht-----
Von: Bert Huijben [mailto:bert_at_qqmail.nl]
Gesendet: Montag, 10. Mai 2010 14:53
An: Walser Markus; users_at_subversion.apache.org
Betreff: RE: Automatically merge of new binary file.

> -----Original Message-----
> From: Walser Markus [mailto:MarkusWalser_at_schleuniger.ch]
> Sent: maandag 10 mei 2010 14:25
> To: users_at_subversion.apache.org
> Subject: Automatically merge of new binary file.
>
> Hi
>
> Recently I ran into following subversion use case:
>
> 1. A new binary file was created in a working copy 1 and *not* added:
> e.g. C:\Test\WorkingCopy1\BinaryFile.pdf
>
> 2. In another working copy 2 of the same repo another binary file with
> the same filename but different content was created and added:
> e.g. C:\TestWorkingCopy2\BinaryFile.pdf. Thereby SVN correctly set
> the mime type to octet.
>
> 3. The newly added file was committed in working copy 2.
>
> 4. Working copy 1 is updated.
>
>
> What happens is that SVN reports successful merging of BinaryFile.pdf.
>
> I'd rather expected a conflict with the local BinaryFile.pdf instead
> of trying to merge the binary file.
>
> Is that binary merging behavior as designed or a know bug?

Which client did you use? (And which version)

TortoiseSVN always uses "svn update --force" (taking unversioned obstructions as the new version of the same file) so this would give this behavior.

        Bert
Received on 2010-05-10 14:56:48 CEST

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

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