[darcs-users] darcs patch: refactor of SelectChanges (and 1 more)

Trent W. Buck trentbuck at gmail.com
Tue Oct 14 01:40:32 UTC 2008


Florent Becker <florent.becker at ens-lyon.org> writes:

> [About a well-needed new presentation for patch selection in presence
> of dependencies.]
>>
>> Then I'm gonna take a hard line and say that (long term) the code ought
>> to be rewritten to support an interaction like that mockup.
> [...]
>
>> (This is not to detract from the work you've already done; it's an
>> improvement over the previous functionality.  But there's still room for
>> big improvements to the usability of this workflow.)
>>
>>>  1/ add a 'last-exit' question, as proposed elsethread, so that
>>> --dont-prompt-for-deps does not act that silently. In a
>>> second time, add your 'that patch has dependencies, pull them?'
>>> question, albeit in "an all or nothing" fashion. We could simply add a
>>> warning "this patch has unpulled dependencies", show them when the user
>>> hits 'v' (in addition to the patch), and offer him to either pull the
>>> patch with all dependencies (with 'y'), or not (with 'w/n'). This is
>>> what i see how to implement in the current state of darcs.
>>>
>>>  2/ Work on making SelectChanges code callable from outside darcs, as a
>>> lib, or as specialised darcs commands/flags (ie either
>>> Darcs.SelectChanges.getDependenciesForSelection, or darcs pull --dry-run
>>> --dont-prompt-for-deps --read-selection FILE) so that we can code a more
>>> featureful (maybe graphical) UI outside of darcs. There we could get rid
>>> of the sequential prompt/answer paradigm, and have richer interactions.
>>
>> I agree with the idea of a libdarcs that other apps can talk to.  But I
>> still think my mockup workflow deserves to be in Darcs proper, rather
>> than relegated to a separate opt-in application.
>
> Of course, my point was that since we'll have to rewrite selectChanges
> for this anyway, we'd be better off if we did it right (ie prepared
> for libdarcs). This is probably long term, and I want to be sure we
> get the API right. When we have that infrastructure, we can get your
> mockup workflow within darcs too. Still, I think (1) is a good step
> forward and can be made for the january release. (knock on wood)

+1 to all those statements.



More information about the darcs-users mailing list