[Kde-scm-interest] Kopete git migration

Thu Apr 18 19:48:59 UTC 2013

On Thursday 18 April 2013 21:33:51 Jeremy Whiting wrote:
> On Thu, Apr 18, 2013 at 2:41 AM, Urs Wolfer <uwolfer at kde.org> 
wrote:
> > Hi Jeremy
> > 
> > Thanks a lot for your work! :)
> 
> No problem, glad to help.
> 
> > About the KRDC stuff: it's not that complicated: there was
> > one version until KDE 4.0, then for KDE 4.0 I have
> > completely rewritten KRDC, started from scratch. At the
> > moment the old version is in the branch "original". If you
> > could keep the branches / tags from 4.0 it would also be
> > okay. Do you think you can fix this?
> 
> Yeah, should be able to convert it to use the include
> common-kdenetwork-rules or alternatively expand that into
> krdc-rules and change the branch names for the old revisions.
>  We did similarly for one or two kdesdk apps if I recall
> correctly.
> 
> > I have shorty checked the kget repo and it looks quite good.
> > I will check more later. When should I notify the
> > maintainers to check their repos?
> 
> Maintainers can look now, but the strigi-analyzers at least
> has some interesting history towards the top of master branch
> I'd like to fix before that gets too many eyes on it.  The
> more eyes we can get on these repos the more accurate they
> will be when we do the real conversion though. I'll take a
> look at it, probably not until the weekend though.
> 
> > Do you think I should start backport the standalone fixes /
> > docs moving the the 4.10 branch now?
> 
> The simplest way to do that is after the migration to git by
> simply going into each git repo and doing a git cherry-pick
> -x of the commit on master on the KDE/4.10 branch.
> 
> By the way the post processing of kopete takes quite some
> time, as does the svn-all-fast-export run, even with a
> revlist to make it fast it took about 30 mins here.  I guess
> that's just how kopete is since it has so much history, but I
> think we probably ought to not include so many unused things
> in the main kopete repo in my opinion.  It's not a problem,
> but it sure makes kopete look messy in gitk and such to have
> so many branches lying around.
> 

Hi,

problem why kopete-filter script is slow is due to first git filter-
branch call (and not only because of big history).

Very slow is --tree-filter, because due to kde git policy all 
commits with *.orig and *.rej filenames are rejected. This filter 
removing that files on every commit with rm -rf. Next problem is 
with kdenetwork/doc directory which is imported into git under 
name doc-user. But Urs already imported it by svn revision 
1340343 and svn2git cannot handle this, so after svn rev, there 
are doc files two times (one under directory doc-user and one 
under doc). So there is filter which removing doc-user directory 
after svn revision 1340343. But because git filter-branch, script 
checking for svn revision number (in commit message) in each git 
commit in history (very slow).

Other problem why git filter-branch is slow is due commit message 
in svn revision 723898 which is in ISO-8859-2 encoding instead 
UTF-8. Because git pritning error for it, I added --msg-filter 
which fix encoding for svn rev 723898 with iconv tool. But again 
due to git filter-branch this checking for revision is done in 
every single git commit...

If you have other idea how to speed up removing *.orig files, 
remove doc-user after 1340343 and fix encoding in 723898, show it.

I'd rather include all branches (that which are merged to master 
too) into git history.

