subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] Strange svn conflict
Date Tue, 27 Dec 2011 20:39:52 GMT
Le 27 décembre 2011 13:56, Daniel Shahaf <> 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 and default
>> implementation 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
>> 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 ( 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 ]


View raw message