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=%E2%9C%93&q=Roassal http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
As a sidenote, considering you make quite a heavy use of GoogleCode issue tracker, maybe the Bitbucket one (based on JIRA) would fit you better than the GitHub one.
Peter
On Tue, Apr 7, 2015 at 4:53 PM, Alexandre Bergel alexandre.bergel@me.com 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 http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
what kind of advantages does bitbucket offer over github on issue reporting ?
I am no contributor to Moose myself so I can't offer an informed opinion on this choice. But I love working on github and I think the whole pull request design is just brilliant with also the ability to comment and reply on commits and pull request and even attach issue reports to commits and pull requests.
On Tue, Apr 7, 2015 at 6:05 PM, Peter Uhnák i.uhnak@gmail.com wrote:
As a sidenote, considering you make quite a heavy use of GoogleCode issue tracker, maybe the Bitbucket one (based on JIRA) would fit you better than the GitHub one.
Peter
On Tue, Apr 7, 2015 at 4:53 PM, Alexandre Bergel alexandre.bergel@me.com 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 http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Apr 7, 2015 at 5:11 PM, kilon alios kilon.alios@gmail.com wrote:
what kind of advantages does bitbucket offer over github on issue reporting ?
I am no contributor to Moose myself so I can't offer an informed opinion on this choice. But I love working on github and I think the whole pull request design is just brilliant with also the ability to comment and reply on commits and pull request and even attach issue reports to commits and pull requests.
As far as pull requests go, on top of what GitHub provides, Bitbucket also allows you to specify reviewers and "approve" system.
But about issues - GitHub provides you some labeling system but it has NO structure whatsoever. Bitbucket on the other hand has many features like type (new, resolved, on hold, invalid, ...), priority, status, and even custom attributes, and more. Doing this with GitHub label is extremely heavy-handed.
It also comes down to what kind of management you require. If you are ok with ad-hoc, then GitHub is perfect (since you don't need to deal with all the stuff mentioned above), but when you need proper organization, I cannot imagine doing it with just labels.
So, just sharing my 2¢.
Peter
Yes I agree that Github offers more freedom on how one deals with an issue which can be a disadvantage if you want to force users to form a specific workflow on reporting issues.
On Tue, Apr 7, 2015 at 6:30 PM, Peter Uhnák i.uhnak@gmail.com wrote:
On Tue, Apr 7, 2015 at 5:11 PM, kilon alios kilon.alios@gmail.com wrote:
what kind of advantages does bitbucket offer over github on issue reporting ?
I am no contributor to Moose myself so I can't offer an informed opinion on this choice. But I love working on github and I think the whole pull request design is just brilliant with also the ability to comment and reply on commits and pull request and even attach issue reports to commits and pull requests.
As far as pull requests go, on top of what GitHub provides, Bitbucket also allows you to specify reviewers and "approve" system.
But about issues - GitHub provides you some labeling system but it has NO structure whatsoever. Bitbucket on the other hand has many features like type (new, resolved, on hold, invalid, ...), priority, status, and even custom attributes, and more. Doing this with GitHub label is extremely heavy-handed.
It also comes down to what kind of management you require. If you are ok with ad-hoc, then GitHub is perfect (since you don't need to deal with all the stuff mentioned above), but when you need proper organization, I cannot imagine doing it with just labels.
So, just sharing my 2¢.
Peter
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Could be… It would be nice that we all have a clear position on this
Alexandre
Hi,
You mean instead of SmalltalkHub?
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
Anne Le 7 avr. 2015 à 16:53, Alexandre Bergel alexandre.bergel@me.com a écrit :
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=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
IMHO using git in Pharo is still quite painful.
Uko
On 07 Apr 2015, at 17:08, Anne Etien anne.etien@univ-lille1.fr wrote:
Hi,
You mean instead of SmalltalkHub?
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
Anne Le 7 avr. 2015 à 16:53, Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> a écrit :
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=%E2%9C%93&q=Roassal http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Oh… You have an important experience. Why this? What are the troubles you are facing?
Alexandre
As far as I can see, this is not very complex. Monticello simply has to point to a folder on your local hard disk. You then need to do git push and git pull to update your local copy.
Pretty much the same when we are writing a paper :-)
Alexandre
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
There certainly are big issues like a LOT of crashing on Windows, and it
does feel a bit worse experience compared to native git, but at least for me personally (on linux) I am much happier with it than with SmalltalkHub; doing large-ish merge conflicts is so much more convenient.
But I kind of thought that Moose was fine with their setup (considering they've done great things with it), so I am curious what are their (main) motivations to move to GIT.
Peter
Complications come from merging properties, that's why you need the MergeDriver of Thierry.
Phil
What can be fun, is to actually move to git in order to speed up the development of tools for git :)
Uko
On 07 Apr 2015, at 23:36, phil@highoctane.be wrote:
Complications come from merging properties, that's why you need the MergeDriver of Thierry.
Phil _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Le 07/04/2015 17:08, Anne Etien a écrit :
Hi,
You mean instead of SmalltalkHub?
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
Well, I'll let you judge of the complexity.
For Serge effort in the Datathon in Paris/Montreuil, I wanted to merge Sven improvements on Open Street Map in Roassal to Alexandre latest Roassal2.
Sven did it during PharoDays, so, when was that? Two months ago?
So I fired up Monticello, opened the Smalltalkhub repository, and tried merging Roassal2-AlexandreBergel.812 and Roassal2-SvenVanCaenberghe.720.
Should have been easy, no? Sven only modified two or three methods, added a class, that's all.
Result: 282 conflicts... Spread over all of Roassal2, touching almost all classes :( You couldn't even find the true modifications of Sven in all that mess.
So what I did is switch to git. Copy via gitfiletree the common ancestor of Roassal2 (.718), made a branch Sven-OSM and copied there Sven's .719 and .720 versions, moved back to master and copied there the latest Roassal2 (.812), and:
git merge Sven-OSM
1 conflict.
Without counting the fact that git is a lot faster going through Roassal code than Monticello is.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
You have a point.
Now, after looking at the way some (many) of the projects are using Monticello, Metacello (Configurations), I'm not sure waiting for that GUI is a wise decision.
Thierry
Anne Le 7 avr. 2015 à 16:53, Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> a écrit :
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=%E2%9C%93&q=Roassal http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Just out of curiosity, did anyone use STIG/FileTree yet?
Best, Steffen
Am .04.2015, 17:34 Uhr, schrieb Thierry Goubier thierry.goubier@gmail.com:
Le 07/04/2015 17:08, Anne Etien a écrit :
Hi,
You mean instead of SmalltalkHub?
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
Well, I'll let you judge of the complexity.
For Serge effort in the Datathon in Paris/Montreuil, I wanted to merge Sven improvements on Open Street Map in Roassal to Alexandre latest Roassal2.
Sven did it during PharoDays, so, when was that? Two months ago?
So I fired up Monticello, opened the Smalltalkhub repository, and tried merging Roassal2-AlexandreBergel.812 and Roassal2-SvenVanCaenberghe.720.
Should have been easy, no? Sven only modified two or three methods, added a class, that's all.
Result: 282 conflicts... Spread over all of Roassal2, touching almost all classes :( You couldn't even find the true modifications of Sven in all that mess.
So what I did is switch to git. Copy via gitfiletree the common ancestor of Roassal2 (.718), made a branch Sven-OSM and copied there Sven's .719 and .720 versions, moved back to master and copied there the latest Roassal2 (.812), and:
git merge Sven-OSM
1 conflict.
Without counting the fact that git is a lot faster going through Roassal code than Monticello is.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
You have a point.
Now, after looking at the way some (many) of the projects are using Monticello, Metacello (Configurations), I'm not sure waiting for that GUI is a wise decision.
Thierry
Anne Le 7 avr. 2015 à 16:53, Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> a écrit :
<---Schnitt--->
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Steffen,
Le 07/04/2015 17:45, Steffen Märcker a écrit :
Just out of curiosity, did anyone use STIG/FileTree yet?
FileTree has an issue for supporting STIG (https://github.com/dalehenrich/filetree/issues/144).
As soon as it's in, I'll add that to GitFileTree. I want to benefit from the refactoring which will be done for that :)
Thierry
Best, Steffen
Am .04.2015, 17:34 Uhr, schrieb Thierry Goubier thierry.goubier@gmail.com:
Le 07/04/2015 17:08, Anne Etien a écrit :
Hi,
You mean instead of SmalltalkHub?
Are the tools like Monticello adapted to GIT? I don’t think so. And by listening the ones that already moved to GIT, it seems very complex.
Well, I'll let you judge of the complexity.
For Serge effort in the Datathon in Paris/Montreuil, I wanted to merge Sven improvements on Open Street Map in Roassal to Alexandre latest Roassal2.
Sven did it during PharoDays, so, when was that? Two months ago?
So I fired up Monticello, opened the Smalltalkhub repository, and tried merging Roassal2-AlexandreBergel.812 and Roassal2-SvenVanCaenberghe.720.
Should have been easy, no? Sven only modified two or three methods, added a class, that's all.
Result: 282 conflicts... Spread over all of Roassal2, touching almost all classes :( You couldn't even find the true modifications of Sven in all that mess.
So what I did is switch to git. Copy via gitfiletree the common ancestor of Roassal2 (.718), made a branch Sven-OSM and copied there Sven's .719 and .720 versions, moved back to master and copied there the latest Roassal2 (.812), and:
git merge Sven-OSM
1 conflict.
Without counting the fact that git is a lot faster going through Roassal code than Monticello is.
So without a great interface that abstracts all the complex details of GIT, I am not in favor of moving to GIT.
You have a point.
Now, after looking at the way some (many) of the projects are using Monticello, Metacello (Configurations), I'm not sure waiting for that GUI is a wise decision.
Thierry
Anne Le 7 avr. 2015 à 16:53, Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> a écrit :
<---Schnitt--->
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Le 07/04/2015 16:53, Alexandre Bergel a écrit :
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=%E2%9C%93&q=Roassal http://github.com/search?utf8=%E2%9C%93&q=Roassal We cannot ignore this…
Hey, I'm not even the first one cloning Roassal on github :)
Thierry
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
A big +1 on this !!
On Apr 7, 2015, at 18:48, Offray Vladimir Luna Cárdenas offray@riseup.net 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 Moose-dev@iam.unibe.ch 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
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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-598152...
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On Tue, Apr 7, 2015 at 11:48 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> 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
On 04/07/2015 03:50 PM, Peter Uhnák wrote:
On Tue, Apr 7, 2015 at 11:48 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com mailto:dale.henrichs@gemtalksystems.com> wrote:
With regards to bitbucket ... I added bitbucket:// support to Metacello for doing direct downloads of repositories from a Metacello project referencesIs 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 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
On Apr 7, 2015, at 14:54, Offray Vladimir Luna Cárdenas offray@riseup.net 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
On Tue, Apr 7, 2015 at 5:44 PM, stephan stephan@stack.nl 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. 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
Le 08/04/2015 00:59, Peter Uhnák a écrit :
On Tue, Apr 7, 2015 at 5:44 PM, stephan <stephan@stack.nl mailto:stephan@stack.nl> 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 alexandre.bergel@me.com 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=%E2%9C%93&q=Roassal We cannot ignore this…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
SergeStinckwich wrote
- move the code repository to github. A little more tricky.
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 -- View this message in context: http://forum.world.st/Moving-to-GIT-tp4818059p4818236.html Sent from the Moose mailing list archive at Nabble.com.
-
Alexandre Bergel -
Anne Etien -
Dale Henrichs -
Johan Fabry -
kilon alios -
Offray Vladimir Luna Cárdenas -
Peter Uhnák -
phil＠highoctane.be -
Sean P. DeNigris -
Serge Stinckwich -
Steffen Märcker -
stephan -
Thierry Goubier -
Yuriy Tymchuk