- we preserve history currently stored in svn
- a new integration branch should exist - we used the incomplete package model with svn-buildpackage, but now it makes more sense to have the complete history, including the upstream code at the time
- all previous orig tarballs should exist in the git repo in pristine-tar format
- upstream's svn repo should be included entirely so that we can cherry-pick any patches we might want or need
Tonight I have experimented a little with my git-svn clones which I made previously and eventually thought that:
- the main repo should track the upstream repo via git-svn
- I should properly tag the debian package versions in the svn.d.o repo, so svn tags no longer look like branches in git
- ideally all the branches in the package repo should be reproduced in some corresponding branch in the final repo
- the integration branch (that should contain the real debian complete packages) should be created with a non-existant merge strategy which I call overlay (basically, for two branches A and B, the strategy resumes to: all files as in A are present, any files unique to B are present)
- using pristine-tar forces me to keep the 'upstream' branch reserved so I need to avoid using that
It seems the last point could be obtained in some way via this small set of commands (I am sure it needs some modification to make the integration work in another branch C):
git merge --no-commit -s ours B
git checkout B -- .
git checkout A -- .
git commit
Note: Looking back, I think I can do a better job next time and I will se if I can use the resulting repo to create a new repo and drop the svn package maintainance for wormux. If this works, I might be able to create a script to allow migration of svn-bp maintained packages to git, at least for the Debian Games Team.
Since you can't fix a problem if you don't take things one at a time, I started by cloning the initial git-svn generated repos.
So after waiting some time (both git-svn fetch commands took long enough), I had to git-svn repos:
- repo A - the package repo
- repo B - the upstream svn clone repo
In the end I got my A' repo that had:
0 eddy@heidi ~/usr/src/wormux/tt/debian-bare $ git br -a
debian-experimental
debian-sarge
debian-sid
* master
origin/debian-experimental
origin/debian-sarge
origin/master
Yes, and having master in A' is not a good idea, but since I made A' a bare repo I had to suffer. Well, one more thing to better in iteration 2.
Excellent, now I can go in B and add the new remote repo which is A' which I should have called pkgsvn, but I ended up call it 'origin'. Since git-svn doesn't treat the svn repo as a true remote, this was possible.
Due to some confusion I also added 'ups-' as a prefix to the svn remote trunk and tags, but I am still unsure if this was necessary - I'll have to see more clearly into the pristine-tar restrictions area.
After all of this I got this branch configuration:
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch
* master
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch -r
0.8-final
0.8beta4
origin/debian-experimental
origin/debian-sarge
origin/debian-sid
origin/master
ups-tags/wormux-0.7
ups-tags/wormux-0.7.2
ups-tags/wormux-0.7.3
ups-tags/wormux-0.7.4
ups-tags/wormux-0.7.9
ups-tags/wormux-0.7.9rc1
ups-tags/wormux-0.7beta3
ups-tags/wormux-0.8
ups-tags/wormux-0.8alpha1
ups-tags/wormux-0.8beta1
ups-tags/wormux-0.8beta2
ups-tags/wormux-0.8beta3
ups-tags/wormux-0.8beta4
ups-trunk
wormux-0.7
wormux-0.7.9
wormux-0.8beta1
wormux-0.8beta2
So more tracking branches were necessary; I fired 'gitk --all' and got a nice picture, after adding tracking branches for branches originating from A':
This is not yet complete and now I am feeling sleepy, so I'll continue once I experiment more.
1 comment:
Greetings,
Thanks for sharing this link - but unfortunately it seems to be down? Does anybody here at ramblingfoo.blogspot.com have a mirror or another source?
Thanks,
Jack
Post a Comment