> BR,
> Jeremy
> 
> > Bye
> > urs
> > 
> > On 2013-04-17 19:40, Jeremy Whiting wrote:
> >> Urs, Pali,
> >> 
> >> I spent a bit of time looking at the existing
> >> kdenetwork-rules file today.  I also moved it into
> >> kdenetwork folder and split it into one rules file per git
> >> repository.  I intentionally left out kopete since those
> >> rules are on Pali's branch.  I suggest we merge that into
> >> master branch so all the work goes in one place. Pali, if
> >> you could move that that'd be great, otherwise I can if
> >> you want.
> >> 
> >> The rules look ok so far, I changed most of them to use the
> >> common-kdenetwork-rules I created based on the
> >> common-kdesdk-rules we used for kdesdk. but didn't do
> >> krdc-rules as the existing ones are a bit complex.  This
> >> means krdc is the one conversion currently that only has
> >> master branch, the others have normal kde X.Y branches and
> >> tags already, but need a bit of looking over before they
> >> are "final" I'll push up the existing rules conversions to
> >> scratch/whiting/blah for you to look over when you have a
> >> chance.
> >> 
> >> BR,
> >> Jeremy
> >> 
> >> On Sat, Apr 13, 2013 at 6:12 AM, Urs Wolfer
> >> <uwolfer at kde.org> wrote:
> >> 
> >> I have created an initial version of the wiki page:
> >> http://community.kde.org/**KDENETWORK/Git_Migration<http://
> >> community.kde.org/KDENETWORK/Git_Migration>[3]
> >> 
> >> Feel free to complete / improve it. The "last" table on
> >> this page need most work.
> >> 
> >> Also I have two comments for the current ruleset:
> >> - isn't this line required? "include common-kde-ignores"
> >> (or even somem ore "common" stuff?)
> >> - KGet got completely rewritten for KDE 4.0 in branch
> >> "branches/work/make_kget_cool/**kget"; I think we can move
> >> the old (i.e. until 4.0) KGet into the branch "original"
> >> (like KRDC), and put the new one which got copied to trunk
> >> later into master
> >> 
> >> It would be great if somebody with knowledge could review
> >> the existing ruleset and comment on what is missing /
> >> needs to be better.
> >> 
> >> Bye
> >> urs
> >> 
> >> On 2013-04-13 12:30, Urs Wolfer wrote:
> >> 
> >> Jeremy, thanks a lot for your reply. :)
> >> 
> >> I think such a wiki page is a good idea. I have collected /
> >> prepared almost all information already some months ago -
> >> I will setup this page in the next days.
> >> 
> >> I will also merge the standalone build changes from master
> >> for all of kdenetwork apps to the 4.10 branch once we have
> >> fully working migration scripts.
> >> 
> >> About the migration scripts: There are now two "parts"
> >> available: For all of kdenetwork:
> >> https://projects.kde.org/**projects/playground/sdk/kde-**
> >> ruleset/repository/revisions/**master/entry/kdenetwork-rule
> >> s<https://projects.kde.org/projects/playground/sdk/kde-rule
> >> set/repository/revisions/master/entry/kdenetwork-rules>[1]
> >> 
> >> And for Kopete:
> >> https://projects.kde.org/**projects/playground/sdk/kde-**
> >> ruleset/repository/revisions/**kopete/show/kdenetwork<https
> >> ://projects.kde.org/projects/playground/sdk/kde-ruleset/rep
> >> ository/revisions/kopete/show/kdenetwork>[2]
> >> 
> >> 
> >> Do you have an idea how this will work together? Do we need
> >> to create such detailed scripts for all parts of
> >> kdenetwork like Pali has done for Kopete? Or are the ones
> >> for all of kdenetwork almost okay? I cannot decide here
> >> because of my knowledge.
> >> 
> >> For Kopete plugins in extragear: I think Pali needs to
> >> decide. If plugins are in a good shape, you can include
> >> it. Or you could include it in branches.
> >> 
> >> Thanks for your help.
> >> 
> >> Bye
> >> urs
> >> 
> >> On 2013-04-12 21:49, Jeremy Whiting wrote:
> >> Ok, awesome.  I suggest we coordinate this effort like we
> >> did with kdesdk.  Urs since you are the module coordinator
> >> we need some decisions, either from you, or you can ask
> >> application maintainers also.  First of all I guess the
> >> idea is to split kdenetwork into one git repo per
> >> application like has been done in other modules?  If so
> >> what should we name each, the strigi-analyzers in kdesdk
> >> we named kdesdk-strigi-analyzers, so the ones in
> >> kdenetwork should probably be kdenetwork-strigi-analyzers.
> >>  Urs, what kind of time do you have to help with this
> >> effort? We need to copy the KDESDK/Git_Migration community
> >> page to something for kdenetwork which shows who each app
> >> should be maintained by, what each git repo should be
> >> called, etc.
> >> 
> >> Another question I have is if we should put all the kopete
> >> stuff from extragear and playground into the kopete git
> >> repo.  I believe all the stuff from extragear is already
> >> included in what Pali put together, is that right?  What
> >> about plugins/etc. from playground? is that included on
> >> branches also?
> >> 
> >> BR,
> >> Jeremy
> >> 
> >> 
> >> 
> >> Links:
> >> ------
> >> [1]
> >> https://projects.kde.org/**projects/playground/sdk/kde-**
> >> ruleset/repository/revisions/**master/entry/kdenetwork-rule
> >> s<https://projects.kde.org/projects/playground/sdk/kde-rule
> >> set/repository/revisions/master/entry/kdenetwork-rules> [2]
> >> https://projects.kde.org/**projects/playground/sdk/kde-**
> >> ruleset/repository/revisions/**kopete/show/kdenetwork<https
> >> ://projects.kde.org/projects/playground/sdk/kde-ruleset/rep
> >> ository/revisions/kopete/show/kdenetwork> [3]
> >> http://community.kde.org/**KDENETWORK/Git_Migration<http:/
> >> /community.kde.org/KDENETWORK/Git_Migration>

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- 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-scm-interest/attachments/20130418/33b170f4/attachment-0001.sig>