From: Joachim E. <joa...@gm...> - 2010-03-18 20:36:39
|
Hi Wladimir, For the moment creating a local copy of your directory is the only possibility. Previously I had hopes, that some day a KIO-subsystem would do the job of providing the frontend for a version. (Similar to clearcase dynamic views.) But I don't know the current state about this. As you say, a plugin system might help, but a different plugin for each different version control system would be needed. Perhaps someone wants to start such a project. It might even be best, if this plugin system were an external library, usable by KDiff3 or other frontends. For each VCS the commands and the usage are slightly different, so it would be best if people who know their system and want to do some coding would participate. Possibly I could help with defining the interface of the plugins depending on the needs of KDiff3. Or does such a thing already exist? Cheers, Joachim > Hello KDiff3 developers and users, > > First, congratulations, in my opinion kdiff3 is the best visual diff/merge > tool by far. I especially like the directory comparison. > > One of my gripes about version control systems is that they pop up the diff > program for each file separately (git difftool, clearcase code inspection, > etc all have this problem). This is because they create two or three > temporary files, and call the diff tool for each file to be diffed/merged. > > What would be the best way to use KDiff3 directory compare functionality in > this case, as the directory structure exists nowhere on disk? > > The simplest (I guess) would be to make a front-end script that exports the > changed files in a temporary directory structure and call kdiff3 on it. > Personally, I don't really like the idea of creating a temporary directory > structure that much, as they need a (potentially) dangerous recursive > delete to clean up, and leave waste files when the program exits > unexpectedly. > > As it is not practical to pass all that data [(path, (date1, content1), > (date2, content2), (date3, content3) ), ...] on the command line either, > I've been thinking about adding some kind of interface to provide "virtual" > files to KDiff3, for example via DBus-QT. On the other hand, I don't want > to be dependent on the VFS services offered by KDE, as that wouldn't port > to windows... > > The other option would be to build the actual version control functionality > into KDiff3 (for example, using plugins), but I don't like that, as I don't > want to make it specific to any VCS, I just want another script or > application be able to invoke KDiff3 and compare anything. > > So, overall, I guess the option to just create a temporary tree, even > though a bit ugly, might be best... > > Any input on this? > > Cheers, > Wladimir > |