#include <hallo.h>
* John Goerzen [Wed, Aug 02 2006, 08:27:32AM]:
> On Wed, Aug 02, 2006 at 09:41:02AM +0200, Eduard Bloch wrote:
> > #include <hallo.h>
> > * John Goerzen [Tue, Aug 01 2006, 04:47:13PM]:
> >
> > > I do use darcs to track patches against upstream. I really don't
> > > understand the whole cdbs/dpatch/whatever thing -- why use a hack to
> > > manage your patches when you could use a real VC tool that does it
> > > better?
> >
> > Because you can make your work persistent in atoms without having a
> > complicated meta layer inbetween. Patching with VC works well (even with
> > Subversion) if you have just few lines to change (basic use case while
> > developing svn-buildpackage) but the fun disappears when you have a
> > dozen of patches from different sources.
>
> Actually, I think this is where darcs really shines.
>
> Keep in mind that, to darcs, a repository is a collection of patches.
> Darcs also has a notion of patch dependencies. So you can actually do
> things like revert a given patch and all later patches that depend upon
> it. This dependency support is pretty much automatic.
First, I do not believe that this support is perfect. Second, in real
life "removing all subsequent patches to revert one" does hardly make
sense. And even then: if you need manual work to merge different patch
chains of such kind then you will need to do the same (or more) manual
work to cleanup the mess after a such chain has been reverted. And in
the easy cases... where do you need a such shiny support? svn can gives
you a diff between two old revisioins which you can apply with
"patch -R".
> Note that darcs is, at its heart, a patch management system rather than
> a history system. Each patch does have a timestamp, but darcs
> repositories are, fundamentally, just collections of patches. The
> patches don't necessarily have to be applied in the same order (for
> instance, it doesn't matter if you apply the patch that creates file A
> or file B first), though its dependencies ensure that they are applied
> in the correct order when necessary.
>
> Really, I think that getting patches in darcs from people that are using
> "darcs send" is not only easier for me as a maintainer, but also easier
Much easier as storing the mail attachment under debian/patches? I doubt.
> for them as contributors. Plus it is really easy for people that don't
> grok darcs to just use normal tools to edit Debian source packages,
> create diffs, NMU packages, or whatever -- and for me to integrate their
> changes later. This is not the case for the other special-purpose patch
> tools.
This does not really differ from the scenarios with patch management system.
> > I get scared sometimes when I hear people talking proudly about managing
> > their project using a distributed VCS as framework to link dozens of
> > patch layers together though I admittedly never tried to recreate a such
>
> I don't know what you mean by a "patch layer".
Modification layers. Similar to how darcs works (if I understood you
correctly). I remember reading that some maintainers "link" their Debian
directory together from different sources with generic parts.
Sometimes that does make sense, sometimes it does not.
> > scenario. It sounds like a lot of overhead and big waste of time from
> > the beginning, sorry.
>
> I don't know where you get that idea.
>
> As I make changes, I "darcs record" them.
>
> I use dbp-importorig to import new upstream sources -- this is just a
> script that untars them and uses darcs_load_dirs to import them as a
> changeset to the upstream branch. I use "darcs pull" (the darcs merge
> command) to pull it into my Debian tree, and that's that.
Yes... and where is the big difference to other VCs except that you do
not commit to a central repository immediately? (but you need to do it in
an extra step in order to share the work).
Eduard.
--
<ij> Madkiss: Niemand kann so die Nachrichten mehr aufbereiten, dass
Otto-Normal-Bürger die versteht, da dieser viel zu dämlich dafür ist.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
