So far, I’ve spent all morning creating a new Subversion repository for all my projects and importing all my existing code. I previously had each of my projects in a separate repository – I liked the clean separation. However, I started using some code from one project in a second project, and because of this organization, I ended up just keeping two versioned copies of the same file.
But, the bigger problem I ran into recently is that one of my repositories became corrupted. Subversion couldn’t find whole sections of my project when I tried to check out earlier versions. The latest versions always seemed to update and check out fine, but most of the earliest check-ins were lost. This made me a little bit nervous. So, between wanting to having everything centralized and wanting to make sure I started fresh with a totally uncorrupt repository, I’m checking everything into one place.
I debated which way to organize the new repository – should projects go at the top, or at the bottom? Like this:
root -> Project1 -> trunk
-> tags
-> branches
-> Project2 -> trunk
-> tags
-> branches
Or like this:
root -> tags
-> branches
-> trunk -> Project1
-> Project2
In the end, I decided on the first option. In a way, this lets me continue to keep the code and check-ins fairly separate, while allowing me to share code across the repository.
How do you have Subversion organized? Any tips for making sure my repository doesn’t go corrupt *again*?
I currently have my projects in separate repositories. I think I had the same feeling you did about the sense of separation, but am now also facing problems with wanting to “link” between some projects.
I’m not quite convinced to go the single repository route, yet. In particular I think projects for clients will always go in separate repositories. It makes me feel good to know that I have something concrete and separate that I can use to generate a source drop for a client or whatever.
Given your current switch to a single repository, I would suggest keeping the tags and branches at the highest level. Doing otherwise you end up with a similar problem to the separate repositories issue: you will have to manage multiple tags for a single release. Suppose you have MyProduct 1.0 and it depends on sources from MyProduct and MyLibrary. Now to tag the release you’ll have to tag both MyProduct and MyLibrary. Putting a tags folder at the top allows you to easily tag the whole thing.
Of course, you could keep both and just have a “globaltags” folder at the top level.
I haven’t thought it out too well, but I like the idea of some kind of thin module on top of subversion that would automatically handle “multi-repository projects”. This would eliminate a lot of the decisionmaking about whether to group as single or multiple repositories. It would be great to be able to say “this project is comprised of the following SVN repositories.” Then when you wanted to tag or checkout you could just refer to the “meta repository” that knew about all the required repositories.
I haven’t even looked to see if something like that might exist out there. I think that would be a pretty nice, flexible add on.
That’s a pretty good point – basically, what I really want is a combination of the two options I described. I want the trunks separate, and possibly the branches, but I really want the tags to be repository-wide. Very good point.
And some sort of meta-svn browser is an excellent idea. I’ll have to think about that. I’m sure there’s some tough problems to solve in a program like that.
Oh, and yes, a few of my projects will remain separate – one is totally unrelated to any cocoa work that I’ve been doing, and one was just a proof of concept for a friend – similar to client code.
It has to be asked whether you’re using the “fsfs” or “Berkeley DB” back-end for your repository storage. The DB backend is notorious for going corrupt, and I learned this the hard way myself
Releases of subversion over the past several months (longer?) have defaulted to the “fsfs” format for this reason.
If you’re getting corruption from the fsfs format then I guess I will add a little bit of paranoia to my setup. I have been error free since changing formats a while back.
Unfortunately, I am using fsfs.
*But*, I have kind of a funky setup besides that. I have my repository hosted on the same hosting account as this site (with a different subdomain), and they weren’t really set up for Subversion. I’m accessing it using svn+ssh and had to do some specific setup so that I could access Subversion that way. Every now and then, I will get some errors if multiple processes are trying to update the repository from the same machine at the same time. This tended to happen when Xcode was querying the repository at the same time I was using SvnX to make some updates – forgetting that Xcode 2.2 could now access my svn+ssh URLs correctly.
I don’t know if that was the cause of my problems, but problems nonetheless. I don’t really know how to inspect any repository structures to see exactly what the damage is – but it’s on my list of to-do’s to try to take a look sometime.
Interesting. Well hopefully I’m safe for now since I’m keeping my repositories local. If your hosting company doesn’t support subversion, I think Dreamhost does and is pretty cheap.
We are inheriting a previous installation of Subversion with all its trees and branches and so forth. Did you happen to create any utilities to assist you with importing your existing framework? Just curious, because it looks as if this could be potentially time consuming if we have to manually import hundreds of disparate development branches into a new SVN installation!
Any tips or hints or pointers to sites involved with batching any of this stuff?
Ugh – I haven’t found a good way to reorganize repositories quickly and easily (or to import an existing repository along with all its history into a new repository). For me, even small reorgs require LOTS of individual file moves. Blech.