Re: Recursive Directory Compare

• Posted by petelomax at blueyonder.co.uk Sep 14, 2002
• 448 views

{{{ On Sat, 14 Sep 2002 00:26:58 -0300, rforno at tutopia.com wrote:

Thanks, I'm still reading/absorbing that.

I am slowly getting my head round what I want...

Does the following stab at documenting this scan(read well/sense) at all to anyone, specially the CAVEAT bit?

documentation begins

Compare Directory Use this option to quickly process a set of updates to a project which have been stored in a secondary/temporary directory.

Initially you should have open in the current tab any file from the main project directory. The files to be compared against are (optionally) renamed as the processing continues as follows:

.e .ex .ew .eu .exw .exu become .d .dx .dw .du .dxw .dxu

on the basis that "e"uphoria => "d"one. Subsequently, opening files in the relevant directory(ies) will not naturally show files with those extensions.(They will show when the Files of Type drop-down is changed to all files.) [In practice, the first letter of the extension is reduced by one, rather than explicitly changing an "e" to a "d", so eg .xyz will become .wyz]

[CAVEAT: The following is rather pedantic; generally it should work as expected.]

Now, *IF* the initial and target compare directories are "flat", ie neither has any subdirectories, then all will proceed as expected.

The initial directory may validly contain the target directory with no conflict: Eg:

Edit/ screen/ files/ keyboard/ updates/ screen/ files/ keyboard/

Only edit/screen/pos.e & edit/updates/screen/pos.e will be suggested for a file comparison, not (naively) e/u/s/pos.e vs. e/u/s/pos.e (yep, the same file), vice versa, etc.

If the initial and target directories both have subdirectories, then only files within the same sub-directories will be compared.

If the target directory has any subdirectories with no equivalent in the initial directory their contents will be ignored.

However, if the target directory has no sub-directories, then the initial directory will be fully-depth scanned for possible files to match. In this case, any duplicates found within the sub-directories of the initial directory will be ignored; any duplication from the initial directory and any in the sub-directories will only take the file in the initial directory as a possible match. To clarify this point, if you have several readme.txt files scattered throughout the main development directory but only one in the "updates" directory (which has no subdirectories), then only the "main" initial readme.txt will be compared. Further, if the main directory has /screen/readme.txt and /keyboard/readme.txt, then any readme.txt in an /updates/ directory (not in an equivalent subdirectory) will *NOT* be compared when no <initial>/readme.txt exists.

The latter point is moot, perhaps, but important when one or two updated files are returned without the appropriate directory structure. Not all cases can ever be catered for 100% but the above approach reduces conflict as much as possible.

[END OF CAVEAT]

One should also bear in mind that a directory compare operation starting from the "updates" directory will give very different (and probably non-intuitive) results when any/no sub-directories are involved and is therefore strongly discouraged. DO NOT open an updated file you have received and then run Directory Compare

stab at documenting it ends

Comments (be brutal, I can take it!) please...

Pete