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
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.
Reply to: