Re: [PATCH 0/3] git-svn-externals PoC (in a sh script)

[Eric Wong <normalperson@yhbt.net>]

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

Eddy Petrișor <eddy.petrisor@gmail.com> 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 #2: t9126-git-svn-submodule.sh --]
[-- Type: application/x-sh, Size: 988 bytes --]