On Fri, Oct 28, 2011 at 12:31 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> Here is something I don't understand. You just did a new checkout to
> someotherpath. The HEAD of your repository is at least 648291. How
> come that someotherpath/stepws.xsd is at revision 610503? That doesn't
> make sense.
I'm sorry, I cheated a tiny bit, the merge target was made using "svn
co -r 610503" to get the exact version where we first saw the problem,
that was needed because changes have been made in that branch since we
first saw the problem.
I can assure you the problem is exactly the same as originally
(without -r) and shows up with a clean checkout.
To make it less obscure, you can replace "somepath" with
"/branch/version-2" and "someotherpath" with "/branch/version-1".
In other words, what I'm trying to do is to backport a change from
version-2 to version-1, both version-1 and version-2 were forked off
from trunk.
The extra change in the target file appears the change just before the
wanted change in the source file (iow: it appears that the svn merge
command did what I would have expected if I had used svn merge -c
625829,648291 ... in stead of svn merge -c 648291 ...):
svn diff -c 625829 svn+ssh://myserver/somepath/stepws.xsd
Index: stepws.xsd
===================================================================
--- stepws.xsd (revision 625828)
+++ stepws.xsd (revision 625829)
@@ -366,6 +366,42 @@
</complexType>
<element name="getLOVValueIDsResponse"
type="tns:getLOVValueIDsResponseType"/>
+ <!-- addLOVValueIDs -->
+
+ <complexType name="addLOVValueIDsRequestType">
+ <sequence>
+ <element name="accessContext" type="types:accessContext">
+ <annotation>
+ <documentation>username and password for the user
to access STEP as, and the URLs of the context and
+ workspace to access data through.
+ </documentation>
+ </annotation>
+ </element>
+ <element name="nodeURL" type="string">
+ <annotation>
+ <documentation>URL of the LOV to obtain values
from</documentation>
+ </annotation>
+ </element>
+ <element name="add" type="types:lovvalueid" minOccurs="1"
maxOccurs="unbounded">
+ <annotation>
+ <documentation>The list of LOV values to
add</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsRequest"
type="tns:addLOVValueIDsRequestType"/>
+
+ <complexType name="addLOVValueIDsResponseType">
+ <sequence>
+ <element name="values" type="types:lovvalueid"
minOccurs="0" maxOccurs="unbounded">
+ <annotation>
+ <documentation>The new list of LOV values</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsResponse"
type="tns:addLOVValueIDsResponseType"/>
+
<!-- getValuesByAttributeIds -->
<complexType name="getValuesByAttributeIdsRequestType">
> Are you sure that the merge target (someotherpath) was a clean
> checkout, with nothing locally modified?
Absolutely.
> The only explanation (short of a bug in 'merge') I can come up with
> for this behavior, is if someotherpath/stepws.xsd was already modified
> in the working copy (already containing those extra added lines that
> suddenly seemed to appear here).
It did not, it's a completely clean checkout, done from scratch.
This is not the only time I've seen the problem manifest, but the
circumstances where similar, in the other case another developer was
trying to merge a change from version-1 to version-2, he too got extra
changes in his merge target.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Received on 2011-10-28 12:50:10 CEST