Hi, > On 15 Jan 2018, at 10:44, Guillermo Polito <[email protected]> wrote: > > > > On Sun, Jan 14, 2018 at 7:11 PM, Dale Henrichs > <[email protected] <mailto:[email protected]>> > wrote: > I've been skimming the ironically named "blame" thread and just want to clear > up some apparent misconceptions. > > git/github is not the reason that the author/timestamps information was > "lost" ... when tonel was introduced the author/timestamp info was not > included in the format as a separately serialized file. filetree's > implementation of author/timestamp support (around for almost 6 years now) > was an annoying source of commit conflicts and often prevented automatic > merges. > > git/github has perfectly functional blame support[1], so the decision to rely > on git for supplying the author/timestamp for tonel was a sound decision. > Thierry Goubier's GitFileTree[2] implementation does a very good job of > converting git author/timestamp information into Monticello meta data, and is > proof that author/timestamp information can be extracted from a git > repository. > > AFAICT, the single issue here is that the code to link between git's > author/timestamp information and the in-image author/timestamp information > has not been written YET ... > > Actually, I remember Esteban doing a prototype some months ago. The idea was > to query author/timestamp information from git just after bootstrapping, and > to embed this information in the resulting image. > The problem is that this approach was SUPER slow, because it had to blame on > each method. And increasing the build times is not very nice because it kind > of slows down the frequency of integrations, specially during sprints. > > Now, each commit usually changes only a couple of methods, so > author/timestamp of methods will remain the same for 99.9% of the methods > most of the time. It would be possible to cache it and re-calculate the new > ones following the commit diff. At least this would restore the timestamp of > the methods found in the image. > > A second point, and orthogonal to the previous one, would be to also manage > the "browse versions". Today the version browser queryies only the changes > file. I think it would make sense to do it by epicea files (for local > modifications) and then fallback to a git repository (if any) to give a full > history. Technically, it should not be difficult to do, except for the detail > that the repository was transformed at some point from filetree to tonel, so > blame will not quite work out of the box :).
yes. We explored this and there is a “log” functionality already in iceberg, that works for filetree. I’m working on make it work for tonel. As I said we made the experiment, but then after analysis we realise that is very slow and even if we could cache. etc. , we also realised that we do not need to reproduce the same behaviour to have the desired result. So, we are going to change the way author/timestamp work: you will see you in-image versions as now, but then if you want to see everything of a method you will have a button in versions browser that will fill ALL method history, taken from the git repository. This full history will provide correct authorship and an extra, very valuable bonus: you will see the method history from the moment he is born (you can’t have this with plain monticello today) cheers, Esteban > > > git/github is not the reason that there are "1000's of files on disk". Tonel > uses a file per class format which significanly reduces the file count for > Smalltalk repositories on disk. FileTree format uses a file per method format > and for large projects leads to a large number of files, which in and of > itself is not a problem (at least for git), but does lead to excessive disk > space consumption. > > SmalltalkCI[2], which provides support for Smalltalk on travis-ci[3] and > appveyory[4] was created by Fabio Niephaus an active member of the Squeak > community. Travis-ci makes it possible to run cross-dialect tests to validate > github pull requests and checkins[5] for cross-dialect projects. > > It seems that there are at least some (less vocal) members of the Squeak > community who are interested in using git. > > Dale > > [1] https://www.git-scm.com/docs/git-blame > <https://www.git-scm.com/docs/git-blame> > [2] https://github.com/hpi-swa/smalltalkCI > <https://github.com/hpi-swa/smalltalkCI> > [3] https://travis-ci.org/ <https://travis-ci.org/> > [4] https://www.appveyor.com/ <https://www.appveyor.com/> > [5] https://travis-ci.org/Metacello/metacello > <https://travis-ci.org/Metacello/metacello> > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13
