[darcs-users] Re: Programmatic invocation

[David Roundy]

On Thu, Nov 17, 2005 at 08:03:11PM +0100, Juliusz Chroboczek wrote:
> > Also, I find that the interactive modes are incredibly helpful in
> > disentangling mixed-up changes.  I suspect it would be rather hard
> > to emulate those without passing darcs prompts back to the user.
> 
> No, you just need to define some specific non-interactive commands for
> Darcs.  This is, I believe, what Daniel Lutz was hinting at.

This is definitely one approach (and it certainly doesn't hurt to have more
than one approach).  The downside of this approach is that it doesn't allow
feedback as to which combinations of patches are possible.  It'll work
reasonably well for record, but when you use it with pull, you lose most of
the advantages of an interactive pull, since you can't see which other
patches are pulled in when you select one particular patch.  One could give
this feedback with multiple calls to darcs, but at that stage you're likely
to be slowing down considerably, and the interface is approaching the point
where a single piped interactive call to darcs would be easier (which is
why I lean in that direction).

> Here's an outline of what could be done, taking record as an example.
> Add three new (sub)commands:
> 
>   darcs batch take-lock
>   darcs batch release-lock

I wonder if we could combine these two together? Or could we at least make
it so that release-lock can only release a lock taken by take-lock? I'm
concerned about misguided scripts either failing to release a lock (due to
error) or releasing a lock that they didn't take in the first place.

LOCK=`darcs batch take-lock`
darcs whatsnew # we don't need batch for this, do we?
darcs record --lock=$LOCK ...
darcs batch release-lock --lock=$LOCK

So here I'm hoping we can have take-lock return a token that describes the
lock, so that no other malformed script can run "darcs batch record" while
I've got the lock--since they won't have the token.  This obviously
requires that we stick some sort of content in the lock file.

What I'd love would be a scripting idiom analagous to the withLock idiom,
whereby we could run a "darcs lock" that doesn't return, and which removes
the lock when it exits, either because it is sent a signal, or because its
parent exits.  I suppose darcs lock could fork...

> The locking commands should be self-explanatory.  Batch whatsnew would
> give a numbered list of hunks, in an easy to parse format.

I'd rather add a numbering option to ordinary whatsnew...

> Batch record is like record, but it doesn't take a lock (assumed to
> already have been taken by an explicit take-lock), and instead of
> being interactive, takes a subset of the hunk indices produced by
> batch whatsnew.

I'd rather have a --lock flag to record and improved scriptability.  We've
already got the record --pipe mode.

> A GUI for darcs record would then issue the following commands:
> 
>   - darcs batch take-lock;
>   - darcs batch whatsnew;
>   - allow the user to select the hunks he wants to record and enter a
>     log message;
>   - darcs batch record, with the list of hunks computed in the
>     previous step;
>   - darcs batch release-lock.
> 
> If somebody is willing to implement the GUI, I'm willing to implement
> darcs batch.

Apart from the above concerns, I agree.  What we really need in this arena
is someone working on a GUI and someone working on darcs who are working
together.
-- 
David Roundy
http://www.darcs.net