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 least4. more people are starting to work on Git5. 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.PeterOn Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier <[hidden email]> 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
<[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.
Free forum by Nabble | Edit this page |