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
Received on 2008-01-20 06:44:18 CET