Eddy Petrișor <eddy.petrisor@xxxxxxxxx> wrote: > Hello, Hi Eddy, > I have started a while back working on support for svn:externals > support for git-svn, but since I'm not that satisfied with the current > status of the patch, I haven't modified git-svn itself and just left > the sh script I made as a PoC as it was. > > There's still work to be done to it, but I the current version is > functional enough to be probably found useful by more people than > myself. Cool. I definitely like the separate script approach. Not sure if you read my posts, your PoC seems inline with my thoughts on handling externals be seen here: http://article.gmane.org/gmane.comp.version-control.git/91283 http://article.gmane.org/gmane.comp.version-control.git/91293 > Current status follows: > > Current functionality: > - fetches all the externals of an already svn-fetched repo > - support for svn:externals refresh > - if the location of the external has changed, the current working > copy will be placed aside and a new directory will be created > instead > - if the remote URI is the same (maybe a verison bump, there will > be a 'git svn rebase' > - remove support (useful for testing purposes or clean restarts) > - avoid zombie externals at all costs - in some repos empty > svn:externals might exist; svn ignores such externals, so git should > do the same > > TODO: > - take into account the revision of an external, if it exists > - do not do deep svn cloning, to avoid legthy operations, just pull HEAD > (this actually needs changes in git-svn itself) git svn clone -r<latest_revision_number> URL should work if you extract the revision number easily. Specifying "-rHEAD" will only work if the branch of the external you're tracking was the last modified revision in the repository, so it's not very useful. "svn log" seems to have the same semantics as git-svn as far as -rHEAD being useful or not... > - use/create shallow copies to git svn repos (one revision should be enough > for most externals) > - use submodules for externals I'm not sure if mapping submodules to externals is a good idea because externals don't require exact revisions and submodules do. There's also an issue I was just made aware of two days ago with submodules and git-svn that I haven't had time to work on. Another user also privately reported a bug to me about git-svn having trouble dcommitting when using submodules. I've attached the test case here in case you have any thoughts on how to handle this (I think the easiest would be to ignore submodules on dcommit entirely). > Any comments are welcome. Also some small portability issues: "grep -q" is definitely unportable in my experience. There are probably some more that I am missing my eye at this time of night... -- Eric Wong
Attachment:
t9126-git-svn-submodule.sh
Description: Bourne shell script
