December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Le 02/12/2014 20:59, Dale Henrichs a Ã©crit : > > > On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > If you need to update (changes on the central repository), then you > pull (git pull) and you see the new available versions (only with > gitfiletree). FileTree will only show you the top version of each > package. > > > This is an area where I prefer to use `git diff` and enter the territory > of "git integration"... it is possible to use git to compare two > different SHA's for a given package/project/class/method and it is > possible to compare the in-image package/project/class/method with a > particular. But both approaches are allowing you that. What GitFileTree shows you is the git commit history, filtered by packages... and you can diff, as well, whether its by package/project/class/method, or simply explore the history from the point of view of the entity your focusing on (well, ok, no project...). > In my opinion, this is the area where one should break from the > Monticello paradigm where the package is the sole versioned entity and > expand the versioned universe to include project/package/class/method > versions. There is also tremendous value to simply comparing two > different git commits which may span multiple packages and include > updates to documentation and other text files ... Yes, the project on top. I think this is something Phil has been saying as well, and I'm sure this is something which will be added, once Pharo will focus on that. But I'll check first if some projects (I'm thinking say a compiler of which pharo is just the front-end, i.e. over 100 000lines of which 90% is C code) won't end up being too large. Nothing we can't solve with appropriate tools. > To view git through only the package model is too restrictive and limits > some of the real power one can experience when using git ... This was the limitation of working within Monticello. Now that the infrastructure is there, we can (we should) do better. Thierry

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Dale Henrichs

On Tue, Dec 2, 2014 at 11:58 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 02 Dec 2014, at 20:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Yes, but my main point is what when I merge, I donât care about monticello > dataâ¦ I already have a git version, why do I have to care about the > ancestor of monticello version that became different because of > cherrypicking. > > > And this is what we need to fix. We do not need this duplications, and > also it makes a lot more difficult to work in several branchs, etc. > > Use Thierry's merge tool and then ignore the monticello meta data ... I am always doing complex merges of all kinds and Thierry's tool takes care of keeping the monticello data consistent while I can manually deal with the "real conflicts". Until every project on SmalltalkHub has been converted to git, you will need the monticello meta data ... this is something that will not happen overnight ... Dale

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by kilon alios

I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest. What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language. Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Dale Henrichs

On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > If you need to update (changes on the central repository), then you pull > (git pull) and you see the new available versions (only with gitfiletree). > FileTree will only show you the top version of each package. This is an area where I prefer to use `git diff` and enter the territory of "git integration"... it is possible to use git to compare two different SHA's for a given package/project/class/method and it is possible to compare the in-image package/project/class/method with a particular. In my opinion, this is the area where one should break from the Monticello paradigm where the package is the sole versioned entity and expand the versioned universe to include project/package/class/method versions. There is also tremendous value to simply comparing two different git commits which may span multiple packages and include updates to documentation and other text files ... To view git through only the package model is too restrictive and limits some of the real power one can experience when using git ... Dale

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Esteban Lorenzano

