Re: [PATCH 0/3] git-svn-externals PoC (in a sh script)
From: Eddy Petrișor <hidden>
Date: 2016-06-15 22:45:20
(Please keep the CC. Thanks) 2008/8/29 Eric Wong [off-list ref]:
Eddy Petrișor [off-list ref] wrote:quoted
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.)
quoted
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).
quoted
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.
"svn log" seems to have the same semantics as git-svn as far as -rHEAD being useful or not...quoted
- use/create shallow copies to git svn repos (one revision should be enough for most externals) - use submodules for externalsI'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.
quoted
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