This is maybe unusual so let me set the scene:
We have an SVN repo containing our project history - an embedded system based on Linux. The SVN repo contains Linux kernel, U-Boot, busybox etc. sources and all our in-house apps, filesystem and such.
The Linux kernel we have is old and crusty and I am working on porting to the mainline, which is under active development for our platform(s). I am doing the kernel-side work under git and trading patches with "The Community".
I could get things working and take a snapshot of the kernel sources and dump it into SVN, but I'd like to keep the ability to get updates, have local branches and manage patches with git. I could keep two copies of the kernel, one managed by each SCM, but that would be a bit messy. There are also risks of developing and testing using kernel sources managed under git, and forgetting to put those changes into SVN resulting in broken SVN versions where the non-kernel sources are out of sync.
Migrating the entire project to git isn't an option. Managing just the kernel source with git and having a bunch of glue scripts and stored hashes in SVN is possible but it's nicer to have a unified history / diffing ability from SVN for the whole project.
What I'm considering is trying to manage the kernel sources under both SVN and git simultaneously, in the same directory.
As a kernel dev I'd mostly use git and do an SVN commit for internal use when things look good. For other internal users they would be able to get the entire, consistent sources with one SVN checkout, see a unified history, and they could make changes to the kernel sources under SVN. Later I or another git-using person can SVN update to those changes and commit them to git as appropriate.
Some funning around getting git to ignore .svn files and vice versa will have to be done. Also I'm not quite sure how one would take a plain SVN checkout and tell git to start managing the kernel subtree as well, but I'm sure git has some obscure swi开发者_JAVA百科ss-army-knife options to do it.
So that's my idea du jour. It means most co-workers don't have to worry about git, and we can quietly ignore git and fork away later as needed.
The question here really is, has anyone done something like this, how did it work out, or what alternate solutions did you come up with?
I've done this regularly, and it works great.
The only major thing I needed to do was add the .git folder to the subversion ignore list, and the .svn/ folders to the .gitignore file.
精彩评论