Re: Centralized darcs
On Wednesday 02 August 2006 17:31, John Goerzen wrote:
> On Wed, Aug 02, 2006 at 05:20:26PM +0300, George Danchev wrote:
> > > Actually, I disagree with that. I always hate having to work with a
> > > package that uses a patch management system, because then I have to
> > > learn the system before I can do any work on the package. And there
> > > are several systems. Plus it's not always quick & easy to generate a
> > > diff for an NMU out of that. And the resulting diff isn't necessarily
> > > easy to read (being a diff of a diff).
> > How is that not true if one knows a given patch system and does know
> > about your VCS and needs to work on one of your packages. Do they have
> They just apt-get source, hack away, and send me a diff.
Also true for any debian patch system, but with the gain the debian specific
patches are clearly separated and documented as well. Existing patches could
be updated, which could be a good thing when adding a new patch to patch
already patched by other patches stuff is insane.
> > debian/patches/ as separate file, how do I know how to update/remove/etc
> There would be no debian/patches.
That could be bad sometimes, or most of the time. Some people prefer to have
debian-specific patches (applied to the upstream source) separated and with
comments appended, which leads to more fine-grained control.
> They shouldn't be converting the package to use a patch system.
They can send new patch to be included in debian/patches/, remove one, or
update it as well. They can send a patch against the toplevel soruce package
> > them ? How is that different from learning darcs patch system which might
> > happend to be new for me. There is also git arch which also pretend to be
> > a patch system at heart. Thus the diversity is the same as in different
> > patch system / not necessary a bat thing though /.
> They can build and use the package just like normal. Somebody doesn't
> have to know how to use my VC in order to work on my package, which is
> different from the situation with the patch systems.
But you lose debian specific patches to be clearly separated from the upstrem
source (digging diff.gz for that is not fun), unless one knows where to find
your VCS repository, learn that VCS and work from there, which is not always
documented in the source package's themselves.
It all boils down to how you look at it - some prefer separation, other
megring everything at once. Seems like we are not taking about different VCS,
but how the debian specific patches against the upstream source might be
P.S. please do not CC: if not explicitely requested, I'm subscribed.
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB