Thread (9 messages) flat view 9 messages, 2 authors, 2016-06-15

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 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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help