[FFmpeg-devel] Fwd: svn:externals using git submodules

[Ismail Dönmez]

Since we discussed this some time ago, I guess some of you will be interested.

----------  Forwarded Message  ----------

Subject: svn:externals using git submodules
Date: 01 May 2007 Sal
From: Andy Parkins <andyparkins at gmail.com>
To: git at vger.kernel.org

Hello,

I've done this by hand as a proof of concept I suspect it would need loads of 
work in git-svn to do it properly.  However, I thought I'd mention as part of 
my "success with submodules" reports.

ffmpeg is managed with svn; I like to track its development with git-svn.  
Works wonderfully except for one problem: they've made use of svn:externals 
for one component, libswscale.  Previously I just regularly updated the 
libswscale subdirectory by checking out the latest copy (which is all that 
subversion does) and committing it to my own branch off upstream.

With submodule support in git, it makes it possible to do a much better job.  
What I did was have two svn-remote sections in the config:

[svn-remote "ffmpeg"]
    url = svn://svn.mplayerhq.hu/ffmpeg
    fetch = trunk:refs/remotes/ffmpeg-svn

[svn-remote "libswscale"]
    url = svn://svn.mplayerhq.hu/mplayer
    fetch = trunk/libswscale:refs/remotes/libswscale-svn

After running git-svn fetch; there are two independent branches in my 
repository:

  -- * -- * -- * -- * -- * (ffmpeg-svn)
  ---- * ----- * ------- * (libswscale-svn)  

Now, we fork from ffmpeg-svn and libswscale-svn to make non-tracking branches 
that can be committed to:

 $ git checkout -b master-ffm ffmpeg-svn
 $ git branch master-sws libswscale-svn

Next, we create a shared clone of the repository as a subdirectory in that 
repository.

 $ git clone -s . libswscale

Now we want that clone to be even more strongly linked to the parent - to the 
extent that they share the same refs, etc:

 $ cd libswscale
 $ rm -rf .git/refs .git/logs .git/info description config
 $ ln -s ../../.git/refs .git/refs
 $ ln -s ../../.git/logs .git/logs
 $ ln -s ../../.git/info .git/info
 $ ln -s ../../.git/config .git/config
 $ ln -s ../../.git/description .git/description

Only HEAD and index are independent.  Next we switch from the ffmpeg branch to 
the libswscale branch in this subdirectory:

 $ git checkout master-sws

Now, we make the subdirectory a submodule in the parent:

 $ cd ..
 $ git add libswscale
 $ git commit -m "libswscale is now a submodule"

How dangerous is this?  I've made the repository it's own submodule and it 
shares the same refs, info and logs.  LIVING ON THE EDGE MAN!

You have to run two git-svn commands to sync with upstream:

 $ git-svn fetch ffmpeg
 $ git-svn fetch libswscale

Then of course you would merge

 $ git merge ffmpeg-svn
 $ cd libswscale; git merge libswscale-svn; cd ..
 $ git commit -m "Sync with upstream"

Personally I think that's pretty cool, this is significantly better than 
svn:externals because the particular revision of libswscale in use is 
recorded.  Seriously - someone show me another VCS that can do that - I think 
git has actual magic powers :-)

I dare say that git-svn could do much better because it could reconstruct the 
submodule history based on the repository dates and create the link in the 
tracking branch rather than having to do it manually at the end as I've done 
here.  That would mean that the recorded submodule was right for all 
history - again, not the case for svn:externals, if you check out a previous 
version the external remains current.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins at gmail.com
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070501/61352bb5/attachment.pgp>