Bugzilla – Full Text Bug Listing
| Summary: | BOM does not contain revision and timestamp for trunk as it does for branches/tags | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Matthias Kappeller <mkappeller> | ||||
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | thomas | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 198694 [details]
Patch
As promised - the tiny patch...
The BOM is used during check-out. IIRC, the workspace will be locked on a specific revision when a revision specific check out is made. That would mean that your patch invalidates normal day to day use in the IDE. Have you tested what happens when you want to make changes to the workspace after a materialization that contains this patch? (In reply to comment #2) > The BOM is used during check-out. IIRC, the workspace will be locked on a > specific revision when a revision specific check out is made. That would mean > that your patch invalidates normal day to day use in the IDE. Have you tested > what happens when you want to make changes to the workspace after a > materialization that contains this patch? Haven't thought about that - yes. But I've verified that just now. My test case was as follows. 1. Materialize a CQuery with such an advisor node: <cq:advisorNode namePattern="^foo\.bar$" componentType="osgi.bundle" mutableLevel="REQUIRE" sourceLevel="REQUIRE" useMaterialization="true" useTargetPlatform="true" useWorkspace="true" /> The resulting BOM does have this resolution inside: <md:idwrapper id="20a885bb-a2fa-3bc5-bba8-0216ba4c6e70"> <md:resolution cspecId="74f98098-880d-3507-afa7-5b76e6083e48" materializable="true" providerId="c78932c9-6d4f-33be-b74d-407b15b6a2a5" repository="http://polarion.rtc.ch/repo/trunk/foo.bar?moduleAfterTag&moduleAfterBranch" componentType="osgi.bundle" lastModified="0"> <md:request name="foo.bar" componentType="osgi.bundle" versionDesignator="1.0.0"/> <md:versionMatch revision="563882" version="1.0.0.qualifier"/> </md:resolution> </md:idwrapper> 2. Modify the advisor node (ignore exiting materialization and use a revision): <cq:advisorNode namePattern="^foo\.bar$" componentType="osgi.bundle" mutableLevel="REQUIRE" sourceLevel="REQUIRE" useMaterialization="false" useTargetPlatform="false" useWorkspace="false" revision="563004"/> The resulting BOM: <md:idwrapper id="54ee0030-c367-3f25-ae8b-ae5a4c902f4a"> <md:resolution cspecId="66e9db84-385c-3ed6-9481-949143fbfa04" materializable="true" providerId="c78932c9-6d4f-33be-b74d-407b15b6a2a5" repository="http://polarion.rtc.ch/repo/trunk/foo.bar?moduleAfterTag&moduleAfterBranch" componentType="osgi.bundle" lastModified="0"> <md:request name="foo.bar" componentType="osgi.bundle" versionDesignator="1.0.0"/> <md:versionMatch revision="563004" version="1.0.0.qualifier"/> </md:resolution> </md:idwrapper> In my opinion it works because the resolution does take care of the advisor node in my CQuery. So I will get the RevisionEntry which has been found and this one does contain the revision given by the CQuery or at least the HEAD revision. Am I right? (At least it's the way it works in AbstractSCCSVersionFinder.getBestBranchOrTagMatch(boolean, List<RevisionEntry>, IProgressMonitor) ;-) ) I don't like to urge. But ;-) after verifying the possible side effect. Will this patch find its way to be committed? Fix committed. Thanks and sorry for the delay. http://git.eclipse.org/c/buckminster/buckminster.git/commit/?id=6deda3f354427581d77e00ca19eea05b5b3bda4a Thomas, thank you! |
I'd like to use a BOM as a "build-tracker". This does work well for components from a branch: <md:idwrapper id="80f2d3dc-7460-3056-849f-98592378ecd0"> <md:resolution cspecId="651990e2-bafe-32fa-805b-307df190473f" materializable="true" providerId="de552ab2-7c7f-3595-91ae-4c09b90e1b87" repository="http://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster/trunk/org.eclipse.buckminster?moduleAfterBranch&moduleAfterTag" componentType="buckminster" lastModified="0"> <md:request name="org.eclipse.buckminster" componentType="buckminster"/> <md:versionMatch branchOrTag="helios-maintenance" revision="11751" version="1.1.350"/> </md:resolution> </md:idwrapper> Such a resolution does contain the SVN-Revision. If I'm going to do this for the trunk I will not see the revision in the resolution. <md:idwrapper id="6c78ee42-c283-3f8f-86ae-38fcb37a911e"> <md:resolution cspecId="651990e2-bafe-32fa-805b-307df190473f" materializable="true" providerId="de552ab2-7c7f-3595-91ae-4c09b90e1b87" repository="http://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster/trunk/org.eclipse.buckminster?moduleAfterBranch&moduleAfterTag" componentType="buckminster" lastModified="0"> <md:request name="org.eclipse.buckminster" componentType="buckminster"/> <md:versionMatch version="1.1.350"/> </md:resolution> </md:idwrapper> Because in the AbstractSCCSVersionFinder the information will come from the CQuery at what for a branch or tag the information does come from the SVN-Entry. I will append a patch for that. I will be a tiny change :)