[Kde-scm-interest] Kopete git migration

Jeremy Whiting jpwhiting at kde.org
Tue May 7 23:49:15 UTC 2013


Looks like kdepim got the contents of what was in
kdenetwork/kfile-plugins/rfc822 at least, but not it's history.  I don't
think we need that in kdenetwork-strigi-analyzers, but adding all the rules
to make it ignore it is a bit tricky (need to add ignore rules for tags,
branches, and trunk) we probably should just remove those commits in post
processing I believe.  I defer to nicolas to suggest the best way to do
that though.

BR,
Jeremy


On Tue, May 7, 2013 at 5:20 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:

> Urs,
>
> I just spent a few minutes looking at the kdenetwork-strigi-filters which
> was broken and found there was a delete in svn of kfile-plugins after it
> was moved/renamed to strigi-analyzer, so adding an ignore of the deletion
> revision fixed that. However there's also some old history of a
> kfile-plugin/rfc822 that was moved to kdepim as shown here:
> http://websvn.kde.org/?view=revision&revision=200868 do we need that in
> the kdenetwork-strigi-analyzers repo? (I'll check now if it's already been
> made part of the kdepim repo).
>
> thanks,
> Jeremy
>
>
> On Thu, Apr 18, 2013 at 1:33 PM, Jeremy Whiting <jpwhiting at kde.org> 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.
>>
>> 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-rules<https://projects.kde.org/projects/playground/sdk/kde-ruleset/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/repository/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-rules<https://projects.kde.org/projects/playground/sdk/kde-ruleset/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/repository/revisions/kopete/show/kdenetwork>
>>>> [3] http://community.kde.org/**KDENETWORK/Git_Migration<http://community.kde.org/KDENETWORK/Git_Migration>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20130507/e45da346/attachment-0001.html>


More information about the Kde-scm-interest mailing list