On Tue, Jul 15, 2008 at 08:29:42PM +0200, Geert Uytterhoeven wrote:
Over the weekend I played a little a script to extract the history
information as patch series from all the linux-* to the corresponding
m68k-* tag. I have to make some small changes to the repository to make
it easier for the script to properly detect all changesets (e.g. it has
small problems with duplicated logs, as they are used as index), but some
tag information need fixing too, as there are a few commits done between
tagging and import, so they get associated with the wrong release.
Assuming we want to preserve our history in a git tree I need two things.
First, I have an older copy of the repository, which I used for testing
and it mostly works, so a I need a copy of the last repository and it
shouldn't take too long to create the patches (most of the time will be
testing that the patch series really is equal to what has been tagged :) ).
Second, I could use some help on how to merge this into git, as I'm not
using git for much more than fetching the latest sources. :)
One problem here that the current git only starts at 2.6.12, where our CVS
starts at 2.4.12. We could create two repositories, where the first is a
simple CVS conversion as historical tree and the second is based on Linus'
tree starting from 2.6.12, which we can use as our development repository.
Has anyone already something like this? I know it's possible, but I had to
dive deeper into the git docs to find out how. If someone has example
scripts, it might really help and save some time. We basically need to
create a m68k branch, the patches are imported to it using the existing
v2.6.x tags, then the merge needs to be redone. The first patch in a
series is the merge patch, which produces the post CVS merge, so the
merge needs to be synced to this merge patch and committed.
Any other ideas?
The main question is now if and how we want to preserve the CVS history.
IMO it's possible to preserve it, but if nobody needs it, I don't need to
spend more time on it...
You probably want to talk to Ralf, he has some experience with this...
When I switched Linux/MIPS to CVS my intension was to totally obsolete
CVS. With the long history of the lmo archive and nearly zero history in
Linus' git archive that meant a significant overhead back in September
2005. Today the numbers look much more favorable - the overhead is a
constant size but git compression has improved and the overhead of the
histroy to Linus git objects and new MIPS objects has changed very
drastically. And for those who actually mirror the full CVS archive
git has been more space efficient at any time than CVS.
I occasionally dig into the history. Not very often but then it's often
about decissions relating to kernel interface changes or similar so having
the history is crucial. So I'm willing to pay the price.
In case of Linux/MIPS the CVS history started at 2.1.14. After that I
decieded I needed a 2.0 branch. Since starting off a 2.0 branch before the
beginning of history isn't possible in CVS this branch became a separate
repository. And anything predating these two repositories was
maintained as a collection of tarballs and patches. The changeover to
git gave me a once in a lifetime opportunity to unify all that history.
The result is a clean history that looks like Linux/MIPS was developed
using git since '94.
As for branches and tags, I keep Linus objects in the MIPS tree on
linux-mips.org; the git architecture mandates that. But I don't push his
2.3.4 style tags there to avoid the confusion. Any user who wants them
could pull them from kernel.org. For traditions sake my tags are named
like linux-2.3.4 so different from Linus' tags. Mostly because (ignoring
CVS' restrictions on naming of branches) the old CVS tags were named that
way already. In retrospective I should have used a more project-specific
naming scheme like mips-2.3.4 or lm-2.3.4.
The most painful thing of all is the actual conversion from CVS to git.
It's a once in a lifetime chance so it's worth pouring a bit of effort
into the conversion - see the git conversion of the m68k CVS on kernel.org
at http://git.kernel.org/?p=linux/kernel/git/ralf/linux-m68k.git;a=summary
Cheers,
Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
