[Kde-pim] Git migration rules

Thomas McGuire mcguire at kde.org
Thu Mar 11 11:10:58 GMT 2010


Hi,

On Tuesday 09 March 2010 19:17:31 Torgny Nyblom wrote:
> On Tuesday 09 March 2010 15.51.14 Stephen Kelly wrote:
> > Torgny Nyblom wrote:
> > > On Monday 08 March 2010 21.23.26 Thomas McGuire wrote:
> > >> Hi,
> > >> 
> > >> On Monday 08 March 2010 21:04:28 Ingo Klöcker wrote:
> > >> > [..]
> > >> > And then there's a whole bunch of private work branches I didn't
> > >> > look into.
> > >> 
> > >> branches/work/~vkrause had some interesting branches.
> > > 
> > > Guess it's not that hard to extract all relevant branches however
> > > should we try and follow some sort of naming convention? If so any
> > > suggestions?
> > 
> > If a branch has already been merged, does it need a name? Can't we just
> > keep its history and not give it a name?
> 
> Yes but... Then we need to be certain about what branches we should keep
> since all others (not merged with history) will be lost.
> 
> So if someone can give me a list of these branches and we are 100% sure
> about them, yes.

Ok, these branches need to exist in the repo, they are still active:
- trunk
- the X.Y branches (well not sure if we need them all, but at least the 4.Y 
  ones, for the occasional securtiy fix)
- akonadi-ports (Akregator is there)
- enterprise (KDE3-based, still active development)
- enterprise4 (still Kleopatra-related development)

Branches that are fully merged, which we don't need as a branch in the repo:
- branches/kdepim/soc
- branches/work/kdab-post-4.0
- branches/kdepim/proko2
- branches/work/kdepim-3.5.5+
- branches/kdepim/kmail-soc
- branches/kdepim/scalix
- make-it-cool branch
- osnabrück branch 
- branches/work/~vkrause

No idea about the other branches here.

I also found a bunch of branches in /branches/kdepim/, all of them (except the 
ones mentioned above) don't need a branch in the repo, including them in the 
history should be enough.

Now to some special enterprise issues:
There is branches/kdepim/enterprise/kde-l10n/ and 
branches/kdepim/enterprise4/l10n-kde4/. I don't think they should be included 
in the kdepim repo. Can they be added to a seperate repo instead, for example 
kdepim-enterprise-translations (with two branches)?

Then branches/kdepim/enterprise4 contains a bunch of forks of kdelibs and 
kdebase. I have no idea what to do with them, but we can't loose them. Maybe 
add as branches to the main kdelibs and kdebase repos?

Next point: enterprise and enterprise4 contain a "packaging" subdir, which I 
think shouldn't be included in the kdepim repo either. Can we have a seperate 
repo kdepim-packaging or kdepim-enterprise-packaging for that, with two 
branches? Just like kdepim-enterprise-translations.

That should cover the enterprise branches, I think.

The "runtime" subdir of kdepim should be added to a seperate repo, kdepim-
runtime.

Torgny, you and Ingo are communicating with each other to coordinate, I 
assume? Also, is there a wiki page with all information or is everything in 
this thread?

Thanks,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100311/f65b0bcd/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list