[Kde-scm-interest] Git roadmap

[Johannes Sixt]

Thiago Macieira schrieb:
> 2) the conversion from Subversion to git
>   Chris's work on the git-svn-fastexport tool is a good start, but our 
> repository is extremely complex. We need to develop the tool further to 
> be able to import the repository correctly.

Sorry, but I have to ask: What can be "complex" in an SVN repository?

>   Someone on #git has suggested we import all of SVN into one monstruous 
> git repository and then work from there, inside git. I believe, however, 
> we can extract some more metadata from Subversion (read: file-copy 
> relationships)

git does not represent file-copy relationships, so the don't need to be 
converted.

The most important information to be recovered are where merges happened. It 
would be invaluable to represent them in the converted git repository.

There exists a conversion of a part of trunk (not all revisions back to the 
root) at http://userweb.kernel.org/~hpa/kdegit/kdegit.tar.bz2 (that's the 
tar'd-up repository), which is 3GB.

This alone gives an idea what can be done and how the final conversion 
should *not* look like: It shouldn't be a single repository because it's to 
clumsy to be handled that way. Probably, it is also wise to keep historical 
parts in a separate repository (maybe everything before the KDE 4 porting 
efforts and all KDE 3 branches).

> 3) repository layout, ACLs, hooks, etc.
>   First and foremost, switching to git brings the question of whether we 
> should have multiple repositories in KDE (as opposed to a single one like 
> we have with Subversion). I'm not talking about clones. If we have 
> multiple repositories -- which is the recommended way in git -- we have 
> to decide where to split and how to glue everything to gether with 
> submodule support.

I think it's pretty clear:
- Have each major module (kdelibs, kdebase, kdenetwork, ...) in its own 
repository. Also kdeadmin (which in svn is linke in as external) should be 
in its own repository.
- Have an "umbrella" repository that basically only consists of submodule 
references to those major modules.

I don't think that it's necessary to have a finer-grained separation.

>   Then we need to think about the "social" side: who gets push access? Who 
> gets fast-forward-only push access? Will we require "SignedOff by"? Where 
> will we keep our post-commit hooks, like the kde-commits at kde.org mailer? 
> How will we protect the official tags? How will we protect the Root CA 
> files in kdelibs? Etc.

IMHO, there should exist "the one and only official KDE repository".

And only few people have push access to it.

Those people are the "integrators". They pull from the "trusted lieutenants" 
(who are probably in charge of the individual submodules) and publish to 
this official repository.

Other points you raised:
- fast-forward-only push access: don't know what you mean
- Signed-Off-by: naah... KDE could live without it for 10 years, why require 
it now?
- post-commit hooks: The only place where they make sense is in "the one and 
only official KDE repository".
- official tags: git can sign tags with GPG. Is that sufficient?
- protect Root CA: If "protect" means "cannot be changed behind our back": 
As long as you regard SHA1 as sufficiently secure, this is impossible with git.

-- Hannes