You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2011/12/24 14:06:16 UTC
Re: [math] Strange svn conflict
Hi,
I wrote to infrastructure@ yesterday about problems we are currently
facing with SVN at Commons-Math. Daniel answered, but I forgot to keep
the infrastructure@ mailing list copied, so it's probably best to
start afresh.
At least two of us at Commons-Math have been confronted to conflicts
while trying to commit new patches. Here is a
typical example of the message I recently got while trying to commit a patch
{code}
Merge conflict during commit
svn: Commit failed (details follow):
svn: File or directory
'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
is out of date; try updating
svn: resource out of date; try updating
{code}
I've tried the obvious: svn clean, followed by svn update... no
success. Then, I found on the internet that the file .svn/all-wcprops
should be removed, but that didn't work either. More radically, I've
just removed my local copy of the math project, and checked out a
brand new one, applied my patch, and tried to commit it... same answer
from svn.
Gilles Sadowski went through exactly the same problem (and tried
exactly the same tricks) a few weeks ago, with no more success. The
problem was solved when Phil Steitz performed some changes on the
incriminated files.
It has been suggested on the dev mailing list that this might have
something to do with bad synchronization between different
repositories. Yesterday, Daniel was very doubtful about that, and
suggested we run svn info on the file causing the conflict, for both
US/EU mirrors. He also wrote that running `svn info` actually forced
some kind of synchronization between both mirrors (or so I
understood). So I ran `svn info`, then tried again to commit, but that
did not work either.
Here is what `svn info` returns
US MIRROR
Path: BinomialDistribution.java
Name: BinomialDistribution.java
URL: http://svn.us.apache.org/repos/asf/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
Repository Root: http://svn.us.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1222933
Node Kind: file
Last Changed Author: celestin
Last Changed Rev: 1210359
Last Changed Date: 2011-12-05 09:15:38 +0100 (Lun, 05 déc 2011)
EU MIRROR
Path: BinomialDistribution.java
Name: BinomialDistribution.java
URL: http://svn.eu.apache.org/repos/asf/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
Repository Root: http://svn.eu.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1222933
Node Kind: file
Last Changed Author: celestin
Last Changed Rev: 1209963
Last Changed Date: 2011-12-03 19:23:02 +0100 (Sam, 03 déc 2011)
It seems strange that the 'Last Changed Rev' fields should be
different for each mirror. Could that be the origin of our troubles?
Thanks a lot in advance for your help, and a very merry Christmas to you!
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
> > - Server. Does the error reproduce if you check out your working copy
> > from svn-master.apache.org? (If you literally check out from
> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> > you can either bypass them or set
> > # 140.211.11.4 svn.apache.org
> > in your /etc/hosts file)
> >
> Just for the record, the above tests were carried out with the
> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
> As I'm in Europe, I suppose the EU mirror was used (is there a way to
> check?). I've tried to commit the same patch to svn-master. For some
> reasons, I get many error messages with subclipse. For lack of time, I
> therefore only tested the command-line client. It WORKED!!! See rev
> 1225839, and 1225841.
I'd like to underline something here: if any operation whatsoever works
using the cmdline client but doesn't work (at the same circumstances)
using another client (Java-based or otherwise), that's a bug.
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Le 30 décembre 2011 23:30, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
> Sébastien Brisard wrote on Fri, Dec 30, 2011 at 16:24:38 +0100:
>> Hi,
>> sorry for the delay. I have carried out a few more experiments (see below).
>> Sébastien
>>
>> >> >> Should I move to svn 1.7 ?
>> >> >>
>> >> >
>> >> > You could try moving to 1.7, and/or using the official JavaHL bindings
>> >> > instead of the third-party SVNKit implementation. With my svn hat on,
>> >> > though, I'd like to figure out how those revisions with bogus 'log -qv'
>> >> > output were created, and if you have the time to provide a self-contained
>> >> > reproduction recipe (starting with 'svnadmin create', and svn and/or
>> >> > eclipse) we'd appreciate it.
>> >> >
>> >> I'll try my best to do that.
>> >>
>> >
>> > Thanks.
>> >
>> I'm very willing to try, but I'm not sure I really understand (please
>> excuse my very shallow knowledge of SVN...).
>>
>
> See https://subversion.apache.org/docs/community-guide/repro-template.sh
>
>> >
>> > Can you isolate the following factors:
>> >
>> > - Size of the patch. Can you commit a smaller patch --- that touches
>> > all the same files your patch does? A smaller patch that touches
>> > other files?
>> >
>>
>> As I'm not sure this mailing list allow for attachment, I've
>> copied/pasted a very small patch which does demonstrate the bug (at
>> least, on my computer).
>>
>>
>> *****BEGIN PATCH*****
>> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
>> 1225833)
> ... snip one-line patch ...
>> *****END PATCH*****
>>
>> I've tried to commit this patch
>> 1. with eclipse + JavaHL client, this raises the same error as before
>>
>> *****BEGIN ERROR-MESSAGE*****
>> svn: Commit failed (details follow):
>> svn: File or directory 'BinomialDistribution.java' is out of date; try updating
>> svn: resource out of date; try updating
>> *****END ERROR-MESSAGE*****
>>
>> 2. with eclipse + SVNKit client: same story
>> 3. with command-line svn: same story
>>
>
> OK
>
>> >
>> > - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
>> > (b) eclipse with Subversion's official JavaHL bindings, (c) the
>> > cmdline client?
>> >
>> See above. Just curious: how do you force JavaHL or SVNKit client with
>> cmdline? Is this a silly question?
>>
>
> It's silly :P. SVNKit is a third-party full Java implementation; the
> JavaHL libraries and the cmdline client are both thin wrappers around
> the C libraries.
>
>> >
>> > - Server. Does the error reproduce if you check out your working copy
>> > from svn-master.apache.org? (If you literally check out from
>> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
>> > you can either bypass them or set
>> > # 140.211.11.4 svn.apache.org
>> > in your /etc/hosts file)
>> >
>> Just for the record, the above tests were carried out with the
>> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
>> As I'm in Europe, I suppose the EU mirror was used (is there a way to
>> check?).
>
> What IP does svn.apache.org resolve to for you?
>
> % host svn.eu.apache.org
> svn.eu.apache.org has address 192.87.106.227
> svn.eu.apache.org has IPv6 address 2001:610:1:80bc:192:87:106:227
> % host svn.us.apache.org
> svn.us.apache.org has address 140.211.11.4
> % host svn-master.apache.org
> svn-master.apache.org has address 140.211.11.4
>
Here is what I get
$ host svn.apache.org
svn.apache.org is an alias for svn.geo.apache.org.
svn.geo.apache.org has address 192.87.106.227
>> I've tried to commit the same patch to svn-master. For some
>> reasons, I get many error messages with subclipse. For lack of time, I
>> therefore only tested the command-line client. It WORKED!!! See rev
>> 1225839, and 1225841.
>>
>
> The diff seems to be identical between the two mirrors:
>
> % for i in eris harmonia; do svn diff http://$i.apache.org/repos/asf/commons -c 1225839 | sha1sum ; done
> 3730c3ef8fdd6778da568339d90ea7a99b55e886 -
> 3730c3ef8fdd6778da568339d90ea7a99b55e886 -
>
>> As previously mentioned, Gilles already encountered the same
>> difficulty, and the problem was only solved when Phil managed to
>> successfully commit a dummy patch to the incriminated file. So now
>> that the patch was accepted, I tried to commit to
>> https://svn.apache.org/repos/asf/commons/proper/math/trunk the
>> following patch
>>
>> *****BEGIN PATCH*****
>> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
>> 1225842)
> ... snip one-line patch ...
>> *****END PATCH*****
>>
>> It WORKED !!!
>>
>> - r1225843 used subclipse + JavaHL,
>> - r1225844 used subclipse + SVNKit.
>>
>
> So, to summarize: you failed to commit a one-line change to
> BinomialDistribution via the US master regardless of what client you
> used, was able to commit it via the EU mirror with the cmdline client
> (but haven't tested with subclipse), and subsequently to the successful
> commit you could commit another trivial change to the same file with
> both eclipse/JavaHL and eclipse/SVNKit.
>
No, that's not exactly what happened. I failed to commit a one-line
change to BinomialDistribution via eiher US or EU mirror regardless of
what svn client I used. I was able to commit this change via the
svn-master server with the cmdline client. I could then commit another
trivial change to the same file, on any mirror, with any client.
>
> I'm a bit confused as to which combinations exactly do/don't work here,
> but I would guess that the differing 'Last Changed Revision' values
> between the two mirrors cause spurious out-of-date errors. I don't know
> if you checked out fresh working copies from each mirror, but if you
> didn't then it may have contributed to the confusion/disagreements.
>
For the sake of our tests, I did check out fresh working copies.
>
> The fix would be, then, firstly to avoid creating a disparity in the
> changes ('log -qv' and 'svn info | grep "^Last Changed Revision"')
> between the two mirrors --- preferably by preventing null-changes from
> being created in revisions on the master[1], alternatively by faithfully
> reproducing them --- and secondly, to see what can be done about
> "existing in the wild" instances of this bug.
>
Please note that the null-changes you're referring to were committed
by myself, to svn.apache.org, therefore svn.geo.apache.org, *not*
svn-master.
>
> I've filed issue #4090 to track this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4090
>
> [1] which is where the reproduction recipe requested above comes in
>
>> Does all that help?
>
> Yes, it does; thanks a lot. So far I identify at least one concrete
> bug; if there are further problems here, we'll open further issues as
> needed.
>
>> Can I try and commit the longer patch that
>> initially was the cause of this thread, or should I wait for you to
>> explore in more detail this issue?
>>
>
> No, go ahead and commit it please. You should be able to do so to
> one of the two mirrors.
>
>> Best regards, thanks again for your help!
>> Sébastien
>
> Cheers, happy new year,
>
> Daniel
>
Happy new Year to you too, and thanks again for your help!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Le 30 décembre 2011 23:30, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
> Sébastien Brisard wrote on Fri, Dec 30, 2011 at 16:24:38 +0100:
>> Hi,
>> sorry for the delay. I have carried out a few more experiments (see below).
>> Sébastien
>>
>> >> >> Should I move to svn 1.7 ?
>> >> >>
>> >> >
>> >> > You could try moving to 1.7, and/or using the official JavaHL bindings
>> >> > instead of the third-party SVNKit implementation. With my svn hat on,
>> >> > though, I'd like to figure out how those revisions with bogus 'log -qv'
>> >> > output were created, and if you have the time to provide a self-contained
>> >> > reproduction recipe (starting with 'svnadmin create', and svn and/or
>> >> > eclipse) we'd appreciate it.
>> >> >
>> >> I'll try my best to do that.
>> >>
>> >
>> > Thanks.
>> >
>> I'm very willing to try, but I'm not sure I really understand (please
>> excuse my very shallow knowledge of SVN...).
>>
>
> See https://subversion.apache.org/docs/community-guide/repro-template.sh
>
>> >
>> > Can you isolate the following factors:
>> >
>> > - Size of the patch. Can you commit a smaller patch --- that touches
>> > all the same files your patch does? A smaller patch that touches
>> > other files?
>> >
>>
>> As I'm not sure this mailing list allow for attachment, I've
>> copied/pasted a very small patch which does demonstrate the bug (at
>> least, on my computer).
>>
>>
>> *****BEGIN PATCH*****
>> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
>> 1225833)
> ... snip one-line patch ...
>> *****END PATCH*****
>>
>> I've tried to commit this patch
>> 1. with eclipse + JavaHL client, this raises the same error as before
>>
>> *****BEGIN ERROR-MESSAGE*****
>> svn: Commit failed (details follow):
>> svn: File or directory 'BinomialDistribution.java' is out of date; try updating
>> svn: resource out of date; try updating
>> *****END ERROR-MESSAGE*****
>>
>> 2. with eclipse + SVNKit client: same story
>> 3. with command-line svn: same story
>>
>
> OK
>
>> >
>> > - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
>> > (b) eclipse with Subversion's official JavaHL bindings, (c) the
>> > cmdline client?
>> >
>> See above. Just curious: how do you force JavaHL or SVNKit client with
>> cmdline? Is this a silly question?
>>
>
> It's silly :P. SVNKit is a third-party full Java implementation; the
> JavaHL libraries and the cmdline client are both thin wrappers around
> the C libraries.
>
>> >
>> > - Server. Does the error reproduce if you check out your working copy
>> > from svn-master.apache.org? (If you literally check out from
>> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
>> > you can either bypass them or set
>> > # 140.211.11.4 svn.apache.org
>> > in your /etc/hosts file)
>> >
>> Just for the record, the above tests were carried out with the
>> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
>> As I'm in Europe, I suppose the EU mirror was used (is there a way to
>> check?).
>
> What IP does svn.apache.org resolve to for you?
>
> % host svn.eu.apache.org
> svn.eu.apache.org has address 192.87.106.227
> svn.eu.apache.org has IPv6 address 2001:610:1:80bc:192:87:106:227
> % host svn.us.apache.org
> svn.us.apache.org has address 140.211.11.4
> % host svn-master.apache.org
> svn-master.apache.org has address 140.211.11.4
>
Here is what I get
$ host svn.apache.org
svn.apache.org is an alias for svn.geo.apache.org.
svn.geo.apache.org has address 192.87.106.227
>> I've tried to commit the same patch to svn-master. For some
>> reasons, I get many error messages with subclipse. For lack of time, I
>> therefore only tested the command-line client. It WORKED!!! See rev
>> 1225839, and 1225841.
>>
>
> The diff seems to be identical between the two mirrors:
>
> % for i in eris harmonia; do svn diff http://$i.apache.org/repos/asf/commons -c 1225839 | sha1sum ; done
> 3730c3ef8fdd6778da568339d90ea7a99b55e886 -
> 3730c3ef8fdd6778da568339d90ea7a99b55e886 -
>
>> As previously mentioned, Gilles already encountered the same
>> difficulty, and the problem was only solved when Phil managed to
>> successfully commit a dummy patch to the incriminated file. So now
>> that the patch was accepted, I tried to commit to
>> https://svn.apache.org/repos/asf/commons/proper/math/trunk the
>> following patch
>>
>> *****BEGIN PATCH*****
>> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
>> 1225842)
> ... snip one-line patch ...
>> *****END PATCH*****
>>
>> It WORKED !!!
>>
>> - r1225843 used subclipse + JavaHL,
>> - r1225844 used subclipse + SVNKit.
>>
>
> So, to summarize: you failed to commit a one-line change to
> BinomialDistribution via the US master regardless of what client you
> used, was able to commit it via the EU mirror with the cmdline client
> (but haven't tested with subclipse), and subsequently to the successful
> commit you could commit another trivial change to the same file with
> both eclipse/JavaHL and eclipse/SVNKit.
>
No, that's not exactly what happened. I failed to commit a one-line
change to BinomialDistribution via eiher US or EU mirror regardless of
what svn client I used. I was able to commit this change via the
svn-master server with the cmdline client. I could then commit another
trivial change to the same file, on any mirror, with any client.
>
> I'm a bit confused as to which combinations exactly do/don't work here,
> but I would guess that the differing 'Last Changed Revision' values
> between the two mirrors cause spurious out-of-date errors. I don't know
> if you checked out fresh working copies from each mirror, but if you
> didn't then it may have contributed to the confusion/disagreements.
>
For the sake of our tests, I did check out fresh working copies.
>
> The fix would be, then, firstly to avoid creating a disparity in the
> changes ('log -qv' and 'svn info | grep "^Last Changed Revision"')
> between the two mirrors --- preferably by preventing null-changes from
> being created in revisions on the master[1], alternatively by faithfully
> reproducing them --- and secondly, to see what can be done about
> "existing in the wild" instances of this bug.
>
Please note that the null-changes you're referring to were committed
by myself, to svn.apache.org, therefore svn.geo.apache.org, *not*
svn-master.
>
> I've filed issue #4090 to track this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4090
>
> [1] which is where the reproduction recipe requested above comes in
>
>> Does all that help?
>
> Yes, it does; thanks a lot. So far I identify at least one concrete
> bug; if there are further problems here, we'll open further issues as
> needed.
>
>> Can I try and commit the longer patch that
>> initially was the cause of this thread, or should I wait for you to
>> explore in more detail this issue?
>>
>
> No, go ahead and commit it please. You should be able to do so to
> one of the two mirrors.
>
>> Best regards, thanks again for your help!
>> Sébastien
>
> Cheers, happy new year,
>
> Daniel
>
Happy new Year to you too, and thanks again for your help!
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sébastien Brisard wrote on Fri, Dec 30, 2011 at 16:24:38 +0100:
> Hi,
> sorry for the delay. I have carried out a few more experiments (see below).
> Sébastien
>
> >> >> Should I move to svn 1.7 ?
> >> >>
> >> >
> >> > You could try moving to 1.7, and/or using the official JavaHL bindings
> >> > instead of the third-party SVNKit implementation. With my svn hat on,
> >> > though, I'd like to figure out how those revisions with bogus 'log -qv'
> >> > output were created, and if you have the time to provide a self-contained
> >> > reproduction recipe (starting with 'svnadmin create', and svn and/or
> >> > eclipse) we'd appreciate it.
> >> >
> >> I'll try my best to do that.
> >>
> >
> > Thanks.
> >
> I'm very willing to try, but I'm not sure I really understand (please
> excuse my very shallow knowledge of SVN...).
>
See https://subversion.apache.org/docs/community-guide/repro-template.sh
> >
> > Can you isolate the following factors:
> >
> > - Size of the patch. Can you commit a smaller patch --- that touches
> > all the same files your patch does? A smaller patch that touches
> > other files?
> >
>
> As I'm not sure this mailing list allow for attachment, I've
> copied/pasted a very small patch which does demonstrate the bug (at
> least, on my computer).
>
>
> *****BEGIN PATCH*****
> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
> 1225833)
... snip one-line patch ...
> *****END PATCH*****
>
> I've tried to commit this patch
> 1. with eclipse + JavaHL client, this raises the same error as before
>
> *****BEGIN ERROR-MESSAGE*****
> svn: Commit failed (details follow):
> svn: File or directory 'BinomialDistribution.java' is out of date; try updating
> svn: resource out of date; try updating
> *****END ERROR-MESSAGE*****
>
> 2. with eclipse + SVNKit client: same story
> 3. with command-line svn: same story
>
OK
> >
> > - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
> > (b) eclipse with Subversion's official JavaHL bindings, (c) the
> > cmdline client?
> >
> See above. Just curious: how do you force JavaHL or SVNKit client with
> cmdline? Is this a silly question?
>
It's silly :P. SVNKit is a third-party full Java implementation; the
JavaHL libraries and the cmdline client are both thin wrappers around
the C libraries.
> >
> > - Server. Does the error reproduce if you check out your working copy
> > from svn-master.apache.org? (If you literally check out from
> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> > you can either bypass them or set
> > # 140.211.11.4 svn.apache.org
> > in your /etc/hosts file)
> >
> Just for the record, the above tests were carried out with the
> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
> As I'm in Europe, I suppose the EU mirror was used (is there a way to
> check?).
What IP does svn.apache.org resolve to for you?
% host svn.eu.apache.org
svn.eu.apache.org has address 192.87.106.227
svn.eu.apache.org has IPv6 address 2001:610:1:80bc:192:87:106:227
% host svn.us.apache.org
svn.us.apache.org has address 140.211.11.4
% host svn-master.apache.org
svn-master.apache.org has address 140.211.11.4
> I've tried to commit the same patch to svn-master. For some
> reasons, I get many error messages with subclipse. For lack of time, I
> therefore only tested the command-line client. It WORKED!!! See rev
> 1225839, and 1225841.
>
The diff seems to be identical between the two mirrors:
% for i in eris harmonia; do svn diff http://$i.apache.org/repos/asf/commons -c 1225839 | sha1sum ; done
3730c3ef8fdd6778da568339d90ea7a99b55e886 -
3730c3ef8fdd6778da568339d90ea7a99b55e886 -
> As previously mentioned, Gilles already encountered the same
> difficulty, and the problem was only solved when Phil managed to
> successfully commit a dummy patch to the incriminated file. So now
> that the patch was accepted, I tried to commit to
> https://svn.apache.org/repos/asf/commons/proper/math/trunk the
> following patch
>
> *****BEGIN PATCH*****
> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
> 1225842)
... snip one-line patch ...
> *****END PATCH*****
>
> It WORKED !!!
>
> - r1225843 used subclipse + JavaHL,
> - r1225844 used subclipse + SVNKit.
>
So, to summarize: you failed to commit a one-line change to
BinomialDistribution via the US master regardless of what client you
used, was able to commit it via the EU mirror with the cmdline client
(but haven't tested with subclipse), and subsequently to the successful
commit you could commit another trivial change to the same file with
both eclipse/JavaHL and eclipse/SVNKit.
I'm a bit confused as to which combinations exactly do/don't work here,
but I would guess that the differing 'Last Changed Revision' values
between the two mirrors cause spurious out-of-date errors. I don't know
if you checked out fresh working copies from each mirror, but if you
didn't then it may have contributed to the confusion/disagreements.
The fix would be, then, firstly to avoid creating a disparity in the
changes ('log -qv' and 'svn info | grep "^Last Changed Revision"')
between the two mirrors --- preferably by preventing null-changes from
being created in revisions on the master[1], alternatively by faithfully
reproducing them --- and secondly, to see what can be done about
"existing in the wild" instances of this bug.
I've filed issue #4090 to track this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4090
[1] which is where the reproduction recipe requested above comes in
> Does all that help?
Yes, it does; thanks a lot. So far I identify at least one concrete
bug; if there are further problems here, we'll open further issues as
needed.
> Can I try and commit the longer patch that
> initially was the cause of this thread, or should I wait for you to
> explore in more detail this issue?
>
No, go ahead and commit it please. You should be able to do so to
one of the two mirrors.
> Best regards, thanks again for your help!
> Sébastien
Cheers, happy new year,
Daniel
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sébastien Brisard wrote on Fri, Dec 30, 2011 at 16:24:38 +0100:
> Hi,
> sorry for the delay. I have carried out a few more experiments (see below).
> Sébastien
>
> >> >> Should I move to svn 1.7 ?
> >> >>
> >> >
> >> > You could try moving to 1.7, and/or using the official JavaHL bindings
> >> > instead of the third-party SVNKit implementation. With my svn hat on,
> >> > though, I'd like to figure out how those revisions with bogus 'log -qv'
> >> > output were created, and if you have the time to provide a self-contained
> >> > reproduction recipe (starting with 'svnadmin create', and svn and/or
> >> > eclipse) we'd appreciate it.
> >> >
> >> I'll try my best to do that.
> >>
> >
> > Thanks.
> >
> I'm very willing to try, but I'm not sure I really understand (please
> excuse my very shallow knowledge of SVN...).
>
See https://subversion.apache.org/docs/community-guide/repro-template.sh
> >
> > Can you isolate the following factors:
> >
> > - Size of the patch. Can you commit a smaller patch --- that touches
> > all the same files your patch does? A smaller patch that touches
> > other files?
> >
>
> As I'm not sure this mailing list allow for attachment, I've
> copied/pasted a very small patch which does demonstrate the bug (at
> least, on my computer).
>
>
> *****BEGIN PATCH*****
> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
> 1225833)
... snip one-line patch ...
> *****END PATCH*****
>
> I've tried to commit this patch
> 1. with eclipse + JavaHL client, this raises the same error as before
>
> *****BEGIN ERROR-MESSAGE*****
> svn: Commit failed (details follow):
> svn: File or directory 'BinomialDistribution.java' is out of date; try updating
> svn: resource out of date; try updating
> *****END ERROR-MESSAGE*****
>
> 2. with eclipse + SVNKit client: same story
> 3. with command-line svn: same story
>
OK
> >
> > - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
> > (b) eclipse with Subversion's official JavaHL bindings, (c) the
> > cmdline client?
> >
> See above. Just curious: how do you force JavaHL or SVNKit client with
> cmdline? Is this a silly question?
>
It's silly :P. SVNKit is a third-party full Java implementation; the
JavaHL libraries and the cmdline client are both thin wrappers around
the C libraries.
> >
> > - Server. Does the error reproduce if you check out your working copy
> > from svn-master.apache.org? (If you literally check out from
> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> > you can either bypass them or set
> > # 140.211.11.4 svn.apache.org
> > in your /etc/hosts file)
> >
> Just for the record, the above tests were carried out with the
> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
> As I'm in Europe, I suppose the EU mirror was used (is there a way to
> check?).
What IP does svn.apache.org resolve to for you?
% host svn.eu.apache.org
svn.eu.apache.org has address 192.87.106.227
svn.eu.apache.org has IPv6 address 2001:610:1:80bc:192:87:106:227
% host svn.us.apache.org
svn.us.apache.org has address 140.211.11.4
% host svn-master.apache.org
svn-master.apache.org has address 140.211.11.4
> I've tried to commit the same patch to svn-master. For some
> reasons, I get many error messages with subclipse. For lack of time, I
> therefore only tested the command-line client. It WORKED!!! See rev
> 1225839, and 1225841.
>
The diff seems to be identical between the two mirrors:
% for i in eris harmonia; do svn diff http://$i.apache.org/repos/asf/commons -c 1225839 | sha1sum ; done
3730c3ef8fdd6778da568339d90ea7a99b55e886 -
3730c3ef8fdd6778da568339d90ea7a99b55e886 -
> As previously mentioned, Gilles already encountered the same
> difficulty, and the problem was only solved when Phil managed to
> successfully commit a dummy patch to the incriminated file. So now
> that the patch was accepted, I tried to commit to
> https://svn.apache.org/repos/asf/commons/proper/math/trunk the
> following patch
>
> *****BEGIN PATCH*****
> --- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
> 1225842)
... snip one-line patch ...
> *****END PATCH*****
>
> It WORKED !!!
>
> - r1225843 used subclipse + JavaHL,
> - r1225844 used subclipse + SVNKit.
>
So, to summarize: you failed to commit a one-line change to
BinomialDistribution via the US master regardless of what client you
used, was able to commit it via the EU mirror with the cmdline client
(but haven't tested with subclipse), and subsequently to the successful
commit you could commit another trivial change to the same file with
both eclipse/JavaHL and eclipse/SVNKit.
I'm a bit confused as to which combinations exactly do/don't work here,
but I would guess that the differing 'Last Changed Revision' values
between the two mirrors cause spurious out-of-date errors. I don't know
if you checked out fresh working copies from each mirror, but if you
didn't then it may have contributed to the confusion/disagreements.
The fix would be, then, firstly to avoid creating a disparity in the
changes ('log -qv' and 'svn info | grep "^Last Changed Revision"')
between the two mirrors --- preferably by preventing null-changes from
being created in revisions on the master[1], alternatively by faithfully
reproducing them --- and secondly, to see what can be done about
"existing in the wild" instances of this bug.
I've filed issue #4090 to track this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4090
[1] which is where the reproduction recipe requested above comes in
> Does all that help?
Yes, it does; thanks a lot. So far I identify at least one concrete
bug; if there are further problems here, we'll open further issues as
needed.
> Can I try and commit the longer patch that
> initially was the cause of this thread, or should I wait for you to
> explore in more detail this issue?
>
No, go ahead and commit it please. You should be able to do so to
one of the two mirrors.
> Best regards, thanks again for your help!
> Sébastien
Cheers, happy new year,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
> > - Server. Does the error reproduce if you check out your working copy
> > from svn-master.apache.org? (If you literally check out from
> > https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> > you can either bypass them or set
> > # 140.211.11.4 svn.apache.org
> > in your /etc/hosts file)
> >
> Just for the record, the above tests were carried out with the
> repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
> As I'm in Europe, I suppose the EU mirror was used (is there a way to
> check?). I've tried to commit the same patch to svn-master. For some
> reasons, I get many error messages with subclipse. For lack of time, I
> therefore only tested the command-line client. It WORKED!!! See rev
> 1225839, and 1225841.
I'd like to underline something here: if any operation whatsoever works
using the cmdline client but doesn't work (at the same circumstances)
using another client (Java-based or otherwise), that's a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
sorry for the delay. I have carried out a few more experiments (see below).
Sébastien
>> >> Should I move to svn 1.7 ?
>> >>
>> >
>> > You could try moving to 1.7, and/or using the official JavaHL bindings
>> > instead of the third-party SVNKit implementation. With my svn hat on,
>> > though, I'd like to figure out how those revisions with bogus 'log -qv'
>> > output were created, and if you have the time to provide a self-contained
>> > reproduction recipe (starting with 'svnadmin create', and svn and/or
>> > eclipse) we'd appreciate it.
>> >
>> I'll try my best to do that.
>>
>
> Thanks.
>
I'm very willing to try, but I'm not sure I really understand (please
excuse my very shallow knowledge of SVN...).
>
> Can you isolate the following factors:
>
> - Size of the patch. Can you commit a smaller patch --- that touches
> all the same files your patch does? A smaller patch that touches
> other files?
>
As I'm not sure this mailing list allow for attachment, I've
copied/pasted a very small patch which does demonstrate the bug (at
least, on my computer).
*****BEGIN PATCH*****
Index: src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
===================================================================
--- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
1225833)
+++ src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(working
copy)
@@ -23,7 +23,7 @@
import org.apache.commons.math.util.FastMath;
/**
- * Implementation of the binomial distribution.
+ * Implementation of the binomial distribution. DUMMY MODIFICATION
*
* @see <a href="http://en.wikipedia.org/wiki/Binomial_distribution">Binomial
distribution (Wikipedia)</a>
* @see <a href="http://mathworld.wolfram.com/BinomialDistribution.html">Binomial
Distribution (MathWorld)</a>
*****END PATCH*****
I've tried to commit this patch
1. with eclipse + JavaHL client, this raises the same error as before
*****BEGIN ERROR-MESSAGE*****
svn: Commit failed (details follow):
svn: File or directory 'BinomialDistribution.java' is out of date; try updating
svn: resource out of date; try updating
*****END ERROR-MESSAGE*****
2. with eclipse + SVNKit client: same story
3. with command-line svn: same story
>
> - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
> (b) eclipse with Subversion's official JavaHL bindings, (c) the
> cmdline client?
>
See above. Just curious: how do you force JavaHL or SVNKit client with
cmdline? Is this a silly question?
>
> - Server. Does the error reproduce if you check out your working copy
> from svn-master.apache.org? (If you literally check out from
> https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> you can either bypass them or set
> # 140.211.11.4 svn.apache.org
> in your /etc/hosts file)
>
Just for the record, the above tests were carried out with the
repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
As I'm in Europe, I suppose the EU mirror was used (is there a way to
check?). I've tried to commit the same patch to svn-master. For some
reasons, I get many error messages with subclipse. For lack of time, I
therefore only tested the command-line client. It WORKED!!! See rev
1225839, and 1225841.
As previously mentioned, Gilles already encountered the same
difficulty, and the problem was only solved when Phil managed to
successfully commit a dummy patch to the incriminated file. So now
that the patch was accepted, I tried to commit to
https://svn.apache.org/repos/asf/commons/proper/math/trunk the
following patch
*****BEGIN PATCH*****
### Eclipse Workspace Patch 1.0
#P Apache Commons Math
Index: src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
===================================================================
--- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
1225842)
+++ src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (working
copy)
@@ -23,7 +23,7 @@
import org.apache.commons.math.util.FastMath;
/**
- * Implementation of the binomial distribution.
+ * Implementation of the binomial distribution. DUMMY MODIFICATION, SECOND TAKE
*
* @see <a href="http://en.wikipedia.org/wiki/Binomial_distribution">Binomial
distribution (Wikipedia)</a>
* @see <a href="http://mathworld.wolfram.com/BinomialDistribution.html">Binomial
Distribution (MathWorld)</a>
*****END PATCH*****
It WORKED !!!
- r1225843 used subclipse + JavaHL,
- r1225844 used subclipse + SVNKit.
Does all that help? Can I try and commit the longer patch that
initially was the cause of this thread, or should I wait for you to
explore in more detail this issue?
Best regards, thanks again for your help!
Sébastien
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
sorry for the delay. I have carried out a few more experiments (see below).
Sébastien
>> >> Should I move to svn 1.7 ?
>> >>
>> >
>> > You could try moving to 1.7, and/or using the official JavaHL bindings
>> > instead of the third-party SVNKit implementation. With my svn hat on,
>> > though, I'd like to figure out how those revisions with bogus 'log -qv'
>> > output were created, and if you have the time to provide a self-contained
>> > reproduction recipe (starting with 'svnadmin create', and svn and/or
>> > eclipse) we'd appreciate it.
>> >
>> I'll try my best to do that.
>>
>
> Thanks.
>
I'm very willing to try, but I'm not sure I really understand (please
excuse my very shallow knowledge of SVN...).
>
> Can you isolate the following factors:
>
> - Size of the patch. Can you commit a smaller patch --- that touches
> all the same files your patch does? A smaller patch that touches
> other files?
>
As I'm not sure this mailing list allow for attachment, I've
copied/pasted a very small patch which does demonstrate the bug (at
least, on my computer).
*****BEGIN PATCH*****
Index: src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
===================================================================
--- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(revision
1225833)
+++ src/main/java/org/apache/commons/math/distribution/BinomialDistribution.jav(working
copy)
@@ -23,7 +23,7 @@
import org.apache.commons.math.util.FastMath;
/**
- * Implementation of the binomial distribution.
+ * Implementation of the binomial distribution. DUMMY MODIFICATION
*
* @see <a href="http://en.wikipedia.org/wiki/Binomial_distribution">Binomial
distribution (Wikipedia)</a>
* @see <a href="http://mathworld.wolfram.com/BinomialDistribution.html">Binomial
Distribution (MathWorld)</a>
*****END PATCH*****
I've tried to commit this patch
1. with eclipse + JavaHL client, this raises the same error as before
*****BEGIN ERROR-MESSAGE*****
svn: Commit failed (details follow):
svn: File or directory 'BinomialDistribution.java' is out of date; try updating
svn: resource out of date; try updating
*****END ERROR-MESSAGE*****
2. with eclipse + SVNKit client: same story
3. with command-line svn: same story
>
> - Client. Can you reproduce the errors using (a) eclipse with SVNKit,
> (b) eclipse with Subversion's official JavaHL bindings, (c) the
> cmdline client?
>
See above. Just curious: how do you force JavaHL or SVNKit client with
cmdline? Is this a silly question?
>
> - Server. Does the error reproduce if you check out your working copy
> from svn-master.apache.org? (If you literally check out from
> https://svn-master.apache.org/repos/asf/... you'll get SSL warnings;
> you can either bypass them or set
> # 140.211.11.4 svn.apache.org
> in your /etc/hosts file)
>
Just for the record, the above tests were carried out with the
repository https://svn.apache.org/repos/asf/commons/proper/math/trunk.
As I'm in Europe, I suppose the EU mirror was used (is there a way to
check?). I've tried to commit the same patch to svn-master. For some
reasons, I get many error messages with subclipse. For lack of time, I
therefore only tested the command-line client. It WORKED!!! See rev
1225839, and 1225841.
As previously mentioned, Gilles already encountered the same
difficulty, and the problem was only solved when Phil managed to
successfully commit a dummy patch to the incriminated file. So now
that the patch was accepted, I tried to commit to
https://svn.apache.org/repos/asf/commons/proper/math/trunk the
following patch
*****BEGIN PATCH*****
### Eclipse Workspace Patch 1.0
#P Apache Commons Math
Index: src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
===================================================================
--- src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (revision
1225842)
+++ src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java (working
copy)
@@ -23,7 +23,7 @@
import org.apache.commons.math.util.FastMath;
/**
- * Implementation of the binomial distribution.
+ * Implementation of the binomial distribution. DUMMY MODIFICATION, SECOND TAKE
*
* @see <a href="http://en.wikipedia.org/wiki/Binomial_distribution">Binomial
distribution (Wikipedia)</a>
* @see <a href="http://mathworld.wolfram.com/BinomialDistribution.html">Binomial
Distribution (MathWorld)</a>
*****END PATCH*****
It WORKED !!!
- r1225843 used subclipse + JavaHL,
- r1225844 used subclipse + SVNKit.
Does all that help? Can I try and commit the longer patch that
initially was the cause of this thread, or should I wait for you to
explore in more detail this issue?
Best regards, thanks again for your help!
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
Le 27 décembre 2011 14:06, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
>> > - How to reproduce the errors you saw? Can you show the output of `svn
>> > diff` at the time of a failed commit attempt?
>> >
>> I hope this mailing list allows for attachements, in which case you
>> will find attached the patch I've been trying to commit for several
>> days now. It is a rather large patch, but I don't think that this is
>> the cause for our current troubles, since I've tried to commit only a
>> small piece and it did not work either.
>>
>> Just to be sure the trouble was still occuring, I've just tried to
>> commit these changes, and here is what I get.
>>
>> org.tigris.subversion.javahl.ClientException: Merge conflict during commit
>
> (this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
> with 'svn merge')
>
>> svn: Commit failed (details follow):
>> svn: File or directory
>> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
>> is out of date; try updating
>> svn: resource out of date; try updating
>
> You probably recognize this error as the one meaning 'run "svn update"
> and try the commit again. ("update" needs to be run on the containing
> directory, not only on the files in question.)' However, you remarked
> earlier that you also get this error if you 'rm -rf' your working copy
> and try to commit from a new one, right?
>
That's correct. I did update on the directory, as well as checkout a
brand new working copy of Commons-Math.
Was the attached patch of any use to you?
Sébastien
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
Le 27 décembre 2011 14:06, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
>> > - How to reproduce the errors you saw? Can you show the output of `svn
>> > diff` at the time of a failed commit attempt?
>> >
>> I hope this mailing list allows for attachements, in which case you
>> will find attached the patch I've been trying to commit for several
>> days now. It is a rather large patch, but I don't think that this is
>> the cause for our current troubles, since I've tried to commit only a
>> small piece and it did not work either.
>>
>> Just to be sure the trouble was still occuring, I've just tried to
>> commit these changes, and here is what I get.
>>
>> org.tigris.subversion.javahl.ClientException: Merge conflict during commit
>
> (this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
> with 'svn merge')
>
>> svn: Commit failed (details follow):
>> svn: File or directory
>> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
>> is out of date; try updating
>> svn: resource out of date; try updating
>
> You probably recognize this error as the one meaning 'run "svn update"
> and try the commit again. ("update" needs to be run on the containing
> directory, not only on the files in question.)' However, you remarked
> earlier that you also get this error if you 'rm -rf' your working copy
> and try to commit from a new one, right?
>
That's correct. I did update on the directory, as well as checkout a
brand new working copy of Commons-Math.
Was the attached patch of any use to you?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
> > - How to reproduce the errors you saw? Can you show the output of `svn
> > diff` at the time of a failed commit attempt?
> >
> I hope this mailing list allows for attachements, in which case you
> will find attached the patch I've been trying to commit for several
> days now. It is a rather large patch, but I don't think that this is
> the cause for our current troubles, since I've tried to commit only a
> small piece and it did not work either.
>
> Just to be sure the trouble was still occuring, I've just tried to
> commit these changes, and here is what I get.
>
> org.tigris.subversion.javahl.ClientException: Merge conflict during commit
(this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
with 'svn merge')
> svn: Commit failed (details follow):
> svn: File or directory
> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
> is out of date; try updating
> svn: resource out of date; try updating
You probably recognize this error as the one meaning 'run "svn update"
and try the commit again. ("update" needs to be run on the containing
directory, not only on the files in question.)' However, you remarked
earlier that you also get this error if you 'rm -rf' your working copy
and try to commit from a new one, right?
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Le 27 décembre 2011 13:56, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
> Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
>> >
>> > - Why would the N other files have been committed in that revision?
>> > Recall that those files had no text changes and their property lists
>> > were re-set to the values they already had.
>> >
>> I now recall what hapened at that time. As of r1206451 (see
>> MATH-711), interface files xxxDistribution.java and default
>> implementation xxxDistributionImpl.java have been merged. I did this
>> piece of refactoring with Eclipse, and realized later that during the
>> process, all SVN properties had gone. Or so it appeared in Eclipse
>> (since you wrote that the properties had not really gone).
>>
>> So r1210359 had two purposes
>> 1. restore the SVN properties,
>> 2. solve MATH-715 (which resulted in "real" modifications of
>> PascalDistribution.java).
>> I hope I am not the one to blame for the current mess. I now realize
>> that I should have operated the refactoring outside Eclipse, using SVN
>> to remove the interface files, and rename the implementation files.
>
> You should tell svn about add/remove/rename operations, yes. I suppose
> eclipse would do that for you if you had an svn plugin (eg, subclipse)
> installed.
>
I'm actually not sure about that. For the record, I *do* use
subclipse, but I found it sometimes unreliable: I would sometimes be
unable to commit from within Eclipse+subclipse, while commiting from
the command-line would work perfectly. I wonder if other people have
already come across this issue.
>
> The revision in question does not contain any renames, adds, or deletes.
>
>> Also I should have used SVN as a command-line tool to check for the
>> presence of the SVN properties.
>
> Well, only if you suspected eclipse was lying to you. :)
>
see above ;)
>> Again, I hope I did not cause too much
>> damage. What can I do to try and repair that?
>>
>
> Nothing, really; the revision is fine on both mirrors so I'll let it
> stay this way. What you could do is mainly ensuring this doesn't happen
> again --- such as telling us how to reproduce those revisions with bogus
> 'log -qv' outputs. (That's definitely a bug, and needs to be fixed.)
>
>> >
>> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
>> > commit. The servers ran 1.7.0. My client was 1.7.0 too.
>> >
>> Actually, I'm using this time
>> svn --version
>> svn, version 1.6.17 (r1128011)
>> compiled Aug 25 2011, 17:51:49
>>
>
> Yes, that's the version of the cmdline client that you use. But the
> error you pasted above ("org.tigris.subversion.javahl.ClientException")
> indicates that you use at least one other client, and that's where the
> SVNKit version comes in.
>
>> Should I move to svn 1.7 ?
>>
>
> You could try moving to 1.7, and/or using the official JavaHL bindings
> instead of the third-party SVNKit implementation. With my svn hat on,
> though, I'd like to figure out how those revisions with bogus 'log -qv'
> output were created, and if you have the time to provide a self-contained
> reproduction recipe (starting with 'svnadmin create', and svn and/or
> eclipse) we'd appreciate it.
>
I'll try my best to do that.
>> >
>> > As to the diagnosis:
>> >
>> > - The non-functional propchanges should have been collapsed and removed
>> > before or during the commit. This should happen within the FS
>> > backend: the changed-paths information should not list such files with
>> > 'prop_mod=TRUE'. I'm not sure if other layers should do such
>> > collapsing too.
>> >
>> I'm sorry this is far out of my league... But I do hope that I've
>> answered your questions.
>
> Yeah, that was aimed at the svn devs reading this list. :)
>
> [ I trimmed some parts -- will reply to them later ]
>
Thanks,
Sébastien
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Le 27 décembre 2011 13:56, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
> Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
>> >
>> > - Why would the N other files have been committed in that revision?
>> > Recall that those files had no text changes and their property lists
>> > were re-set to the values they already had.
>> >
>> I now recall what hapened at that time. As of r1206451 (see
>> MATH-711), interface files xxxDistribution.java and default
>> implementation xxxDistributionImpl.java have been merged. I did this
>> piece of refactoring with Eclipse, and realized later that during the
>> process, all SVN properties had gone. Or so it appeared in Eclipse
>> (since you wrote that the properties had not really gone).
>>
>> So r1210359 had two purposes
>> 1. restore the SVN properties,
>> 2. solve MATH-715 (which resulted in "real" modifications of
>> PascalDistribution.java).
>> I hope I am not the one to blame for the current mess. I now realize
>> that I should have operated the refactoring outside Eclipse, using SVN
>> to remove the interface files, and rename the implementation files.
>
> You should tell svn about add/remove/rename operations, yes. I suppose
> eclipse would do that for you if you had an svn plugin (eg, subclipse)
> installed.
>
I'm actually not sure about that. For the record, I *do* use
subclipse, but I found it sometimes unreliable: I would sometimes be
unable to commit from within Eclipse+subclipse, while commiting from
the command-line would work perfectly. I wonder if other people have
already come across this issue.
>
> The revision in question does not contain any renames, adds, or deletes.
>
>> Also I should have used SVN as a command-line tool to check for the
>> presence of the SVN properties.
>
> Well, only if you suspected eclipse was lying to you. :)
>
see above ;)
>> Again, I hope I did not cause too much
>> damage. What can I do to try and repair that?
>>
>
> Nothing, really; the revision is fine on both mirrors so I'll let it
> stay this way. What you could do is mainly ensuring this doesn't happen
> again --- such as telling us how to reproduce those revisions with bogus
> 'log -qv' outputs. (That's definitely a bug, and needs to be fixed.)
>
>> >
>> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
>> > commit. The servers ran 1.7.0. My client was 1.7.0 too.
>> >
>> Actually, I'm using this time
>> svn --version
>> svn, version 1.6.17 (r1128011)
>> compiled Aug 25 2011, 17:51:49
>>
>
> Yes, that's the version of the cmdline client that you use. But the
> error you pasted above ("org.tigris.subversion.javahl.ClientException")
> indicates that you use at least one other client, and that's where the
> SVNKit version comes in.
>
>> Should I move to svn 1.7 ?
>>
>
> You could try moving to 1.7, and/or using the official JavaHL bindings
> instead of the third-party SVNKit implementation. With my svn hat on,
> though, I'd like to figure out how those revisions with bogus 'log -qv'
> output were created, and if you have the time to provide a self-contained
> reproduction recipe (starting with 'svnadmin create', and svn and/or
> eclipse) we'd appreciate it.
>
I'll try my best to do that.
>> >
>> > As to the diagnosis:
>> >
>> > - The non-functional propchanges should have been collapsed and removed
>> > before or during the commit. This should happen within the FS
>> > backend: the changed-paths information should not list such files with
>> > 'prop_mod=TRUE'. I'm not sure if other layers should do such
>> > collapsing too.
>> >
>> I'm sorry this is far out of my league... But I do hope that I've
>> answered your questions.
>
> Yeah, that was aimed at the svn devs reading this list. :)
>
> [ I trimmed some parts -- will reply to them later ]
>
Thanks,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
> >
> > - Why would the N other files have been committed in that revision?
> > Recall that those files had no text changes and their property lists
> > were re-set to the values they already had.
> >
> I now recall what hapened at that time. As of r1206451 (see
> MATH-711), interface files xxxDistribution.java and default
> implementation xxxDistributionImpl.java have been merged. I did this
> piece of refactoring with Eclipse, and realized later that during the
> process, all SVN properties had gone. Or so it appeared in Eclipse
> (since you wrote that the properties had not really gone).
>
> So r1210359 had two purposes
> 1. restore the SVN properties,
> 2. solve MATH-715 (which resulted in "real" modifications of
> PascalDistribution.java).
> I hope I am not the one to blame for the current mess. I now realize
> that I should have operated the refactoring outside Eclipse, using SVN
> to remove the interface files, and rename the implementation files.
You should tell svn about add/remove/rename operations, yes. I suppose
eclipse would do that for you if you had an svn plugin (eg, subclipse)
installed.
The revision in question does not contain any renames, adds, or deletes.
> Also I should have used SVN as a command-line tool to check for the
> presence of the SVN properties.
Well, only if you suspected eclipse was lying to you. :)
> Again, I hope I did not cause too much
> damage. What can I do to try and repair that?
>
Nothing, really; the revision is fine on both mirrors so I'll let it
stay this way. What you could do is mainly ensuring this doesn't happen
again --- such as telling us how to reproduce those revisions with bogus
'log -qv' outputs. (That's definitely a bug, and needs to be fixed.)
> >
> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
> > commit. The servers ran 1.7.0. My client was 1.7.0 too.
> >
> Actually, I'm using this time
> svn --version
> svn, version 1.6.17 (r1128011)
> compiled Aug 25 2011, 17:51:49
>
Yes, that's the version of the cmdline client that you use. But the
error you pasted above ("org.tigris.subversion.javahl.ClientException")
indicates that you use at least one other client, and that's where the
SVNKit version comes in.
> Should I move to svn 1.7 ?
>
You could try moving to 1.7, and/or using the official JavaHL bindings
instead of the third-party SVNKit implementation. With my svn hat on,
though, I'd like to figure out how those revisions with bogus 'log -qv'
output were created, and if you have the time to provide a self-contained
reproduction recipe (starting with 'svnadmin create', and svn and/or
eclipse) we'd appreciate it.
> >
> > As to the diagnosis:
> >
> > - The non-functional propchanges should have been collapsed and removed
> > before or during the commit. This should happen within the FS
> > backend: the changed-paths information should not list such files with
> > 'prop_mod=TRUE'. I'm not sure if other layers should do such
> > collapsing too.
> >
> I'm sorry this is far out of my league... But I do hope that I've
> answered your questions.
Yeah, that was aimed at the svn devs reading this list. :)
[ I trimmed some parts -- will reply to them later ]
Re: [math] Strange svn conflict
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
> I hope I am not the one to blame for the current mess. I now realize
> that I should have operated the refactoring outside Eclipse, using SVN
> to remove the interface files, and rename the implementation files.
> Also I should have used SVN as a command-line tool to check for the
> presence of the SVN properties. Again, I hope I did not cause too much
> damage. What can I do to try and repair that?
This problem can, and did, occur even without using Eclipse.
> [...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
> >
> > - Why would the N other files have been committed in that revision?
> > Recall that those files had no text changes and their property lists
> > were re-set to the values they already had.
> >
> I now recall what hapened at that time. As of r1206451 (see
> MATH-711), interface files xxxDistribution.java and default
> implementation xxxDistributionImpl.java have been merged. I did this
> piece of refactoring with Eclipse, and realized later that during the
> process, all SVN properties had gone. Or so it appeared in Eclipse
> (since you wrote that the properties had not really gone).
>
> So r1210359 had two purposes
> 1. restore the SVN properties,
> 2. solve MATH-715 (which resulted in "real" modifications of
> PascalDistribution.java).
> I hope I am not the one to blame for the current mess. I now realize
> that I should have operated the refactoring outside Eclipse, using SVN
> to remove the interface files, and rename the implementation files.
You should tell svn about add/remove/rename operations, yes. I suppose
eclipse would do that for you if you had an svn plugin (eg, subclipse)
installed.
The revision in question does not contain any renames, adds, or deletes.
> Also I should have used SVN as a command-line tool to check for the
> presence of the SVN properties.
Well, only if you suspected eclipse was lying to you. :)
> Again, I hope I did not cause too much
> damage. What can I do to try and repair that?
>
Nothing, really; the revision is fine on both mirrors so I'll let it
stay this way. What you could do is mainly ensuring this doesn't happen
again --- such as telling us how to reproduce those revisions with bogus
'log -qv' outputs. (That's definitely a bug, and needs to be fixed.)
> >
> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
> > commit. The servers ran 1.7.0. My client was 1.7.0 too.
> >
> Actually, I'm using this time
> svn --version
> svn, version 1.6.17 (r1128011)
> compiled Aug 25 2011, 17:51:49
>
Yes, that's the version of the cmdline client that you use. But the
error you pasted above ("org.tigris.subversion.javahl.ClientException")
indicates that you use at least one other client, and that's where the
SVNKit version comes in.
> Should I move to svn 1.7 ?
>
You could try moving to 1.7, and/or using the official JavaHL bindings
instead of the third-party SVNKit implementation. With my svn hat on,
though, I'd like to figure out how those revisions with bogus 'log -qv'
output were created, and if you have the time to provide a self-contained
reproduction recipe (starting with 'svnadmin create', and svn and/or
eclipse) we'd appreciate it.
> >
> > As to the diagnosis:
> >
> > - The non-functional propchanges should have been collapsed and removed
> > before or during the commit. This should happen within the FS
> > backend: the changed-paths information should not list such files with
> > 'prop_mod=TRUE'. I'm not sure if other layers should do such
> > collapsing too.
> >
> I'm sorry this is far out of my league... But I do hope that I've
> answered your questions.
Yeah, that was aimed at the svn devs reading this list. :)
[ I trimmed some parts -- will reply to them later ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
> > - How to reproduce the errors you saw? Can you show the output of `svn
> > diff` at the time of a failed commit attempt?
> >
> I hope this mailing list allows for attachements, in which case you
> will find attached the patch I've been trying to commit for several
> days now. It is a rather large patch, but I don't think that this is
> the cause for our current troubles, since I've tried to commit only a
> small piece and it did not work either.
>
> Just to be sure the trouble was still occuring, I've just tried to
> commit these changes, and here is what I get.
>
> org.tigris.subversion.javahl.ClientException: Merge conflict during commit
(this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
with 'svn merge')
> svn: Commit failed (details follow):
> svn: File or directory
> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
> is out of date; try updating
> svn: resource out of date; try updating
You probably recognize this error as the one meaning 'run "svn update"
and try the commit again. ("update" needs to be run on the containing
directory, not only on the files in question.)' However, you remarked
earlier that you also get this error if you 'rm -rf' your working copy
and try to commit from a new one, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
and many thanks for your help
>
> I have a few questions still:
>
> - Can you run 'svn diff -c r1210359' (against either mirror) and confirm
> that that is exactly what you intended to commit?
>
Done on the EU mirror: the diff file seems OK to me.
>
> - Why would the N other files have been committed in that revision?
> Recall that those files had no text changes and their property lists
> were re-set to the values they already had.
>
I now recall what hapened at that time. As of r1206451 (see
MATH-711), interface files xxxDistribution.java and default
implementation xxxDistributionImpl.java have been merged. I did this
piece of refactoring with Eclipse, and realized later that during the
process, all SVN properties had gone. Or so it appeared in Eclipse
(since you wrote that the properties had not really gone).
So r1210359 had two purposes
1. restore the SVN properties,
2. solve MATH-715 (which resulted in "real" modifications of
PascalDistribution.java).
I hope I am not the one to blame for the current mess. I now realize
that I should have operated the refactoring outside Eclipse, using SVN
to remove the interface files, and rename the implementation files.
Also I should have used SVN as a command-line tool to check for the
presence of the SVN properties. Again, I hope I did not cause too much
damage. What can I do to try and repair that?
>
> - How to reproduce the errors you saw? Can you show the output of `svn
> diff` at the time of a failed commit attempt?
>
I hope this mailing list allows for attachements, in which case you
will find attached the patch I've been trying to commit for several
days now. It is a rather large patch, but I don't think that this is
the cause for our current troubles, since I've tried to commit only a
small piece and it did not work either.
Just to be sure the trouble was still occuring, I've just tried to
commit these changes, and here is what I get.
org.tigris.subversion.javahl.ClientException: Merge conflict during commit
svn: Commit failed (details follow):
svn: File or directory
'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
is out of date; try updating
svn: resource out of date; try updating
>
> - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
> commit. The servers ran 1.7.0. My client was 1.7.0 too.
>
Actually, I'm using this time
svn --version
svn, version 1.6.17 (r1128011)
compiled Aug 25 2011, 17:51:49
Should I move to svn 1.7 ?
>
> As to the diagnosis:
>
> - The non-functional propchanges should have been collapsed and removed
> before or during the commit. This should happen within the FS
> backend: the changed-paths information should not list such files with
> 'prop_mod=TRUE'. I'm not sure if other layers should do such
> collapsing too.
>
I'm sorry this is far out of my league... But I do hope that I've
answered your questions.
>
> Thanks,
>
> Daniel
>
Thank *you*,
Sébastien
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
Hi,
and many thanks for your help
>
> I have a few questions still:
>
> - Can you run 'svn diff -c r1210359' (against either mirror) and confirm
> that that is exactly what you intended to commit?
>
Done on the EU mirror: the diff file seems OK to me.
>
> - Why would the N other files have been committed in that revision?
> Recall that those files had no text changes and their property lists
> were re-set to the values they already had.
>
I now recall what hapened at that time. As of r1206451 (see
MATH-711), interface files xxxDistribution.java and default
implementation xxxDistributionImpl.java have been merged. I did this
piece of refactoring with Eclipse, and realized later that during the
process, all SVN properties had gone. Or so it appeared in Eclipse
(since you wrote that the properties had not really gone).
So r1210359 had two purposes
1. restore the SVN properties,
2. solve MATH-715 (which resulted in "real" modifications of
PascalDistribution.java).
I hope I am not the one to blame for the current mess. I now realize
that I should have operated the refactoring outside Eclipse, using SVN
to remove the interface files, and rename the implementation files.
Also I should have used SVN as a command-line tool to check for the
presence of the SVN properties. Again, I hope I did not cause too much
damage. What can I do to try and repair that?
>
> - How to reproduce the errors you saw? Can you show the output of `svn
> diff` at the time of a failed commit attempt?
>
I hope this mailing list allows for attachements, in which case you
will find attached the patch I've been trying to commit for several
days now. It is a rather large patch, but I don't think that this is
the cause for our current troubles, since I've tried to commit only a
small piece and it did not work either.
Just to be sure the trouble was still occuring, I've just tried to
commit these changes, and here is what I get.
org.tigris.subversion.javahl.ClientException: Merge conflict during commit
svn: Commit failed (details follow):
svn: File or directory
'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
is out of date; try updating
svn: resource out of date; try updating
>
> - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
> commit. The servers ran 1.7.0. My client was 1.7.0 too.
>
Actually, I'm using this time
svn --version
svn, version 1.6.17 (r1128011)
compiled Aug 25 2011, 17:51:49
Should I move to svn 1.7 ?
>
> As to the diagnosis:
>
> - The non-functional propchanges should have been collapsed and removed
> before or during the commit. This should happen within the FS
> backend: the changed-paths information should not list such files with
> 'prop_mod=TRUE'. I'm not sure if other layers should do such
> collapsing too.
>
I'm sorry this is far out of my league... But I do hope that I've
answered your questions.
>
> Thanks,
>
> Daniel
>
Thank *you*,
Sébastien
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ CC += users@svn; context for them: 'svn commit' error report, and
discovery that 'log -qv r1210359' differs between svn.eu.a.o and
svn.us.a.o; it appears that only 'log -qv' is wrong (false positives)
but the file contents/props are fine ]
Sébastien Brisard wrote on Sat, Dec 24, 2011 at 17:37:02 +0100:
> >
> > You're right, that shouldn't be the case. Something appears to be very wrong:
> >
> > eris,1:svn/asf% svnlook changed -r 1210359 $PWD
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
> > UU commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
> >
> > harmonia,0:svn/asf% svnlook changed -r 1210359 $PWD
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> >
> > The harmonia version is definitely wrong. Commons devs (especially
> > celestin) --- please confirm whether or not r1210359 _on svn.us.apache.org_
> > is correct.
> >
> As far as I (== celestin) can judge, *both* versions look OK. What I
> did is svn checkout of the latest version on both repositories. Then,
> I ran diff on each of the files listed above. *All* files are
> identical, but for the svn:keywords which *might* sometimes differ.
>
> More precisely, the following files are strictly identical on both repositories
> ChiSquaredDistribution.java (HEAD=r1210756)
> ExponentialDistribution.java (HEAD=r1209963)
> FDistribution.java (HEAD=r1210756)
> GammaDistribution.java (HEAD=r1210756)
> NormalDistribution.java (HEAD=r1210756)
> TDistribution.java (HEAD=r1210756)
>
> while the following files are tagged r1210359 on us mirror, and
> r1209963 on the eu mirror (but the remainder of the files are
> identical)
> BinomialDistribution.java
> CauchyDistribution.java
> HypergeometricDistribution.java
> KolmogorovSmirnovDistribution.java
> PoissonDistribution.java
> WeibullDistribution.java
> ZipfDistribution.java
> I *believe* these files should in fact be tagged r1210359 on *both*
> repositories.
>
> Does that help?
> Sébastien
Yes. Carefully comparing checkouts of the relevant revisions from both
mirrors confirms that both r1210358 and r1210359 actually agree between
the two mirrors on the contents of all files and props, and only
disagree in the 'log -qv' output (and in the changed-paths cache within
the revision file).
What happened is that eris(svn.us) thinks the N-3 files it has in excess
had undergone a propchange but no textchange, where in fact the revision
simply replaces the proplist by a proplist identical to the existing
one. The sync process[1] is justified in silently swallowing these
changes.
I have a few questions still:
- Can you run 'svn diff -c r1210359' (against either mirror) and confirm
that that is exactly what you intended to commit?
- Why would the N other files have been committed in that revision?
Recall that those files had no text changes and their property lists
were re-set to the values they already had.
- How to reproduce the errors you saw? Can you show the output of `svn
diff` at the time of a failed commit attempt?
I tried to commit (from a fresh checkout of HEAD) via the mirror, once
to files that did change in the revision and once to files that didn't
change in the revision, and both attempts succeeded (r1223004,
r1223005).
- You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
commit. The servers ran 1.7.0. My client was 1.7.0 too.
As to the diagnosis:
- The non-functional propchanges should have been collapsed and removed
before or during the commit. This should happen within the FS
backend: the changed-paths information should not list such files with
'prop_mod=TRUE'. I'm not sure if other layers should do such
collapsing too.
Thanks,
Daniel
[1] Not only to harmonia, but also to another mirror which he booted off
the end-of-november dumpfiles and synced from svn.us.
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ CC += users@svn; context for them: 'svn commit' error report, and
discovery that 'log -qv r1210359' differs between svn.eu.a.o and
svn.us.a.o; it appears that only 'log -qv' is wrong (false positives)
but the file contents/props are fine ]
Sébastien Brisard wrote on Sat, Dec 24, 2011 at 17:37:02 +0100:
> >
> > You're right, that shouldn't be the case. Something appears to be very wrong:
> >
> > eris,1:svn/asf% svnlook changed -r 1210359 $PWD
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
> > UU commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
> >
> > harmonia,0:svn/asf% svnlook changed -r 1210359 $PWD
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> > U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> > _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> >
> > The harmonia version is definitely wrong. Commons devs (especially
> > celestin) --- please confirm whether or not r1210359 _on svn.us.apache.org_
> > is correct.
> >
> As far as I (== celestin) can judge, *both* versions look OK. What I
> did is svn checkout of the latest version on both repositories. Then,
> I ran diff on each of the files listed above. *All* files are
> identical, but for the svn:keywords which *might* sometimes differ.
>
> More precisely, the following files are strictly identical on both repositories
> ChiSquaredDistribution.java (HEAD=r1210756)
> ExponentialDistribution.java (HEAD=r1209963)
> FDistribution.java (HEAD=r1210756)
> GammaDistribution.java (HEAD=r1210756)
> NormalDistribution.java (HEAD=r1210756)
> TDistribution.java (HEAD=r1210756)
>
> while the following files are tagged r1210359 on us mirror, and
> r1209963 on the eu mirror (but the remainder of the files are
> identical)
> BinomialDistribution.java
> CauchyDistribution.java
> HypergeometricDistribution.java
> KolmogorovSmirnovDistribution.java
> PoissonDistribution.java
> WeibullDistribution.java
> ZipfDistribution.java
> I *believe* these files should in fact be tagged r1210359 on *both*
> repositories.
>
> Does that help?
> Sébastien
Yes. Carefully comparing checkouts of the relevant revisions from both
mirrors confirms that both r1210358 and r1210359 actually agree between
the two mirrors on the contents of all files and props, and only
disagree in the 'log -qv' output (and in the changed-paths cache within
the revision file).
What happened is that eris(svn.us) thinks the N-3 files it has in excess
had undergone a propchange but no textchange, where in fact the revision
simply replaces the proplist by a proplist identical to the existing
one. The sync process[1] is justified in silently swallowing these
changes.
I have a few questions still:
- Can you run 'svn diff -c r1210359' (against either mirror) and confirm
that that is exactly what you intended to commit?
- Why would the N other files have been committed in that revision?
Recall that those files had no text changes and their property lists
were re-set to the values they already had.
- How to reproduce the errors you saw? Can you show the output of `svn
diff` at the time of a failed commit attempt?
I tried to commit (from a fresh checkout of HEAD) via the mirror, once
to files that did change in the revision and once to files that didn't
change in the revision, and both attempts succeeded (r1223004,
r1223005).
- You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
commit. The servers ran 1.7.0. My client was 1.7.0 too.
As to the diagnosis:
- The non-functional propchanges should have been collapsed and removed
before or during the commit. This should happen within the FS
backend: the changed-paths information should not list such files with
'prop_mod=TRUE'. I'm not sure if other layers should do such
collapsing too.
Thanks,
Daniel
[1] Not only to harmonia, but also to another mirror which he booted off
the end-of-november dumpfiles and synced from svn.us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
>
> You're right, that shouldn't be the case. Something appears to be very wrong:
>
> eris,1:svn/asf% svnlook changed -r 1210359 $PWD
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
> UU commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
>
> harmonia,0:svn/asf% svnlook changed -r 1210359 $PWD
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
>
> The harmonia version is definitely wrong. Commons devs (especially
> celestin) --- please confirm whether or not r1210359 _on svn.us.apache.org_
> is correct.
>
As far as I (== celestin) can judge, *both* versions look OK. What I
did is svn checkout of the latest version on both repositories. Then,
I ran diff on each of the files listed above. *All* files are
identical, but for the svn:keywords which *might* sometimes differ.
More precisely, the following files are strictly identical on both repositories
ChiSquaredDistribution.java (HEAD=r1210756)
ExponentialDistribution.java (HEAD=r1209963)
FDistribution.java (HEAD=r1210756)
GammaDistribution.java (HEAD=r1210756)
NormalDistribution.java (HEAD=r1210756)
TDistribution.java (HEAD=r1210756)
while the following files are tagged r1210359 on us mirror, and
r1209963 on the eu mirror (but the remainder of the files are
identical)
BinomialDistribution.java
CauchyDistribution.java
HypergeometricDistribution.java
KolmogorovSmirnovDistribution.java
PoissonDistribution.java
WeibullDistribution.java
ZipfDistribution.java
I *believe* these files should in fact be tagged r1210359 on *both*
repositories.
Does that help?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Sébastien Brisard <ce...@apache.org>.
>
> You're right, that shouldn't be the case. Something appears to be very wrong:
>
> eris,1:svn/asf% svnlook changed -r 1210359 $PWD
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
> UU commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
>
> harmonia,0:svn/asf% svnlook changed -r 1210359 $PWD
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
> U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
> _U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
>
> The harmonia version is definitely wrong. Commons devs (especially
> celestin) --- please confirm whether or not r1210359 _on svn.us.apache.org_
> is correct.
>
As far as I (== celestin) can judge, *both* versions look OK. What I
did is svn checkout of the latest version on both repositories. Then,
I ran diff on each of the files listed above. *All* files are
identical, but for the svn:keywords which *might* sometimes differ.
More precisely, the following files are strictly identical on both repositories
ChiSquaredDistribution.java (HEAD=r1210756)
ExponentialDistribution.java (HEAD=r1209963)
FDistribution.java (HEAD=r1210756)
GammaDistribution.java (HEAD=r1210756)
NormalDistribution.java (HEAD=r1210756)
TDistribution.java (HEAD=r1210756)
while the following files are tagged r1210359 on us mirror, and
r1209963 on the eu mirror (but the remainder of the files are
identical)
BinomialDistribution.java
CauchyDistribution.java
HypergeometricDistribution.java
KolmogorovSmirnovDistribution.java
PoissonDistribution.java
WeibullDistribution.java
ZipfDistribution.java
I *believe* these files should in fact be tagged r1210359 on *both*
repositories.
Does that help?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
CC += celestin@ as author of r1210359
Sébastien Brisard wrote on Sat, Dec 24, 2011 at 14:06:16 +0100:
> US MIRROR
> Path: BinomialDistribution.java
> Name: BinomialDistribution.java
> URL: http://svn.us.apache.org/repos/asf/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> Repository Root: http://svn.us.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1222933
> Node Kind: file
> Last Changed Author: celestin
> Last Changed Rev: 1210359
> Last Changed Date: 2011-12-05 09:15:38 +0100 (Lun, 05 déc 2011)
>
> EU MIRROR
> Path: BinomialDistribution.java
> Name: BinomialDistribution.java
> URL: http://svn.eu.apache.org/repos/asf/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
> Repository Root: http://svn.eu.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1222933
> Node Kind: file
> Last Changed Author: celestin
> Last Changed Rev: 1209963
> Last Changed Date: 2011-12-03 19:23:02 +0100 (Sam, 03 déc 2011)
>
> It seems strange that the 'Last Changed Rev' fields should be
> different for each mirror. Could that be the origin of our troubles?
>
You're right, that shouldn't be the case. Something appears to be very wrong:
eris,1:svn/asf% svnlook changed -r 1210359 $PWD
U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
UU commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
harmonia,0:svn/asf% svnlook changed -r 1210359 $PWD
U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
_U commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
The harmonia version is definitely wrong. Commons devs (especially
celestin) --- please confirm whether or not r1210359 _on svn.us.apache.org_
is correct.
> Thanks a lot in advance for your help, and a very merry Christmas to you!
> Sébastien
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Strange svn conflict
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sébastien Brisard wrote on Sat, Dec 24, 2011 at 14:06:16 +0100:
> It has been suggested on the dev mailing list that this might have
> something to do with bad synchronization between different
> repositories. Yesterday, Daniel was very doubtful about that, and
> suggested we run svn info on the file causing the conflict, for both
> US/EU mirrors. He also wrote that running `svn info` actually forced
> some kind of synchronization between both mirrors (or so I
> understood). So I ran `svn info`, then tried again to commit, but that
> did not work either.
'svn info' does not cause the mirrors to sync. It was meant to compare
the HEAD revisions of the two mirrors (they turned out to be equal) to
rule that out as the cause of the problem.
As you point out later, the mirrors disagree in a more severe way: in
their histories. Thanks a lot for highlighting that! (I missed it in
your original `svn info` output)
No other revision in the last 30k revisions appears to be affected,
insofar as 'log -qv' is indicative.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org