[Pharo-dev] Support understanding changes

Goubier Thierry thierry.goubier at cea.fr
Wed Nov 6 08:28:28 EST 2013



Le 06/11/2013 14:01, Camillo Bruni a écrit :
>
> On 2013-11-06, at 13:38, Goubier Thierry <thierry.goubier at cea.fr> wrote:
>
>>
>>
>> Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
>>> Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but
>>> take into account the actions that have been performed like rename class, split….
>>
>> Yes! I want that too! How do we try EPICEA? Is it already integrated?
>>
>>> Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston)
>>> representing the semantics of the operation that led to the changes) so that tools can take advantage of this information
>>> to present semantical operation instead of plain stupid diff. For example split this method, rename class,….
>>
>> +100
>
> Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames:
> 	https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_renames.3F
> 	http://permalink.gmane.org/gmane.comp.version-control.git/217
> Specially the last link is worth reading ;)

Yes, this seems probable, but we need to try to be sure.

>> My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
>>
>> In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
>>
>> What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
>
> If you attach the information to the commit itself that will be fine: 	
> 	https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
>
> because, as you say, each time metadata ends up in the sources part of the git
> repository we will have merge problems, since you can only properly merge such
> data if you fully understand the semantic meaning.

Hum. Reading git notes say that there is a merge operation involved...

I hope that a git merge can be done without touching at the notes, and 
then it becomes easy to rebuild the EPICEA history from scanning the git 
history and recovering the notes (and as long as we are not using MC 
approach to searching past versions, of course).

I know I can make an equivalent proposal as a directory and files, i.e. 
not hidden in git notes (which makes it non-portable to other version 
control systems / non git).

> Additionally I think, that the transition data should not go into the sources,
> technically they are no sources, but they belong on the commit itself.

I have no such limit :) And I suspect that in some formats (mcz), this 
metadata will have to appear as part of the source.

Thierry
-- 
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95




More information about the Pharo-dev mailing list