"Mikel Ward" <mikel_at_mikelward.com> writes:
> I'm using svn 1.4.6 (r28251) on Fedora 9 preview (Linux i686) with an
> svn+ssh repository. As far as I can tell, the repo is running 1.4.2
> (r22196).
>
> I tried to commit a file yesterday, but it failed for some reason. It
> left an svn-commit.tmp file. I think the reason was "working copy out
> of date" or similar, but I also often abort checkins manually.
>
> The repository definitely doesn't have the change (doing a fresh
> checkout shows the old contents), but my working copy obviously got
> corrupted, because svn stat, svn di, and svn ci all do nothing.
> .svn/text-base contains the changes (I assume it would be the same
> inode as the working copy, except I copied the working file to a
> backup name then copied the backup over the working copy to see what
> would happen).
Yup, this sounds like a bug. It should be impossible for a commit to
succeed on the client side while failing on the repository side (the
inverse is possible, but that's not what happened here).
> Please let me know if there's anything I can do to help figure out the
> problem.
Unfortunately, without a reproduction recipe we are powerless. I
understand why you don't have one. If you ever see this happen again,
and you can remember the error that caused the commit to fail, that
might help a bit...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-14 22:43:55 CEST