Re: Diffing directories with external diff

Jerzy,

> I think if you put the "preview" files in their own view window it 
> will be difficult to operate from dialog boxes like commit dialog. 
Why not make all dialogs non-modal for that? Would be useful in many 
cases. (Ctrl+M, type some long message and realize that you've forgot 
something...) Opening two non-modal dialogs at the same time could be 
forbidden (the currently open modal dialog is stored in some 
variable).

> I think it's best to have it as a flat view instead of folder view 
+ 
> file view because it's easier to group files from different 
folders. 
> One can easily sort or filter by path to narrow view etc.
Honestly, I'd prefer a tree view for that. You can group by path as 
easy (just restrict your view to files in that folder), optionally 
one could of course filter the items in the tree view. We could 
implement both views, switchable by the already existing "Flat view" 
button.

> If you like the idea then create a flat file view with arbitrary 
files 
> then make it working with your diff implementation. We can extend 
it 
> later to accept files from different sources. It may be possible to 
> use current flat view for that if modified a bit.
Maybe that's the best approach for the "basket" -- implement a 
special case and then, after it's been tested, extend it to something 
more general. Let's see... If I'll do something like that, I will try 
to make it extendable to a general case. How can we coordinate this 
so this feature can make it into MacCvs and gCvs?

> Now that I got myself going I have another big idea. To make a 
folder 
> diff really fast and allow folder diff with different options it 
would 
> be best to get the diff output and then copy affected files to temp 
> folder and apply "patch" to it and then run an external diff. We 
used 
> to have patch.exe in our distro long time ago but it was dropped. 
We 
> could either re-introduce it or just copy some code out of it if 
it's 
> not too much. This is by far most efficient way but also much more 
> work.
That would be definitely the crudest speed-up possible, at least over 
slow connections. For the first time, we could rely on some external 
patch.exe or just supply our own binary (for WinCvs). We can even 
make do without it and use CVS's built-in patch algorithm:

- Copy the files in question to a temp folder (keeping the folder 
hierarchy and with the CVS sandbox files)
- Issue a cvs update -r... [-r...] for the temp location and only for 
those files

The "update" approach won't work if we want to avoid copying all 
sandbox files to the temp folder _and_ use one cvs diff pass only. 
So, if we're doing optimization in this direction, I think it's 
better to use a patch.exe of our own and apply the patches as they 
come.

Still, for changed files in the sandbox, a transmission of the 
file's "clean copy" is inevitable. (The CVS/Base subfolder is 
populated by the cvs edit command, we could optionally get the clean 
files from there if they exist.)

Let's keep this idea. For now, the performance of multi-file diff is 
horrible due to the fact that for every file a separate CVS 
connection is opened. I've figured out how to make it faster, this is 
what I'm about to do next.

Regards,

Kirill





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/