[opensuse-buildservice] how does osc handle long-lived branches?
Example scenario: - configure 'submitrequest_on_accept_action = update' in ~/.oscrc (BTW I can't find documentation for this option anywhere except for comments in the config file template. Once you delete them, the only way of retrieving them is to read the source :-/ ) - osc bco $prj $pkg - hack on home:$me:$prj/$pkg, test, hack, test etc. - commit to home:$me:$prj/$pkg - submitrequest to $prj/$pkg - submitrequest gets accepted - wait a couple of months for $prj/$pkg to get updated by other people At this point, I have numerous questions: 1. What is the state of home:$me:$prj/$pkg server-side? 2. Does it automatically contain all the latest changes from the upstream $prj/$pkg? i.e. if I do 'osc up' on my working copy, will I get them? 3. If so, why? - how does this work? 4. If not, presumably there is some equivalent of 'osc pull' which applies to branches rather than linkpac'd packages? 5. How would I cherry-pick some but not all of the upstream changes into my branch? 6. Is any of this workflow documented anywhere? http://en.opensuse.org/openSUSE:Build_Service_Collaboration would be the obvious place for it, but it's not there yet. So, trying to reverse-engineer this, I see that my working copy of home:aspiers:branches:openSUSE:Tools/obs-service-tar_scm contains the following line in .osc/_files: <linkinfo baserev="663c096f8c0695af0960d98d6ed7b435" lsrcmd5="b01017819c52ddd0eabd72fd7d5d3c64" package="obs-service-tar_scm" project="openSUSE:Tools" srcmd5="ffd170170ba0a40a0db1015702ccdee5" /> and also 'osc log' shows: ---------------------------------------------------------------------------- r9 | buildservice-autocommit | 2012-07-27 13:35:33 | b01017819c52ddd0eabd72fd7d5d3c64 | unknown | rq129093 baserev update by copy to link target Looking in my working copy of openSUSE:Tools/obs-service-tar_scm, I see that .osc/_files contains: <directory name="obs-service-tar_scm" rev="ffd170170ba0a40a0db1015702ccdee5" srcmd5="ffd170170ba0a40a0db1015702ccdee5"> So 'lsrcmd5' in the branch points to the baserev update autocommit, and 'srcmd5' points to the directory revision of the upstream project. But I'm still not really any wiser - what does baserev point to, how is it used? Thanks! Adam -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Donnerstag, 1. November 2012, 15:56:08 schrieb Adam Spiers:
Example scenario:
- configure 'submitrequest_on_accept_action = update' in ~/.oscrc
(BTW I can't find documentation for this option anywhere except for comments in the config file template. Once you delete them, the only way of retrieving them is to read the source :-/ )
- osc bco $prj $pkg
- hack on home:$me:$prj/$pkg, test, hack, test etc.
- commit to home:$me:$prj/$pkg
- submitrequest to $prj/$pkg
- submitrequest gets accepted
- wait a couple of months for $prj/$pkg to get updated by other people
At this point, I have numerous questions:
1. What is the state of home:$me:$prj/$pkg server-side?
2. Does it automatically contain all the latest changes from the upstream $prj/$pkg? i.e. if I do 'osc up' on my working copy, will I get them?
No and yes.
3. If so, why? - how does this work?
On the server (and also on your local checkout in un-expanded mode) nothing changes. However, an "osc up" usually runs in expanded mode and that means it tries to merge the changes from the linkes package as long as no versioned link is used. The same happens when a build is starting.
4. If not, presumably there is some equivalent of 'osc pull' which applies to branches rather than linkpac'd packages?
"osc pull" works on branches!?
5. How would I cherry-pick some but not all of the upstream changes into my branch?
We have no cherry-pick function. You can of course show the diff and apply it to your copy.
6. Is any of this workflow documented anywhere? http://en.opensuse.org/openSUSE:Build_Service_Collaboration would be the obvious place for it, but it's not there yet.
I do not understand what exactly you want to achieve at all.
So, trying to reverse-engineer this, I see that my working copy of
home:aspiers:branches:openSUSE:Tools/obs-service-tar_scm
contains the following line in .osc/_files:
<linkinfo baserev="663c096f8c0695af0960d98d6ed7b435" lsrcmd5="b01017819c52ddd0eabd72fd7d5d3c64" package="obs-service-tar_scm" project="openSUSE:Tools" srcmd5="ffd170170ba0a40a0db1015702ccdee5" />
and also 'osc log' shows:
---------------------------------------------------------------------------- r9 | buildservice-autocommit | 2012-07-27 13:35:33 | b01017819c52ddd0eabd72fd7d5d3c64 | unknown | rq129093
baserev update by copy to link target
Looking in my working copy of openSUSE:Tools/obs-service-tar_scm, I see that .osc/_files contains:
<directory name="obs-service-tar_scm" rev="ffd170170ba0a40a0db1015702ccdee5" srcmd5="ffd170170ba0a40a0db1015702ccdee5">
So 'lsrcmd5' in the branch points to the baserev update autocommit, and 'srcmd5' points to the directory revision of the upstream project. But I'm still not really any wiser - what does baserev point to, how is it used?
It is just informational, it tells on which former source change base your branch got created/updated the last time. This is important for the classic 3-way merging of sources like any VCS is doing it.
Thanks! Adam
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2012-11-05 10:03, Adrian Schröter wrote:
4. If not, presumably there is some equivalent of 'osc pull' which applies to branches rather than linkpac'd packages?
"osc pull" works on branches!?
If `osc up` notified you that conflicts arose, then `osc pull` is what seems to be needed to actually attempt the merge and add conflict markers. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Adam Spiers
-
Adrian Schröter
-
Jan Engelhardt