GNOME Bugzilla – Bug 366244
compares every file in a dir, which doesn't exist on the other side
Last modified: 2015-05-08 19:18:13 UTC
Please describe the problem: i compare two dirs. one very big directory, doesn't exist on the left side, but meld lookup, every file on the right side. so the comparing is not very effective. the directory which not exist, needs 30 minuntes to compare. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? yes Other information:
What is the expected behavior in this case?
it would be beautiful if meld, could ignore the subfiles, which are IN the not existing directory.
That would be OK, but it would be very easy to miss changes. There's another bug about marking folders containing differences which would need to be tackled first. BTW if it's the same directory each time (obj/ or build/ ?) there are folder name filters.
I hope you understand me. I will try another explanation. the left tree looks like this: /home/sascha /home/sascha/devel /home/sascha/devel/kernel /home/sascha/devel/kernel/... ... the right side: /home/sascha /home/sascha/devel /home/sascha/devel/anjuta /home/sascha/devel/anjuta/src /home/sascha/devel/anjuta/src/ /home/sascha/devel/anjuta/src/main.c /home/sascha/devel/anjuta/src/Makefile .... /home/sascha/devel/kernel /home/sascha/devel/kernel/... ... there is no, anjuta directory on the left-side, but meld is looking for /home/sascha/devel/anjuta/src /home/sascha/devel/anjuta/src/main.c /home/sascha/devel/anjuta/src/Makefile .... /home/sascha/devel/anjuta/src/__/__/__/..... and so on I do not understand, why meld for the files within anjuta listing looks. because it is clear that the entire anjute directory is missing. (sorry for my bad english)
I think parsing the output of "diff -wurq <dir1> <dir2> |grep -v CVS |grep -v .pyc" could be the fastest way to make everyone happy. 8 seconds vs _way more than 300 seconds_! (showing new and modified files in two cvs checkouts on a Celeron 2.80 GHz) diff and grep should be optimized and well-tested C code, but the greatest difference is that Meld 1.1.4 is scanning directories (and files?) that don't exist in the other directory.
*** Bug 488940 has been marked as a duplicate of this bug. ***
I'm sure this used to be true, but we don't actually do this any more. We always scan the whole tree (i.e., even if the right side doesn't contain /foo/bar, we'll still descend /foo/bar on the left side because we always want to show the whole tree) but we don't constantly stat non-existent files.
OK, but why is showing contents of a folder that does not exist on both sides necessary for a comparison? It does not add any useful information to the comparison results. If you want to look into the folder you can still right click and choose "open externally". Would it be possible to at least defer the scanning of folders that exist only on one side to the end of the scan so the differences of *existing* files appear more quickly? Or better yet, defer the scan until the path is interactively expanded by the user? If you compare huge (as in >20GB) directory trees using Meld and you do this you will most probably notice a huge difference in speed.