Re: git-svn and empty directories in svn

From: Steven Grimm <koreth@midwinter.com>
Date: Dec 3, 2006, 04:08 UTC
Message-ID: <45724DB0.4060607@midwinter.com>
In-Reply-To: <20061203014756.GE1369@localdomain>

Eric Wong wrote:

Show 5 quoted lines

> Since git-svn misses some other stuff (many property settings,
> externals) I'll be working on an internal logging format that can help
> track those things.  It'd be nice to have a command like git svn
> checkout which works like git checkout; but empty directories are
> created.

Presumably once the submodule support is worked out, svn externals could be represented as git-svn-managed submodules, yes?

In fact, I'd go so far as to say it should be a design goal of the submodule support: you should be able to indicate somehow that a submodule is a git clone of some non-git resource, and anything that iterates through the submodules (e.g. to freshen them from their respective origins) should know how to run git-svn or whatever so it's all seamlessly integrated. I suppose that's a special case of making git-svn and friends more tightly integrated with git in general; if the git "push" and "fetch" commands know to run git-svn instead of talking to a remote git repository, then it might Just Work for submodules.

Independent of the supermodule being managed by git-svn, the "my software depends on externally-managed code" problem that submodules are attempting to address would be solved a lot more comprehensively if the remote code base could be an svn repository and git knew enough to run git-svn as appropriate to keep it fresh. (Not just svn, of course; any foreign CM system that has an equivalent of git-svn should work.) It'd be pretty cool to have a supermodule that tied together some native-git-managed code, a couple of external svn repositories, and a CVS tree or two, all under a single umbrella with the details automatically taken care of by default.