is there a chance you have any umlauts in your path?
On Jan 20, 2008, at 3:57 AM, Tristan Schmelcher wrote:
> FYI, I discovered that dumping the repo and loading it into a new one
> fixed the problem of not being able to access the old version of
> Foo.java (though revision 63 still shows bar/Baz.java). Interestingly,
> in the re-loaded repo, the old version's revision number is 62, not
> 56,
> and it seems that that's correct. So part of the problem was evidently
> that the repo was looking for the file in the wrong revision. In the
> original repo I can even browse the full revision history and see that
> revision 62 did indeed create Foo.java and that revision 56 had
> nothing
> to do with, though when I try to view it in revision 62 I get:
>
> svn: URL 'file:///.../Foo.java' non-existent in revision '62'
>
> So how the "svnadmin dump" managed to find the data is beyond me,
> but it
> does seem to be intact now, and I didn't see any warnings during the
> dump or load.
>
> Shall I report this bug and include the work-around?
>
> On Sun, 2007-12-16 at 14:41 -0800, Tristan Schmelcher wrote:
>> I have just recently encountered this behaviour in Subversion and
>> it's
>> pretty clear to me that it's a bug, but I thought I'd post here
>> before
>> filing it.
>>
>> A few days ago I committed changes to several files in my project,
>> creating revision 63. Among the files changed were Foo.java and
>> bar/Baz.java. Everything seemed to go fine, but I later discovered
>> that
>> this was not the case. Revision 63 of Foo.java did not contain what I
>> wrote for it; it contained what I wrote for bar/Baz.java! However, my
>> check-out contained the "correct" results; .svn/text-base/Foo.java
>> showed the intended content, and its md5sum matched the one
>> in .svn/entries. Hence, when I later went to commit my next
>> revision--which also changed Foo.java--I got a "Base checksum
>> mismatch".
>> This was how I discovered the problem.
>>
>> To "fix" the issue, I used the command-line svn client to
>> replace .svn/text-base/Foo.java with the (incorrect) data in the repo
>> and edited .svn/entries to contain its md5sum. I was then able to
>> commit, thus creating revision 64 of Foo.java with the content that I
>> actually wanted for it.
>>
>> However, not all is well; I am unable to retrieve any revisions for
>> Foo.java from before 63 (of which there is only one, numbered 56).
>> Attempting to do so results in "Unable to find repository location
>> for ..." (indicating that the bug is probably server-side, since no
>> client foul-up should be able to cause that). Thus all the old data
>> for
>> Foo.java would seem to be lost (though of course I could've saved
>> rev.
>> 63 from text-base if I had cared to). I don't expect to need that
>> data
>> though so that's not a major problem, but I now have little
>> confidence
>> in the integrity of my repository.
>>
>> I backed-up my check-out and my repository before I "fixed" the
>> problem,
>> so I can run any tests that you want, though I'd rather not give
>> you the
>> raw data since this project is not public (hence the made-up file
>> names).
>>
>> My OS is Ubuntu Gutsy Gibbon i686 (fully up-to-date) and Subversion
>> is
>> version 1.4.4 (from APT). I'd repro on 1.4.5 but I have no idea how
>> I'd
>> go about repro'ing a fluke like this. My SVN repo is local (i.e.,
>> file:/// URL type) and my client is Subclipse 1.2.4 in Eclipse
>> 3.3.1.1
>> (from eclipse.org) on Sun Java 6 (from APT).
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-20 23:05:46 CET