[Kde-scm-interest] Fwd: ideas to git conversion

[Raul Fernandes]

2008/12/4 Johannes Sixt <j.sixt at viscovery.net>:

> because if a fix is applied to the oldest live branch, then it will have
> to be merged into the later live branches:

I think that the fixes is generally backported, not the way you said.
In any case, the merge is not the solution. It has to be
cherry-picking (getting one patch and applying to other branch). The
work will be almost the same if there are one or more repositories.

> But if SVN is read-only you can't apply fixes there, and you *have* to
> keep 4.0, 4.1 alive in git, and merge 4.0->4.1->4.2->master occasionally.

I have said to stay in read-only svn only the ancient history. Not
these branches that has some activity. These branches stay in other
git repositories. So, we will have these repositories:

kde-3.5.x
kde-4.0.x
kde-4.1.x
kde-4.2.x (soon)
kde (trunk)

The rest of the history will be in in the read-only repository.
When another new stable branch is out, another repository will be
create with the history until the point of *fork* and the work
continues in the *main* repository.
Of course, I'm talking about the stable repositories, those
repositories that has release versions. Each developer will have a
personal repository that can live in the git.kde.org server and has
experimental branches.

>> As for 3.5, at this point in time, it can be considered a completely different
>> codebase, so anything there can't be merged into 4.2. So it would be either a
>> patch or a manual change.
>
> Fair enough. 3.5 *is* a completely different beast.

It's I talking about. It's like another project. Why do we want a copy
of the whole history in each developer's computer?? It's useless.


Raul Fernandes
rgfernandes at gmail.com