[Pharo-dev] Support understanding changes
stephane.ducasse at inria.fr
Fri Nov 8 20:06:42 EST 2013
> Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution.
you do not what to infer refactoring.
> As a side note, git for instance does not track renames:
> Specially the last link is worth reading ;)
>> 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:
> 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.
> 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.
ok for now we hsould have a proto using MCZ and see how it goes.
More information about the Pharo-dev