Am 02.09.2005 um 17:02 schrieb Martin Ellis:
On Monday 29 Aug 2005 17:56, Daniel Lutz wrote:
1) It must be possible to address each patch in a repository
unambiguosly in every command which accepts patches (e.g. diff,
changes, unrecord).
Ian Lynagh has just pointed me to part of the manual that explains this
In the "Common options to darcs commands" section, under "Match"
see:
"This is intended to be used, for example, by programs allowing you
to view darcs repositories (e.g. cgi scripts like viewCVS)."
It's talking about the patch hash. You seem to be able to get that
from
darcs changes --xml-output.
That does the job. Thanks!
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.
I thought this was discussed before somewhere, and I can't find it now.
One option was simply to use get to create a new repo to the given tag
and then just copy the file. Not particularly efficient, maybe
someone else
can remember...
At work we use BitKeeper and its great difftool and revtool.
Personally, I find it a very efficient way to get an overview. But it
has to be really fast to be useful. When you have to move megabytes
(cloning) this is not the case...
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.
I'm not sure I see where the problem is here, unless you start using
things
like unpull.... On the other hand, it's Friday afternoon, and I'm
probably
missing something.
Darcs does (of course) lock while it runs a command.
For scripts you want to have guaranteed that the repository is locked
during several Darcs command (e.g. because the output of one command is
used as input for a second).
Concerning GUIs: It is much simpler for a GUI which displays in some
ways the state of the repository when it can assume that the repository
is not changed. Without a flexible locking mechanism on the Darcs
repository itself this is not possible.
[...]
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...
Daniel
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
