[darcs-devel] status of libdarcs?

[Ben Coburn]

On Mar 29, 2008, at 08:24, David Roundy wrote:
> On Sat, Mar 29, 2008 at 12:50:12AM -0700, Ben Coburn wrote:
>> Basically I think "libdarcs" should allow external code to be
>> interposed between any gathering of information and subsequent
>> manipulation of the repository (or export of data). While "one shot"
>> commands that mimic the command line interface should be included,
>> commands that allow for the manipulation of intermediate data are  
>> much
>> more useful. There should also be a programmer friendly way to handle
>> interactive commands where answers to each question may changes the
>> other questions. Naturally "libdarcs" would also provide for reading/
>> parsing, creation, and output of all darcs data structures/formats
>> (i.e. patch files, darcs send -o files, etc).
>>
>> Hopefully I've been clear without being to verbose here.
>
> Yes, you've been pretty clear.  This is the sort of libdarcs that  
> I'd be
> very suprised to see actually happen, mostly because noone seems  
> interested
> in creating it, and those who claim to want it don't seem interested  
> in
> working on it.  And it's a very hard problem.  But I might be wrong.
>

I think that the people who want this kind of "libdarcs" are, by  
definition, not Haskell programmers. This produces a bit of a "chicken  
and egg" problem.

If I wrote Haskell, I would probably have written the tool I've been  
working on as an overlay of patches over darcs-unstable to produce my  
own "flavor" of darcs. Unfortunately, I barely have time for my own  
projects right now -- let alone picking up another language "just for  
fun".

> Also in question is whether libdarcs should allow arbitrary programs  
> to
> corrupt user's repositories.  The sort of API you ask for would be  
> very
> hard to implement in anything approaching a safe manner.
>

I don't think it is as hard to produce a relatively safe "libdarcs"  
API as you describe. Naturally I may be overlooking something, but let  
me outline some brainstorming on how a safe "libdarcs camp 2.5" API  
might work. I'll break this down based on types of repository  
corruption/errors.

1) Tool corrupts patch data before giving it to "libdarcs".
The tool is breaking it's contract with the user.... Any good tool  
developer should catch these bugs in testing. Even so, "libdarcs" may  
still produce a sane error (see below).

2) Repository changes with unexpected or bad side effects.
2.a) Adding a patch to the set of patches in a repository produces a  
conflict.
2.b) Modifying a patch breaks repository history for existing  
repositories.
Normal methods that detect these errors "roll back" any changes they  
have made to the repository and throw an exception of severity  
"warning". This gives the tool a chance to detect the warning and take  
appropriate action. To make a method run to completion with side  
effects, one uses the "forced" version of the method. For example,  
repo.putFromMem(patch) is safe but may throw exceptions, while  
repo.forcePutFromMem(patch) does not throw "warnings" and may leave  
marked changes in the repository. Naturally, the "forced" flavor of  
methods should only be used when necessary. This gives tool developers  
a way to avoid unexpectedly shooting themselves in the foot, while  
requiring them to think about exactly what it is they are doing.

3) Darcs commutation errors or other crises.
If at all possible the method should safely "roll back" any changes  
that were made to the repository and throw an exception of severity  
"error". This will allow the tool to try a different way or inform the  
user that a particular operation is "impossible". If "libdarcs" can  
not "roll back" the changes, it should trigger a more severe "fatal  
error" exception that will allow the tool to stop and warn the user  
before any more damage occurs. (These "fatal error" exceptions should  
never happen because a normal "error" exception should be thrown  
before data is written to disk in a permanent way.)

4) Corruption of darcs files or file formats on disk.
Using "libdarcs" to read/write all darcs format data should make this  
a "can't happen" error. Only a state that produces a "fatal error"  
exception (see case 3) could produce on disk corruption.

Maybe I'm missing some other classes of problems, but this is what I  
could think of quickly.

Another part of a rich "libdarcs camp 2.5" API are some methods for  
abstracting the process of correcting repository history. For example,  
we could use a command that recursively corrects explicit dependencies  
in inventories and tags after changing one or more patches -- such as  
repo.correctDependencies(fromArray, toArray). Typically the lists of  
patch identifiers would be one-to-many or many-to-one where patches  
are split or merged. Patch objects should probably run the trivial  
case of a one-to-one change automatically when they are saved back to  
the repository (keeping in mind case 2 exceptions).

Well that's enough brainstorming for now... hope it is an interesting  
read. :-)

Regards, Ben Coburn