September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Max Leske

> On 28 Sep 2015, at 13:57, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? Yes it could. Iâve been thinking about that too. There are some nice properties, e.g. 1 commit <-> one note (where a note can be tree). That way you donât get merge conflicts on changing metadata. However, youâd need to find an equivalent mechanism for each new SCM. Also, using such a mechanism is a bit obscure. But the idea definitely deserves some attention. Cheers, Max > > [1] http://git-scm.com/docs/git-notes > > cheers -ben >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> >> >> >> I have a vague recollection that the problem was a particular file >> >> where data changed each commit and having the idea that this might be >> >> solved by: each commit writing metadata to a different file e.g. >> >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> >> metadata. >> > >> > >> > Hum, I thought that as well, but in fact write the merge driver turned >> > out >> > as far better and simpler. Moreover, all type of data oriented files >> > (ston, json, version) do not merge properly in git. So even Esteban >> > saying >> > he will use STON does not seems to solve the merge issue, unless he is >> > planning something else. I do take in account we will have more metadata >> > in >> > the future, thanks to EPICEA, so we need a way to handle it. >> > >> > Merging is easy, you just need to hook into it. >> > >> > I believed also that we could do the merge ourselves and force git to >> > commit >> > the result, but discovered this was a bad idea. Imagine having to fire >> > Pharo >> > to merge a 250k OCaml project with 2k of st code in it :( >> >> btw, would "notes" [1] be useful for attaching metadata? >> "A typical use of notes is to supplement a commit message without >> changing the commit itself." >> Or is the metadata better inside the commit? > > > I don't know. What happens to notes when you merge? Do you need to fetch > down all the ancestors (some of them without notes, because it was a merge > of whatever external stuff was in the repository, so you need to recurse[2]) > and merge them yourself everytime? What happens if a guy do a by hand edit > of a st file and commits outside of Pharo? Can it work outside git (Fossil, > Mercury, bazaar)? Does it scale to a lot of metadata? > > Thierry > > [2] gitfiletree has that code, and it gives unintuitive, but correct, > results at time. > > >> >> [1] http://git-scm.com/docs/git-notes >> All good questions I don't have answers for. Its something I only came across last week and I'm still understanding its general usage pattern. cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Christophe Demarey

Le 28 sept. 2015 Ã 13:57, Ben Coman a Ã©crit : > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > > [1] http://git-scm.com/docs/git-notes I would not use that to store data useful to Pharo. Packages meta-data should be versioned at the same place that the code itself. Git is the trendy SCM but there are others. I prefer to not rely on a specific feature of a SCM to let door opened to others

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > Le 28/09/2015 04:27, Ben Coman a Ã©crit : > >> > >> > >> I have a vague recollection that the problem was a particular file > >> where data changed each commit and having the idea that this might be > >> solved by: each commit writing metadata to a different file e.g. > >> NNNN.metadata, and Monticello knows to pick up the highest numbered > >> metadata. > > > > > > Hum, I thought that as well, but in fact write the merge driver turned > out > > as far better and simpler. Moreover, all type of data oriented files > > (ston, json, version) do not merge properly in git. So even Esteban > saying > > he will use STON does not seems to solve the merge issue, unless he is > > planning something else. I do take in account we will have more metadata > in > > the future, thanks to EPICEA, so we need a way to handle it. > > > > Merging is easy, you just need to hook into it. > > > > I believed also that we could do the merge ourselves and force git to > commit > > the result, but discovered this was a bad idea. Imagine having to fire > Pharo > > to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > I don't know. What happens to notes when you merge? Do you need to fetch down all the ancestors (some of them without notes, because it was a merge of whatever external stuff was in the repository, so you need to recurse[2]) and merge them yourself everytime? What happens if a guy do a by hand edit of a st file and commits outside of Pharo? Can it work outside git (Fossil, Mercury, bazaar)? Does it scale to a lot of metadata? Thierry [2] gitfiletree has that code, and it gives unintuitive, but correct, results at time. > [1] http://git-scm.com/docs/git-notes > > cheers -ben > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> I have a vague recollection that the problem was a particular file >> where data changed each commit and having the idea that this might be >> solved by: each commit writing metadata to a different file e.g. >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> metadata. > > > Hum, I thought that as well, but in fact write the merge driver turned out > as far better and simpler. Moreover, all type of data oriented files > (ston, json, version) do not merge properly in git. So even Esteban saying > he will use STON does not seems to solve the merge issue, unless he is > planning something else. I do take in account we will have more metadata in > the future, thanks to EPICEA, so we need a way to handle it. > > Merging is easy, you just need to hook into it. > > I believed also that we could do the merge ourselves and force git to commit > the result, but discovered this was a bad idea. Imagine having to fire Pharo > to merge a 250k OCaml project with 2k of st code in it :( btw, would "notes" [1] be useful for attaching metadata? "A typical use of notes is to supplement a commit message without changing the commit itself." Or is the metadata better inside the commit? [1] http://git-scm.com/docs/git-notes cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] [Pharo-users] Changing method icons priorities in nautilus

by Damien Cassou

Peter UhnÃ¡k <i.uhnak(a)gmail.com> writes: > So would it make sense to swap the priority? I agree with you. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Changing method icons priorities in nautilus

by Peter UhnÃ¡k

Hi, is it a good idea to have the test icon have higher priority than overrides (is overriding parent method/the method is overriden by a child) â Because the state of the test is also available from: 1) the test class itself 2) TestRunner (and one of the two I will have open regardless) And often a method affects more than one test so the icon is not representative of the state anyway. On the other hand if I want to reach the overriden method it's much harder because I have to open new browser, click on the class, find the method. So would it make sense to swap the priority? There's long standing issue in the tracker with having multiple icons per method, but resolving that from UI perspective is perhaps not as easy... (The remaining priorities seem ok... higher number = more important) â Peter

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Stephan Eggermont

On 28-09-15 04:27, Ben Coman wrote: > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. There is no such thing as one workflow. That is to say, the one workflow is simply very complicated, as different people need to solve different problems with design data management. The problems of the core pharo team are not those of the community. To do this well it would be good to work with personas, like in http://gsoc2013.esug.org/projects/distributed-issue-tracker Adoption will come only when a sufficiently large, consistent and complete part of the stakeholders needs is covered. Personas are also very useful to drive the documentation. Stephan

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Alexandre Bergel

Video are good. But please, do not show trivial things. Show us an example with several users and conflict resolution. Alexandre > On Sep 28, 2015, at 10:59 AM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > philippe.back(a)highoctane.be <philippe.back(a)gmail.com> writes: > >> It isn't. It is actually very easy to use git. >> >> Time for a video :-) >> >> Expect that for tomorrow. > > tomorrow is today :-). We expect it! > > Thanks Philippe > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Damien Cassou

philippe.back(a)highoctane.be <philippe.back(a)gmail.com> writes: > It isn't. It is actually very easy to use git. > > Time for a video :-) > > Expect that for tomorrow. tomorrow is today :-). We expect it! Thanks Philippe -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015