On Wed, Apr 8, 2009 at 12:01 AM, TK Soh <teekay...@gmail.com> wrote: > On Wed, Apr 8, 2009 at 4:00 AM, Steve Borho <st...@borho.org> wrote: >> I'm stuck in a dilemma regarding the visual diff system as it's >> developing on the crew repository. >> >> I've pulled the extdiff functionality into TortoiseHg, creating a new >> visdiff.py module under hggtk. >> It has three improvements over extdiff: >> >> 1) Uses py2.4's subprocess module to launch your tool, so no more >> escaping issues and no more cmd windows >> 2) Provides a GUI for selecting among the diffable files (no more >> directory diff requirement) >> 3) Directly compares against the working copy files, even when more >> than one file is being diffed. >> >> It's currently only wired up to the 'hgtk vdiff' command (and thus the >> shell context menu). >> >> Here's my delimma. I've already removed one of the two major >> stumbling blocks for setting up any any arbitrary diff tool by >> removing the requirement for your tool to support directory diffs >> (making tools like p4merge now useable). The other major stumbling >> block that new users run into is making sure their tool does not fork >> another process. The way extdiff normally operates, it creates >> temporary copies of the files you are comparing, launches your diff >> tool, waits for the tool to exit, then cleans up those temp >> directories. Many tools fork a GUI process and exit immediately, >> which then sets up a race condition on whether they read the temp >> files before those files are deleted (see issue #126). >> >> When the visdiff GUI is launched, it holds the temporary files in >> place until our GUI is closed. This removes the requirement for the >> tool not to fork an extra process, it no longer matters. However, >> today we only launch the GUI when more than one file is diffable. If >> only a single file is to be compared, we launch the diff tool directly >> (less clicking, and all). >> >> So what I'm asking is whether you, the users, think removing this last >> requirement on the diff tools outweighs the annoyance of bringing up >> the selection GUI even when there is only a single file to be diffed? > > It's not that clear to me what the 'last requirement' is. Please help > elaborate.
The last requirement is that your diff tool does not fork a background process. I'm leaning towards Oleg's idea: * Always launch the GUI * Always keep the temporary files until our GUI is closed * Always launch the diff tool asynchronously * When only a single file is listed, launch the tool right away This makes the behavior consistent and will be easier to document. I'll probably add a descriptive label on the GUI telling the user that the temporary files will be deleted when the window is closed. Now that I think about it, this is probably the only way this could work if we want other dialogs to be able to use this. Otherwise there would be GTK/threading problems. -- Steve Borho ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Tortoisehg-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
