Migrating to git

[Raphael Kubo da Costa]

(Long message ahead)

Hey there,

#### What has been done so far ####

As you might have noticed, I've recently started working on the
conversion rules in preparation for moving kdeutils from SVN to git. I
have started from scratch, as Johannes Obermayr did not answer any of
those mails I sent him and CC'ed this list.

Right now, things are reaching an acceptable state, but a few things
still need to be ironed out before the real move (such as the tags
created by cvs2svn), some commit author names and addresses and maybe
removing files which were accidentally committed (such as .*.swp vim
files).

I have pushed to my scratch area the result of a recent conversion
experiment. If you are a KDE developer, you should be able to clone it
with

    git clone git at git.kde.org:scratch/rkcosta/kdeutils-conversion.git

otherwise, you should use

    git clone git://anongit.kde.org/scratch/rkcosta/kdeutils-conversion.git

I'd really appreciate if application maintainers checked the history
for their application with "git log -C -C -- dirname", such as 'git
log -C -C -- ark" and tell me if something looks wrong or is missing
-- svn mv's around should have been tracked automatically, but I had
to manually add some rules for the work done in /branches/work/kgpg2
or /branches/work/libarchive-based-ark, for example.

#### What needs to be done ####

We (the kdeutils team) need to decide whether we want to keep a single
repository (and history) for the whole module, or if we prefer to go
with a split layout. In a few words, keeping a single history means
there will be a "kdeutils" repository on git, and everyone will push
to the same repository in a similar way to what is currently done, and
choosing a split layout means the "kdeutils" module will only exist
virtually in KDE's git repository, as there is actually going to be a
single repository for Ark, a single one for KGpg, a single one for
KRemoteControl, so on so forth.

In the former case, the history for all modules is mixed, whereas each
application would only have its own history in the latter case.

mzanetti mentioned in the other thread that we should follow what the
other SC modules are doing. To be honest, there are not many
precedents (or consensus) yet -- kdelibs is staying as-is, kdebase is
being split into three separate repositories (kdebase-apps,
kdebase-runtime and kdebase-workspace), kdebindings is going the split
way, kdeaccessibility (IIRC) is staying as-is, kdepim is splitting
partially (between kdepim and kdepim-runtime), kdepimlibs stays as is,
as well as kdeplasma-addons. The other SC modules have not started
moving (or stated their layout decision) yet.

Anyway, what I have been told more than once in #kde-git is that
choosing the repository layout depends mostly on whether there are
inter-dependencies between the subdirectories in the module and
whether the developers work on many of them together (think of
kdelibs, for example). In our case, there are no inter-dependencies
(each subdirectory contains an independent application) and each
application maintainer usually does not commit to the other
applications.

Please notice that the converted repository I have pushed to
git.kde.org is not a split one, but that is mainly because I did not
know there was this option when I started writing the rules, so please
do not take this into account when emitting your opinions -- creating
separate repositories from the current rules should not require too
much work at all.

It is also worth mentioning that even if we choose a split layout,
that does not mean kdeutils is ceasing to exist as a module.

My personal vote is to go for a split layout, for the reasons I stated
above (especially no inter-dependencies).

---
Raphael Kubo da Costa
rakuco (Ark maintainer)