Quoting [EMAIL PROTECTED]: > > > Interesting. Do you have any test cases? Or could this tool be used in > any > > test cases to help stress darcs? > > No, but I use deps.pl personally to generate pretty graphs of my patch > dependencies. > > > I'm wondering if we should have a darcs-contrib repository. I'm > envisioning a > > set of contributed tools (like darcs.cgi, this tool and others) which work > well > > with darcs but are not required for a fully functional darcs. > > That's what the tools/ dir is supposed to be.
Actually I inferred that :) My reason for contrib was subtle and I should explain my reasoning better. My thought is to reduce the amount of code in the darcs repository and to decouple darcs from the darcs tools as much as possible. IMO, the darcs repo should just contain enough code for darcs itself + documentation and test suite. I think the tools that make darcs better are important and needed, but I'm not crazy about the idea of lumping them all in with the darcs source. One possible counter argument to separating the tools from darcs is that the tools will implicitly depend on a specific version of darcs and bundling them together will help maintain the implicit dependence. Here I would argue that it's better for the tools to change their interaction with darcs depending on the version of darcs that they need to interface with. This reminds me of something I've been meaning to bring up. Darcs version numbers seem to be crawling along in this sequence 1.0.3, 1.0.4, 1.0.5, 1.0.6, ... Meanwhile new features have been implemented, existing features/command names have been changed and bugs have been fixed. I think it would be better if the version number gave you a hint about when it contains bug fixes vs. feature changes vs. interface changes vs. new features. I don't claim to have a schema to translate version numbers to the above information but I'm sure we could cook up something. For example, whenever the interface changes we could have a policy of incrementing the middle number. It's simple, but perhaps not that useful. Maybe instead, what we need is a UI version or API version that can be queried. Maybe we need a really complex solution such as having an xml output that describes the darcs interface for other programs to make sense of. To summarize, I have this implict goal of making darcs be a very focused, minimal but extensible tool which plays nicely with addons contributed from all over the place. Is anyone with me here or does this sound like over engineering? Thanks, Jason _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
