Raphael, please follow the Debian Mailing List code of conduct <URL:http://www.debian.org/MailingLists#codeofconduct>; in particular, don't send individual copies of list messages unless specifically requested.
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Imagine an history like this: > > - Change behaviour1 > - Change behaviour2 > - Bugfix in patch to change behaviour1 > - Bugfix in patch to change behaviour2 > > You have two logical patches and a dumb export from the VCS into > debian/patches/ would give 4 patches when you really want only two. In a VCS with good merging support (most DVCSes fit this description, Subversion does not), those "logical patches" can be maintained as "feature branches". Essentially, any set of changes that is more than "add this change and let it be absorbed into the stream of changes" merits branching the development tree to maintain that feature. Into that feature branch go any commits that are related logically to the feature; anything else goes into other branches. Any time you want to find how feature-branch-A differs from the development branch, that's a simple diff operation between the two branches (optionally specifying which revision of each you're interested in comparing). Merges between the two will show up as single revisions in each branch, so the changes in feature-branch-A will show exactly the history of feature A. Any time the changes in feature-branch-A are at a point where they need to be included in the main development branch, simply merge them in. The important thing that enables this workflow is *easy merging* between arbitrary branches that share a common ancestor. Again, this rules CVS and Subversion out. (Some, like git, allow merging *anywhere*, but that's not necessary for this to work well.) -- \ "I have had a perfectly wonderful evening, but this wasn't it." | `\ -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
