Oh I certainly don't think that FileTree is the best possible way ...�

as it stands FileTree functions as a �bridge that allows folks to migrate towards using git/mercurial/svn ...�

once a beach head in the git/mercurial/svn world is established it is a good time to re-evaluate what is important...

tools integration is probably much more important than the implementation detail of what the packages look like on disk ... but that's just my opinion:)

Personally when I am working, the method is the unit of functionality that is important ... so for me the history of method is important information and when I identify a change that is "interesting" i then may want to see all of the other things that changed when that method was changed ...�

the current implementation of FileTree makes this kind of spelunking possible ... but it takes tools to bring this to reality ...

Are there other ways to make this a reality? �... I'm almost certain that there are ... but perhaps this functionality is only important to me ... or perhaps there are better ways of looking at the whole problem ... or ???

I have a vision for where FileTree and tools built upon it are headed but I won't claim that my vision "the one true way"...�

I've said this about Metacello for years: "I can hardly wait until someone implements a replacement for Metacello" ... and I feel the same way about FileTree:)

I encourage other folks to implement their own visions...

This is evolution in action ... stand on the shoulders of FileTree and build something better ... stand on the shoulders of git and build something better ...�

Dale


On Thu, Mar 6, 2014 at 5:09 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Just to rephase myself: The fact we're discussing how to store things
in git is a HUGE advance in mindset, it means we'll end up versioning
on top of it.

I said: "That means we'll end up doing it the best possible way."

Maybe FileTree is the best possible way that considers all the
constraints and requirements you mention :)

When you built FileTree/Cypress you were an outlier (in the Smalltalk
realm), now it's mainstream. ;-)

Regards!


--
Esteban


2014-03-06 20:24 GMT-03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
> When you invent the next format, keep in mind that cross-platform source
> code sharing is something to consider as well ... It's always harder to make
> cross-platform code and some compromises have to be made to accommodate
> multiple dialects ...
>
> Also consider that with FileTree we are only on the first step of Make it
> work, Make it right, Make it fast ...
>
> Put your energy into implementations not arguments:)
>
> Dale
>
>
> On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo@gmail.com>
> wrote:
>>
>> I'm coming late to this, but Dolphin's VCS format has one file per package
>> and "extensions", and one file per class (instance and metaclass).
>>
>> We succesfuly used that approach with git for more than a year. I know
>> Object Arts did the same but backed by MS VCS (sourcesafe).
>>
>> It is good that we're discussing HOW to version everything with an
>> external file based VCS. That means we'll end up doing it the best possible
>> way.
>>
>> Regards.
>>
>> El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribi�:
>>
>>> On 06/03/14 22:34, Dale Henrichs wrote:
>>>>
>>>> My dream has finally come true ... Smalltalkers arguing the merits of
>>>> git vs. mercurial!
>>>
>>>
>>> Lucky you, I still have to wait for this to happen :-)
>>>
>>> Let's make myself clear, +1 was not because of mercurial,
>>> but because of class-per-file on-disk layout.
>>>
>>> Jan
>>>
>>>
>>>>
>>>> Alternate implementations to FileTree are welcome!
>>>>
>>>> Dale
>>>>
>>>>
>>>> On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz
>>>> <mailto:jan.vrany@fit.cvut.cz>> wrote:
>>>>
>>>>
>>>>
>>>> � � � � 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.
>>>>
>>>>
>>>> � � +1.
>>>> � � In St/X I do exactly the same. Works just fine.
>>>>
>>>> � � Jan
>>>>
>>>>
>>>>
>>>
>>>
>