On 06.03.2014, at 22:14, Eliot Miranda <[email protected]> wrote:
> > > > On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs > <[email protected]> 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? We don’t. Diffing has nothing to do with this (or only little). But if a method has its own file, then the hash of that method will be stable as long as it is unchanged, regardless of the number of commits it is referenced by. This makes it very easy to identify the changes that have been made to a particular method. How these changes are *visualized* is a different matter (and I would like to have a nice GUI for that too). > 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 > > > > On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <[email protected]> wrote: > Max wrote > >In my opinion there are other factors, like readability, maintenance etc, > >that are maybe more important than speed. > > I’m not totally convinced. The readability from the outside is limited by > having one file per method. > Mainstream tooling assumes one file per class. The emails from github to this > list are a good example > of the usability problems that leads to. I don’t want to suggest switching to > a larger granularity, as that > leads to another set of problems. > > My point was more if we could mostly avoid the source view, and directly work > with the archive. > Why is working with single files fastest? > > Stephan > > > > > -- > best, > Eliot
