I'm not 100% certain that this is caused by the subversion bundle, but I have not been able to pinpoint the exact cause, and it only seems to be happening when I'm working through TextMate:
At some (undetermined) points, when I try to commit my project I get this error:
svn: Commit failed (details follow): svn: Your file or directory 'config.inc.php' is probably out-of-date 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).
(where config.inc.php is the first file that was modified in the list)
Now the problem is this: The resource is NOT out of date, and I'm the only one with access to the repository. An update command says that I have the latest revision checked out, and `svn info` verifies the fact. Subsequent check-ins come back with the same error. The only way I've been able to get around this is check out a new copy of the repository, move the modified files over one by one, and check in from there. And next time I need to check in, the same thing happens. Is there an issue with the 'Find in Project' search and replace feature that I should be aware of? (I use it a lot). Also I don't have any modifications in the bundles, nor any related checked out bundles.
Additionally, the 'diff' button from the subversion bundle status list displays the correct diff, but there's no syntax highlighting. When I use the diff bundle directly, or even through the subversion menu, the highlighting works just fine.
Any ideas?
Constantinos
On 14/09/2007, at 3:49 AM, Constantinos Neophytou ♎ wrote:
I'm not 100% certain that this is caused by the subversion bundle
I have experienced this quite frequently with SVN 1.4.x on multiple platforms not using TextMate. Not saying that it definitely isn't TextMate causing your problem, just saying that I get very similar behaviour not using TextMate.
- LD.
On 14 Sep 2007, at 02:52, Luke Daley wrote:
I have experienced this quite frequently with SVN 1.4.x on multiple platforms not using TextMate. Not saying that it definitely isn't TextMate causing your problem, just saying that I get very similar behaviour not using TextMate.
Fair enough, were you ever able to figure out what was wrong? Because it's happened to me before, but only once or twice. Now it's happening every other checkin, and it's becoming a big problem, especially with the number of files i'm dealing with.
c
On 14/09/2007, at 9:54 AM, Constantinos Neophytou ♎ wrote:
Fair enough, were you ever able to figure out what was wrong? Because it's happened to me before, but only once or twice. Now it's happening every other checkin, and it's becoming a big problem, especially with the number of files i'm dealing with.
Haven't sorry. Still trying to work out what triggers it.
- LD.
On 13/09/2007, at 19:49, Constantinos Neophytou ♎ wrote:
[...] svn: Commit failed (details follow): svn: Your file or directory 'config.inc.php' is probably out-of-date 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).
(where config.inc.php is the first file that was modified in the list)
Now the problem is this: The resource is NOT out of date, and I'm the only one with access to the repository.
Does ‘svn up’ solve it?
For example if you change properties on a folder, ‘svn up’ is required.
An update command says that I have the latest revision checked out, and `svn info` verifies the fact. Subsequent check-ins come back with the same error.
What about checkins from the shell? What about ‘svn cleanup’? What does ‘svn -u st’ show?
The only way I've been able to get around this is check out a new copy of the repository, move the modified files over one by one, and check in from there. And next time I need to check in, the same thing happens. Is there an issue with the 'Find in Project' search and replace feature that I should be aware of? (I use it a lot). Also I don't have any modifications in the bundles, nor any related checked out bundles.
I assume you do not see .svn folders in your project -- the only thing TM could potentially do was mess up the svn meta data (via Find in Project), but by default, the .svn folders are excluded from projects, so shouldn’t happen.
On 14 Sep 2007, at 10:24, Allan Odgaard wrote:
Does ‘svn up’ solve it?
For example if you change properties on a folder, ‘svn up’ is required.
Nope. That's the problem, it should.
What about checkins from the shell? What about ‘svn cleanup’? What does ‘svn -u st’ show?
Same problems. svn cleanup does nothing, and svn -u st shows exactly what it should. The list of modified files, and matching revision numbers.
I assume you do not see .svn folders in your project -- the only thing TM could potentially do was mess up the svn meta data (via Find in Project), but by default, the .svn folders are excluded from projects, so shouldn’t happen.
Yes, I did know that, but at that point I was grabbing at straws....
On 14/09/2007, at 11:11, Constantinos Neophytou ♎ wrote:
What about checkins from the shell? What about ‘svn cleanup’? What does ‘svn -u st’ show?
Same problems. svn cleanup does nothing, and svn -u st shows exactly what it should. The list of modified files, and matching revision numbers.
Try do a new checkout then run: diff -ru «old» «new»
Since you say a new checkout allows you to commit, the problem must be with the svn meta data, and the above should show how this is different in the new checkout.
On 14 Sep 2007, at 17:18, Allan Odgaard wrote:
Try do a new checkout then run: diff -ru «old» «new»
Since you say a new checkout allows you to commit, the problem must be with the svn meta data, and the above should show how this is different in the new checkout.
aha... even though svn -u st reports that everything is up to date, the diff -ru command shows that, in fact, everything is out of date (according to the metadata). The 'old' sandbox started as a checkout of version 5, and for some reason after the commit the metadata did not get updated, and refuses to get updated. It could not be permission problems, but i tried everything with sudo anyway, and I get the same errors...
I'm really at a loss...
On Sep 14, 2007, at 10:27 AM, Constantinos Neophytou ♎ wrote:
aha... even though svn -u st reports that everything is up to date, the diff -ru command shows that, in fact, everything is out of date (according to the metadata). The 'old' sandbox started as a checkout of version 5, and for some reason after the commit the metadata did not get updated, and refuses to get updated. It could not be permission problems, but i tried everything with sudo anyway, and I get the same errors...
Is your working copy checked out to a local HFS+ file system or is it stored remotely and accessed via AFP, Samba, SSHFS, etc?
IIRC, when the svn client updates metadata in the working copy, it does some sort of locking that most remote filesystems don't support.
--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.
Rob McBroom wrote:
On Sep 14, 2007, at 10:27 AM, Constantinos Neophytou ♎ wrote:
aha... even though svn -u st reports that everything is up to date, the diff -ru command shows that, in fact, everything is out of date (according to the metadata). The 'old' sandbox started as a checkout of version 5, and for some reason after the commit the metadata did not get updated, and refuses to get updated. It could not be permission problems, but i tried everything with sudo anyway, and I get the same errors...
Is your working copy checked out to a local HFS+ file system or is it stored remotely and accessed via AFP, Samba, SSHFS, etc?
IIRC, when the svn client updates metadata in the working copy, it does some sort of locking that most remote filesystems don't support.
Yep, I get someting like this when using Tortoise in the Parallels VM on a shared working copy. Any commit fails afterwards My error is clearer though: it says it can't move one of the .svn/ files, usually .snv/entries. This happens because svn sets the no-change flag in HFS. I solve it with
chflags -R noucgh working_copy/
You should normally get a permission error when something like this happens though. Cheers, V.-
-
Allan Odgaard -
Constantinos Neophytou ♎ -
Luke Daley -
Rob McBroom -
Vassilis Rizopoulos