Thanks to all those who have directly or indirectly responded to my message. The issues that have emerged are very interesting, but in most cases I am not qualified to intervene.
Perhaps, I didn´t adequately explain my intentions: I am not asking anyone else to develop a particular tool (or an API), what I mean is that I'll do it myself. In this regard, I would say the following: 1. I do not have time to study Haskell, DARCS internals and then program a new indexing in the metadata to make some operations fly.... but I have time to study DARCS from a user point of view, and then program some C# tools based on my knowledge as a user. 1. Perhaps the CLI and a scripting language is all we need to get the most out of DARCS. But my personal view is that different interfaces are not alternative but complementary. So, the development of a rich UI for DARCS still stands. 2. Perhaps programming in layers and developing APIs brings many complications to the software life cycle, but the fact is that I am unable to program otherwise (I mess too much). Hence, I have no other choice but to develop a "libdarcs" from the unique DARCS interface: the CLI (as I said in my first message, to develop an API over CLI is quite complicated, but I find more complicated to study repository format). 3. What classes and functions will have libdarcs? In principle, it would be more desirable to develop a standard. For a long time, "de facto" standard in version control was the MSSSC Visual Source Safe. MSSSC is quite simple, but has the advantage of being supported in many environments (IDEs, etc.). Recently, more complete APIs have appeared, but (in my opinion) none do justice to DARCS special characteristics. The best option is to develop a special DARCS API (libdarcs), and then build restrictive enclosures that reduces libdarcs to meet the standards (Visual Studio 2008 admits non standard VC addins). 4. As I am only able to program in layers, there will be a set of classes that reflect DARCS commands and options (at a lower level of abstraction than the API). It is not necessary that this layer reflects all commands and all options to support the API, but if we reflect all commands and all options, we will have an added value: from this command layer, will be very easy to build an assisted visual script generator. 5. Before writing this message, I made an initial model with a few Command and API classes that works ok: it creates a DARCS repository, records patches and then load the patches, hunks and related files from a "darcs changes -s --xml" command. 6. After completing an initial development, I will put a source repository online. Santiago _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
