Charles Plessy <[EMAIL PROTECTED]> writes: > But I am still missing something: how can we get the benefits of > using a patching strategy, that is to break up changes into logical > components, with the VCS strategy?
Make commits to the VCS branch for the package, at the same level of granularity (or finer) as you would write individual patches. Be sure to describe the commit with a good message, just as you would comment a patch file. With any decent modern VCS, each individual commit can be inspected at any later date, including generating a patch against another arbitrary revision. Indeed, this is how I generate most patches for submitting via email: make the change to a working tree in a VCS branch, then invoke the VCS to generate a diff against the upstream revision (even if I was the one who committed that upstream revision myself). Thus, you get a record of every granular change from a given state, automatically sequenced in the right order. You also get to roll up the entire set into a .diff.gz against the original upstream source, for creating the Debian source package. There are in fact tools in Debian that know how to do this automatically for most popular DVCSen; look for packages called '$VCSNAME-buildpackage'. -- \ "To me, boxing is like a ballet, except there's no music, no | `\ choreography, and the dancers hit each other." —Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
