I think we should make it a policy to never convert other projects' revision control to git, if they're not already git, because the extra software it requires packagers to learn, install, and use does not convey any extra benefits. (And I REALLY don't want to have to install bzr or hg or perforce on my machine to update a package, EVER.)
git-svn (which is something completely different from git-svn-mirror) might get a pass because it's not an extra thing to install and I already mostly know how to use it, but dammit it's still an extra thing to learn and it still doesn't help us. The way I see it, we need source control to help us do the following things: * Publish the code we're using and the changes we've made. * Separate the changes we've made from the pristine, upstream version. * Trace each one of our changes to an individual author, and preferably learn something about why each change was made. * Update our version of the code with new code from upstream, while still keeping our changes intact. * Maintain multiple stable branches for projects that have multiple stable revisions that we need to care about. Most importantly, our set of changes will be very similar for each branch, but not identical, and our source control should help us keep it straight. * Backport important fixes that have not yet made it to an upstream release, or that are not present on an older stable branch that we still care about. In order to do everything consistently and with the same tools, we're using git for everything. This requires us to get code from projects not using git into git somehow. There are two possible approaches to doing this. One is to import the project's entire history, in whatever original form it takes, using some automated tool. I've already explained why I don't like this approach. I think we should instead import snapshots of the project into git manually as needed (in most cases, I would advocate for doing this every release, but every project is different and some may not have releases or may not have them often enough). That approach looks like this: * Create a new Git repository with a branch named 'upstream' (or something like upstream-2.6 if we need to track multiple upstream branches). * Download a tarball of a release of this project, dump the files in the repository (without the project-version prefix they usually add), and commit them. * Create a master branch based on the upstream branch, and do the packaging work. * Create a repository in the coapp-packages organization containing both the master and the upstream branch. You can have mirrors in your own github account if that is how you like to use github. I won't judge. To update: * Checkout the upstream branch (if you prefer to keep a separate repository for every branch, you're doing it wrong, but git will let you), remove all the files, add the new files, and commit. * Checkout the master branch. * Merge the new upstream branch into the master branch. * Test to make sure you didn't completely break things. * Push it to coapp-packages or make a pull request or whatever it is you kids with your githubs are doing these days. As for the idea of keeping one's private repository separate as a "testing" stage, this is entirely separate from the question of importing changes from a foreign RCS. I think that if there's a need for this, it should be done with separate branches in the same repository. That is what branches are for. Private repositories are for changes you have made that are not yet approved to go in the official repository. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
