[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to cope with patches sanely (Was: State of the project - input needed)



On Sat, Feb 02, 2008 at 07:18:26PM +1100, martin f krafft wrote:
> also sprach David Nusinow <dnusinow@speakeasy.net> [2008.01.27.0334 +1100]:
> > External patch systems are not ideal by any means, but they do
> > clearly address these issues as well as I could ask for. It's
> > trivial to update the patches, just go one by one through them.
> > You can trivially see the patch in full, which makes it quite easy
> > to deal with. Patches, once ready, can be easily sent upstream for
> > later inclusion. Patches can be commented in their headers, which
> > allows an easy single place to collect information rather than
> > having to scour through your history. 
> 
> I really don't see how this is in any way different from feature
> branches. Sure, having 30-or-so feature branches around may make you
> dizzy at first, but most of them you won't have to touch, and if you
> do, then what you get is pretty cool:
> 
>   - merge support, in case the base branch ('master' or 'upstream'
>     or 'debianisation') has changed. Unless there have been
>     incompatible changes, the VCS can "update" your patch trivially
>     easy, and better than any of the patch systems I've seen.

You should really look at quilt. It allows quick merging of patches the
same way a VCS does. This is the reason why as a tool it stands head and
shoulders above systems like dpatch, and can compare favorably to a system
like git. It's also why, if you look at those speaking in this thread,
those of us who work on large codebases favor quilt ahead of things like
dpatch.
 
>   - patch/feature-branch-specific history. Say feature branch 'foo'
>     has a bug, so you check it out and work on it again... now
>     you're suddenly in the context of all the work you've previously
>     done and you can trivially browse the history of changes
>     applicable only to what you're currently working on.

How do you decide the order to apply your feature branches? Do you encode
it in the branch name? Congratulations, you've just reinvented dbs. Do you
have a separate file in the debian directory that tells you the merge
order? Congratulations, you've just reimplemented quilt. Do you write a
script to update your branches automatically, only failing when you have to
manually update yourself? Congratulations, you've just reinvented every
other patch system in existence.

Doing it in the VCS might have its merits, but it really is just
reinventing the wheel for a problem that is solved remarkably well already.
diffs are a universal format for patch exchange, so we win big by using
them explicitly.


 - David Nusinow


Reply to: