Max Battcher <[EMAIL PROTECTED]> writes: > Max Battcher wrote: >> Ultimately, however I think worrying about libdarcs in this case is a >> red herring: the first focus should be performance. Given CLI commands >> that run nearly as fast as their git counterparts is probably more >> useful to everyone involved (even with shell-scripting >> interop/marshalling concerns). > > I thought this an important enough paragraph to republish above the > fold. It seems to me that a good portion of the call for a libdarcs is > centered around performance/marshalling issues. It seems to me that if > you think that libdarcs will impact a third-party application > significantly in performance, on release, there are only a couple of > assumptions to draw: > > 1) Haskell's shell IO is slow. > 2) Darcs' use of shell IO is slow. > 3) Third-party's language system calls are slow. > 4) Third-party's language (xml, regex) parsers are slow.
5) The CLI is does not have some useful functions that applications could leverage. For example, a whole swag of visualization tools would be easier if there was an easy way to find out if there was any dependency relation between two patches X and Y, and if so, what kind of relation it is. The only way I've seen that done by a darcs CLI-using script is to repeatedly pull and unpull patches from a repository, taking note of which patches are skipped. This approach was something like O(n²) or possibly O(nⁿ) time; certainly it wasn't usable for a repository with more than a couple of hundred patches. Similarly, I can't think of an easy way to answer questions about conflictors like "with which hunks, in which patches, does this |: hunk conflict?" using the command-line interface. Maybe Darcs could have such utilities built-in, but I'm not sure it's the Right Thing for a version control system to include code for emitting Graphviz graph definitions, for example. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
