Jordan, UDK2010.SR1 and UDK2014 are still be updated in 2014. UDK2014.SP1 will be expected to like all the branches before. There will be many patches to be waited for syncing.
I have tried to use svn to create/apply patch automatically. But svn create/apply operations cannot work for the binary file (for example, UNI file). If you have better tools, please tell me. Moreover, some patches could not be applied successfully, due to the code bases different between branch and trunk. We have to sync it manually. If sync the patch one by one, it's much effort to do the verification (such as pass building). That's why we tend to sync a serial patches together. Usually we have building and basic testing after applied a serial patches and then check-in them together based on package. I don't know how many people work on UDK Branch instead of trunk. We could evaluate the requirement and maintain effort. Thanks! Jeff -----Original Message----- From: Justen, Jordan L Sent: Thursday, October 09, 2014 8:17 PM To: Fan, Jeff; [email protected] Subject: RE: [edk2] UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from main trunk. On 2014-10-09 04:11:31, Fan, Jeff wrote: > Jordan, > > We have the following branches totally. > UDK2010: https://svn.code.sf.net/p/edk2/code/branches/UDK2010 Last updated January 2012 :) > UKD2010.SR1 : https://svn.code.sf.net/p/edk2/code/branches/UDK2010.SR1 > UDK2014 : https://svn.code.sf.net/p/edk2/code/branches/UDK2014 > UDK2014.SP1: https://svn.code.sf.net/p/edk2/code/branches/UDK2014.SP1 > > UDK2014.SP is just created from the middle of last month. And only > several hot-fix patches applied, so you only see few patches synced. > Please see the log the other branches for how many patches synced from > main trunk. I think you are saying that doing this the better way is too much effort. I guess the reason for difficulty with maintaining branches is caused by the tools that you are using. :) -Jordan > -----Original Message----- > From: Justen, Jordan L > Sent: Thursday, October 09, 2014 5:40 PM > To: Fan, Jeff; [email protected] > Subject: Re: [edk2] UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch > r16181 from main trunk. > > On 2014-10-08 18:44:41, Fan, Jeff wrote: > > Jordan, > > > > For single patch sync, I agree with using "patch+message" in the first line > > is better for git to summarize the log history. But it is rare case. > > > > On most cases, to reduce the maintain effort (hundreds of patches > > for each branch release. > > I think your estimate of 'hundreds of patches' may be too large. :) > > For r16174 and r16176, UDK2014.SP1 BaseTools is upgraded from trunk > r16114 to r16160. > > svn log -r 16114:16160 > https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools > only shows 6 patches. > > > Also sometimes, some patch maybe hard to be applied or to be synced > > to > > branch) and to reduce the revision number increasing, > > Why do you want to prevent the revision number from increasing? > > > we shall check-in a serial of patches together. > > One example in MdeModulePkg as blow: > > Sync patches r14006, r14034 and r14035 from main trunk. > > 1. Base on the value type to get the value for default opcode. > > 2. Base on the type field to generate numeric opcode. > > 3. Base on the type field to generate oneof opcode. > > We already provided enough original patches information. If the git > > developer wants for details of some patch, he/she could use get the > > whole log body instead of from the summary log. Do you any better > > suggestion on it? > > If you have all the patches visible separately (cherry-pick), then it > enables the 'git bisect' feature. (If someone encounters a bug on the > UDK2014 branch, then they can do a git assisted binary search to find > when the bug was introduced.) > > > Why we delete the BaseTools and copy the updated BaseTools from main > > trunk is to try best to keep original log information from main trunk. > > You could see the log of BaseTools on branches for it. > > Regarding deleting a directory on the branch, if you checkout $ svn > checkout -r 16176 > https://svn.code.sf.net/p/edk2/code/branches/UDK2014.SP1 > Then you have no BaseTools in your tree. Therefore the delete/copy > process creates an unusable version of the tree. (You agree?) > > I think if the patches are sepately 'cherry-picked' to the branch, then it is > easier to view the log data directly. With delete/copy, you have to > separately look at the log of the trunk to see the patches. Also, you may > have to filter changes in the trunk to see the actualy changes. > > -Jordan > > > -----Original Message----- > > From: Jordan Justen [mailto:[email protected]] > > Sent: Tuesday, September 30, 2014 6:50 AM > > To: [email protected]; Fan, Jeff > > Subject: UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from > > main trunk. > > > > Just wanted to note that git cherry-pick would make this type of > > maintenance easier, and would produce a more useful result is the > > branch history. (You'd see the original patch+message rather than > > 'sync patch r#...') > > > > r16182 | Sync patch r16181 from main trunk. > > r16180 | Sync patch r16179 from main trunk. > > > > === > > > > I don't think it is a good idea to update the branch packages by deleting > > and copying newer versions. This means if anyone checks out r16176, they > > will have an unusable tree. Normally you'd want to avoid that so a tree > > could be bisected to locate the source of some breakage. > > > > Once again, I think this is something where git cherry-pick could produce a > > more useful result by having each patch appear individually on the branch's > > history. > > > > But, lacking git, perhaps creating a patch with svn and applying it > > to the branch would allow you to sync in the new changes from the > > main branch. (Without having to delete and copy.) > > > > r16177 | Copy BaseTools r16160 to UDK2014.SP1 Branch. > > r16176 | Delete BaseTools from UDK2014.SP1 Branch. > > > > -Jordan > > > > === > > > > r16175 | Copy ShellBinPkg r16166 to UDK2014.SP1 Branch. > > r16174 | Copy ShellPkg r16163 to UDK2014.SP1 Branch. > > r16173 | Delete ShellPkg and ShellBinPkg from UDK2014.SP1 Branch. > > r16164 | Sync patch r16128 from main trunk. > > r16151 | Correct the convert hex string to decimal value logic. > > r16130 | Sync patch r16129 from main trunk. > > r16119 | Create UDK2014.SP1 BaseTools branch based on revision 16114 > > r16118 | Create UDK2014.SP1 BaseTools branch based on revision 16114 > > r16117 | Remove UDK2014.SP1 BaseTools branch. > > r16111 | Create UDK2014.SP1 branch > > > > On Sat, Sep 27, 2014 at 6:15 PM, <[email protected]> wrote: > > > Revision: 16182 > > > http://sourceforge.net/p/edk2/code/16182 > > > Author: vanjeff > > > Date: 2014-09-28 01:15:46 +0000 (Sun, 28 Sep 2014) > > > Log Message: > > > ----------- > > > Sync patch r16181 from main trunk. > > > Fix an issue on FixedMtreProgramming - AND/OR mask incorrect. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Jeff Fan <[email protected]> > > > > > > Revision Links: > > > -------------- > > > http://sourceforge.net/p/edk2/code/16181 > > > > > > Modified Paths: > > > -------------- > > > > > > branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > > > > > > Modified: > > > branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > > > =================================================================== > > > --- branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > > > 2014-09-28 01:07:13 UTC (rev 16181) > > > +++ branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c > > > 2014-09-28 01:15:46 UTC (rev 16182) > > > @@ -381,7 +381,7 @@ > > > *Len -= mFixedMtrrTable[MsrNum].Length; > > > *Base += mFixedMtrrTable[MsrNum].Length; > > > } > > > - TempQword = AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & > > > (~ClearMask | OrMask); > > > + TempQword = (AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & > > > + (~ClearMask)) | OrMask; > > > AsmWriteMsr64 (mFixedMtrrTable[MsrNum].Msr, TempQword); > > > > > > return EFI_SUCCESS; > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > -- > > > -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog > > > Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box > > > PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? > > > Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 > > > with EventLog Analyzer > > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg. > > > clktrk _______________________________________________ > > > edk2-commits mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/edk2-commits > > -------------------------------------------------------------------- > > -- > > -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog > > Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box > > PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? > > Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 > > with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg. > > clktrk _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
