Hi Maik, I was looking at exactly this issue yesterday.
On 20/07/2012, at 6:32 AM, Maik Musall wrote: > One server, an extensive folder structore on that, where eventually some > subfolder represents a project. In that project folder again subfolders for > the app and each framework. In another folder somewhere in the structure > there are subfolders for the generic frameworks. As I understand subversion, > there's no hard distinction between folders and repos, as a repo is also just > a folder that happens to contain the project files. We have a similar structure in one of our Subversion repos: some top-level organisational folders, with folders named for the projects they contain below those, and then finally trunks/tags/branches, and then the actual projects, within those. Some of the projects are related, others are essentially standalone. This works just fine with Subversion, as you can root a checkout at any arbitrary point in the repo's tree. (So in that way there's no hard distinction, but as Kieran notes elsewhere, commits to that kind of working copy still apply to the repo as a whole.) I'm tending towards the opinion that this is not a good repository structure for Git. (I touched on this in a thread last month: "WO, Git and Jenkins: Impedance mismatch?") The problem reduces to the fact that you _can't_ check out a working copy from an arbitrary point in the tree. This imposes only a minor change in workflow for Eclipse (in that you clone the entire repo once into one place, and then import the projects you need into your workspace from there), but for build systems and other tools that want to work on a single project at a time in a discrete workspace it imposes the overhead of having to clone the entire repo repeatedly for each project. (We have an application with four separate Eclipse projects, and we're building 'master' and 'develop' branches for each—8 clones on the build server.) It's not so much the disk space that bothers me (disk is cheap), it's the feeling that there must be a better way. Kieran writes: > Sounds a lot like the manner in which Project Wonder is arranged ... a > hierarchy of nicely organized files, folders and subfolders. Wonder is different in that it has a monolithic, integrated build system. Imagine if you wanted to build every framework in Wonder separately. >> IMHO, just do a one-to-one svn repo conversion and convert the svn history >> to git history (plenty of articles showing how to do that, and it should be >> straightforward if your svn layout was always the standard >> trunk/branches/tags. > > Unfortunately, there's a mixture between stuff using the standard > trunk/tags/branches layout and stuff that just sits directly in it's folder. > Sigh… I've found that git-svn-clone does a pretty reasonable job of converting the Subversion conventions for branches/tags into their Git counterparts. Combined with git-filter-branch, you should be able to extract individual projects from your existing repo into their own Git repos. Further, unless you have currently active branches, you could just forget about _converting_ them altogether (in which case they would end up in a folder called 'branches'), or simply ignore them. It depends how particular you are about preserving history. (I used to think I was very particular about preserving history. It's amazing how _actually trying to do it_ can relax your outlook.) > Good thing is, I can clone and look at it at will locally, so I'm now > experimenting with different layouts. The most probably outcome so far looks > like one repo for the app and the app-specific frameworks, and separate repos > for each generic framework. But I have no idea yet how to manage the > dependencies between those. That's pretty much what I decided on. I've made the move with a couple of applications, one of which has four Eclipse projects in it as mentioned above—that's about as big as I would like to get. What are the dependency issues you're worried about? This is a topic I am very interested in—keep us up to date with how you go, Maik. -- Paul Hoadley http://logicsquad.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
