On Oct 3, 2007, at 14:31, Chris 'Xenon' Hanson wrote:
> I posted this originally to the TortoiseSVN list:
> http://thread.gmane.org/gmane.comp.version-
> control.subversion.tortoisesvn.user/8278/focus=8279
>
> because I was using TortoiseSVN. However, the consensus over
> there seems to indicate I have a Subversion problem (server or
> libraries) rather than something specific to Tortoise. I also have
> AnkhSVN (plugin for VC++) installed and have used it at times as well.
>
> I'll refer to my original posting to avoid duplicating the same
> info.
>
> Summary: 3 SVN users and a big (very new) SVN repository. If a
> user checks in a change to a file, then does some more work and
> checks in the same file again, there is a good chance the second
> check-in will fail with the message:
>
> "svn: The version resource does not correspond to the resource
> within the transaction. Either the requested version resource is
> out of date (needs to be updated), or the requested version
> resource is newer than the transaction root (restart the commit)."
>
> No amount of updating the file, updating the whole working
> directory or 'cleanup' will resolve the problem. If I copy the
> changed file to elsewhere, then update to get a fresh clean copy
> (which succeeds), then over-write it with the changed file, commit
> STILL fails.
>
> At one point, I tried deleting the .svn/all-wcprops file and
> updating. This seemed to solve the problem, but I was severely
> chastised for doing this.
>
> Checking out a fresh working directory from the repository is
> 130Mb, which takes a while over our LAN and a LONG while over the
> Internet to a remote developer's office.
>
> I have a post-commit hook installed invoking the commit-email.py
> script:
> /usr/share/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV"
> --diff n -h 3dnature.com -s "svn commit:" devs@3dnature.com
>
> Questions:
>
> Any idea how this situation keeps arising? At the moment both I
> and another developer are stuck in this state and unable to commit
> changes to some files. It was suggested that a slow post-commit
> hook could be the cause, is commit-email known to be susceptible to
> this?
>
> Any ideas how to get out of this state? Cleanup didn't help. I
> can checkout a new working directory, but that's not a real viable
> solution given the size of the repo, and the speed of the link
> between here and our offsite developers. :(
If your working copy is corrupted, checking out a new working copy is
the approved solution. Messing with the contents of .svn directories
is not approved. Your working copy should not keep getting corrupted,
though; if it does, then something is wrong (obviously). I'm not sure
what's causing it, unfortunately.
The client will wait for the post-commit hook to finish on the
server. There's really no point to this, since it's not like the post-
commit hook can send any info to the client or affect the client in
any way. But the client still waits. And sometimes you see errors as
a result. Commit-mail scripts can sometimes take a long time, if the
revision is large and they have been asked to put the diff of the
commit into the email. To ensure your post-commit hook finishes
quickly in any case, fork any other tasks off into new processes,
like this:
/usr/share/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" --
diff n -h 3dnature.com -s "svn commit:" devs@3dnature.com >/dev/null
2>/dev/null &
I do not know if that will help you specifically with the issue
you're asking about, but it's a good thing to do anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 23:45:19 2007