Damyan Ivanov wrote: > -=| Russ Allbery, Thu, Jan 24, 2008 at 03:14:43PM -0800 |=- > > I still find it really important to be able to separate out individual > > changes to feed upstream when working with a CPAN package. With quilt, I > > can do that. With git, I can do that, > > How? > (I am not saying it is impossible, but every time I try to imagine how > to do it, I reach a point where quilt seems far more convenient :) * Create a branch for the change. * Make the change there. * Merge the change back to master. * When there's a new upstream release, handle it as usual (ie, use git-import-orig to update the upstream branch, and merge it into master). * Then merge the upstream branch into the change's branch too. (Or, skip doing this if you're lazy.) * When you want to send the change upsteam, git diff between the upstream branch and the change's branch. * (If you decided to be lazy before, merge the latest upstream release into the branch first.) There are much more complicated and even possibly automated ways to do it of course. > TTBOMLK (L=limited), git-svn can't help us here as we use a repository > structure that is not that straight-forward. git-svn works best with: > $SVN/ trunk/ (here the main line of development goes) > branches/ (branches, one directory per branch) > tags/ (and tags, one directory per tag) > that is: one trunk, one place for all branches, one place for all > tags. > > and we have (ignoring the multi-package "detail"): > $SVN/ trunk/ (same as above) > branches/ > upstream/ > current/ (here's the "HEAD" of the upstream branch) > 1.01/ (and these are "tags" of it) > 1.02/ > 2.00/ > other branch1/ (possibly for backports, security, > other branch2/ stable-updates etc) > tags/ (these are the tags out of trunk) > > Perhaps there *is* a way to convert this, however it seems far from > trivial to me. git-svn can handle this ok, I converted a similar layout in my own svn repsository when coverting it to git. You have to run git-svn once per package, creating a separate git repo per package, and pass it --trunk, --tags and --branches. > * accounting (for a lack of better words) > > right now, one has to simply run "svn up" in a checked-out trunk/ and > all packages are updated and new ones checked out. As Git would use > one repository per package, we'll need some sort of "service area" > where the list is kept. http://kitenet.net/~joey/code/mr/ is my solution to this. However, there's certianly a problem here, in that if you have 500 git repos, a single "mr up" means 500 individual ssh connections to alioth to update them. It is possible to use ssh connection caching to speed things up. mr can also run N updates in parallel. > Currently git.debian.org shows 776 repositories, this takes ~10s to > show here, perhaps half of these being due to network traffic (~430K > at approx. 1Mbit/s)) > Doubling this may not be well accepted by alioth admins If scalability of gitweb on the front page is an issue, alioth is going to have to deal with it doubling with or without us, I'm afraid. :-) -- see shy jo
Attachment:
signature.asc
Description: Digital signature