This is sad to admit, but I am fairly new to Subversion. I implemented my first code repository like three weeks ago. So far I am loving it. It's really awesome to able to actually delete code rather than commenting it our or making ".BAK" files. Finally, a way to both clean and backup my code base as the same time.
As much as it has been easy to implement, I did run into a snag yesterday. I had just made some major changes to my application, including directory renames and dozens of file updates; when I went to commit the changes, it looks like everything was processing smoothly, and then suddenly TortoiseSVN told me that the commit failed at the very end. I tried to run the Commit again and it said that it could not work - it told me to run a Clean Up command. So I did that. But then, it told me:
Subversion: Cleanup Failed To Process The Following Paths
I tried to clean different directories, but none of them worked. To make things even more confusing, I took a look at the repository using the Repo Browser and it appeared that all the updated code had been, in fact, committed properly. What the heck was going on?!?
After a little Googling, it looks like sometimes Subversions commits actually work, but fail to unlock the code tree (or something) .... and there's not much you can do about it. From what I read, this is a known bug in Subversion. Unless someone has a better suggestion here is how I fixed my WWW code base:
- Created a new folder called "www_temp" at the same level as "www".
- Checked out Trunk [HEAD revision] into www_temp.
- Used Beyond Compare to make sure that the www and www_temp folders were in synch (that the Commit command actually committed all files and to bring over files that were purposely not part of the repository [such as an ACCESS database]).
- Renamed www to "www_failed_commit".
- Renamed www_temp to "www" and am using it as the new code base.
This was frustrating because it took a while to checkout the entire code base to the "www_temp" folder; but, it seems to have done the trick. I am gonna keep my "www_failed_commit" around for a while to make sure all the code it there, but it appears that the transfer worked properly.
Aside from this, I am really loving Subversion. I finally see what all the hype is about :) I hope that this might help some people out.
Looking For A New Job?
Ooops, there are no jobs. Post one now for only $29 and own this real estate!
I had to laugh when I saw the title of your post because I just finished a post myself describing a problem I had with Subversion. After I post I always check MXNA to see if my post shows up and there it was, immediately above your post. Of course my problem wasn't a bug, it was just my stupidity, but still, it was a funny coincidence.
I had the same thing - I have your post open in another tab and will read it after my conference call :)
I don't like SVN... whilst it is definitely an improvement over CVS, it's too quirky and SLOW.
For anyone not tied to SVN, I'd recommend switching to either Git ( git.or.cz ) or Bazaar ( bazaar-vcs.org ).
I have heard of Git. I don't find SVN to be too slow. I only commit like once or twice a day depending on what I am doing, so it's been OK. We are using a hosting SVN service, so doing it over HTTPS makes it noticeably slower, but still, I am OK with it so far.
I will definitely look into Git though.
@Peter: I too have heard of Git, but not investigated at all. Does it have integration into Eclipse similar to SVN? Does it have a decent Windows GUI?
>> Does it have a decent Windows GUI? <<
There is an integrated Cygwin-Git package that will run on Windows, and from within that you can invoke a GUI repository viewer (gitk), plus a commit staging area thing (git-gui) - the latter of which you can also create a edsktop shortcut to, so you don't even need to go into the Cygwin terminal.
>> Does it have integration into Eclipse similar to SVN? <<
There is a project named Egit which does Eclipse integration, but I've not yet tried that.
There's also git-svn which is some sort of bridge between Git and SVN - I'm not certain but I think that may allow you to use SVN tools with Git.
Do you mind sharing which hosted Subversion service you are using?
Actually, can you tell us more about why you decided to go with a hosted solution rather than managing the Subversion Server yourself on your own machine?
@macbuoy - the good thing about a hosted service is that you never need to worry about installation or maintenance or security patches etc. That's the job of the service!
The other thing is of course piece of mind. If your machine dies you know your code is nice and safe in a fully redundant environment which you can access from other machines.
That is of course another thing (for Bens environment). If he ever does distributed development, how will remote developers access his svn server? Of course it could be setup without too much pain, but just something else to worry about.
For me there are pleny of paid and free svn providers out there to use.
Before you get too far with Subversion, you'd do well to give Bazaar a try. Command-for-command, it's very similar to Subversion for most of the basics, and if you're into GUIs, TortoiseBZR is functional, though perhaps not as refined as TortoiseSVN.
I found that despite knowing the value of using source control, the overhead of setting up and maintaining access to Subversion repositories made it unattractive. Too many times I'd say, "I wish I'd been tracking this."
Not so with Bazaar. It fulfills the maxim "simple things simple and hard things possible" much better than Subversion. I love that I can start tracking files anywhere anytime without having to involve some outside server in the process. And I love the fact that if I do need to sync to some third party, that's all built-in, dirt simple, and flexible.
I'm not sure what to recommend with regard to hosting Bazaar repositories. The obvious choice, Launchpad.net, is (as I understand) only for open source projects. But you can host a Bazaar repository anywhere that's running sshd.
Give it a try; I'm sure you won't regret it!
Micheal hit it right on the head. For us, it was two things: backups and distributed development. We decided to go with CVSDude.com. Apparently they do backups many times through out the day. I can also create users and assign them different rights to different repositories. The whole things was really easy to set up.
Code is our product; if something were to go wrong, then we are screwed. As such, we didn't want the overhead of getting that process 100% perfect. We'd rather have experts handle it for us so that we can concentrate on writing the code.
So far, I am really pleased with their service.
You may want to consider doing commits more frequently than twice a day IMO. I will make commits at key points that I can go back from if need be just so that there is a version in the repo.
Just a thought!
I find that I do a commit when I have completed a "thought". Meaning, if I wanted to update the way something works, it might involve 10 different files. I don't commit until I have updated and tested those 10 files. But, I have no problems committing more than that.
Git is the New Hotness is some circles (like amongst Rubyists). It was originally designed by Linus Torvalds as the tool to manage the Linux kernel sources, so it's very much optimized for widely-spread, totally decentralized development. There's no central server, just lots of people with their copies of the source, swapping patches back and forth. This also means that it has lots of tools for handling branching, and N-way merging.
That may or may not be what you're looking for. What Git is good at, Subversion basically can't touch. But if you actually want a central authority, or a more traditional workflow, Subversion may be a better fit. Git can simulate some of those modes, but that's not really what it's FOR. I also find it conceptually much more difficult, but that could easily be a matter of relative unfamiliarity.
I had the same problem.
I deleted my local directory where the files were (after backing them up), and then did an update.
I need some sort of Subversion/GIT for dummies book. My designer mind has a hard time seeing the big picture or birds eye view of how a versioning system works. I'm behind the times and am tired of FTP'ing to a dev server and copying changes to a prod server. :-(
I dont' have anything in the way of a recommendation. I am relatively new to this stuff myself. Good luck!
Gah, sorry I'm late to the party on this post.
Those looking for a solid introduction to SVN would do well to read this (online) book:
(I've linked the "so you're new to SVN" chapter, but the whole thing's there)
I've found this book to be an exceptional piece of documentation.
I have to admit that I found that book a bit confusing. The order of the chapters felt very weird. I don't remember exactly, but I feel like the basics where towards the end and the beginning lacked explanation. Maybe it was just a bit over my head.
@Jono thanks for the link. I did check that book out a few months back and had a little bit of a tough time with it. I thought to myself, this would be a lot easier if I had a friend or coworker who fully understood it to point me in the right direction. One of those things I think if you see someone do it it's easier to understand.
Not possible in this case but wishful thinking. I will go back in and maybe skip a bit further down in the book, maybe once I get over the hump it'll be easier (or maybe I'm making it out to be more difficult that it really is).
Thanks this post saved my ass today, SVN was almost driving me crazy with this stupid error.
It's pretty lame though that I had to delete my old dir and create a new one. I don't like SVN at all too, but hey, it's free, has a nice windows GUI (Tortoise) and can be hosted on Linux servers (free too).
If you want something more reliable or at least with a company you can blame and complain for, spend some extra hundred bucks from your budget and get Microsoft's Source Safe (or similar, I don't know how they call this now). :)
Glad this could help :) Yeah, it is lame that you have to create a totally new folder and do all the refreshing... but like you said, its Free and it works pretty well like 95% of the time.
Same problem here, but I really (REALLY) didn't feel like checking out the original repository and copying over. So here is the very hacky solution: go search for "lock" files in the .svn directories (these are 0 length files that supposedly lock the directory). After deleting these files by hand I was able to do a normal update.
Disclaimer: I only did this because I hadn't worked on the project in a while and knew that I wouldn't lose code. If worst came to worst I could just do a clean checkout. Don't try this solution with critical code :-) Or at least back up any changes you made before doing so. Also, the first thing to try should be the cleanup command. Only if that fails, go and try the brute-force approach.
It's funny you mention that. I actually tried that using FlexRename:
After I deleted all the lock files, I tried to run cleanup again, and it broke in the same way. Maybe my problem was that I tried to run the cleanup again :)
Subversion is generally preferred by Windows user, due to the popular file system extension, TortoiseSVN. Bazaar seems to be used by mainly LAMP users; Apache, Unix, etc.
BTW I have this problem all the time with SubVersion; it just happened again, and I was hoping to find an elegant solution, instead of my normal method of blowing away all the hidden .svn files and tricking SVN. This time I had to re check out; like you described above, but in my case only half the files committed before it locked up... so i was stuck in monotony land for a while. Its not enough to make me want to switch though - I like svn for the most part.
I love Subversion (SVN), but I am definitely finding something things that you should not do. Namely, I have found it very ugly to use SVN to rename folders, especially if you are swapping names. Deleting folders has also been a bit dodgy. Still working out the best way to handle that.
The key to me, so far, seems to re-commit after *every* folder alteration (renaming or deleting a folder).
Yep; the key seems to be to tread lightly with svn. Folder deletes and renames are problematic and should be done carefully and in tiny steps; move files, commit; delete files, commit; etc.
Exactly - baby steps to completion :)
I actually found that doing an Update, followed by a Commit after doing things like renames, did the trick.
Hmm, I would be nervous about doing the Update only because sometimes when I delete via SVN, it deletes from the repository, but doesn't delete the folders locally (not always and not completely). I feel like doing the commit afterward finalize that physical delete.
It's just a workflow that I found works for me when using Tortoise SVN for deleting and renaming. It took me awhile to figure out what was causing so many problems for me with those types of operations, and then I started doing that sequence: Tortoise SVN delete/rename -> Update -> Commit, and it's been gold ever since. YMMV.
I will definitely reference this comment thread next time I do one of these actions (fingers crossed).
I haven't had this error before, so I'm guessing the place I'm using it here has an older version of SVN.
I also had this annoying error happening. I tried a commit, and saw it list my 'obj' directory as obstructing things. It looks like you can't have a non-SVN directory (at least) with the same name as something which exists in the tree under SVN. My renaming my non-SVN 'obj' directory, I was able to finally complete a cleanup.
That sounds funky. SVN is still something that I am getting comfortable with :)
I have got the same problem and actually solution for me was run the clean up from Administator's session on my Vista machine.
I know,UAC is very hostile
I encountered this problem today with my SVN through the TortoiseSVN client, a folder in my project appeared with the "obstructed" status and I couldn't do a CleanUp.
David Buhler's suggestion worked for me, I deleted the project folder and then updated from the repository.
I guess by shooting the 3-legged horse that was my local repository and bringing down a normal horse from my SVN server swept away whatever detritus in my local that caused this.
Just wanted to drop in to say thanks for adding this! The internet is a great place. Saved me a good hour of trial and error trying to figure out what that error meant :)
I've been using SVN for a number of years and had never been prompted to "cleanup" until I started using the Tortoise client. So I am not convinced this is an issue with SVN, but rather the GUI client. Think I'll stick with using PuTTY and avoid the headache.
Oh that's an interesting point - I never considered that it was a problem with Tortoise. Thanks for giving me a different perspective.
I found this post while looking for a solution to my SVN problem. Sadly, my "cleanup failed" problem is recurring every couple of days, so I don't think this is going to be a good long-term solution for me. What the heck is up SVN? This is really aggravating.
I pretty much only work in teams of One; as such, I pretty much use SVN like a back up rather than a branching / merging mechanism. I also don't use it as often as I should. All in all, I can't add too much more insight. Sorry.
I think my problem was my backup software. It runs every day and touches all the files. I moved my SVN repositories out of the folder that is backed up, and the problem seems to have gone away.
Ah nice! Good to know in case anyone comes up against that.
if subversion is a man, I wan to kick him in the nut over and over again. I got the same problem today that it locks up and can't be cleaned up, and it is crazy to check out a copy and try to see what has been changed.
I don't know much about svn, only used cvs a lot.
But I was able to go into the .svn folder and manually remove the lock and log files and then I am able to clean it up. I try to unlock before but it said there isn't any lock, weird.
I got this problem when I was doing mass commit, so in the future, I will commit small.
I've heard great things about GIT. I actually haven't touched too much code lately, so haven't done much committing.
The manuals explicitly warn against using network shares for working
copies. Especially because of these kind of possible errors.
Move the working copies to regular local disks and you should be fine.
I've been trying to move most of my development to localhost style lately. I've been really enjoying it.
Thank you. As a new Ankh user this was a bit unsettling. In my case it completely boiled down to a directory I had created, checked in, and deleted.
The interesting part is that the problem didn't show up until a couple commits later.
Nearly three years later and this post is still helping me out. Whew... I thought I had really screwed something up. Nice to know the fix is so easy. I tried it and now I'm cruising along again.
@Prosto - Hopefully this gets a response, but did you use tortoise, or command line to cleanup?
I just had this issue using Tortoise and ran across this post while searching. A good solution is provided at http://stackoverflow.com/questions/127932/svn-working-copy-xxx-locked-and-cleanup-failed
It's the second listed solution and basically goes like this:
1. Find all the 'lock' files in your .svn directories and delete them.
2. Run an Update.
In my case I also had some .svn file permissions that did not allow editing as well.
@Leviaguirre, do you still have problems with this?
Hi guys, I have just started with TortoiseSVN today and I have been trying to CHECKOUT a TRUNK so I can make a BRANCH. I feel like a lumberjack!
Every time (around 15 unsuccessful attempts) I tried to pull down I kept hitting this same problem, each time the file was located in the .svn/pristine folder. So I started taking a look at system logs and things.
It turned out that my antivirus (M$ Security Essentials) was trying to check all the files as they were being pulled down and then either finding a file that looked suspicious or just getting over worked, tried to pause the download so it can catch up. This in turn causes TortoiseSVN to stumble and possibly corrupt a file (still not sure on this bit).
All I had to do was tell my AV to not watch the folder containing my sites and the next time I tried to checkout it ran fine.... on with my work!
It may be worth just checking your AV, either suspending it or if you have the option tell it to 'Exclude a location' from real time scanning.
Thank you all for the info. It pointed me in the right direction.
Thanks for your comments. This can save a lot of trouble from users facing this problem.
svn sucks i don't know what your talking about