[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: d-i git repo: sample conversion

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 

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 

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
- 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).


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.

Reply to: