7 Apr
2015
7 Apr
'15
4:53 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 Apr
7 Apr
5:05 p.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:11 p.m.
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(a)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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:30 p.m.
On Tue, Apr 7, 2015 at 5:11 PM, kilon alios <kilon.alios(a)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
5:58 p.m.
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(a)gmail.com> wrote:
On Tue, Apr 7, 2015 at 5:11 PM, kilon alios
<kilon.alios(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:12 p.m.
Could be… It would be nice that we all have a clear position on this
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/>
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 7, 2015, at 12:05 PM, Peter Uhnák
<i.uhnak(a)gmail.com <mailto: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(a)me.com
<mailto: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 <http://www.bergel.eu/>
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:08 p.m.
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(a)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=✓&q=Roassal
We cannot ignore this…
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:12 p.m.
IMHO using git in Pharo is still quite painful.
Uko
On 07 Apr 2015, at 17:08, Anne Etien
<anne.etien(a)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(a)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=✓&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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:20 p.m.
Oh… You have an important experience. Why this? What are the troubles you are facing?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 7, 2015, at 12:12 PM, Yuriy Tymchuk
<yuriy.tymchuk(a)me.com> wrote:
IMHO using git in Pharo is still quite painful.
Uko
On 07 Apr 2015, at 17:08, Anne Etien
<anne.etien(a)univ-lille1.fr <mailto: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(a)me.com
<mailto:alexandre.bergel@me.com>> a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <http://www.bergel.eu/>
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:14 p.m.
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 7, 2015, at 12:08 PM, Anne Etien
<anne.etien(a)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(a)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=✓&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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:36 p.m.
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
11:36 p.m.
Complications come from merging properties, that's why you need the
MergeDriver of Thierry.
Phil
11:41 p.m.
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(a)highoctane.be wrote:
Complications come from merging properties, that's why you need the MergeDriver of
Thierry.
Phil
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:34 p.m.
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(a)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=✓&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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:45 p.m.
Just out of curiosity, did anyone use STIG/FileTree yet?
Best, Steffen
Am .04.2015, 17:34 Uhr, schrieb Thierry Goubier
<thierry.goubier(a)gmail.com>om>:
Le 07/04/2015 17:08, Anne Etien a écrit :
<---Schnitt--->
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(a)me.com
> <mailto:alexandre.bergel@me.com>> a écrit :
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:54 p.m.
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(a)gmail.com>om>:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Le 07/04/2015 17:08, Anne Etien a écrit :
<---Schnitt--->
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(a)me.com
> <mailto:alexandre.bergel@me.com>> a écrit :
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:17 p.m.
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=✓&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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:44 p.m.
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
7:54 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:12 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:58 p.m.
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ó:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 07-04-15 16:53, Alexandre Bergel wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10 p.m.
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ó:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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ó:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:17 p.m.
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 <offray(a)riseup.net> 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 :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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ó:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:33 p.m.
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
8 Apr
8 Apr
12:04 a.m.
El 07/04/15 a las 16:33, Dale Henrichs escribió:
On 04/07/2015 02:17 PM, Alexandre Bergel wrote:
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
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 ...
12:10 a.m.
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:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 ...
7 Apr
7 Apr
11:48 p.m.
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
8 Apr
8 Apr
12:15 a.m.
A big +1 on this !!
On Apr 7, 2015, at 18:48, Offray Vladimir Luna
Cárdenas <offray(a)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ó:
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:45 a.m.
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
7 Apr
7 Apr
9:11 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:48 p.m.
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-59815…
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ó:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 07-04-15 16:53, Alexandre Bergel wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8 Apr
8 Apr
12:08 a.m.
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
12:50 a.m.
On Tue, Apr 7, 2015 at 11:48 PM, Dale Henrichs <
dale.henrichs(a)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
2:18 a.m.
On 04/07/2015 03:50 PM, Peter Uhnák wrote:
On Tue, Apr 7, 2015 at 11:48 PM, Dale Henrichs
<dale.henrichs(a)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 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 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
7 Apr
7 Apr
9:26 p.m.
On Apr 7, 2015, at 14:54, Offray Vladimir Luna
Cárdenas <offray(a)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
8 Apr
8 Apr
12:59 a.m.
On Tue, Apr 7, 2015 at 5:44 PM, stephan <stephan(a)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
4:14 p.m.
Le 08/04/2015 00:59, Peter Uhnák a écrit :
On Tue, Apr 7, 2015 at 5:44 PM, stephan
<stephan(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7 Apr
7 Apr
10:26 p.m.
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(a)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
We cannot ignore this…
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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/
8 Apr
8 Apr
1:32 a.m.
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.
3316
days inactive
3317
days old
38 comments
14 participants
participants (14)
-
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