[darcs-users] switching all references by patches to be by hash only

[Eric Kow]

On Mon, Aug 24, 2009 at 16:07:21 -0400, Max Battcher wrote:
> I was thinking about this a little bit, too, Eric. Particularly if a  
> two-hash context format "infected" the contexts of patch bundles

I think we want to avoid code duplication when at all possible, so if
we're going to be using hashed contexts, it probably makes sense to use
bundles with hashed contexts as well.

Also we want to avoid needless variation, cut down on code path
divergences.  It's all about the surgery

> What might work is simply darcs changes support for contexts, something  
> like:
>
> darcs changes --of-context some.context

Perhaps I'm being excessive in my grumpiness here, but that isn't
exactly at a glance is it?

There's also a bit of last resort robustness I'm aiming for here.  I'm
not good at designing things, so I'd best leave this to darcs-users, but
my thinking is that us relying on textual information where possible is
that should darcs ever screw something up badly, at least it's easier to
do forensics and figure out what the heck happened.

One example is that the current textual contexts mean that it was
actually very easy for me to hack up patch bundles and do a sort of
manual transplant operation.  Definitely a Don't Try This at Home, but
it's the kind of thing I wouldn't have ever figured out if the contexts
were all goobledygook.  There is a sort of transparency behind text that
makes it all the more learnable.  (Yeah, so the point of this example
isn't "oh, you can do manual transplant", but "oh, you can get enough of
an idea how Darcs works to work out how to do a manual transplant and
explain the process of repo forensics to other people").  Sorry if I'm
rambling.

More generally, one of the fears in the back of my mind is that as we
continue tinkering with the Darcs interface, we'll somehow accumulate a
certain cruftiness and lose whatever quality Darcs has that makes it so
easy to use.  I don't know what it is.  There is a combination of
symmetry, interactiveness and broad transferability of ideas from one
domain to another (eg. cherry picking of primitive patches to cherry
picking of named patches) that makes it all hang together.  This
probably isn't germane to this discussion in particular, but I hope we
can continue to improve Darcs without me getting a Screwing up the UI
anxiety attack :-)

> A key benefit here is also that you get a visual way to inspect when  
> darcs cannot locate a patch at all, before you attempt to rely on it in  
> a get/apply/send. Darcs changes could even provide some sort of  
> assistance at this point on how to request a copy of the necessary  
> patch(es) from the repository that the context is related to.

--dry-run might have the same effect although on the other hand, I guess
it would be reasonable to expect dry-run to never actually fetch
anything

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090824/965b76dd/attachment.pgp>