I have checked out now a local working copy of a codebase that lives in an svn repo. It’s a big Java project that I use Eclipse to develop in. Eclipse of course builds everything on the fly, in it’s own way with all the binaries ending up in [project root]/bin. That’s perfectly fine with me, for development, but when the build runs on the build server, it looks quite a lot different (maven build, binaries end up in a different directory structure, etc).
Sometimes I need to recreate the build server environment on my local development system to debug the build or what have you, so I usually end up downloading an entirely new working copy into a new workspace and running the build from there (prevents cluttering my development workspace with all the build artifacts and dirtying up the working copy). Of course sometimes I’m interested in running the full build on code that I don’t want to check in yet, so I will manually copy over the “development” workspace onto the “build” workspace. Besides taking a lot of extra time copying a lot of files that I don’t actually need (just overlaying the new over the old), this also screws up my svn metadata, meaning that I can’t check in changes from that “build workspace” working copy, and I often end up having to re-download the code to get it back into a known state.
So I’m thinking I make my svn working copy a local git repo, then “check out” the in-development code from the svn working copy/git master, into the local build workspace. Then I can build, revert my changes, have all the advantages of a version controlled working copy in the build workspace. Then if I need to make changes to the build, push those back into the git master (which is also a svn working copy), then check them into the main svn repo.
|-------------|
|main svn repo| <------- |---------------------|
|-------------| |svn working copy | <------- |--------------------|
| (svn dev workspace/ | | non-svn-versioned |
| git master) | | build workspace |
|---------------------| | (git working copy) |
|--------------------|
Just switching everything to git would obviously be better, but, big company, too many people using svn, too costly to change everything, etc. We’re stuck with svn as the main repo for now.
BTW, I know there is a maven plugin for Eclipse and everything, I’m mainly interested to know if there is a way to maintain a workspace that is both a git working copy and an svn working copy. Actually any distributed version control system would probably work (hg possibly?). Advice? How does everybody else handle this situation of having to manage both a “development” build process and a “production” build process?
The idea of cloning a git repo (copy of a svn repo) into another git repo can work.
Since Git1.7.0, you can associate this approach with sparse checkout if you do not want to checkout everything from your first Git repo.