[darcs-users] Colin Walters blogs on Arch changesets vs Darcs

[Colin Walters]

[ Apologies for the lack of References:; I only just subscribed to this
list, so I had to grab the mail from the web archives ]

> From: Florian Weimer fw at deneb.enyo.de 
> Fri Nov 19 12:04:15 EST 2004
> 
> His argument has certainly some merit.  But as it happens, the arch
> folks almost *never* send around isolated changesets.  

That is not true at all.  In my experience with Arch development of
Arch, cherrypicking is equally as frequent as star-merge, if not moreso.
I'm pretty sure that's the way Tom has merged several of my changesets,
for example.  

> It tends to break star-merge, IIRC.

That is true.

> Unfortunately, the arch approach which chooses patch targets based
> upon file identity is not very useful because the file might have been
> split into two.  In such cases, you probably want to try to apply the
> patch to *both* files.  

Not necessarily.  It seems to me one could want previous changesets to
apply to neither file, or just one.  It depends on the situation.  But
it is true that while Arch allows you to express "neither" or "one", it
does not allow for "both".  My gut feeling is that "both" is going to be
an uncommon situation, and probably indicative of a design problem in
the project.  If you're patching code, then you likely want to factor
the region out into a shared function.

> Maybe we would see more use of "tla mkpatch" if actually created
> human-readable text output for text files. 

I think the output of "tla show-changeset --diffs" gives you a nice overview,
with e.g.:

foo => bar     (renaming foo to bar)
-- foo         (modified permissions for foo)

Then you get all of the diffs.  The major missing thing I can think of
is binary file additions, but it's a bit unclear how you'd sanely
present that in text output.

> Currently, it writes a
> directory structure, which you cannot directly include in an email
> message. 

tar, zip

>  This makes arch changesets rather useless for peer review on
> mailing lists.

That's certainly not an insoluble problem; there has been discussion of
a flat-file format for changesets, but it is true that it is not
entirely trivial as one may think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041119/2834a69c/attachment.pgp