> On 02 Dec 2014, at 20:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : >>> Hi Luc, >>> >>> most of these problems are solved by gitfiletree by Goubier Thierry. >>> It automatically commits the thing that you commit with Monticello, >>> it allows you to push, and it shows you the history (sometimes a bit >>> screwed, but good enough). ConfigurationOf works with GitHub >>> projects, but I think there is also something in a new Metacello that >>> I donât know about. >> >> If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually). >> >>> Big con is that you essentially communicate with git through >>> Monticello. And to doing advanced stuff, like a lot of branching, >>> pull requests and so on, gives an impression that you are always >>> hacking something. >> >> I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it. > > My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it backâ¦ But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo. > >> >>> If you want to really work with git, you want to be able to have only >>> git versions of your code, stage and commit certain changes, >>> communicate with remote repos, and if something goes wrong talk to >>> command line and deal with file-based pharo representation. But >>> instead of this you have one more screen of Monticello + nasty >>> metadata which complicates merging. >> >> You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it. > > Yes, but my main point is what when I merge, I donât care about monticello dataâ¦ I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking. And this is what we need to fix. We do not need this duplications, and also it makes a lot more difficult to work in several branchs, etc. Esteban > > > Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones. > > Uko > >> >> Thierry >> >>> Uko >>> >>>> On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)gmail.com> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I continue the discussion here because I really would like to know >>>> the cons of using Git + Pharo. From kilon's video (thx) and the >>>> discussion that followed, I have the following questions about >>>> possible drawbacks of Git+Pharo: >>>> >>>> - The most important point to me is: does ConfigurationOf work >>>> correctly with a repo on GitHub for example? any example >>>> somewhere? >>>> >>>> - we should go to command line to commit/update but that could be >>>> saved with what has been done by Dale in tODE (shell integration, >>>> UI to commit, push/pull) IIUC. right? >>>> >>>> - Merging could be harder because it would rely on git tools? >>>> >>>> - opening a filetree repo in MC does not show the latest content >>>> since it is the local git repo that may not be in sync with the >>>> remote one => you should first pull the repo >>>> >>>> Thx for enlightening me, >>>> >>>> #Luc

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Le 02/12/2014 20:41, Yuriy Tymchuk a Ã©crit : > >> On 02 Dec 2014, at 19:03, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : >>> Hi Luc, >>> >>> most of these problems are solved by gitfiletree by Goubier >>> Thierry. It automatically commits the thing that you commit with >>> Monticello, it allows you to push, and it shows you the history >>> (sometimes a bit screwed, but good enough). ConfigurationOf works >>> with GitHub projects, but I think there is also something in a >>> new Metacello that I donât know about. >> >> If you find a strange history, can you share? It seems it happens, >> but I'm never sure. It handles fairly complicated cases (like the >> FileTree repository where, in some commits, you can't load the >> packages with filetree because they are broken: merge conflicts >> usually). >> >>> Big con is that you essentially communicate with git through >>> Monticello. And to doing advanced stuff, like a lot of >>> branching, pull requests and so on, gives an impression that you >>> are always hacking something. >> >> I think this is the git philosophy anyway. You need to go on >> expensive, entreprise versionning systems (ClearCase?) to have a >> very powerfull, yet still handholding system. Git is a hacker's >> tool. And git users are supposed (encouraged?) to hack it. > > My problem is not in git, itâs in Monticello. Iâm used to be able to > commit exactly what I want even if Iâve made more changes, Iâm used > to make branches for each new feature and then merge it backâ¦ But I > always have two versioning going on. I do things in git, and then I > do things in monticello. Another problem is a real lack of features. Yes. I can understand that. It's very hard, in truth, to make that integration work. I'm cheating with Monticello in many places, just to reach that goal. > Imagine if you could see a method blame from inside Pharo. That one would be real easy, in fact :) You just have to touch the GUI in Nautilus and add a command to GitFileTree (five or ten lines, no more). AltBrowser has one additional gui(s) which is triggered with gitfiletree support: a method version browser which is just like the normal one, except that it queries git for method versions in addition to the ones kept in the changes. Adding git blame access would be done in the same way. >>> If you want to really work with git, you want to be able to have >>> only git versions of your code, stage and commit certain >>> changes, communicate with remote repos, and if something goes >>> wrong talk to command line and deal with file-based pharo >>> representation. But instead of this you have one more screen of >>> Monticello + nasty metadata which complicates merging. >> >> You need to use the merge driver for that, really. Ok, it requires >> a lot more polish than it has, but this is a larger, Pharo wide >> effort we need to plan for. The GitFileTree-MergeDriver was really >> a proof-of-concept which worked surprisingly well for the time I >> spent on it. > > Yes, but my main point is what when I merge, I donât care about > monticello dataâ¦ I already have a git version, why do I have to care > about the ancestor of monticello version that became different > because of cherrypicking. Hum. You'll need to give me an example because I don't know enough git to understand what you're saying. Do you mean that, if you merge in git, when reloaded in Pharo, it doesn't show you the right history? Or do you say that merging with Monticello doesn't appear correctly in git? > Again, Iâm not complaining. Iâm very glad that we have what we have > now. Itâs just that I donât agree that git support is ready to be > used by everyone. Because with git in general Iâm 10x more efficient > than with git in Pharo. And with git in pharo itâs the same as with > monticello, I just trade one problems for another ones. Well, I guess that in both FileTree and GitFileTree visions, we went into close integration with the existing Monticello, with all the limitations inherent to that approach. Now, the question is how we make a better use of what we have access to. Thierry

