Blame support P7
Locked
12
12
 
|
Not having timestamps/authors in Pharo 7 due to git and missing blame support
(see [1]) has other bad side effects: - it clobbers all method stamps in an MCZ package [1] if you use Monticello which can lead easily to trouble/lamenting - it is not possible to fileout a changeset [2] in the ChangeSorter Was there any further discussion/decision for P7 on solving this or adding blame support? Thx T. [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html [3] https://pharo.fogbugz.com/f/cases/20951/ |
|
|
Hi torsten
we have a super long list of *important* fixes and enhancements to do. Stef On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <[hidden email]> wrote: > Not having timestamps/authors in Pharo 7 due to git and missing blame support > (see [1]) has other bad side effects: > > > - it clobbers all method stamps in an MCZ package [1] if you use Monticello > which can lead easily to trouble/lamenting > > - it is not possible to fileout a changeset [2] in the ChangeSorter > > Was there any further discussion/decision for P7 on solving this > or adding blame support? > > Thx > T. > > > [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html > [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html > [3] https://pharo.fogbugz.com/f/cases/20951/ > |
|
|
Don‘t you think having Author and timestamps is important?
> Am 12.01.2018 um 10:26 schrieb Stephane Ducasse <[hidden email]>: > > Hi torsten > > we have a super long list of *important* fixes and enhancements to do. > > Stef > >> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <[hidden email]> wrote: >> Not having timestamps/authors in Pharo 7 due to git and missing blame support >> (see [1]) has other bad side effects: >> >> >> - it clobbers all method stamps in an MCZ package [1] if you use Monticello >> which can lead easily to trouble/lamenting >> >> - it is not possible to fileout a changeset [2] in the ChangeSorter >> >> Was there any further discussion/decision for P7 on solving this >> or adding blame support? >> >> Thx >> T. >> >> >> [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html >> [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html >> [3] https://pharo.fogbugz.com/f/cases/20951/ >> |
|
|
2018-01-12 21:23 GMT+01:00 Norbert Hartl <[hidden email]>: Don‘t you think having Author and timestamps is important? Glad to see Pharo Community waking up :) I felt a bit alone since I complained about that in last November ('about SortFunctions' thread)
|
|
|
I don‘t think it slept. There are just too much important things to do. So a temporary sacrifice is sometimes necesssary.
|
|
|
In reply to this post by Nicolas Cellier
On 13 January 2018 at 04:50, Nicolas Cellier <[hidden email]> wrote:
I've recently started using Pharo 7 and found it disconcerting when troubleshooting not knowing how old a method is or have any hint who might be familiar with it. IIUC the loss of author/timestamps is a consequence of merge conflicts in version information. I don't have a good grasp of the background on this though. I can't remember seeing a reproducible use case presented to the community to solve. Probably I was too busy and missed the discussion. Could someone link to a past steps to reproduce? Or now we have new Tonel files, how we can reintroduce version info code into a branch so we can experiment with solutions? I had a vague idea where version-info was kept in a separate file to the Tonel file. Each time the Tonel file is updated, its associated version-info is written to a *new* file. The hash of the Tonel file would form part of the version-info filename so you can always find the version-info file for a given Tonel file if they become separated. This might avoid version conflicts since whole version-info files are never modified, only deleted and added. cheers -ben
|
|
|
In reply to this post by Stephane Ducasse-3
Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <[hidden email]> wrote: Hi torsten Isn't it important to preserve the ability to exchange code between Pharo, Squeak and Cuis? Don't you care that the VM development is directly affected by this? Is the VM and plugin support not important to Pharo?
_,,,^..^,,,_ best, Eliot |
|
|
Eliot Miranda <[hidden email]>
wrote: > Isn't it important to preserve the ability to exchange code between Pharo, > Squeak and Cuis? Don't you care that the VM development is directly > affected by this? Is the VM and plugin support not important to Pharo? Git support turns out to be much more work than we hoped and expected. Too many library updates needed, support for different workflows and platforms, switch to file per class. The Iceberg channel on Discord is one of the busiest channels. Stephan |
|
|
In reply to this post by Eliot Miranda-2
Sure it is important. If you would ask if anyone considers this as not important you’ll have a hard time finding many. That is not the point. If everyone stays in its own personal context and judges from there it is obvious that most decisions outside look non-sense from there. This community is about collaboration. And collaboration does not mean that everyone understands everyone else’s decision. It means that if you don’t understand a decision from someone you still be able to believe he has good reason to do so. my 2 cents, Norbert
|
|
|
|
|
|
In reply to this post by Stephan Eggermont-3
Hi Stephan,
> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <[hidden email]> wrote: > > Eliot Miranda <[hidden email]> > wrote: >> Isn't it important to preserve the ability to exchange code > between Pharo, >> Squeak and Cuis? Don't you care that the VM development is directly >> affected by this? Is the VM and plugin support not important to Pharo? > > Git support turns out to be much more work than we hoped and expected. Too > many library updates needed, support for different workflows and platforms, > switch to file per class. The Iceberg channel on Discord is one of the > busiest channels. You don't say? One of Clément's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk. We are hugely productive in the vm simulator. People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control? This is a huge blunder. Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities. Iceberg is well named. People rearranged the chairs on deck while the Titanic sank. > > Stephan _,,,^..^,,,_ (phone) |
|
|
In reply to this post by Stephan Eggermont-3
|
|
|
In reply to this post by Eliot Miranda-2
Am 13.01.18 um 12:39 schrieb Eliot Miranda:
> Hi Stephan, > > >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <[hidden email]> wrote: >> >> Eliot Miranda <[hidden email]> >> wrote: >>> Isn't it important to preserve the ability to exchange code >> between Pharo, >>> Squeak and Cuis? Don't you care that the VM development is directly >>> affected by this? Is the VM and plugin support not important to Pharo? >> Git support turns out to be much more work than we hoped and expected. Too >> many library updates needed, support for different workflows and platforms, >> switch to file per class. The Iceberg channel on Discord is one of the >> busiest channels. > You don't say? One of Clément's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk. We are hugely productive in the vm simulator. People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. > > Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control? This is a huge blunder. Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities. Iceberg is well named. People rearranged the chairs on deck while the Titanic sank. |
|
|
In reply to this post by Eliot Miranda-2
Can we agree that a class/method/… stops being smalltalk after it has been serialized to text? If you can agree to this I don’t know what you are talking about. We exchange the to-text-serializer monticello-backend with git-backend. The rest (the important part) stays nearly the same. The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative? There are even a lot of people that don’t like git (including me). But I like the collaboration model because that can do what no smalltalk tool can do to my knowledge. Or to turn your argument around. You are a small vm team and you have to be small because I doubt with the current collaboration model you are able to grow. Norbert
|
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda <[hidden email]>
wrote: > Hi Stephan, > Then why on /earth/ would one stop using Smalltalk in /the most central > part/ of the collaborative programming process, version control? Because of the underestimation of the work needed, vs. the advantage of eliminating one barrier to entry. One of the differences in perspective is that Stef sees lots of people new to smalltalk (students) and needs them to get up to speed really fast. The collaboration needs there are different from yours, where you need to deal with long-term collaboration mostly between experts. There is also a significant underestimation of the complexity of version control, and the need to support different workflows. The community members having experience managing complex workflows don't manage to explain well enough what they need. Stephan |
Re: Blame support P7
|
|
In reply to this post by NorbertHartl
> So what would be the alternative? A centralized server (e.g. Cincom Public Repository, SqueakSource, SmalltalkHub, SqueakSource 3). After that, all you need is a detailed project/package/framework description. Google will index it. The whole "GitHub adventure" was started on the premise that it would give Pharo more visibility. I don't see how it differs from SqueakSource from a visibility standpoint unless you specifically search for code only on GitHub. Most people just google anyway! Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers. I was recently told "I just gave up on Smalltalk when I saw 200+ files"... It was too late. I told the poor guy it was just the way code was *stored* on GitHub but in your dev environment, everything resides in the image... Too late : I had lost him solely based on the impression that he was entering into a code management nightmare worse than a thousand C header files! In the current state of things, the whole Cuis/Pharo/Squeak world is a mess. Newcomers looking for code end up having to pick between a myriad of links to SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz files, fileOuts, etc. Ever tried to do some database stuff with Squeak or Pharo? Just try to pick a package that works! You'll find plenty of code on all platforms (SqueakSource, SqueakMap, SS3, GitHub), many ports from one to the other and, in the end, you'll have tried to load 8 packages without success... Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak (and/or others such as VW, VAST, Dolphin) and share a common import/export format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and would probably do a decent job) and have the capability to store *other files* as well (such as config files, source code in other languages, SQL scripts, etc). Something with the functionalities/capabilities of Store (VW code management) with code store in a portable format. My 2 cents. ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) From: Norbert Hartl <[hidden email]> To: Pharo Dev <[hidden email]> Sent: Saturday, January 13, 2018 7:13 AM Subject: Re: [Pharo-dev] Blame support P7 Can we agree that a class/method/… stops being smalltalk after it has been serialized to text? If you can agree to this I don’t know what you are talking about. We exchange the to-text-serializer monticello-backend with git-backend. The rest (the important part) stays nearly the same. The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative? There are even a lot of people that don’t like git (including me). But I like the collaboration model because that can do what no smalltalk tool can do to my knowledge. Or to turn your argument around. You are a small vm team and you have to be small because I doubt with the current collaboration model you are able to grow. Norbert
|
|
|
In reply to this post by Eliot Miranda-2
Hi eliot
Why do you attack me personally on this? I paid with my team money the salary of clement to work with you and I never said a word on the direction. So I would appreciate that you respect me. Thanks in advance for your understanding. Personally I would like to have a Pharo VM that does not crash when I type because of keybinding and freetype. And many more usability concerns. I will not reply to this thread anymore because I do not like to be insulted. Stef On Sat, Jan 13, 2018 at 5:22 AM, Eliot Miranda <[hidden email]> wrote: > Hi Stephane, > > On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <[hidden email]> > wrote: >> >> Hi torsten >> >> we have a super long list of *important* fixes and enhancements to do. > > > Isn't it important to preserve the ability to exchange code between Pharo, > Squeak and Cuis? Don't you care that the VM development is directly > affected by this? Is the VM and plugin support not important to Pharo? > >> >> >> Stef >> >> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <[hidden email]> wrote: >> > Not having timestamps/authors in Pharo 7 due to git and missing blame >> > support >> > (see [1]) has other bad side effects: >> > >> > >> > - it clobbers all method stamps in an MCZ package [1] if you use >> > Monticello >> > which can lead easily to trouble/lamenting >> > >> > - it is not possible to fileout a changeset [2] in the ChangeSorter >> > >> > Was there any further discussion/decision for P7 on solving this >> > or adding blame support? >> > >> > Thx >> > T. >> > >> > >> > [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html >> > [2] >> > http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html >> > [3] https://pharo.fogbugz.com/f/cases/20951/ >> > >> > > > > -- > _,,,^..^,,,_ > best, Eliot |
Re: Blame support P7
|
|
In reply to this post by Eliot Miranda-2
>Then why on /earth/ would one stop using Smalltalk in /the most central
part/ of the collaborative programming >process, version control? This
is a huge blunder. +1000 ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
|
|
In reply to this post by Eliot Miranda-2
>
> > > Am 13.01.2018 um 05:22 schrieb Eliot Miranda <[hidden email]>: > > Hi Stephane, > > On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <[hidden email]> > wrote: >> >> Hi torsten >> >> we have a super long list of *important* fixes and enhancements to do. > > > Isn't it important to preserve the ability to exchange code between Pharo, > Squeak and Cuis? Don't you care that the VM development is directly > affected by this? Is the VM and plugin support not important to Pharo? > > > Sure it is important. If you would ask if anyone considers this as not > important you’ll have a hard time finding many. That is not the point. If > everyone stays in its own personal context and judges from there it is > obvious that most decisions outside look non-sense from there. > This community is about collaboration. And collaboration does not mean that > everyone understands everyone else’s decision. It means that if you don’t > understand a decision from someone you still be able to believe he has good > reason to do so. > > > If the community is about collaboration then one prioritizes that which > promotes collaboration and fixing that which hinders it. Good that you mention that. Now I will not reply more because you will not really be able to understand my concerns about the way the VM is managed in a so community friendly way. About git support some companies told us that GIT support is KEY for them and it will be Key for the expansion of Pharo. Stef |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
I think that some people are talking without really understanding. Let
me shed some light - Iceberg uses the Monticello meta model to compute models and store information in Git (files). - Now Monticello just stores the information in zip files. - In addition Pharo itself is doing the diff model and does not let git doing the diff between models. So I do not understand why Iceberg is less Smalltalk centric than Envy or Store (BTW about store I would have a lot to say about the industrial strength of the product - one db expert look at the model and he was realllllllly surprised.). - Now what Git gives us is that we can manage C, Pharo, PNG, css, .... the same way. In addition you may not like git (I do not like git personally but I really love the model) and we need to have a real decentralized source versioning control system. We are not afraid by sharing :) and collaborating. The world is using Git and we are too. The situation will improve and it will continue to improve. Now it looks like the great smalltalk community does not like when people get some traction. I cannot do much for them. Do not participate, complain and tell us that we are plain idiots and that this is our fault. Now nobody force anyone to use Pharo. We will continue and I'm confident that we will have success. Stef On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev <[hidden email]> > Subject: Re: [Pharo-dev] Blame support P7 >>Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming >process, version control? This is a huge blunder. > > +1000 > > ----------------- > Benoît St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |