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 ]
Received on 2011-12-27 13:58:38 CET