- Pharo-users - lists.pharo.org

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

2015-07-24 13:18 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > > On Fri, Jul 24, 2015 at 1:13 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-07-24 13:04 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> >>> Alex, would you be able to show something with Roassal? It would be >>>> really nice to see the overall git history graph overlaid with the graph of >>>> the history of the selected package. >>>> >>> >>> Interesting that if someone else needs it I have no problem writing >>> Roassal scripts etc, but when I need it I don't even think of using Roassal >>> to actually solve my problems... >>> >> >> :) >> >> >>> >>> Anyway I ran into similar issue I had before, that >>> McFileTreeGitRepository is returning GitFileTreePackageEntry instead of >>> filenames, so this fails. >>> >> >>> ~~~~~~~~~~~~~~~~ >>> mc := MCFileTreeGitRepository allInstances detect: [ :m | m name >>> includesSubstring: 'dynacase/repository' ]. >>> >>> root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc >>> readableFileNames doesn't return file names" >>> ~~~~~~~~~~~~~~~ >>> (The above for SmalltalkHub repos works just fine.) >>> >> >> Yes. I spent a lot of time try to guess what was the repository API used >> by Monticello, and I failed for part of it ;) >> >> With git, I couldn't work with something as primitive as a file name to >> refer to a git commit :) so had to work at a higher level and try to patch >> all the places where Monticello was forcing strings on me. >> > > Ok, so should I work around this because it's unfixable, or is it a bug? > No, it's a bug... But one of a whack-a-mole type :). FileTree (and GitFileTree) have a bunch of tests for internal coverage (reading, writing, etc....) with a complex setup (you need to provide test repositories)... which isn't included in Pharo integration testing by the way. However there are weaknesses in the Gofer to repositories testing (again probably because setting up a test environment with test repositories for Pharo would be complex). Thierry

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 1:24 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-07-24 13:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> I'm not sure how is Pharo 4 related (I do all dev in 5 now). >>> >> >> I should update DynaCASE docs, if that's where you got that impression... >> > > Yes, from the DynaCASE doc, I believed you were in Pharo4 :) > Sorry, I've fixed that now. I moved to Pharo 5 during ESUG and forgot to update it. In fact the original issue emerged after I switched to 5, so in 4 it should be ok. Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

2015-07-24 13:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > I'm not sure how is Pharo 4 related (I do all dev in 5 now). >> > > I should update DynaCASE docs, if that's where you got that impression... > Yes, from the DynaCASE doc, I believed you were in Pharo4 :) Thierry

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> > I'm not sure how is Pharo 4 related (I do all dev in 5 now). > I should update DynaCASE docs, if that's where you got that impression...

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 1:13 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-07-24 13:04 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> >> Alex, would you be able to show something with Roassal? It would be >>> really nice to see the overall git history graph overlaid with the graph of >>> the history of the selected package. >>> >> >> Interesting that if someone else needs it I have no problem writing >> Roassal scripts etc, but when I need it I don't even think of using Roassal >> to actually solve my problems... >> > > :) > > >> >> Anyway I ran into similar issue I had before, that >> McFileTreeGitRepository is returning GitFileTreePackageEntry instead of >> filenames, so this fails. >> > >> ~~~~~~~~~~~~~~~~ >> mc := MCFileTreeGitRepository allInstances detect: [ :m | m name >> includesSubstring: 'dynacase/repository' ]. >> >> root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc >> readableFileNames doesn't return file names" >> ~~~~~~~~~~~~~~~ >> (The above for SmalltalkHub repos works just fine.) >> > > Yes. I spent a lot of time try to guess what was the repository API used > by Monticello, and I failed for part of it ;) > > With git, I couldn't work with something as primitive as a file name to > refer to a git commit :) so had to work at a higher level and try to patch > all the places where Monticello was forcing strings on me. > Ok, so should I work around this because it's unfixable, or is it a bug? > > >> >> This is the previous issue you've already fixed >> http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… >> , it seems related. >> > > Ok. It is present in Pharo 4 as well, then. > I'm not sure how is Pharo 4 related (I do all dev in 5 now). > > Thanks, > > Thierry > >> >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

