Hi folks.
This problem I've already described on the irc channel, but it couldn't
be solved it yet. First, let me say that this _might_ have to do with
TortoiseSVN, but it doesn't necessarily _have_to_be_ that. So before you
start dizzing me now, yes, I _have_ asked them, and they sent me to you.
The thing thing is, I can commit a file, but I can't commit it twice. At
least, not unless somebody else has commited this file in the meantime.
Example:
- The repository contains a file bla.tex
- I'm the only one who's actually working on this file
- I commit it once after changing it
- Everything's fine
- I modify it again
- Commit fails, error message "Commit failed (details follow): Your file
or directory 'bla.tex' is probably out of date; 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, please don't say it. I _am_ aware that I have to check for updates,
and that an update would usually help to solve this problem, but in this
case it doesn't. Neither an update of the entire folder, nor the file
itselt, nor another commit of any of these files change anything. What
does surprisingly work is that, after somebody else makes a dummy change
(e.g. inserting a blank line in bla.tex) and commits it, the update on
my copy passes the regular update with a successful merge, and I can
commit again.
So, speaking in revision numbers, that means: If the revision number was
38 after my first commit, somebody else must take it to 39, I update to
39, and then I can commit to 40. However, I can _not_ go to 41 thereafter.
I've checked the version numbers of svn and all software that could be
involved in the communication. We have a Suse 9.1 server running with
the latest patches installed for this release. Subversion is 1.0.0, as
of August 4, 2004. So is the Apache2 subversion module. Tortoise has the
latest version as well.
In another thread I read that somebody had a similar problem, apparently
due to badly synchronized clocks, so I installed NTP clients on both my
computer and the server. Unsuccessful.
After discovering some database problems yesterday in a test run of "svn
verify repo", I noticed that this might have been caused by improperly
set user masks, so I had the repository repaired and checked all
ownerships. When this changed nothing, I decided to create an entirely
new repository. This time, I su'ed to wwwrun first and did everything as
the Apache2 user to ensure that no conflict would occur on the way
between Apache and the actual svn command-line tool. Didn't help. Still
getting the same errors, except that the revision numbers are slightly
lower this time. :-)
As you can see, I've already checked a number of possible reasons. If
you have more ideas, I'll check these points momentarily as well. But
I'm at my wits' end. Working with a versioning system in this state is
really a hassle.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 4 13:28:19 2004