Re: Centralized darcs
#include <hallo.h>
* Matthew Palmer [Thu, Aug 03 2006, 08:03:21AM]:
> 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
Nitpicking, you know what I mean.
> 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
> familiar.
>
> 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.
And you can do all that with dpatch-edit-dpatch and the regular Unix
commands without learning another VCS and/or without needing access to
it. Advantage? Yes.
> > 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.
If you like the *WAY* it does this things, ok. I don't, I have described
why and Frank did as well.
> > > > 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?
Statements based on uncertain premisses are uncertain as well. And you
got the answer already: there are lots of cases where the patch
management is better made visible to others, as files rather trough
some obscure meta layer (CMS) between the maintainer and users.
Just get it as is, there is no question whether you like this fact or
not.
Eduard.
Reply to: