Archive:Xbmc-git-svn

This page has notes on what is done for the migration from svn to git.

= XBMC Main Repo = This is the script used to sync the xbmc git repository from the svn repository.

= Vendor Branches = All vendor sources are being recloned from their respective upstream VCS repositories. We're keeping each vendor source as it's own repository on sourceforge. The "current" branch in the repos is the branch we pin ourselves to make modifications. They are the specific tags or revisions we modify from the respective upstream for xbmc. The "master" branch contains those modifications made from the "current" branch.

faad2
cvs from sourceforge

FFmpeg and libswscale
Setting up a repo for FFmpeg with libswscale included was somewhat tricky due to libswscale residing in a different location than FFmpeg. We made use of git-submodule to make this work.

libswscale
First we start off by setting up libswscale. Cloning and pushing libswscale is relatively easy. There's no branches or tags to worry about.

We pin ourselves to a particular revision, namely r29464. XBMC svn repo has it as we pinned ourselves to r29476, but the last change made to libswscale was actually r29464.

Afterwards we create our "current" branch, then push the "master" and "current" branches to reside in refs/heads on our remote branch in sourceforge. The branch used to track libswscale svn, "git-svn", is also pushed to refs/heads.

FFmpeg
Next we setup FFmpeg. FFmpeg has branches and the trunk branch in svn, but no tags. Here is what's done for our vendor repository of ffmpeg

Next is pinning down what revision we're working with. Here we pin ourselves to r19851

Now we create the current branch, push master and current to sf, then push the branches used to track ffmpeg svn up to sf.

libswscale as submodule
Now we want to add libswscale into our ffmpeg repo as a submodule. This is simple enough.

We check that it was written correctly.

Then we commit via our ffmpeg repo (the superproject) and push.

Finally, we want the submodule added for the "current" branch as well. We checkout current and ignore the warning saying that libswscale couldn't be removed (it shouldn't be). Then we simply merge with master and push current to sf.

Now for anyone wanting to checkout the vendor repo for FFmpeg with libswscale as a submodule, it's a matter of using these four commands.

liba52
svn from videolan

libcdio
Development for libcdio is done with a git repository so this one is really simple.

We pin ourselves to release 0.80 and create the "current" branch.

Now we push to sourceforge.

Here we didn't push the branches or all tags from the libcdio upstream git since they're using a git repository anyway. Instead, anyone wanting to track changes from upstream can simply do the following in the libcdio repository cloned from xbmc.

libdvdcss
Fetching libdvdcss is rather simple.

We always change the default location where tags get placed.

Now we fetch.

Now we pin ourselves to the 1.2.10 tag and create the "current" branch.

Finally we push to sourceforge.

libdvdnav
There's no branches or tags for libdvdnav either, so it's just a simple clone.

We reset to a particular commit made back in Feb. 2, 2009 (revision 1167). Then we create the "current" branch.

Now we push everything to sourceforge.

libdvdread
There's no branches or tags for libdvdread, so it's just a simple clone.

We reset to a particular commit made back in Feb. 15, 2009 (revision 1168). Then we create the "current" branch.

Now we push everything to sourceforge.

libmpeg2
svn from videolan

libprojectm
svn from sourceforge

libsquish
svn from googlecode

ogg
ogg development is done in an svn repository with a non standard layout. There's no branches to track.

We modify where the trunk and tags get stored in the git repo.

Now we fetch

We track the 1.1.3 release of ogg and create the "current" branch.

Now we push to sourceforge.

Python
We're currently fetching from svn for now. We'll switch to using the hg-git plugin or hg-fast-export once the Python migration to mercurial is complete.

Python has a standard layout for their svn repo (branches, tags, and trunk). We want to change where tags gets placed, so here we start by creating a directory for python, then doing a 'git svn init'.

Next we modify where the tags will go.

Now we start fetching.

We pin ourselves to release 2.4.6 and create a "current" branch.

Now we push to sourceforge.

Fetch after git clone
If you cloned the python repo, either directly or via git submodule within the xbmc git repo (once it's up), you may setup the python repo to fetch from python. Here we do the initial setup, then change the locations for the tags.

Then you push in a similar manner as if you had cloned the python svn repo directly. Just supply the correct refspec for the branches and tags.

timidity
cvs from sourceforge

vorbis
vorbis development is done in an svn repository with a non standard layout. There's no branches to track. This is pretty much the same way to clone as ogg.

We modify where the trunk and tags get stored in the git repo.

Now we fetch

We pin ourselves to tag 1.2.0 and create the "current" branch.

Now we push to sourceforge.

zlib
unknown VCS