>>>>> "David" == David Roundy <[EMAIL PROTECTED]> writes:
David> On Mon, Aug 01, 2005 at 06:48:37PM +0900, Stephen
David> J. Turnbull wrote:
>> >>>>> "Erik" == Erik Schnetter <[EMAIL PROTECTED]> writes:
Erik> We could introduce a directory /deleted-patches and put a
Erik> copy of the patch there. This way it could be resurrected
Erik> with "darcs undelete".
>> Don't we have plenty of options for keeping the patch in the
>> repository but not using it in the current workspace?
David> Actually, this isn't such a bad idea. We could keep a
David> patch bundle around. I think I'd rather avoid darcs
David> undelete, though, if at all possible. We've just got too
David> many un-commands already. On the other hand, if done right
David> the uncommand naming scheme can be intuitive.
I didn't mean to imply it was a _bad_ idea. However, as you point
out, designing an interface for it is going to be non-trivial. And it
all seems a bit out of line with darcs to me---more arch-like with its
emphasis on never losing history and delegation of non-trivial
dependency computations to the user. That's why I ask if darcs needs
an unpull-with-backup.
Rather than a patch bundle, why not create a new repository? Then the
user has all the power of darcs available if she decides to redo the
pull. "darcs pull" from the created repository, obviously, but it
would also be possible to use the created repository to reconstruct
the desired version if that made more sense. This also has the
potential to get arch-like (especially if the feature is used
frequently enough that there is a demand for efficiency enhancements
like linking to the existing patches instead of creating a whole new
repository), but I think it takes much better advantage of darcs's
features.
By the way, people who (think they) know what they're doing will still
want an --obliterate option to unpull, but combined with the "check
for copies in other repositories" strategy you can probably get a
pretty accurate "do what I mean" implementation, which would also be
efficient unless there was real need for a backup.
David> Perhaps it would be better to handle it like we do
David> unrevert, where we only allow you to unrevert the most
David> recent revert.
This pushes the danger (or substantial inconvenience if you store
patch bundles but the user doesn't have a black belt in darcs
internals) back one level ... but I would guess that people are
generally going to be able to foresee for a couple of "rounds" that
they _don't_ need this patch at all, and only later realize they were
wrong.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
