On 2014-3-17 05:42 , Sean Farley wrote:
>
> If MacPorts really wants to switch to distributed version control, then
> I would suggest Mercurial. I have experimented with using Mercurial for
> the MacPorts repo and found that the mercurial UI is much, much more
> consistent than git coming from Sub
Email is not the way to do voting >_<
On March 16, 2014 9:17:37 PM EDT, Blair Zajac wrote:
>
>On Mar 16, 2014, at 11:52 AM, mk-macpo...@techno.ms wrote:
>
>> On 16 Mar 2014, at 19:42 , Sean Farley wrote:
>>> I would suggest Mercurial.
>>
>> +1
>>
>> But, in order to avoid any flamewars: I’d be
On Mar 16, 2014, at 11:52 AM, mk-macpo...@techno.ms wrote:
> On 16 Mar 2014, at 19:42 , Sean Farley wrote:
>> I would suggest Mercurial.
>
> +1
>
> But, in order to avoid any flamewars: I’d be going for git as well, if it
> would win in an election. :-)
Since people are stating a preference
Clemens Lang writes:
> Hi,
>
> I'd like to chime in and offer my $.02. I'll try to keep it brief though,
> because nobody wants to read thousands of large opinionated posts in this
> thread if it's supposed to go somewhere.
>
> I think the popularity gives git the clear advantage over mercuria
On 2014-03-16 23:57, Clemens Lang wrote:
>> I propose we change to our policies to make it possible to work
>> with any tool locally, giving developers the choice to work with
>> the tool they like the most, be it svn, git-svn, hgsubversion,
>> bzr-svn, ...
>
> While I like the idea of that, I'm n
Rainer Müller writes:
> On 2014-03-16 19:42, Sean Farley wrote:
>> If MacPorts really wants to switch to distributed version control, then
>> I would suggest Mercurial. I have experimented with using Mercurial for
>> the MacPorts repo and found that the mercurial UI is much, much more
>> consist
Hi,
I'd like to chime in and offer my $.02. I'll try to keep it brief though,
because nobody wants to read thousands of large opinionated posts in this
thread if it's supposed to go somewhere.
I think the popularity gives git the clear advantage over mercurial or any of
the other systems. Also
On 2014-03-16 19:42, Sean Farley wrote:
> If MacPorts really wants to switch to distributed version control, then
> I would suggest Mercurial. I have experimented with using Mercurial for
> the MacPorts repo and found that the mercurial UI is much, much more
> consistent than git coming from Subver
On 16 Mar 2014, at 21:07 , Rainer Müller wrote:
> I am afraid of the increased complexity of git and the changing workflow for
> other
> developers.
>
> We cannot simply swap out Subversion and bless a git mirror as the new
> main ports tree, a new way of working with git has to be worked out f
On Mar 16, 2014, at 12:53 PM, Chris Jones wrote:
> Could i ask a commitor to take a look at
>
> https://trac.macports.org/ticket/42867
>
> It updates root to a new version, that fixes compilation with the latest
> Xcode 5.1 on OSX 10.9, so it would be useful to get it out quickly.
https://tra
On 2014-03-16 19:27, Ivan Larionov wrote:
> I want to start this discussion mainly about ports tree, but actually
> base and some other stuff could use github and infra around it as well.
> I understand this is not so easy and may be you already discussed it and
> may be already decided not to do,
Mark Anderson writes:
> Ok. I'm willing to play ball on that. Also since Atlassian products are
> pretty cool. I just like the idea of a more modern workflow. If I got a
> vote, which I suppose I don't, It would be git/github, but hg/bitbucket is
> ok. Git/bitbucket is what I use on the side as
Ok. I'm willing to play ball on that. Also since Atlassian products are
pretty cool. I just like the idea of a more modern workflow. If I got a
vote, which I suppose I don't, It would be git/github, but hg/bitbucket is
ok. Git/bitbucket is what I use on the side as well.
--Mark
___
Ryan Schmidt writes:
> On Mar 16, 2014, at 13:27, Ivan Larionov wrote:
>
>> I want to start this discussion mainly about ports tree, but actually base
>> and some other stuff could use github and infra around it as well. I
>> understand this is not so easy and may be you already discussed it a
Ivan Larionov writes:
> Actually main thing here isn’t git, but github. It’s interface and features
> take contribution process to the next level. It’s so easy — just fork, commit
> and send pull request.
>
> I understand that someone could like mercurial more and we have bitbucket,
> but actual
Yeah, I agree with Ivan, the big deal is Github. Git is great, but hg
offers a lot of the same stuff. As to Ryan's objections, I too had those
same objections after working with SVN and CVS for almost 2 decades. But
once I switched, I wondered why I hadn't switched earlier. I'm sure those
of us in
Actually main thing here isn’t git, but github. It’s interface and features
take contribution process to the next level. It’s so easy — just fork, commit
and send pull request.
I understand that someone could like mercurial more and we have bitbucket,
but actually, I see people use github more and
Yeah, I actually like the idea of GitHub for the idea of pull requests. So
much so, I mirror the Macports on github, make my changes in branches and
make patches for SVN there. I'm certain we could save all the history we
needed. I've made this shift several times on a few projects.
I even have ba
On Mar 16, 2014, at 13:27, Ivan Larionov wrote:
> I want to start this discussion mainly about ports tree, but actually base
> and some other stuff could use github and infra around it as well. I
> understand this is not so easy and may be you already discussed it and may be
> already decided
On 16 Mar 2014, at 19:42 , Sean Farley wrote:
> I would suggest Mercurial.
+1
But, in order to avoid any flamewars: I’d be going for git as well, if it would
win in an election. :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https
Ivan Larionov writes:
> I want to start this discussion mainly about ports tree, but actually base
> and some other stuff could use github and infra around it as well. I
> understand this is not so easy and may be you already discussed it and may be
> already decided not to do, but there are
I want to start this discussion mainly about ports tree, but actually base and
some other stuff could use github and infra around it as well. I understand
this is not so easy and may be you already discussed it and may be already
decided not to do, but there are huge pros:
* git >> svn
* pull r
Hi,
Could i ask a commitor to take a look at
https://trac.macports.org/ticket/42867
It updates root to a new version, that fixes compilation with the latest Xcode
5.1 on OSX 10.9, so it would be useful to get it out quickly.
Cheers Chris
___
macpor
Hi Clemens,
thanks for the quick response.
I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
File not found
Killed: 9
—
But I guess that could be due to the applicatio
Hi Clemens,
thanks for the quick response.
I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
File not found
Killed: 9
—
But I guess that could be due to the applicatio
Hi,
> ./testgraphical.shell: line 4: 59742 Trace/BPT trap: 5
> DYLD_LIBRARY_PATH=/Users/marko/projects/TestGraphical/build/lib/./:/opt/local/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
> "/Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/testgraphical"
> "$@"
That's
Hi,
I am testing KDevelop a little.
After a short hiccup I was able to get a scaffold for a “graphical app”
automagically built fine! :)
But the real problem starts when trying to run the app:
—
$ ./testgraphical.shell
dyld: Symbol not found: __cg_jpeg_resync_to_restart
Referenced from:
/Sys
On Mar 16, 2014, at 00:02, take...@macports.org wrote:
> Revision
> 117881
> Author
> take...@macports.org
> Date
> 2014-03-15 22:02:06 -0700 (Sat, 15 Mar 2014)
> Log Message
>
> netcdf: updated for 4.3.1.1. Obtain distfiles from github using PortGroup
> github. Commented out mpi.enforce_varian
28 matches
Mail list logo