Dec. 2, 2014

Re: [Pharo-dev] Duration year

by Maximiliano Taborda

Hi all. The same examples using ChaltÃ©n: February twentyninth, 2012 next: 1 yearMeasure. "=> February 28th, 2013" March first, 2011 next: 1 yearMeasure. "=> March 1st, 2012" March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012" Hilaire, In ChaltÃ©n a year is a year so you don't need to care about of the number of days in it. Regards. Maxi 2014-12-02 16:37 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > GenericYear does this. The generic Year will take > '2/29/2000' asDate + 1 year "=> 28 February 2001" > In other words, we want it at the same time next year; more importantly > the same month and close to what we have now. > Also: > '3/1/2001' asDate - 1 year "=> 1 March 2000" > Still, same month - we want to be at the beginning of the month the > previous year. > > Basically, my idea (and, more importantly, what I expect - hence my code) > is that I want to pretend that we do have a field-based representation and > make it work that way. except better (since there is no 2/29/2001). > > > Ej, which one of the followings is OK? > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > Well, I have a bug here. That needs to be fixed. > > -cbc > > > On Tue, Dec 2, 2014 at 8:34 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Esteban A. Maringolo wrote >> > Ej, which one of the followings is OK? >> > '2012-02-29' asDate + 1 year "=> 2013-02-28" >> > '2011-03-01' asDate + 1 year "=> 2012-02-29" >> >> One solution (just ignore the source ha ha) - >> >> http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Duration-year-tp4791727p4793656.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Le 02/12/2014 20:35, Luc Fabresse a Ã©crit : > > I will digest that amount of info now ;-) > I am still unclear on some parts for example nowadays I load a ConfigOf > and then I open the repositories of the dependencies in MC to check if > there are updates to be merged in. > It seems that it will not be that simple with this new setup. In a baselineOf + github scenario (github, gitfiletree, by hand git clone + filetree), you allways load the latest on the branch or tag, so it's not needed. If you need to update (changes on the central repository), then you pull (git pull) and you see the new available versions (only with gitfiletree). FileTree will only show you the top version of each package. > I will give it a try. Tell us how it goes. We need to know! But I guess I should work on that Git and Pharo chapter ;) Thierry > Thank you all! > > #Luc > > 2014-12-02 18:00 GMT+01:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > > > On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse(a)gmail.com > <mailto:luc.fabresse@gmail.com>> wrote: > > Hi, > > I continue the discussion here because I really would like to > know the cons of using Git + Pharo. > From kilon's video (thx) and the discussion that followed, I > have the following questions about possible drawbacks of Git+Pharo: > > - The most important point to me is: does ConfigurationOf work > correctly with a repo on GitHub for example? any example somewhere? > > > When using git, you do not need to use a ConfigurationOf as all of > the packages are versioned together so it isn't necessary to track > individual mcz package versions ... you only really need a baseline > to specify package/project dependencies. > Instead of a ConfigurationOf you use a BaselineOf which has a single > baseline: method[1]. The baseline: method is like any other > baseline, except it isn't necessary to explicitly specify a repo - > the repo used for the packages is the same one as the BaselineOf was > loaded from. > > To load a baseline from a github repo you use an expression like the > following: > > Metacello new > baseline: 'Cryptography'; > repository: 'github://GsDevKit/Cryptography:master/repository'; > load: #('Cryptography') > > The :master in the repo specification can the name of a branch > (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? > will load tags 1.1.0, 1.1.1, 1.1.2, etc.). > > To load from a local git clone (filetree repo) you use something > like the following: > > Metacello new > baseline: 'Cryptography'; > repository: 'filetree:///opt/git/Cryptography/repository'; > load: #('Cryptography') > > [1] > https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfC… > > > - we should go to command line to commit/update but that could > be saved with what has been done by Dale in tODE (shell > integration, UI to commit, push/pull) IIUC. right? > > > In tODE I've wrapped a large chunk of the shell command line git api > with Smalltalk ... tODE has it's own command line, so git commands > can be run from within tODE on the command line. Other tools make > calls to he Smalltalk api. > > > - Merging could be harder because it would rely on git tools? > > > When merging with git, you may be merging multiple packages plus doc > files, etc., at once, so the tool required for merge must be built > to work with git merge meta data ... there are external merge tools, > but I built a merge tool in tODE that I actually prefer over the > other available merge tools ... > > > - opening a filetree repo in MC does not show the latest content > since it is the local git repo that may not be in sync with the > remote one => you should first pull the repo > > This is actually an advantage ... when you have a local git clone, > you control when and how projects are updated ... how many times > have previously working build procedures suddenly stop working > because someone has made a change to a configuration of a project? > With local clones your environment is static and stable until you > are ready to upgrade to a new version and then you do so in a > controlled manner. > > If you use a spec like > 'github://GsDevKit/Cryptography:master/repository', you are really > using the latest version of master branch (bleeding edge for a > remote repo)...In theory you can "require" that all tests pass > before a change is merged into the master branch (using pull > requests and travis-ci). so using the latest master branch should > always be "safe". > > Dale > >

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Yuriy Tymchuk

