No, just alphanumeric English characters, spaces, and hyphens.
On Sun, 2008-01-20 at 23:05 +0100, Christian Unger wrote:
> 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-21 01:12:06 CET