Why not having just one  folder level? As we would have in any other language? 
One folder per package, and inside a .st file per class. 

Alexandre 

> Le 30 sept. 2015 à 18:47, Dale Henrichs <[email protected]> a 
> écrit :
> 
> 
> 
>> On 09/29/2015 01:50 AM, Henrik Johansen wrote:
>> 
>>> On 29 Sep 2015, at 1:48 , Dale Henrichs <[email protected]> 
>>> wrote:
>>> 
>>> The big issue for git and windows (in general) is that there is a 255 
>>> character limit on the paths for files .... I recently pruned some file 
>>> names for Metacello (on a win-hack branch) just to get Metacello to work 
>>> with filetree .. 
>>> 
>>> Working with Github Desktop[1] for Windows makes the experience of using 
>>> git from the command line tolerable on Windows - you get a retty nice bash 
>>> shell to work with so as a non-windows user I can work in a pretty familiar 
>>> environment ...
>>> 
>>> At the moment I'm working with Pharo3.0 on Windows, so I don't have any 
>>> useful feedback right now (assuming things have changed a bit on Windows 
>>> with Pharo4.0 and Pharo5.0) ...
>>> 
>>> Dale
>> 
>> IIRC, there is some flag you can set to make (some?) the actual git client 
>> (but not bundled tools)  support long filenames on Windows:
>> git config core.longpaths true
>> For instance, cloning the PharoVM repo choked (or rather, failed 
>> semi-silently) on some really long selector in an obscure plugin somewhere 
>> until I found that...
> 
> Thanks Henry, I have done the `git config core.longpaths true` and I believe 
> that that (supposedly) addresses manipulating long file paths problem for 
> git, it does not help an application like pharo read the files with long 
> paths ... without additional work ... and even then it's not clear that it 
> truly fixes the problem ... because the fundamental limit is embedded in the 
> OS ... for example from the git bash shell, I cannot `rm` the directories 
> that have long paths (I have to use the explorer to delete them) and when I 
> write out a package with long paths from Pharo3.0 the long path files are 
> silently deleted ... 
> 
> If it worked for you, that's good ... my experience was not quite as nice:)
> 
> Dale

Reply via email to