On Mon, Aug 29, 2005 at 06:56:04PM +0200, Daniel Lutz wrote: > So, I'm planing to build a GUI for darcs (most probably with Qt/C++). > When I started to gather (my) requirements theses requirements for > darcs came out. Maybe I missed something but I didn't see a way how to > fullfill them with my current darcs in a clean, robust and scalable > way.
This would definitely be nice. > For good scriptability I think the following features should be > available in darcs (I guess all these things are relatively easy to > implement): ... > 2) It must be possible to get the file which comes out when all patches > until some patch are applied to an empty file. This is mainly required > to allow the usage of external (graphical) diff tools. It's not efficient, but darcs annotate -p foo filename | grep -v '^#' | sed -e 's/^ //' (or --match "hash XXX") Or annotate --xml with appropriate processing (harder to do in sed and grep). We could add a --plain option to annotate, which would eliminate the post-processing and could be implemented to run faster. Or we could stick this in the query supercommand as something like darcs query filecontents -p foo filename The query namespace is intended to hold numerous simple commands for getting data out of darcs, replacing especially the functionality of annotate, which is way complicated and bloated (since you can "annotate" the contents of either files, directories or patches). > 3) Repository locking. In BitKeeper there is a (blocking) block > command. Something similar would greatly improve the robustness of the > repository when using GUIs and shell scripts. We could certainly implement this. What do you mean by a "(blocking)" block command? Does it just run forever until interrupted, and then unlock the repo before exiting? I hadn't thought of that. When this sort of feature was suggested before, the assumption was a "lock" and "unlock" command, and I wasn't comfortable with the "unlock" command since it could easily let people corrupt their repositories. But if the block command just blocks while it's running, we'd be safe, which would be great. > 4) Setting the explicit dependencies (darcs record) by command > arguments (instead of asking for each available patch). Hmmm. Explicit dependencies are quite rarely used, so I don't want to complicate the interface much for their sake. But this would be a pretty easy feature to use... and if we dropped the prompting, we could actually simplify the interface and code. I can imagine something like five flags, --depends-on-tag --depends-on-patches --depends-on-patch --depends-on-matches --depends-on-match, where the plural and singular versions would add depends to all matching patches or just the most recent matching patch respectively. Technically we'd only need *either* the singular version *or* the plural one, but I'm not sure which would be more useful. Probably just the singular, since you don't want to accidentally introduce too many dependencies. > 5) Querying the patches from which a patch depends directly should be > possible without eximining the patches/*.gz files. > -> http://bugs.darcs.net//Ticket/Display.html?id=457 Actually, but 457 is asking about implicit dependencies. You never need examine the patches/*.gz files, since darcs annotate -p foo will give you their contents. But of course, you shouldn't need to be parsing darcs patch contents anyways. I think perhaps a darcs query dependencies would be appropriate. It could by default give explicit dependencies, and later (if someone wants to implement this) give implicit dependencies, which are much more expensive (of course) to compute. I'm also thinking a darcs query patch would be appropriate (which would implement a subset of annotate's features)... > What do you think: > - Are there already (clean) solutions for this in the current darcs > which I didn't see? I think only to the first (which others responded to), although even then there ought to be a nicer way to find the hash of a patch than with changes --xml. Adding new darcs commands is actually quite easy due to its internal framework, so this sort of work is appropriate for newer darcs developers. The only issue is that we don't want a proliferation of top-level darcs commands, which is why we created the query supercommand (which currently only contains manifest as a subcommand). I'd like to put into query all the sorts of commands you're asking about--things that don't modify the repository. The idea is that we can have many separate simple query subcommands, which would be easy to explain and understand, easy to use, easy to implement and easy to modify. For example, we could stick a command "darcs query hash" (or "patchhash"), which would only ever output a single hash value, and would have a few flags of the patch-selecting variety (--match, --patch, --tag) as its input. This would perhaps involve 50 lines of code (plus documentation). Emailing the BTS often gets better response than the -devel list (it goes to the -devel list also, on the initial report), so once you've got an idea what you want (and that we agree--for example, the features discussed above), submitting a wishlist bug per feature would be great. I'm hoping that someone will step up to implement this sort of feature. Another nice trick to encourage people to implement a feature (and also help out) is to create test scripts (in either shell or perl) that will test the desired feature. Mark does this occasionally, and if it looks like a reasonable feature (and a well-written test), sometimes I'll apply the patch and leave it in my local repository as a reminder that the feature should be implemented some time. A test script also ensures that we don't accidentally end up breaking the feature later. > - Is this the direction in the development of darcs anyway? Definitely. [from another email] > >On the other hand, I guess you might find it very difficult if the you > >run into trouble and if the developers still won't even acknowledge your > >emails... > [...] > In fact this seems to be a problem... I've definitely been busy. I glanced at the email when it first came in, and realized it would take a while to respond to, so I waited. I tend to get more darcs-related email than I can respond to, and so old messages accumulate and sometimes get forgotten (although I suspect I wouldn't have forgotten this one). I also sometimes intentionally wait, hoping someone else will answer (or volunteer), especially for feature requests like this, since I'm trying to let other developers implement features while I focus on bugs and performance (and reviewing new code, of course). -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
