Given the team meeting this evening I guess this is my last chance to comment. The main reason I haven't so far is that I find myself simply caring less and less, but well.
I really have only one argument against the switch to git: the splitting of the repository into multiple separate repositories. IMO that split is a huge loss. If there were really huge advantages *for D-I as a Debian project*, I could imagine accepting that loss, but IMO there are no significant advantages. Debian Installer is *one* (upstream!) project with components that are sometimes tightly related, which should have a *single* (either central or decentral) repository; splitting components into separate repositories will cause inefficiencies and a large number of annoyances in day-to-day development work. The way D-I is managed as a project and most work on D-I does IMO not require distributed SCM, and for the situations where either distributed or offline work is desired, git-svn is IMO a more than adequate solution. Let me also make clear that I have very little against git, except that it has a *lot* steeper learning curve than subversion. I use git a lot myself and it's a great environment to work in. If git offered a good solution for keeping D-I as a _single_ repository, I'd probably be in favor of a switch. In the proposal a few things besides the manual and master PO files are now weirdly kept in a "master" SVN repo: - scripts - kernel/massbuild* So for example when there is a kernel update, we'll now have to do an svn commit to update the massbuild.versions file, followed by separate git commits to update the various kernel-versions files. This exactly shows *why* D-I should live in a single repository: D-I is a single *upstream* project, and not a loose collection of unrelated components. Sure, 'mr' is being proposed as "the" solution to keep it all hanging together. I somewhat remember the announcement of 'mr' as a useful tool to keep repos for *unrelated* projects up-to-date. It's fine for that purpose, but promoting it as the glue for the proposed D-I setup is just crazy. It means that developers will now have to choose between *three* sets of commands (mr, git and svn) to do stuff as NONE of them will be appropriate in all situations. Doesn't that just sound crazy by definition? Is that an environment to which you can easily invite new contributors? IMO it's simply butt ugly. Here's a few things that currently are possible using git-svn (or with any solution that keeps D-I as a *single* source repository) that will no longer be possible with the new setup. - git grep across repo (mr is no option) - git gc across repo (mr probably is an option for this) - using gitk across repo (mr is no option) - branching across repo - committing related changes in multiple components in one commit The last two are actually the most important. I've had *many* occasions where a change required interdependent changes in multiple components, for example in multiple partman components, or in pkgsel and di-utils, or in a component and in the D-I build system. If D-I is a single repository I can simply create a new branch and work there. If the components are split up, I will continually need to create branches, make sure that I'm in the correct branch for the current component when changing directories, etc. And I will no longer be able to commit related changes in different components as a single commit. And even if I could use 'mr' (which probably is possible) to create branches for all separate git repos at the same time, and switch all those branches at the same time, that will only show the craziness of using 'mr' for that purpose: - it is horribly inefficient as git will need to load all individual repositories; - for most components those branches will remain unused - 'mr' can never *guarantee* that all components are on the same branch: that is 100% dependent on the user remembering to use 'mr' and not git - 'mr' would probably also (try to?) create branches for the SVN parts of the repo, which will cause its own problems I've also objected before to the incomplete switch. The current demo repos don't even include branches for all the release-specific updates we've done! Why would you want to do a migration where you don't include all the stable and security updates? When the migration from CVS to SVN was done at least nothing was lost. This migration simply drops a lot of work that was done in the past (such as obsoleted components), which means that the SVN repo will need to be kept forever if we think history is important. As conclusion: if the rest of the team really wants to switch to the proposed setup, then please go ahead. But to me the whole scheme sounds insane. The whole plan reeks of "we want to be able to work in git, but we can't be bothered to do a proper migration". And in the proposals I have seen no mention of concrete examples of things that will be possible after the switch to git that are not possible now (using subversion for the central repository, with git-svn as option for distributed and offline work). Cheers, FJP On Thursday 13 August 2009, Joey Hess wrote: > Other whole-tree tags and branches are not included. These include > sarge, etch, and lenny tags and branches, and old tags like rc1, rc2, > rc3. As mentioned above: why not? I'd think especially the release branches are essential. It also means you do not have tags for versions uploaded to testing or stable. > I am not currently filtering out the da.po miscommits. Leaving them in > increases the total git repo size by 5 mb. If they are removed, there > are two ways to do it, that affect tags made during the problem > period in different ways: > > 1. Keep da.po miscommits in the tags. This bloats the git repo size > about the same amount, and means that those tags will not be > connected to the rest of the repo history. > 2. Drop the bad da.po changes from everything, including tags. That > would mean that 17 tags don't match what was originally committed > to svn, but would otherwise work great. IMO that cleanup should still be done _before_ a migration. That should give a clean migration while keeping correct history. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org