On 2012-07-19, at 4:09 PM, Paul Hoadley wrote: > 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.
Some of these links may be useful in addressing this: http://speirs.org/blog/2009/5/11/understanding-git-submodules.html https://help.github.com/articles/worki http://kerneltrap.org/mailarchive/git/2007/5/1/245002 http://alexking.org/blog/2012/03/05/git-submodules-vs-svn-externals https://github.com/patmaddox/giternal/ Like Paul, I am interested, but still learning. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/gvc/practical_webobjects _______________________________________________ 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]
