[Kde-scm-interest] Fwd: ideas to git conversion
Johannes Sixt
j.sixt at viscovery.net
Thu Dec 4 14:46:56 CET 2008
Raul Fernandes schrieb:
> Having the all history is a good idea a priori, but
> it will consume a lot of space to a totally unnecessary thing.
> Actually, garbage for the most of people.
> We are working with Qt4, why do you need the history form Qt 1, 2 and
> 3 to be immediately available from your copy of kde repository?? If
> you need it, it always be available from the svn repository (in
> read-only mode). And there is no many times you will need it.
KDE has a few "live" branches, that is branches where changes are
committed to: There's trunk, there's 3.5, perhaps 4.0, 4.1, and 4.2
(ReallySoonNow). At the time when a conversion to git happens, *all*
history is needed that goes back to the fork point X of the oldest live
branch if SVN should go into read-only mode:
X--o-...--o--o--o--o--o--o--o--E--o--o master == trunk
\ \ \ \
o--A 3.5 o--B 4.0 C 4.1 D 4.2
because if a fix is applied to the oldest live branch, then it will have
to be merged into the later live branches:
X--o-...--o--o--o--o--o--o--o--E--o--o--M master == trunk
\ \ \ \ /
o--A o--B C D /
\ \ \ \ /
F---------M-----M--------M---'
^ 3.5 ^ 4.0 ^ 4.1 ^ 4.2
In order to do this merge, a merge base must be known, and it would be X.
There do exist tricks that this is not needed (using grafts), and, say we
had histories for each branch only starting at A,B,C,D,E respectively,
then the history after the merge would look like this:
E--o--o--M master == trunk
/
A B C D /
\ \ \ \ /
F---------M-----M--------M---'
^ 3.5 ^ 4.0 ^ 4.1 ^ 4.2
Not pretty, eh? But certainly only a matter of taste if repository sizes
prohibit more complete histories.
>> I don't know which version of linux repo do you use but I get my sources from
>> Torvalds repo and every version I need is in it.
>
> No. The Torvalds' repository has only the main development. The stable
> trees are in different repositories.
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y.git
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.24.y.git
This doesn't make a difference. They are still mere branches. The
difference is that Linus never merges from them.
That's a policy that I personally absolutely detest. As outlined above,
fixes should *always* be applied to the oldest live branch where it is
needed and then be *forward* merged. Not the other way like is customary
with KDE+SVN: fix on trunk and *back-port*. [I don't want to know how many
bug fixes are on trunk but never get back-ported due to
lazyness/forgetfulness/etc].
-- Hannes
More information about the Kde-scm-interest
mailing list