I am using Dreamweaver CS5 and Apache Subversion. Until today, the setup had been error-free. However, when I attempted to check in a file I had revised, I got the following error message from Dreamweaver:
SVN: #160024, Commit failed (details follow): File or directory ‘about.html’ is out of date; try updating
resource out of date; try updating
Background: I am the only user. SVN is hosted on another Mac on my home network running OS X 10.7. I set it up this way because I could never get SVN working on my MacBook Pro, which is running Mavericks. I have tried getting the current version, re-editing, then checking back in, but I have the same problem. Reverting the file and re-editing also fails on check-in.
In Terminal on the Mac running svn, I tried svn cleanup (& sudo svn cleanup), both of which produced the following response: svn: '.' is not a working copy directory. SVN update produces but one message: Skipped '.'
I have used Dreamweaver regularly for over 15 years, but I just started using svn a couple of months ago. I am a svn novice and just followed some very great and detailed instructions on the Adobe website to get it up and running and connect Dreamweaver. Other than this one file, the check-in/out process works fine. When I right-click on the problem file in Dreamweaver's file list, go to version control, and select "Show Revisions," it is up to date; that is, it shows all revisions up to the last one I was able to successfully check in.
This particular file has few revisions to date, so if it is easier and quicker to somehow kick it out of svn altogether and just save the current version back, that would be fine. However, I do need to be able to save version changes of it going forward, as I anticipate significant changes in the future.
Any help would be appreciated!
I've had these errors before. select the file and get the latest version from the server. The commit should work fine again.
Don't know what causes it but this has worked for me several times.
Related
So I upgraded to MacOS Sierra and now whenever I try to do anything in my working copy I get the error that it
"is too old (format 29) to work with client version '1.9.4 (r1740329)' (expects format 31). You need to upgrade the working copy first."
When I run svn upgrade, as it suggests it says
"Can't open file /.svn/entries: No such file or directory"
Any suggestions will be greatly appreciated!
Open Terminal
go to error folder. ex : cd svn/project/game
command write only "svn upgrade"
Your problem is that the version of the SVN client got upgraded locally; whereas your local working copy (and the server) didn't change! Now the new client is unable to work with the existing working copy.
Now you have three choices:
You can try to get your new SVN client to accept the existing working copy
You downgrade your local SVN client to the previous version
You throw your existing repositories away and start with fresh checkouts
For option 1, you might look here or there.
For option 2, this might help.
Option 3; I guess, is the one-line-no-brainer which maybe costs you download time, but should come with the least amount of "you spending your time" debugging this (unless you got a ton of uncommitted changes sitting in your current repositories). But of course, you would first try to create a new checkout with the new client, before throwing the old directory away.
I solved my problem by doing the 'svn upgrade' on the 'cd' of root folder of the project
I got error when execute 'svn upgrade'.
I had used svn 1.6 in Mac OS Lion. And i updated to Mac OS Mountain Lion few days ago.
so i have to upgrade svn.
I usually use Terminal application and execute svn command in CUI.
when i execute 'svn update'
$ svn update svn:
E155036: Please see the 'svn upgrade' command svn: E155036: Working
copy 'xxxxx' is too old
(format 10, created by Subversion 1.6)
when i execute 'svn upgrade'
$ svn upgrade
...
Upgraded
'aaaaa'
Upgraded
'bbbbb'
Upgraded
'ccccc'
Upgraded
'ddddd'
svn: E155016: This working copy is corrupt and cannot be upgraded.
Please check out a new working copy. svn: E155016: The file
'eeeee'
has no checksum
BY the way, the error file has Japanese Character in file name.
Maybe this is cause.
So How should i resolve this problem?
Thanks.
Looks like you've switched from 1.6 to 1.7 or 1.8. You don't mention where you got your copy of svn 1.6 you're using but it's possible you were using one that was patched with the fix for the unicode composition issue. Specifically there is a patch that's floating around that's in common usage but hasn't been applied to the project as a whole since it is not a complete solution. I'm not sure if Japanese would run into these problems since I don't know much about Japanese but it seems plausible.
I'd suggest that you create a new checkout from the working copy with your new Subversion client. I'm not sure if there is a good way to recover from this situation. In particular I'm not sure if the patch is capable of ensuring that svn upgrade executes properly.
On the other hand this might have nothing to do with the unicode issues on OS X and your working copy might just have been corrupted in a way that didn't turn up until recently. The upgrade command needs to touch everything in order to convert from the old flat file system to sqlite. So it often turns up corrupted working copies. It's usually not worth the effort to try to debug the corruption when you can do a new checkout.
If you have uncommitted changes you want to preserve in your working copy I'd suggest that you checkout the same revision(s) of the contents of your working copy with the new version. You ought to be able to figure out the version with an old 1.6 svnversion command or by manual inspection of the .svn/entries files. Once you've done that, rsync the contents of the old working copy over the new working copy while ignoring the .svn directories. Then run an svn update. If you don't get the versions of the working copy checkout exactly right you might have some additional issues when you run update. But hopefully you don't have too many uncommitted changes to clean up.
Alternatively you can try installing a 1.6 copy of Subversion and seeing if you can diff your changes out and determine the correct versions. But I'm not sure what the state of the working copy databases will be during an interrupted upgrade. This might be the best way to go since I believe we're really careful about not botching things.
I try to check out the repo to a new computer but Smart SVN on mac os x claims that working copy format of ~/ProjectPath is too old '0'.I tried everththing that i found on the web.I upgraded svn to 1.7.6 and i also downloaded the lastest version of smart SVN but it really did not help.
svn upgrade says the following
svn: E155019: Can't upgrade '/Users/ilker/Desktop/CallingCard_v2.0' as it is not a pre-1.7 working copy directory
and svn cleanup says
svn: E200030: sqlite: no such table: wcroot
the only difference that i have on this machine is that i have mac os x 10.6.8 while other clients have at least 10.7.I think but it should not matter.
Did you try the svn checkout command to get a new working copy instead of trying to svn upgrade your current one ?
I have faced the slightly different situation that resulted in the same error.
I made checkout on a server that had almost 0% space free. The checkout downloaded the parent directory from SVN but not the content. When I freed disk space and made check out the issue was still there.
When I deleted the parent directory and made checkout again the issue disappeared.
So you may try deleting the checked out content and checkout again.
xCode is giving me trouble, and i've been unable to help myself so far.
When I commit my project, xCode reports:
The working copy "[projectName]" failed to commit files
svn: Commit failed (details follow);
svn: '/Users/[user dir]/[path to project]/[source dir]/.DS_Store' is not under versioning control.
Funny thing is, I'm not even trying to add or commit the .DS_Store. Anyway, I tried to resolve this error by deleting .DS_Store using finder (very futile, pops up again right after killing it), and the command line (less futile, but still no luck).
Then I followed this advise http://soledadpenades.com/2009/07/02/keeping-ds_store-files-at-bay/ to add .DS_Store to my ignore list, both in the project dir and all subdirectories using
svn propset svn:ignore .DS_Store .
However, I will admit, that I did not know exactly what I was doing there. I've been using SVN for a long time on Windows exclusively with the Tortoise UI, and feel an appropriate amount of shame for not owning sufficient svn command line skills.
After the ignore, the error looks like this:
The Woking copy "[projectName]" has failed to commit files
svn: Commit failed (details fllow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating
I guess that happens if you follow advise from the internet blindly without a sufficient level of understanding (shame on me).
Performing an update, didn't do anything, all files were up to date.
Because I don't want to make things worse than they are right now, I'd humbly ask for some help from you awesome guys and gals.
Thanks,
Chris
Answer
Forcing a commit from terminal. After that, using source control in xCode worked fine again.
The Mac OS stores additional information in .DS_Store. This is why you can't delete the folder: The OS needs it.
What you need is to tell SVN to ignore the folder. That's what you did.
For some reason, editing svn:ignore has the side effect that the folder gets "out of sync" (whatever that means).
The solution here is to update the folder: svn up . from the terminal. After that, you can commit the new property.
After restarting Xcode, everything should be fine again.
Try to edit the ignore list from inside Xcode next time, it might do the necessary magic for you.
I have a problem with git.
Basically, here is what I have. I access a svn repository through git. Until now, on python files, everything worked fine.
But lately I also added some pyd, dll and lib files on the repository. THe first update went well. But then, these files have been modified and since then I can't update. These files were added from a windows computer with TortoiseSvn on the svn repository.
If I do a git svn rebase on linux, everything works fine.
If I do a git svn rebase on windows with msysgit (and also tortoisegit), I have the following error : fatal: write error: Invalid argument
If I do a git svn rebase on windows with cygwin, I have the following error : didn't find newline after blob at /usr/lib/perl5/vendor_perl/5.10/Git.pm line 916
I tried several stuff (autocrlf true/false, safecrlf true/false), adding .gitattributes file with the following line *.* -crlf -diff -merge and nothing worked.
I'm a little stuck here so any suggestion would be welcome.
Thanks in advance.
Had identical issue with Msysgit v1.7.2.3, the latest version as at 29 Sep 10, and wanted to share my findings here (Google turns up several cases, but no solutions).
Trying to do "git svn rebase" on a repo (that has this has worked on plenty of times in the past) consistently failed with a "fatal: write error: Invalid argument" after a certain number of commits. The sync would then revert to the beginning again.
I believe this is a bug in Msysgit relating to large(ish) binaries and available memory (on a Win XP SP3 system with 4GB RAM and plenty free HD space). The remote system was the DotNetNuke SVN repo on CodePlex (https://dotnetnuke.svn.codeplex.com/svn).
Initially it was choking on a 330KB "CHM" file (~212th commit, r52261). It consistently did so, even after disabling Avast AV, Google Desktop, etc and verifying that there were no other processes with locks on the repo folder. After a reboot (but opening Outlook, Dreamweaver, etc), it then was consistently and repeatedly failing on a ~15.3MB DLL (~416th commit, same revision).
Finally, after another reboot, disabling Avast, Carbonite and Google Desktop and running no other programs, the sync worked first time.
This seems to point firmly to my conclusion that it was an available memory issue, probably linked to the presence of a largish binary and large number of commits in the revision. Note that I also tried "git fsck", "git svn reset xx" and tweaking the "packSizeLimit" / "usedeltabaseoffset" config vars, without success.
I've found that the best policy for using Git on windows is to tell it to not do anything about line endings.
I don't know if that will help you recover your current git repo, but it's worth a shot.
I set:
[core]
autocrlf = false