Le 27/06/2013 10:46, Frank Shearar a écrit :
On 27 June 2013 09:49, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 27/06/2013 10:30, Camillo Bruni a écrit :
On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 27/06/2013 10:14, Camillo Bruni a écrit :
I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need.
yeah but you have the "wrong" hash as the source includes the category :) I prefer storing the methods in subfolders which represent categories, so I keep the methods sources as clean as possible. For instance this way a recategorization is detected as a move by standard git tools. Now that I say, we should do the same for the classes :P.
In this case, how would you query git for all the versions of a method? If it is recategorized, you would not be able to see through the move, no?
if you store the category in the method you won't see a move of course, otherwise yes:
https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe7...
I still have a worry with that, because I don't see how to load a method version previous to the change (except with a lot of code to understand it image side).
When I scan for method versions, I do, given a commitID, get the method + metadata. If the method path is dependent on which commitID I select, it becomes significantly more complex.
Why not just have a directory for the methods, and a single metadata file for categorising methods? We've talked on and off over the years about turning categories into tags (so a method could be in multiple categories), which this would allow. It would _also_ mean that recategorising a method wouldn't touch the file containing the method.
Yes! I want more of that kind of suggestions :) 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