Confused about svn vs git

[Eike Hein]

On 02/24/2011 03:35 PM, Dirk Mueller wrote:
> Could somebody please summarize for me where I should tag the 4.6.1 release
> from?

[18:29] <dirkMob> can somebody drop me an email with the mapping on 
release-team@?
[18:29] <dirkMob> Ihave to drop offline and I'll be back online later
[18:30] <dirkMob> Sho_ or dfaure?

Ok, let me try to get a handle on this mess ... I'll start with
a preface on Kate and then go module by module.

a) Kate: There is a kate.git repository collecting KTextEditor from
    kdelibs, KWrite from kdebase-apps and Kate from kdesdk. However,
    this repository does not have a 4.6 branch, so it's irrelevant
    for tagging and tarballing those bits. Rather, their 4.6 ver-
    sions still reside in the 4.6 branches of the respective modules,
    some of which are in SVN and some are in git, as below.

b) kdelibs: 4.6 branch in kdelibs.git, to be tagged there, tarballed
    as-is.

c) kdebase-runtime: 4.6 branch in kde-runtime.git, to be tagged
    there, tarballed as-is.

d) kdebase-workspace: 4.6 branch in kde-workspace.git, to be tagged
    there.
    HOWEVER: This repository doesn't contain the wallpapers which
    used to be in trunk/KDE/kdebase/workspace/wallpapers. To solve
    this toma has created a 4.6 branch just for the wallpapers in
    SVN at: branches/KDE/4.6/kde-wallpapers
    So the wallpapers will have to be tagged there and spliced into
    the workspace tarball.

    In the future there might be a separate git repo for the wall-
    papers, as I understood things.

e) kdebase-apps: 4.6 branch in kde-baseapps.git, to be tagged there.
    HOWEVER: Konsole was split out into a separate konsole.git, which
    has its own 4.6 branch. Thus it also needs to be tagged there,
    and the tarball must be combined from kde-baseapps.git and
    konsole.git.

f) kdegraphics: This is another big mess. kdegraphics has been
    partially split up into many git repositories, the list of
    which can be seen here:

    https://projects.kde.org/projects/kde/kdegraphics

    They have 4.6 branches and need to be tagged there.

    HOWEVER: The migration of kdegraphics is not complete. Other
    parts of the module still remain in SVN (e.g. Okular). They
    would have to be tagged there, and the SVN and git bits com-
    bined into a tarball.

    Pino Toscano however says that the 4.6 branches of the git
    conversions haven't seen commits yet and could perhaps also
    be tarballed from SVN. They could perhaps also be tagged in
    SVN and the tags manually recreated in git later, but that
    seems to come with no gain to me vs. tagging in git directly.

g) kdebindings: kdebindings has radically changed its layout
    and split into many git repositories. However, there was
    also a clear decision made that 4.6 would be packaged from
    SVN precisely due to that. So it's to be tarballed from
    SVN ... as for where to tag it, no idea. I guess tech-
    nically the git repositories also contain 4.6 bits, but
    I don't know whether the kdebindings folks are keeping
    this in sync / what their plan is to have git history be
    complete, also tag-wise if it's still tagged in SVN.

h) kdeplasma-addons: 4.6 branch in kdeplasma-addons.git, to
    be tagged there,  tarballed as-is.

i) kdepimlibs, kdepim-runtime and kdepim: are also in git,
    but not released afaik, so no tagging or tarballing.

j) kdeexamples: Is in kdeexamples.git, but has no 4.6
    branch ... we don't tag or tarball this anyway, right?

k) The other modules remain in SVN at the moment, to be
    tagged and tarballed from there.


NOTE: Some have suggested putting the workspace tarballs
and Konsole into separate tarballs, however packagers have
(unsurprisingly) emphasized that this is not what they expect
from a point release and that it reduces the chances of the
point release making it into the hands of users due to update
process rules and so on. Since the point of a bugfix release
is to get it into the hands of users, I'm against the split-
ting personally (4.7 is a different story of course).


> Thanks,
> Dirk

-- 
Best regards,
Eike Hein