2015-07-24 13:04 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > Alex, would you be able to show something with Roassal? It would be really >> nice to see the overall git history graph overlaid with the graph of the >> history of the selected package. >> > > Interesting that if someone else needs it I have no problem writing > Roassal scripts etc, but when I need it I don't even think of using Roassal > to actually solve my problems... > :) > > Anyway I ran into similar issue I had before, that McFileTreeGitRepository > is returning GitFileTreePackageEntry instead of filenames, so this fails. > > ~~~~~~~~~~~~~~~~ > mc := MCFileTreeGitRepository allInstances detect: [ :m | m name > includesSubstring: 'dynacase/repository' ]. > > root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc > readableFileNames doesn't return file names" > ~~~~~~~~~~~~~~~ > (The above for SmalltalkHub repos works just fine.) > Yes. I spent a lot of time try to guess what was the repository API used by Monticello, and I failed for part of it ;) With git, I couldn't work with something as primitive as a file name to refer to a git commit :) so had to work at a higher level and try to patch all the places where Monticello was forcing strings on me. > > This is the previous issue you've already fixed > http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… > , it seems related. > Ok. It is present in Pharo 4 as well, then. Thanks, Thierry >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> Alex, would you be able to show something with Roassal? It would be really > nice to see the overall git history graph overlaid with the graph of the > history of the selected package. > Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems... Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails. ~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ]. root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.) This is the previous issue you've already fixed http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-… , it seems related. Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, here is my analysis on DynaCASE-PeterUhnak.147. When going through the history on git, many of the merges do not register as belonging to the DynaCASE package (a git commit belongs to a package when it modify something inside the package directory or modify the version file, I don't remember which indicator I used...). So, to be able to recover all the parents of DynaCASE-PeterUhnak.147, the algorithm (one) has to go through thoses merges transitively until all the branches it has so followed ends with a commit belonging to DynaCASE. Sometimes, drawing this as a graph in the repository inspector would help immensely... Alex, would you be able to show something with Roassal? It would be really nice to see the overall git history graph overlaid with the graph of the history of the selected package. By the way, if you want to explore some of the issues you have to tackle when reading metadata in a git repository, I suggest trying gitg on the dynacase repository... and wait :) Makes Pharo look like a speedy beast :) Thierry 2015-07-24 11:05 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >>> Sorry for the lack of support on windows. You'll have to wait for >>>> libcgit. >>> >>> >>> Is there an estimated timeline when this will be? (weeks, months, years, >>> ...?) >>> >> >> I don't know; the lib has been included in the Pharo vm for a long time, >> and I remember talks about having it for Pharo5. Stef, what is the Pharo >> consortium plans on that? >> > > CCed Stef :) ^^ > > >> >> >>> Yes, this also happens to me, but it is different. >>> Actually this is what I was expecting would happen in the issue >>> described originally... that when I check changes (and it was already >>> committed) that it would just disappear as false positive... but nope, it >>> still claimed it's new and only actual git history have shown that it was a >>> false positive. >>> >>> Anyway, it doesn't seem there will be resolution for this until it can >>> be reproduced consistently... so I'll try be more observant. :) >>> >> >> Well, it may be an issue in the way diffs are built, so it would be good >> to see it confirmed. Thanks for volunteering, by the way :) >> > > As I'm the only one experiencing this apparently, I don't have a choice > but to volunteer. :) >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

> > >> Sorry for the lack of support on windows. You'll have to wait for >>> libcgit. >> >> >> Is there an estimated timeline when this will be? (weeks, months, years, >> ...?) >> > > I don't know; the lib has been included in the Pharo vm for a long time, > and I remember talks about having it for Pharo5. Stef, what is the Pharo > consortium plans on that? > CCed Stef :) ^^ > > >> Yes, this also happens to me, but it is different. >> Actually this is what I was expecting would happen in the issue described >> originally... that when I check changes (and it was already committed) that >> it would just disappear as false positive... but nope, it still claimed >> it's new and only actual git history have shown that it was a false >> positive. >> >> Anyway, it doesn't seem there will be resolution for this until it can be >> reproduced consistently... so I'll try be more observant. :) >> > > Well, it may be an issue in the way diffs are built, so it would be good > to see it confirmed. Thanks for volunteering, by the way :) > As I'm the only one experiencing this apparently, I don't have a choice but to volunteer. :)

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, 2015-07-24 10:47 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Check which versions are bold when you open the package. Because when I >> use gitfiletree it usually shows me that the latest few versions are not >> loaded (they are in bold) but I am anyway on the latest one. > > > As I've said, it shows me that I am on the latest version. > > I'm looking at DynaCASE-PeterUhnak.147, the one with the interesting history... > Maybe this happens to you because you load it from github and only after > you add gitfiletree? (At least from what I remember what you've shown me > (and you are using GitFileTree from MetaRepo30?)) > > Understood. So this means all commits you've done (the -bliznjan) were >> done with filetree? >> > > He suffered through with git on Windows for some time, so maybe the later > half? > Again, sorry for that poor Windows support... GitFileTree is an excellent bench for the robustness of the external process support, and I only barely touch the underlying plugin on Unix-like platform. I'll write for professional reasons another possibility for support on Windows, but it won't be available. > > Sorry for the lack of support on windows. You'll have to wait for >> libcgit. > > > Is there an estimated timeline when this will be? (weeks, months, years, > ...?) > I don't know; the lib has been included in the Pharo vm for a long time, and I remember talks about having it for Pharo5. Stef, what is the Pharo consortium plans on that? > Yes, this also happens to me, but it is different. > Actually this is what I was expecting would happen in the issue described > originally... that when I check changes (and it was already committed) that > it would just disappear as false positive... but nope, it still claimed > it's new and only actual git history have shown that it was a false > positive. > > Anyway, it doesn't seem there will be resolution for this until it can be > reproduced consistently... so I'll try be more observant. :) > Well, it may be an issue in the way diffs are built, so it would be good to see it confirmed. Thanks for volunteering, by the way :) Thierry

July 24, 2015