> On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : >> Hi Luc, >> >> most of these problems are solved by gitfiletree by Goubier Thierry. >> It automatically commits the thing that you commit with Monticello, >> it allows you to push, and it shows you the history (sometimes a bit >> screwed, but good enough). ConfigurationOf works with GitHub >> projects, but I think there is also something in a new Metacello that >> I donât know about. > > If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually). > >> Big con is that you essentially communicate with git through >> Monticello. And to doing advanced stuff, like a lot of branching, >> pull requests and so on, gives an impression that you are always >> hacking something. > > I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it. My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it backâ¦ But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo. > >> If you want to really work with git, you want to be able to have only >> git versions of your code, stage and commit certain changes, >> communicate with remote repos, and if something goes wrong talk to >> command line and deal with file-based pharo representation. But >> instead of this you have one more screen of Monticello + nasty >> metadata which complicates merging. > > You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it. Yes, but my main point is what when I merge, I donât care about monticello dataâ¦ I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking. Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones. Uko > > Thierry > >> Uko >> >>> On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> I continue the discussion here because I really would like to know >>> the cons of using Git + Pharo. From kilon's video (thx) and the >>> discussion that followed, I have the following questions about >>> possible drawbacks of Git+Pharo: >>> >>> - The most important point to me is: does ConfigurationOf work >>> correctly with a repo on GitHub for example? any example >>> somewhere? >>> >>> - we should go to command line to commit/update but that could be >>> saved with what has been done by Dale in tODE (shell integration, >>> UI to commit, push/pull) IIUC. right? >>> >>> - Merging could be harder because it would rely on git tools? >>> >>> - opening a filetree repo in MC does not show the latest content >>> since it is the local git repo that may not be in sync with the >>> remote one => you should first pull the repo >>> >>> Thx for enlightening me, >>> >>> #Luc >> >> >> > >

Dec. 2, 2014

Re: [Pharo-dev] Duration year

by Chris Cunningham

GenericYear does this. The generic Year will take '2/29/2000' asDate + 1 year "=> 28 February 2001" In other words, we want it at the same time next year; more importantly the same month and close to what we have now. Also: '3/1/2001' asDate - 1 year "=> 1 March 2000" Still, same month - we want to be at the beginning of the month the previous year. Basically, my idea (and, more importantly, what I expect - hence my code) is that I want to pretend that we do have a field-based representation and make it work that way. except better (since there is no 2/29/2001). > Ej, which one of the followings is OK? > '2011-03-01' asDate + 1 year "=> 2012-02-29" Well, I have a bug here. That needs to be fixed. -cbc On Tue, Dec 2, 2014 at 8:34 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban A. Maringolo wrote > > Ej, which one of the followings is OK? > > '2012-02-29' asDate + 1 year "=> 2013-02-28" > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > One solution (just ignore the source ha ha) - > > http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Duration-year-tp4791727p4793656.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 2, 2014