Moving to GIT?
Locked
12
12
 
|
> On Apr 7, 2015, at 14:54, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > > I try to evade git as hell. Yep, I'm in a minority, Just to say that I am happily part of the same minority. :-) Git is a huge and powerful weapon of war, but we are not always fighting wars, many times we are involved in a small neighborhood dispute that can be solved with much less violence ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
Hi Thierry,
Thanks for your comments. For me at this moment, Monticello is simple and nicely integrated, but maybe if I dig deeper I would discover the same as you. Surely, at that moment, I can take a look at GitFileTree and try to create something like FossilFileTree. For the moment my combination is Monticello for Pharo source code control and Fossil for source file control. Its working fine. What I'm advocating is to not convert git in a forced prerequisite for source control on Roasal or pharo. Cheers, Offray El 07/04/15 a las 13:58, Thierry Goubier escribió: > Hi Offray, > > more debate about which DVCS to use! Cool. Needed. In particular, we > need a Slice-based workflow. Suggestions welcomed :) > > First counter argument: the simplicity of Monticello. > > Yes, me too, when I started with Pharo, I was attracted by the > simplicity and the fact it is nicely integrated... I integrated > GitFileTree inside Monticello / Metacello / Gofer to keep that. > > But, then I discovered how Monticello does certain things. Then I > discovered how Monticello was written. Then I discovered how people are > using it. > > Now I know that when Monticello works correctly, this is by accident or > because we use it for very simple projects (*). It has so many ways of > getting basic operations wrongly :(. It doesn't scale well to the size > of Pharo, for sure. And it has an impact on how you maintain multiple > targets for a Pharo project, adding complexity inside the code to cope > with Monticello tooling deficiencies. > > Second counter argument: do we have the choice of DVCS? > > Yes, if we have the hosting linked with it. No, if we consider workplace > requirements. In short, my workplace has SVN and git. Given that, I take > git. > > Mind you, I'll have a look at Fossil too. > > Thierry > > Le 07/04/2015 20:12, Offray Vladimir Luna Cárdenas a écrit : >> And talking about workflows compare the "cheat sheet" of Git[1] versus >> the workflow of Fossil[2]. >> >> [1] http://www.ubuntu-mobile.net/wp-content/uploads/2013/06/79302966.png >> [2] http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow >> >> Cheers, >> >> Offray >> >> El 07/04/15 a las 12:54, Offray Vladimir Luna Cárdenas escribió: >>> Hi, >>> >>> Please don't move source code to git, only bug tracker (or even try >>> Bitbucket before or something else). >>> >>> I try to evade git as hell. Yep, I'm in a minority, but after trying >>> git, svn, arch, bazaar, mercurial, trac and fossil I will keep the last >>> one only (kind of a "GiHub in a box" on only 1.5 Mb self-contained >>> simple to use and install binary). For the curious about Fossil at [1] >>> you can find the workflow and at [2] some (biased) quotes about it >>> versus git :-) (of course you could find this biased versus thing all >>> the time for anything, but at least is a call to have a panoramic view >>> before any choosing of a tool). >>> >>> [1] >>> http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow >>> [2] http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki >>> >>> One of the main reason that made git so popular was undoubtedly the >>> Linux kernel community, but I don't understand why a tool that is suited >>> for a thousand developers community and project should be forced into >>> every development project and community. Its like a bazooka for killing >>> mosquitoes with gratuitous complexity most of the times. >>> >>> I really like the integration, fine grained control and smoothness of >>> Monticello in Pharo/Smalltalk for working with objects, not files. The >>> only thing I'm missing is named and visual branches. But having a tool >>> that has a cumbersome work flow, is difficult to install and all the >>> time gets in your way is precisely the opposite of Monticello or any >>> improvement we should be looking for on what we have now. Monticello (or >>> fossil for that matter) is newbie friendly, Git is not. >>> >>> Please, only migrate to file based control system when it has the same >>> smoothness of Monticello and hopefully with Git as an option, not >>> before. >>> >>> >>> Thanks, >>> >>> Offray >>> >>> El 07/04/15 a las 10:44, stephan escribió: >>>> >>>> >>>> On 07-04-15 16:53, Alexandre Bergel wrote: >>>>> We will soon have to change our bug trackers. >>>>> What about taking this opportunity and moving to GIT? >>>> >>>> I very much like using git and github for doing small commits to >>>> text repositories like PFTE. I would love to have a nicely >>>> integrated workflow for source code too. The work by (a.o) >>>> Thierry makes me confident that we'll be able to achieve that >>>> in the not too far future. At the moment however, we are not even >>>> able to reliably find the git executable on all platforms. >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
There is two separate topics here:
- move the issues trackers to github. Quite easy at the moment. - move the code repository to github. A little more tricky. On Tue, Apr 7, 2015 at 4:53 PM, Alexandre Bergel <[hidden email]> wrote: > Hi! > > We will soon have to change our bug trackers. > What about taking this opportunity and moving to GIT? > > Some people have already cloned Roassal on github: > https://github.com/search?utf8=✓&q=Roassal > We cannot ignore this… > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Offray
I perfectly understand your position. I am also relatively satisfied with Monticello. My real underlying question is: are we not missing something big by delaying our adoption of Git? The World is moving toward, and apparently we are just (poorly) copying some of the things github has.
Consider Roassal. We were all happy with Mondrian, and then with Roassal1. No user came saying we need something new. At the end, producing Roassal2 was a painful but very positive move. Coming back to Smalltalkhub/github: Nobody is really complaining about Monticello/Metacello. But would it not be a progress if we switch to a git solution? Sure, it will be painful at the beginning. But would it not be better in the long term? Metacello came along with a rather complex versioning mechanism. But Git offer this. There is also an effort to produce application catalog. Would it be not easier to do this catalog if we were all using github? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 7, 2015, at 5:00 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > > Hi Thierry, > > Thanks for your comments. For me at this moment, Monticello is simple and nicely integrated, but maybe if I dig deeper I would discover the same as you. Surely, at that moment, I can take a look at GitFileTree and try to create something like FossilFileTree. For the moment my combination is Monticello for Pharo source code control and Fossil for source file control. Its working fine. What I'm advocating is to not convert git in a forced prerequisite for source control on Roasal or pharo. > > Cheers, > > Offray > > El 07/04/15 a las 13:58, Thierry Goubier escribió: >> Hi Offray, >> >> more debate about which DVCS to use! Cool. Needed. In particular, we >> need a Slice-based workflow. Suggestions welcomed :) >> >> First counter argument: the simplicity of Monticello. >> >> Yes, me too, when I started with Pharo, I was attracted by the >> simplicity and the fact it is nicely integrated... I integrated >> GitFileTree inside Monticello / Metacello / Gofer to keep that. >> >> But, then I discovered how Monticello does certain things. Then I >> discovered how Monticello was written. Then I discovered how people are >> using it. >> >> Now I know that when Monticello works correctly, this is by accident or >> because we use it for very simple projects (*). It has so many ways of >> getting basic operations wrongly :(. It doesn't scale well to the size >> of Pharo, for sure. And it has an impact on how you maintain multiple >> targets for a Pharo project, adding complexity inside the code to cope >> with Monticello tooling deficiencies. >> >> Second counter argument: do we have the choice of DVCS? >> >> Yes, if we have the hosting linked with it. No, if we consider workplace >> requirements. In short, my workplace has SVN and git. Given that, I take >> git. >> >> Mind you, I'll have a look at Fossil too. >> >> Thierry >> >> Le 07/04/2015 20:12, Offray Vladimir Luna Cárdenas a écrit : >>> And talking about workflows compare the "cheat sheet" of Git[1] versus >>> the workflow of Fossil[2]. >>> >>> [1] http://www.ubuntu-mobile.net/wp-content/uploads/2013/06/79302966.png >>> [2] http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow >>> >>> Cheers, >>> >>> Offray >>> >>> El 07/04/15 a las 12:54, Offray Vladimir Luna Cárdenas escribió: >>>> Hi, >>>> >>>> Please don't move source code to git, only bug tracker (or even try >>>> Bitbucket before or something else). >>>> >>>> I try to evade git as hell. Yep, I'm in a minority, but after trying >>>> git, svn, arch, bazaar, mercurial, trac and fossil I will keep the last >>>> one only (kind of a "GiHub in a box" on only 1.5 Mb self-contained >>>> simple to use and install binary). For the curious about Fossil at [1] >>>> you can find the workflow and at [2] some (biased) quotes about it >>>> versus git :-) (of course you could find this biased versus thing all >>>> the time for anything, but at least is a call to have a panoramic view >>>> before any choosing of a tool). >>>> >>>> [1] >>>> http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow >>>> [2] http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki >>>> >>>> One of the main reason that made git so popular was undoubtedly the >>>> Linux kernel community, but I don't understand why a tool that is suited >>>> for a thousand developers community and project should be forced into >>>> every development project and community. Its like a bazooka for killing >>>> mosquitoes with gratuitous complexity most of the times. >>>> >>>> I really like the integration, fine grained control and smoothness of >>>> Monticello in Pharo/Smalltalk for working with objects, not files. The >>>> only thing I'm missing is named and visual branches. But having a tool >>>> that has a cumbersome work flow, is difficult to install and all the >>>> time gets in your way is precisely the opposite of Monticello or any >>>> improvement we should be looking for on what we have now. Monticello (or >>>> fossil for that matter) is newbie friendly, Git is not. >>>> >>>> Please, only migrate to file based control system when it has the same >>>> smoothness of Monticello and hopefully with Git as an option, not >>>> before. >>>> >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>>> El 07/04/15 a las 10:44, stephan escribió: >>>>> >>>>> >>>>> On 07-04-15 16:53, Alexandre Bergel wrote: >>>>>> We will soon have to change our bug trackers. >>>>>> What about taking this opportunity and moving to GIT? >>>>> >>>>> I very much like using git and github for doing small commits to >>>>> text repositories like PFTE. I would love to have a nicely >>>>> integrated workflow for source code too. The work by (a.o) >>>>> Thierry makes me confident that we'll be able to achieve that >>>>> in the not too far future. At the moment however, we are not even >>>>> able to reliably find the git executable on all platforms. >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On 04/07/2015 02:17 PM, Alexandre Bergel wrote: > Metacello came along with a rather complex versioning mechanism. But Git offer this. Agree 100%. With git taking on the lion's share of the load for managing the versioning of multiple packages, The Metacello "configuration" reduces down to a a single baseline method in a BaselineOf .... all that one needs to do is specify the project and package dependencies ... no need to create new version methods and update configurations with new package versions ... The only time one touches a baseline is when a new package is added or project dependency is added ... Dale _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
Complications come from merging properties, that's why you need the MergeDriver of Thierry.
Phil _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
What can be fun, is to actually move to git in order to speed up the development of tools for git :)
Uko
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
Hi,
For me is not so much about Monticello being satisfactory (at this moment it is for me) but is more about not choosing gratuitous complexity of Git, when we I think that we should consider this more carefully. The world moving to Git and GitHub is not a sign of the wisdom of the masses, but quite the contrary. Fortunately, Pharo/Smalltalk has a tradition for not following the masses. Sometimes is too much of a self-contained solipsistic world, but sometimes is sane to have a panoramic view before making any choose. Early decisions are the most costly ones, so if we can choose any DVCS to work with, would be nice to consider extra options besides git. Sadly we don't have the main power for that and surely what will happen will be in the direction of the decisions we can NOT make, but others have done for us, like Thierry said (for example our bosses in the work environments choosing git because... well... everybody else is doing it). If that's the direction the project will take, please make Git as invisible as possible, I wouldn't like to start to think in pulls, pushes, blames, fetchs, patchs, stashs, bisects and all that stuff. Something like choose the repository. Sync local with remote, like in Monticello/Fossil will be ideal, not because is what we have now, but because is something with the same smoothness while can open the door to some advantages of DVCS without the extra complexity of Git. Cheers, Offray El 07/04/15 a las 16:17, Alexandre Bergel escribió: > I perfectly understand your position. I am also relatively satisfied with Monticello. My real underlying question is: are we not missing something big by delaying our adoption of Git? The World is moving toward, and apparently we are just (poorly) copying some of the things github has. > > Consider Roassal. We were all happy with Mondrian, and then with Roassal1. No user came saying we need something new. At the end, producing Roassal2 was a painful but very positive move. > > Coming back to Smalltalkhub/github: Nobody is really complaining about Monticello/Metacello. But would it not be a progress if we switch to a git solution? Sure, it will be painful at the beginning. But would it not be better in the long term? > Metacello came along with a rather complex versioning mechanism. But Git offer this. There is also an effort to produce application catalog. Would it be not easier to do this catalog if we were all using github? > > Cheers, > Alexandre > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
Thierry and Offray ...
I don't have the time to personally dig into Fossil (at the moment), but I am in favor of leveraging the "best SCM for the job" FileTree is an SCM neutral disk format so supporting alternate SCMs is more of a "tools issue" ... Git/Github was targeted initially, because one had to start somewhere... the [GitHub collaboration tools][1] are pretty darn good up on GitHub and that is another of the major appeals for me ... Haven't looked closely at Fossil so I can't comment on the state of their collaboration tools ... With regards to bitbucket ... I added bitbucket:// support to Metacello for doing direct downloads of repositories from a Metacello project references (ala github://), however with bitbucket being picked up by gitlab, it's not quite as easy to implement a gitlab:// ... The github:// feature means that developers can load code from a github-based repository without having to install git first .... a definite advantage in the days (even now) when git/hg/fossil/svn aren't widely installed by pharo/gemstone/squeak users ... Dale [1] https://help.github.com/categories/collaborating/ [2] https://github.com/dalehenrich/metacello-work/issues/287#issuecomment-59815235 On 04/07/2015 12:11 PM, Thierry Goubier wrote: > Hi Offray, > > reading through Fossil... I think one could turn GitFileTree in a > FossilFileTree in a matter of hours, at most days. If you want to work > with Fossil, I would encourage you to explore this way. > > Thierry > > Le 07/04/2015 19:54, Offray Vladimir Luna Cárdenas a écrit : >> Hi, >> >> Please don't move source code to git, only bug tracker (or even try >> Bitbucket before or something else). >> >> I try to evade git as hell. Yep, I'm in a minority, but after trying >> git, svn, arch, bazaar, mercurial, trac and fossil I will keep the last >> one only (kind of a "GiHub in a box" on only 1.5 Mb self-contained >> simple to use and install binary). For the curious about Fossil at [1] >> you can find the workflow and at [2] some (biased) quotes about it >> versus git :-) (of course you could find this biased versus thing all >> the time for anything, but at least is a call to have a panoramic view >> before any choosing of a tool). >> >> [1] >> http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow >> [2] http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki >> >> One of the main reason that made git so popular was undoubtedly the >> Linux kernel community, but I don't understand why a tool that is suited >> for a thousand developers community and project should be forced into >> every development project and community. Its like a bazooka for killing >> mosquitoes with gratuitous complexity most of the times. >> >> I really like the integration, fine grained control and smoothness of >> Monticello in Pharo/Smalltalk for working with objects, not files. The >> only thing I'm missing is named and visual branches. But having a tool >> that has a cumbersome work flow, is difficult to install and all the >> time gets in your way is precisely the opposite of Monticello or any >> improvement we should be looking for on what we have now. Monticello (or >> fossil for that matter) is newbie friendly, Git is not. >> >> Please, only migrate to file based control system when it has the same >> smoothness of Monticello and hopefully with Git as an option, not >> before. >> >> >> Thanks, >> >> Offray >> >> El 07/04/15 a las 10:44, stephan escribió: >>> >>> >>> On 07-04-15 16:53, Alexandre Bergel wrote: >>>> We will soon have to change our bug trackers. >>>> What about taking this opportunity and moving to GIT? >>> >>> I very much like using git and github for doing small commits to >>> text repositories like PFTE. I would love to have a nicely >>> integrated workflow for source code too. The work by (a.o) >>> Thierry makes me confident that we'll be able to achieve that >>> in the not too far future. At the moment however, we are not even >>> able to reliably find the git executable on all platforms. >>> >>> Stephan >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dale Henrichs-3
El 07/04/15 a las 16:33, Dale Henrichs escribió: > > > On 04/07/2015 02:17 PM, Alexandre Bergel wrote: >> Metacello came along with a rather complex versioning mechanism. But >> Git offer this. > > Agree 100%. > > With git taking on the lion's share of the load for managing the > versioning of multiple packages, The Metacello "configuration" reduces > down to a a single baseline method in a BaselineOf .... all that one > needs to do is specify the project and package dependencies ... no need > to create new version methods and update configurations with new package > versions ... Yep, but any DVCS can take care of managing versions of multiple packages. Git is the bazooka for making that. Surely I will not implement the DVCS behind Metacello, but now that is the time for voicing an opinion about that moving, that's mine. (Even would be nice to being able of loading the last version of messages/methods/objects stored in a branch of a DVCS without having to run any git command or even have it installed locally.) Cheers, Offray _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dale Henrichs-3
Hi Dale,
El 07/04/15 a las 16:48, Dale Henrichs escribió: > The > github:// feature means that developers can load code from a > github-based repository without having to install git first .... a > definite advantage in the days (even now) when git/hg/fossil/svn aren't > widely installed by pharo/gemstone/squeak users ... Just what I was proposing in another reply of the same thread. Seems wise for a smooth operation/transition. Cheers, Offray _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Offray
Offray,
Point well taken. I didn't mean to imply that one could not use a BaselineOf with Fossil ... FileTree and BaselineOf should go hand in hand with any disk-based SCM including Fossil ... Dale On 04/07/2015 03:04 PM, Offray Vladimir Luna Cárdenas wrote: > > > El 07/04/15 a las 16:33, Dale Henrichs escribió: >> >> >> On 04/07/2015 02:17 PM, Alexandre Bergel wrote: >>> Metacello came along with a rather complex versioning mechanism. But >>> Git offer this. >> >> Agree 100%. >> >> With git taking on the lion's share of the load for managing the >> versioning of multiple packages, The Metacello "configuration" reduces >> down to a a single baseline method in a BaselineOf .... all that one >> needs to do is specify the project and package dependencies ... no need >> to create new version methods and update configurations with new package >> versions ... > > Yep, but any DVCS can take care of managing versions of multiple > packages. Git is the bazooka for making that. Surely I will not > implement the DVCS behind Metacello, but now that is the time for > voicing an opinion about that moving, that's mine. (Even would be nice > to being able of loading the last version of messages/methods/objects > stored in a branch of a DVCS without having to run any git command or > even have it installed locally.) > > Cheers, > > Offray > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Offray
A big +1 on this !!
> On Apr 7, 2015, at 18:48, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > > Hi, > > For me is not so much about Monticello being satisfactory (at this moment it is for me) but is more about not choosing gratuitous complexity of Git, when we > > I think that we should consider this more carefully. The world moving to Git and GitHub is not a sign of the wisdom of the masses, but quite the contrary. Fortunately, Pharo/Smalltalk has a tradition for not following the masses. Sometimes is too much of a self-contained solipsistic world, but sometimes is sane to have a panoramic view before making any choose. Early decisions are the most costly ones, so if we can choose any DVCS to work with, would be nice to consider extra options besides git. Sadly we don't have the main power for that and surely what will happen will be in the direction of the decisions we can NOT make, but others have done for us, like Thierry said (for example our bosses in the work environments choosing git because... well... everybody else is doing it). > > If that's the direction the project will take, please make Git as invisible as possible, I wouldn't like to start to think in pulls, pushes, blames, fetchs, patchs, stashs, bisects and all that stuff. Something like choose the repository. Sync local with remote, like in Monticello/Fossil will be ideal, not because is what we have now, but because is something with the same smoothness while can open the door to some advantages of DVCS without the extra complexity of Git. > > Cheers, > > Offray > > El 07/04/15 a las 16:17, Alexandre Bergel escribió: >> I perfectly understand your position. I am also relatively satisfied with Monticello. My real underlying question is: are we not missing something big by delaying our adoption of Git? The World is moving toward, and apparently we are just (poorly) copying some of the things github has. >> >> Consider Roassal. We were all happy with Mondrian, and then with Roassal1. No user came saying we need something new. At the end, producing Roassal2 was a painful but very positive move. >> >> Coming back to Smalltalkhub/github: Nobody is really complaining about Monticello/Metacello. But would it not be a progress if we switch to a git solution? Sure, it will be painful at the beginning. But would it not be better in the long term? >> Metacello came along with a rather complex versioning mechanism. But Git offer this. There is also an effort to produce application catalog. Would it be not easier to do this catalog if we were all using github? >> >> Cheers, >> Alexandre >> > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Offray
The world moving to Git and GitHub Why every time I see discussion about why Git is bad I see these two together? Each of them is very different beast, not mentioning that GitHub can be easily replaced for Bitbucket, Gitlab or other in-house solutions and universal-ish trackers (e.g. Redmine). Early decisions are the most costly ones, so if we can choose any DVCS to work with, would be nice to consider extra options besides git. Certainly locking ourselves out of options would be bad idea, but I don't think that is happening. Git gets the most manpower, because most people know it. (for example our bosses in the work environments choosing git because... well... everybody else is doing it). I am curious… if you already use alternative language like Smalltalk, does boss really have a say in choosing VCS? If that's the direction the project will take, please make Git as invisible as possible, I wouldn't like to start to think in pulls, pushes, blames, fetchs, patchs, stashs, bisects and all that stuff. Speaking of blames, does current Monticello / STHub even support such thing? I've struggled it many times when I was trying to figure out when and why certain line appeared in code. I can do that with git trivially. Something like choose the repository. Sync local with remote, like in Monticello/Fossil will be ideal, not because is what we have now, but because is something with the same smoothness while can open the door to some advantages of DVCS without the extra complexity of Git. From what I understood about Fossil syncing, such behavior can be achieved with git hooks, arguably hooks are cheating and messy. There is also an effort to produce application catalog. Would it be not easier to do this catalog if we were all using github? I don't think this would be a good move to rely solely on github. I like that we already have ConfigurationOf/BaselineOf; for projects and I would much rather see more versatile solution - SmalltalkHub, GitHub, Bitbucket, .zip, what have you. Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dale Henrichs-3
On Tue, Apr 7, 2015 at 11:48 PM, Dale Henrichs <[hidden email]> wrote: With regards to bitbucket ... I added bitbucket:// support to Metacello for doing direct downloads of repositories from a Metacello project references Is this really equivalent? Because the download is read-only so even if I have GitFileTree I cannot easily just pick it up and start changing it; and if I wanted to I would have to unload everything a reload it from local repositories with locks (that's what I do anyways... and I have just four repositories; having tens of repositories (Moose?) seems messy; or maybe I'm just using the most painful way available.. Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stephan Eggermont-3
On Tue, Apr 7, 2015 at 5:44 PM, stephan <[hidden email]> wrote:
Finding the executable isn't such issue, that's what environment is for after all (but it should show nicer errors) - or there could be prompt for user if it is not in path. The bigger problem is that on Windows it has reportedly 50%+ crash rate, which is quite mentally draining - and hearing things like "I usually start downloading the repos in five images and in one of them it will not crash" is bit crazy, and I do feel terrible that I forced this solution on others not knowing the state of it on Windows. But this is most likely ProcessWrapper fault (or was it OSWrapper?). Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
Administrator
|
In reply to this post by SergeStinckwich
Whatever you decide, you could mirror the code on GitHub. I've found it pretty simple for my StHub projects on GitHub via GitFileTree.
Cheers,
Sean |
|
|
In reply to this post by Peter Uhnak
On 04/07/2015 03:50 PM, Peter Uhnák
wrote:
Peter this is a good point and why in a post on the pharo list, I mention tools.... In tODE I have a `clone` menu item on my project browser that will clone a github repository to the local disk and then changed the Metacello locks and package repositoryGroups to point at the newly cloned repository ... so tools ARE important and perhaps the tools support in Pharo hasn't quite reached the point where git/github can go "prime time" I think that going to a disk-based SCM for Moose will solve some problems: namely the problem with the shifting sands of the #stable versions ... at least with local clones of the various projects it is possible to achieve a completely stable load environment (no matter how many repos are involved) because things will only change when you are ready to change and even then you can merge in only the work that you want to pick up ... With a disk-based scm, it could be practical to consolidate some projects or even host a number of separate repositories in a single git repository that is always versioned together .. this type of thing might make sense for the wholly owned Moose projects ... with separate directories folks can load bits a pieces but the local clone that they will ensure that allof the pieces are guaranteed to work together .... there are a number of possiblities here ... but still tools support is a critical item ... Dale _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Peter Uhnak
Le 08/04/2015 00:59, Peter Uhnák a écrit :
> On Tue, Apr 7, 2015 at 5:44 PM, stephan <[hidden email] > <mailto:[hidden email]>> wrote: > > At the moment however, we are not even able to reliably find the git > executable on all platforms. > > Finding the executable isn't such issue, that's what environment is for > after all (but it should show nicer errors) - or there could be prompt > for user if it is not in path.ss I'm a taker for issues and even pull requests on that :) Please use http://github.com/dalehenrich/filetree for filing in issues and features request. > The bigger problem is that on Windows it has reportedly 50%+ crash rate, > which is quite mentally draining - and hearing things like "I usually > start downloading the repos in five images and in one of them it will > not crash" is bit crazy, and I do feel terrible that I forced this > solution on others not knowing the state of it on Windows. But this is > most likely ProcessWrapper fault (or was it OSWrapper?). I would dream of seeing an effort to get an OSProcess working as it should on Windows... Would make a lot of stuff easier, not only git support. Git should have its libcgit support at one point, which should help on Windows. Thierry > Peter > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |