Posted by
Thierry Goubier on
Apr 08, 2015; 5:12am
URL: https://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818264.html
Le 08/04/2015 02:05, Dale Henrichs a écrit :
> Peter,
>
> That looks like a bug in the FileTree writer ... wiht one method change
> there should have been only one method property file change ...
Yes, I'd agree. This is surprising.
Unless you had been loading that package via another repository /
another version / another branch before in the same image?
MCMethodDefinition has a cache which consider equals methods with
different timestamps, and, in that case, it would carry the timestamps
of the previous version, and writing those upon save instead of the
originals.
> Peter and Sean,
>
> If you are interested in contributing code/bugfixes to FileTree, I will
> welcome pull requests ... As I have mentioned in several posts today, I
> do not have the time to fiddle with changes to the FileTree format
> myself, but I welcome contributions.
>
> Damien has started work on an updated version of the FileTree format[2].
>
> I have threatened in the past to add an option to a repository that
> would eliminate the need to store monticello meta data ... Damien is
> working on "starting from scratch" on the new format, because the
> current implementation supports 4-5 different FileTree formats. Damien's
> work could be leveraged to add an "optional Monticello meta data" option
> to FileTree and if your SCM (like git) gives you per method history with
> the proper tools you can leverage that information..
I would say this could be a reasonable possibility, in that you could
have two modes of compatibility:
- Complete filetree compatibility for gitfiletree: the current
situation, with properties and version written to disk.
- Partial filetree compatibility, where that metadata isn't written and
you rely on gitfiletree to recreate it to export as .mcz.
Partial compatibility has two effects, which need to be considered. When
using github:// or bitbucket:// urls, filetree will be used and your
packages will end up having no version number (except .1?), no author,
no timestamps for methods, etc... And the second one is that, if you
clone a mcz inside the gitfiletree repository, the mcz ancestry of
versions and author timestamps on methods will be lost, which is
something you may not want.
Thierry
> As I ranted in another post ... changing the disk format is the easy
> part ... building and maintaining tools for the 4-5 different Smalltalk
> dialects is a different matter ...
>
> Dale
>
> [1]
https://github.com/dalehenrich/filetree/issues> [2]
https://github.com/dalehenrich/filetree/issues/144> On 04/07/2015 04:38 PM, Peter Uhnák wrote:
>> Yeah, I do use the MergeDriver and it saved me a lot of headache, but
>> when I see things like this
>>
>>
https://github.com/dynacase/dynacase/commit/90141d63bfdd433e51a768c2191e035b76c5da83>>
>> where one five lines long method generated 14 file changes with 180
>> additions and 172 deletions... it makes the log on github and pull
>> requests incredibly messy.
>>
>> I don't want to cut branch under myself if I were to remove the
>> properties file. So my question now is: how hard would it be to
>> regenerate those files?
>>
>> Or maybe if it was moved to some metadirectory. This reminds me a bit
>> of svn which polluted the whole folder tree with .svn files everywhere.
>>
>> Peter
>>
>>
>>
>> On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris
>> <
[hidden email] <mailto:
[hidden email]>> wrote:
>>
>> Dale Henrichs-3 wrote
>> > Personally I use
>> >
https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never
>> > think twice about the properties files ...
>>
>> Ooh, intriguing. In other to make it easier to view code on
>> GitHub, I've
>> been toying with the idea of generating one-class-per-file in
>> addition to
>> the regular gitfiletree files. Could this be used to make that
>> possible
>> without complicating Git?
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> View this message in context:
>>
http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233.html>> Sent from the Pharo Smalltalk Users mailing list archive at
>> Nabble.com.
>>
>>
>