kdiff3-user

[Kdiff3-user] "virtual" directory compare

[Wladimir v. d. L. <la...@gm...>]

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

Re: [Kdiff3-user] "virtual" directory compare

[Joachim E. <joa...@gm...>]

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
> 

Re: [Kdiff3-user] "virtual" directory compare

[Nick <no...@co...>]

The Meld diff/merge tool (http://meld.sourceforge.net) has built-in
knowledge of some version control systems, though I don't know if it
employs a plugin interface for that functionality.  You may want to take
a look at it for ideas on achieving your goal w/ KDiff3. 

Best regards,
Nick


On Thu, 2010-03-18 at 21:36 +0100, Joachim Eibl wrote:

> 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
> > 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Kdiff3-user mailing list
> Kdi...@li...
> https://lists.sourceforge.net/lists/listinfo/kdiff3-user