You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rob Hubbard <ro...@softel.co.uk> on 2009/10/07 08:41:03 UTC
SVN bug? merge replaces all files in an added directory
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.
________________________________________________________________
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&dsMessageId=2404416
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: SVN bug? merge replaces all files in an added directory
Posted by Rob Hubbard <ro...@softel.co.uk>.
Hello Peter,
Thanks very much for the reply and the ideas.
Please continue to CC me on any further replies.
> 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
I can see how the above could give rise to such similar problems. That's
not the situation I have, however. I think mine is even simpler. In your
case, the behaviour I would expect to see (if the software is working
correctly) is
R branch2/test (from /trunk/test:1234)
whereas in my situation, I am expecting to see
A branch/test (from /trunk/test:1234)
There is no second branch involved in my case.
> 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
As you suggested, I took a closer look at what's happening at the
revisions in question.
As far as I can tell, here are the key steps:
(1) a branch is created from the trunk
(2) a directory of files is moved in the trunk
(3) the trunk is merged to the branch
However, I have tried this in a test script, and I still get correct
results (i.e. no superfluous file replacements).
Unfortunately, there is a lot of activity on the repository, and the
history is quite hard to follow. It is possible I have missed something
significant.
I have also tried merging with and without the --ignore-ancestry option
(as suggested by Lakshman), but have not seen the symptoms I'm trying to
reproduce either way.
Again, it could be a problem with different versions of
server/repository/client... but I have limited time to spend
experimenting with such things. At the moment it's just a matter of
curiosity. I'd like to understand why this is happening. I expect the
SVN developers would like to know too, in order to fix any problem. This
is not stopping me getting on with my work.
If anyone has any further suggestions or ideas, I'd still be interested
to hear them.
> (TSVN repo-browser helps a lot!).
Yes I use a mixture of SVN and T-SVN, but I usually have to hunt around
more to see how to do something with the latter.
> PS:
> are you the C64-musician Rob Hubbard? if yes: Hail to the chief (just
> listening slay radio), if no: damn good name ;-)
I'm not, but this is not the first time I've been asked the question.
I preferred Acorns to Commodores anyway. :-)
Thanks again for your help (to both Peter and Lakshman).
Kind regards,
Rob.
________________________________________________________________
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&dsMessageId=2405459
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: SVN bug? merge replaces all files in an added directory
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
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@yogasurftech.de]
Sent: Friday, 9 October 2009 10:25 AM
To: Rob Hubbard
Cc: users@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@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2405370
To unsubscribe from this discussion, e-mail:
[users-unsubscribe@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@subversion.tigris.org].
RE: SVN bug? merge replaces all files in an added directory
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
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@yogasurftech.de]
Sent: Friday, 9 October 2009 10:25 AM
To: Rob Hubbard
Cc: users@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@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2405370
To unsubscribe from this discussion, e-mail:
[users-unsubscribe@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@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405657
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: SVN bug? merge replaces all files in an added directory
Posted by Peter Parker <sv...@yogasurftech.de>.
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&dsMessageId=2404416
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405370
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].