From: Eddy Petrișor Date: Wed, 10 Sep 2008 13:56:10 GMT Subject: Re: [PATCH 0/3] git-svn-externals PoC (in a sh script) 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 : > Eddy Petrișor 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.) >> 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). >> 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 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. > "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. > 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. >> 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