Eric Kow wrote:
> [cut]
> Those are my personal desires anyway.
> What do you think? Sound like a plan?
Ok, those are short term things and I like them and they
should be considered high priority.
I (as a user) could add few more low priority wishes which
I did not notice in issue tracker. Not sure anybody else
beside me would be interested. The last one is probably
for something like darcs 3.0 :-D
1) Darcs help should mention the preferred commands in a
consistent way:
a) Use only non-abbreviated command aliases there (e.g.
move instead of mv).
b) Use only dash separated command names (for commands
which consist of more words or concatenated names,
add aliases where a corresponding counterpart is
missing).
c) List all aliases (or primary command names) in help
message for each command. E.g. help for "move" says
it is an alias for "mv", but help for "mv" does not
say it has an alias named "move".
2) Create a patch theory primer. Looks like Ian is working
on this, though it looks like he will describe something
else as the implementation and it looks to be geared
towards a full paper proving some desirable properties
but it may not be far from a primer to be usable by
newbs. Or ... is the darcs source code around conflict
resolution that well documented that one can figure it
out from there? If yes, what files should one read?
3) Make darcs really patch based:
a) Amend-record should be safe. This probably means
that a hierarchy should be added to patches.
A patch (as seen in darcs log and other UI commands)
should be composed of a sequence of patches so
amending a patch would add the "amendment" to it and
it would not be a problem when the original patch
was already pushed (the "amendment" would get pushed
the next time). It should be possible to look at
components of a patch then.
b) Allow patches which depend on each other to commute
(by adding conflict resolution). So if we have patches
Porig Qorig in repository, we could change their
order to Qnew Pnew where Qnew would be actually
a sequence like (Porig Qorig Porig^') and Pnew would
be (Porig Qorig Qnew^). These Qnew and Pnew should
replicate to cloned repositories without problem in
a similar way as in option 3.a - as a patch to patch
(maybe by transferring Porig^' and some associated
info).
Order P Q means P is first in the repository.
^ stands for inverse patch.
' stands for the patch on the opposite side of square.
I do not know whether this would work as I proposed.
I'm not able to check it (partially because of my
request 2 and laziness to figure it out from source
code, David's partial description in darcs book and
Ian's draft) but I'm guessing it is possible. Anyway
I think this would be superior to alternatives like
mercurial queues or git rebase.
Peter.
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
