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
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
