[darcs-users] Status of issue #291 (hunk editing)

[Eric Kow]

On Fri, Apr 24, 2009 at 20:23:56 -0500, Rob Hoelz wrote:
> Alright, I've been working on this on and off for a while now, so I
> figure I should put down a bit of an update:
> 
> There's a sort-of working implementation in my repository at
> http://darcs.hoelzro.net/darcs.  This implementation will allow you to
> edit a file at a given hunk, and it'll build a new hunk list for that
> file when you're done.  However, the new hunks won't make it into the
> recorded patch, and any old hunks that you may have removed during your
> edit are still there (More on this below).  There are more notes about
> the limitations of my implementation in the patch's comment section,
> but they aren't as bad/difficult to solve as the problem I'm about to
> discuss.

Whee!

I've had a quick look at the patch comment.  It occurred to me that
you're probably doing the right thing by ignoring any changes that don't
apply to the file in question.

In fact, I might even go further by fetching a pristine version of the
file in a temporary directory, applying all the InFirst patches to it,
and then having the user edit *that*.  In fact, what you can do there is
just to discard the InMiddle and InLast patches that affect this file
and just re-compute them.  It's OK if the user makes changes which
clobber the InFirst choices because then all you get are new patches on
top of the patches the user already made, which darcs should handle in
theory (think of amend-record, for example).

I've snipped your interesting concerns about PatchChoices below because
I think that this plan might just side-step them.

The one thing you'll have to watch out for if go with this simplifying
assumption is re-applying the user's changes back to the working
directory.  Hmm.  So maybe we come back full circle to what I think
you're doing, which is to do let the user modify the working directory
directly and then pick up the changes there (ignoring all changes that
don't affect the file in question).  But I think that somehow, there is
this core idea that you're not modifying the file A, but the file A' (in
which the InFirst patches are done and dusted) which we could use to
make things easier.

Does this rambling sort of make sense?

-- 
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/20090425/64d37cd0/attachment.pgp>