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
