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

From: Eddy Petrișor <eddy.petrisor@gmail.com>
Date: Sep 10, 2008, 13:56 UTC
Message-ID: <60381eeb0809100656u1117cfb6i72e327495d513f9c@mail.gmail.com>
In-Reply-To: <20080829092927.GA7500@yp-box.dyndns.org>

(Please keep the CC. Thanks)

2008/8/29 Eric Wong <normalperson@yhbt.net>:

> Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
>> Hello,
>
> Hi Eddy,

Hello and sorry for the late reply.

(I was on a small vacation away from the computer in the last two weeks.)

Show 17 quoted lines

>> 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

WRT the revision pinning, it seems to me that is enough to locate that revision on the URI in question and checkout that revision. Still I am unsure if it would be wise to (stash +) svn rebase + checkout the pinned version (+ stash pop), since one would needlessly pull newer stuff as the remote svn HEAD advances, but the pinned version might simply stagnate.

I already have/wrote some code that follows the remote HEAD or a specific for the necessary, but I am unsure if is still present in the PoC script, is not that hard (in sh - a "svn info" on the URI, not on the local copy would reveal the real revision of the HEAD).

Show 22 quoted lines

>> 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.

Why was I under the impression that this wasn't working? Or was I expecting a shallow repo?

> 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.

as I already said, "svn info URI" can return the real revision, no need to ness with the pseudo-revision HEAD.

Show 9 quoted lines

>  "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.

I don't think I can follow you. Externals actually require exact revisions or can be made to pretend as if they do in git-svn context with continuous HEAD refresh.

Show 7 quoted lines

> 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).

Probably, and try later to tackle the problem.

Show 5 quoted lines

>> 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...

Will fix it.

-- 
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein