There is a recent discussion about AUTOREV which has got me thinking a bit about the big picture and incremental development.
Currently AUTOREV injects into PV. The reasons for that are historical, when OE was not taskhash based we had to do that to trigger updates. There are now different ways it could be done with the revision just needing injection into PKGPV for packaging purposes. I've also been looking at externalsrc bugs. This got me thinking, if we did make AUTOREV work without messing with PV, we could probably go a step further and allow the fetcher to incrementally update an existing git checkout rather than remove and start again from scratch. Patches may or may not be an issue, we could mandate a clean single git:// srcuri to start with although the patch code can remove the patch stack already. This would need to hook in to disable some of the cleanup/removal code. The usecase would be to allow the developer to pull updates from a remote repo, or even commit changes locally and then have the system "flow" the changes through from there. This would remove the annoying clean and re-checkout process which drives some developers crazy. It might also allow externalsrc to change to a new model with less deviation from the normal workflow. Whilst on the subject, I have also been wondering about a new image target, effectively one that would build a new image but then allow an rsync over to a running target. Obviously this may or may not be advisable depending on what was actually running but for some development, it could be useful. Anyway, just thinking out loud but wanted to document the idea. I might look into at least improving the way AUTOREV works... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1725): https://lists.openembedded.org/g/openembedded-architecture/message/1725 Mute This Topic: https://lists.openembedded.org/mt/100618420/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
