(Please keep the CC. Thanks) 2008/8/29 Eric Wong <normalperson@xxxxxxxx>:> Eddy Petrișor <eddy.petrisor@xxxxxxxxx> 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 thatrevision on the URI in question and checkout that revision. Still I amunsure if it would be wise to (stash +) svn rebase + checkout thepinned version (+ stash pop), since one would needlessly pull newerstuff as the remote svn HEAD advances, but the pinned version mightsimply stagnate. I already have/wrote some code that follows the remote HEAD or aspecific for the necessary, but I am unsure if is still present in thePoC script, is not that hard (in sh - a "svn info" on the URI, not onthe 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<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 Iexpecting 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, noneed 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 exactrevisions or can be made to pretend as if they do in git-svn contextwith 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��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
