> I am curious about the ordering you picked: was there any
> (performance? usability?) reason for it? I guess if I had to come up
> with an ordering for diff myself, I'd just have picked 'sort by name',
> not 'files first, directories second, sorted by name'.
Actually there was a good reason (well, thats a subjective statement,
*I* believe its a good reason, you be the judge).
It is very common practice, when contributing large patches,
to have the maintainers ask you to split the patch up into
multiple smaller pieces, so that they can be more effectively
reviewed. There are two ways of doing that:
a) run svn diff fon specific sets of files for each patch
b) run wvn diff on the whole tree, and use the generated output
to work on a CHangeLong, and split the large diff into its
It is in light of option (b) that I chose the ordering I did.
Lets take a real-world example. Suppose I am working on gcc,
and I have made changes that span most of its sub-trees. If
we were to sort the entire list alphabetically, I would have
my diff to calls.c followed by patches to files in config/i386
followed by the diff to toplev.c. But patches in subdirectories
tend to be logically grouped. Thus, the patches in config/* are
likely to be target-specific patches, whereas the patches in the
main gcc directory are generic. I would normally want to put
all of the generic fixes in one patch, and platform or target
sepcific ones in another. A simple lexical sort would foil that.
If you are not familiar with the gcc tree, pretend its the svn
tree itself. If I made patches in libsvn_fs_base, I am much
more likely to want to group all of the *.[ch] files into a
patch, then all the bdb/* into another, then util/* into yet
another. This is a poorer example becuase the layout of svn
actually lends itself better to things being "sensible" if
a simple lexical ordering was used, but you get the idea.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Nov 20 22:00:03 2005