On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs
<dale.henrichs@gemtalksystems.com> wrote:
Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems.
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Dale