[darcs-devel] Scriptability, GUI

[Daniel Lutz]

Am 03.09.2005 um 14:45 schrieb David Roundy:
[...]
>> For good scriptability I think the following features should be
>> available in darcs (I guess all these things are relatively easy to
>> implement):
> ...
>> 2) It must be possible to get the file which comes out when all 
>> patches
>> until some patch are applied to an empty file. This is mainly required
>> to allow the usage of external (graphical) diff tools.
>
> It's not efficient, but
>
> darcs annotate -p foo filename | grep -v '^#' | sed -e 's/^ //'
>
> (or --match "hash XXX")
>
> Or annotate --xml with appropriate processing (harder to do in sed and
> grep).

So, in principle it's already possible -> that's good.

> We could add a --plain option to annotate, which would eliminate the
> post-processing and could be implemented to run faster.  Or we could 
> stick
> this in the query supercommand as something like
>
> darcs query filecontents -p foo filename

This would be great.
Probably even better would be if the command could accept a list of 
patches
(e.g. --match ...  --match ...) because file "versions" which differ 
only in
a few patches could benefit of their common predecessor patches (which 
could
improve efficiency on large repositories).

>> 3) Repository locking. In BitKeeper there is a (blocking) block
>> command. Something similar would greatly improve the robustness of the
>> repository when using GUIs and shell scripts.
>
> We could certainly implement this.  What do you mean by a "(blocking)"
> block command? Does it just run forever until interrupted, and then 
> unlock
> the repo before exiting? I hadn't thought of that.  When this sort of
> feature was suggested before, the assumption was a "lock" and "unlock"
> command, and I wasn't comfortable with the "unlock" command since it 
> could
> easily let people corrupt their repositories.  But if the block command
> just blocks while it's running, we'd be safe, which would be great.

According to its documentation BitKeeper's block command blocks as long 
as
the calling process exists, if I remember correctly. To be honest, I did
never use this command (since I never had the need to expand BitKeeper's
functionality), so I cannot say how good it is in practice.
But I can try this on Monday.

>> 4) Setting the explicit dependencies (darcs record) by command
>> arguments (instead of asking for each available patch).
>
> Hmmm.  Explicit dependencies are quite rarely used, so I don't want to
> complicate the interface much for their sake.  But this would be a 
> pretty
> easy feature to use... and if we dropped the prompting, we could 
> actually
> simplify the interface and code.  I can imagine something like five 
> flags,
> --depends-on-tag --depends-on-patches --depends-on-patch
> --depends-on-matches --depends-on-match, where the plural and singular
> versions would add depends to all matching patches or just the most 
> recent
> matching patch respectively.  Technically we'd only need *either* the
> singular version *or* the plural one, but I'm not sure which would be 
> more
> useful.  Probably just the singular, since you don't want to 
> accidentally
> introduce too many dependencies.

Personally, I would prefer the --depends-on-match variant.

>> 5) Querying the patches from which a patch depends directly should be
>> possible without eximining the patches/*.gz files.
>>   -> http://bugs.darcs.net//Ticket/Display.html?id=457
[...]
> I think perhaps a darcs query dependencies would be appropriate.  It 
> could
> by default give explicit dependencies, and later (if someone wants to
> implement this) give implicit dependencies, which are much more 
> expensive
> (of course) to compute.
>
> I'm also thinking a darcs query patch would be appropriate (which would
> implement a subset of annotate's features)...

Sounds good.

>> What do you think:
>> - Are there already (clean) solutions for this in the current darcs
>> which I didn't see?
[...]
> Adding new darcs commands is actually quite easy due to its internal
> framework, so this sort of work is appropriate for newer darcs 
> developers.

Ok, understood the tip :-)
Unfortunately Darcs is my first contact with Haskell. So, if I wrote
Haskell code now it would be bad code... But I guess that by examinig 
the
code for interfacing with the GUI tool I will get more familar with
Darcs/Haskell...

[...]
>> Is this the direction in the development of darcs anyway?
>
> Definitely.
>
> [from another email]
>>> On the other hand, I guess you might find it very difficult if the 
>>> you
>>> run into trouble and if the developers still won't even acknowledge 
>>> your
>>> emails...
>> [...]
>> In fact this seems to be a problem...
>
> I've definitely been busy.  I glanced at the email when it first came 
> in,

Thank you very much!
I'm now convinced that
- the existing functionality is sufficient to build the targeted GUI 
tool to 80%
- the aspect of scriptability will be considered when implementing new 
Darcs features
- (once more) the Darcs philosophy is great!

Daniel