[Jean Delvare] > You should really dedicate the subsection to a typical in place codebase > update (and we don't care how the update is done, manually or through > CVS, it doesn't matter).
[Jerome Lacoste] > It matters in the sense that with CVS, if you do it wrong, you have to > start from scratch. Hence my confusing footnote. I still don't see how different it is from a non CVS-based baseline update. For example, here is how I handle my local stack of kernel patches: 1* I start from the latest Linus' -rc tree. 2* I push patches as they are sent to me. After some times I have a significant number of patches in my stack. Some of them eventually go to Greg KH, then Andrew Morton, then Linus Torvalds. 3* When a newer -rc tree is available, I want to use it as my new baseline. I pop all patches, then apply the incremental -rc patch to my tree. 4* I delete all patches previously in my series which made it to Linus' already, as they are now part of my baseline. 5* Finally I push all the remaining patches in the series, fixing conflicts as needed. This third step is very similar to a "cvs update" or equivalent, isn't it? And if I'd do it the wrong way around (e.g. applying the baseline patch before popping all the series patches), I'd screw everything up just as a cvs update would do. [Jerome Lacoste] > Agree. But on the other side merging with upstream is an important > part of the usage of quilt. Isn't it? Agreed, and documenting it is very needed. But let's keep the documentation concise, so that the reader actually understands how easy it is. Updating the codebase is a simple, 4 step process: pop all patches, update the codebase (whatever the method is), delete all redundant patches, push all remaining patches. I don't think we have to say more than just that. Thanks, -- Jean Delvare _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
