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

Re: Centralized darcs

On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]:
> > On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote:
> > > > to learn how we deal with this all.
> > > 
> > > This is fine, but (again) you forget about your 'apt-get source' users, which 
> > 
> > NO.  They need not care.  They can just hack and send me diffs.  My
> > debian/changelog will already document what has been going on anyway.
> Heh. So they need two copies, one where they do modifications, then diff
> those and send you the diff. Or they need to change debian/changelog and
> learn to use interdiff. All that is more work that just callin
> "dpatch_edit_patch foo".

$ dpatch_edit_patch
zsh: command not found: dpatch_edit_patch

Yep, that was very little work.  Even less benefit, though.

Oh, you meant dpatch-edit-patch, perhaps?  That's great, but there's plenty
of packages that contain debian/patches/ were dpatch-edit-patch will get you
nowhere.  And when you do find a package where dpatch-edit-patch "works",
all it does, effectively, is make two copies, one where you do
modifications, and then diff those and store the diff.  Gee that sounds

dpatch-edit-patch also suffers from the difficulty that you need to manually
revert bits and pieces that you don't want in your final dpatch, like (for
instance) updated changelog entries (which you made to make test builds to
ensure that everything's working OK before going through the rigamarole of
wrapping up the patch, and then reopening it again -- a full-tree diff,
removal, and re-copying -- if you got it wrong.

> Why do dist.VCS fans always talk about patches like the would rain from
> the sky just so?

Because we've moved on from being our own VCS (a la dpatch) and are now
using an automated tool to track things *for* us, instead.  So now working
with patches is simple and straightforward.

> > > are not supposed to be aware of your SCM, where your repo is, patches applied 
> > > to the upstream source and why they have been applied. I.e. if you have 
> > > patches, do them debian way (using a debian patch system) even using SCM to 
> > > manage your whole packaging. Your orig.tar.gz must be really original tar.gz, 
> > > and your diff.gz should hold whole debian-specific thing.
> > 
> > I am quite well aware of that and it is trivial to do.
> And if the user has more than one patch which needs to be maintained
> separately, is it still is still trivial FOR HIM? (or her)

HE (or she) can work out how to make things work FOR HIMSELF (or herself). 
Chances are, no matter which system you choose, someone out there isn't
going to like it.  So why hamstring yourself with a sub-standard system that
you don't like working with, just to please some minority of users?

- Matt

Reply to: