Le 27 décembre 2011 13:56, Daniel Shahaf <d.s_at_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
Received on 2011-12-27 21:40:29 CET