Hi Rob,
To test Peter's theory please try merging using --ignore-ancestry.
If the merge works as expected, then Peter's theory is correct and you
have an "evil twin".
Thanks
Lakshman
-----Original Message-----
From: Peter Parker [mailto:svn_at_yogasurftech.de]
Sent: Friday, 9 October 2009 10:25 AM
To: Rob Hubbard
Cc: users_at_subversion.tigris.org
Subject: Re: SVN bug? merge replaces all files in an added directory
Rob Hubbard wrote:
> Hello,
>
> I have seen some odd behaviour in our source code repository. I have
> tried to write a script to demonstrate the problem, but have been
> unable to do so; my script always seems to produce the expected
result.
> Therefore, unfortunately, I do not know exactly what circumstances
> lead to this problem; there is something happening on our main server
> that I'm not doing in my test scripts (on a locally created
> repository). I'm sorry that I have been unable to determine what that
difference is.
>
> The symptoms are that in a merge operation, when a directory has been
> added in the source of the merge, every file within the directory is
> replaced in the target.
>
> Therefore, when the log of the committed merged revision is viewed,
> rather than a simple
>
> A branch/directory (from /trunk/directory:1234)
>
> you see
>
> A branch/directory (from /trunk/directory:1234)
> R branch/directory/file1.txt (from
> /trunk/directory/file1.txt:1234)
> R branch/directory/file2.txt (from
> /trunk/directory/file2.txt:1234)
> R branch/directory/file3.txt (from
> /trunk/directory/file3.txt:1234)
> ...
>
> I don't think this always happens.
>
> I have tried experimenting with changes to the svn:eol-style, as I
> suspected the problem might be to do with changes to that property. [I
> believe that when this property is set, linefeeds are represented as
> LF, so when a Windoze-style text file has the property set, even to
> 'CRLF', every line in the file changes, but the changes are
> 'unimportant'.] I thought that perhaps this property was changing
> independently of the file content. However, that did not appear to be
the case after all:
> even with deliberate property changes I could not reproduce this
> problem.
>
> The SVN clients are version 1.6.5, server version 1.6.4. I'm not sure
> what version the repository itself is, but it has ./format=3,
> ./db/format=1, ./db/fs-type=fsfs; is that a 1.3 structure? Could that
> be relevant?
>
> Other members of the team are using 1.6.x clients. It is possible that
> some 1.5.x clients are in use, but I don't think so. This is all
> running on Windows XP SP3 with the repository on Windows 2003 SP1.
>
> Has anyone else seen this behaviour, or know why it happens?
> Could it be due to some kind of user error?
>
> This is not a major problem, but I would like to understand what is
> going on.
>
> If anyone could offer even just clues or untested suggestions I would
> very much appreciate it.
>
> (Please CC me on any replies.)
>
> Many thanks,
> Rob.
Hi Rob,
I have experienced similar problems on a customers repository:
It turns out that another branch had merged the directory before so
subversion thought to replace the files and not to merge.
I try to do some ascii art to visualize the info-flow:
adding dir "test" into branch
|
v
branch 1: ------*--->
/ \
trunk :---------------1-----2->
\ \ /
branch 2: ---------*--
|
adding dir "test to other branch (maybe merged from branch
1?)
1: here test will be added for the first time
2: here test will be replaced
Maybe you can try to set this up as a test to see if this reproduces
your problems..
Also check carefully the creations of a file or directory and look into
the repository in these particular revisions (TSVN repo-browser helps a
lot!).
Best regards,
Peter
PS:
are you the C64-musician Rob Hubbard? if yes: Hail to the chief(just
listening slay radio), if no: damn good name ;-)
>
> ________________________________________________________________
> This message has been independently scanned for the Softel Group and
cleared of containing viruses and other malicious data.
>
> Powering Television Beyond the Video (TM)
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessag
> eId=2404416
>
> To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2405370
To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405402
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-09 04:48:32 CEST