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
pgpT69aSuOyct.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
