> > I thnk that rather than focus on the disk format which I hardly ever > actually look at ... that folks should be looking at tools support (like > Thierry) ... this is where the real work needs to happen ... good tools can > hide the disk fomat completely so why does the disk format matter ...
I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). But to bottom line this thread (for me at least, because I'm getting lost): 1. methodProperties.json provide compatibility for FileTree, so I don't want to get rid of it (for now) 2. the large amount of file changes is probably a bug (I'll try to be more observant about the commits in the future and hopefully some pattern will emerge.) 3. I shouldn't want to break things for now at least 4. more people are starting to work on Git 5. I need to learn about FileTree at some point if I want to contribute and experiment with (my) ideas (which won't be soon as I'm preparing for my finals) Thanks for all your answers. Peter On Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier <thierry.goub...@gmail.com> wrote: > 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 >>> <s...@clipperadams.com <mailto:s...@clipperadams.com>> 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. >>> >>> >>> >> > >
