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 <jpwhit...@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 <jpwhit...@kde.org> wrote: > >> >> >> >> On Thu, Apr 18, 2013 at 2:41 AM, Urs Wolfer <uwol...@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 <uwol...@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> >>>> >>> >> >
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
