On Mon, 2007-08-06 at 22:56 -0400, Michael Olson wrote: > Reinhard Tartler <[EMAIL PROTECTED]> > writes: > > > "Emmet Hikory" <[EMAIL PROTECTED]> > > writes: > > > >> The reason I prefer a patch system is that it organises the > >> patches by purpose, rather than historically. With a VCS, it is very > >> difficult to extract the specific set of changes required to > >> implement a specific feature, especially when those changes may span > >> several files, and have been updated several times during this > >> history of the package to match upstream changes (often in > >> combination with other updates). Purpose-oriented patches are easier > >> to review for adoption upstream, and easier to understand as an > >> example to implement a similar feature in another package. > > > > This is adressed by the concept called 'feature branches', a concept > > that Manoj Srivastava uses for his packages. A feature branch only > > contains the changes that you would normally put in a dpatch. It can > > be easily extracted and exported to a patch file. Furthermore, you can > > track and merge changes with other developers. > > > > Together with the bzr-rebase plugin, I think the implementation of > > feature branches with debian packages becomes more and more feasible > > in bazaar.
I'm not sure rebase needs to be involved; rebasing discards revision ids and harms collaboration. > I'm intrigued by this idea. Unless I'm mistaken, the main issues with > using bzr for this is that bzr needs a separate working tree for each > feature branch. This causes the following problems. bzr switch can switch between lightweight working trees. Fixing that for heavyweight checkouts would be relatively easy; and pull --overwrite is essentially the same thing for branches anyhow. > 1. If working with a Launchpad-hosted repository, each branch has to be > registered with Launchpad before work can be done on it. 'bzr push' will create branches automatically on launchpad. > 2. There are often a lot of individual patches in debian/patches -- > making a feature branch for each patch seems slightly wasteful of > disk space. This is not a huge concern since debian/ directories > are almost always small, but it would feel wasteful nonetheless, > compared to having just one working directory, like git offers. On your local disk you can use a shared repository which shares the disk storage between branches 'just like git'. > 4. A new contributor to the project would have to check out not just > the branch that has the debian/ directory, but also every single > feature branch, which could be a hassle. I would be included to have the merged branch be what people checkout. To edit a specific patch you then checkout the one feature branch you want to edit, or make a new one, and then merge that in. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
