[Kde-scm-interest] Kopete git migration

Thu Apr 18 20:13:08 UTC 2013

On Fri, Apr 19, 2013 at 7:48 AM, Pali Rohár <pali.rohar at gmail.com> wrote:
> 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

This is not necessary. We grant exceptions to the commit policies when
migrating projects such as Kopete from Subversion.

> 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

Regards,
Ben Cooksley
KDE Sysadmin

>
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest
>