[boost] [git] Mercurial?
Daryle Walker
Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git? They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.) I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
I don't have a preference, but I want to make sure we consider the rival options.
Daryle W.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Bronek Kozicki
>
> Git has a competitor called Mercurial? If we're moving to a
> Distributed-VCS, should we go to Mercurial instead of Git? They're
> kind-of like CVS vs. Subversion, except I think they came up in
> parallel. (While Subversion was designed as an updated CVS.) I
> think Git was made up of a bunch of script hacks, while Mercurial was
> a regimented single program. I don't have a preference, but I want to
> make sure we consider the rival options.
Actually git was written from zero in C. Scripts only if you write them
on top of git, extremely efficient and steep learning curve, but
rewarding to use!
I'm using git daily together with p4 integration (for SOX compliant
history) and it's really great for team collaboration.
B.
Mathias Gaunard
>
> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git?
> They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.)
It's not at all like CVS vs Subversion, in part for the reason you
mentioned...
> I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
That is incorrect.
It's simply following the UNIX philosophy.
> I don't have a preference, but I want to make sure we consider the rival options.
How about we stop wasting time discussing this?
It has been way too long already.
Git is the most powerful versioning system today, is increasingly
popular, and has a vibrant community around it.
While Mercurial is comparable, Git has built-in support for more
advanced features and is more popular in the open-source world.
Most importantly, Git is already being used by several boost libraries.
Hasn't it been years since the idea of moving to Git has been submitted?
What's left to discuss?
Sergiu Dotenco
>
> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git? They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.) I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
> I don't have a preference, but I want to make sure we consider the rival options.
> Daryle W.
While we're at it, Google's analysis of Git and Mercurial shouldn't be
neglected:
http://code.google.com/p/support/wiki/DVCSAnalysis
Oliver Kowalke
maybe, when does boost-trunk move to git?
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Sergiu Dotenco
> Most importantly, Git is already being used by several boost libraries.
Not really, unless there are plans to use submodules/subrepositories.
Mark Borgerding
> On 19.03.2012 15:02, Daryle Walker wrote:
>> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git?
> http://code.google.com/p/support/wiki/DVCSAnalysis
>
FYI, here is a somewhat more entertaining, but still relevant,
comparison which frames git as MacGyver and mercurial as James Bond.
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
I'm sorry if I am fanning the flames of resurrecting an old discussion.
I did a little searching to see if this question had a distinct decision
on the forums. I saw discussions that were primarily focused on "why
DVCS?" not "which DVCS?"
It looks like the Boost wiki asks the question of "Why Git?" (
https://svn.boost.org/trac/boost/wiki/Git/WhyGit ) but does not answer
it. Perhaps the deciders can give more information on the wiki? Then
when this comes up again, simply provide the link.
My anecdote: Take it for what it's worth ( maybe two cents) ...
I first encountered DVCS by helping out under the Eigen c++ library
project. I quickly became a convert to the concept of dvcs and
secondarily to mercurial as an implementation.
I talked the rest of the developers at my company into migrating our
then-cvs repos forward to something more modern. I did not want to
taint the decision by simply grabbing for what I knew. So we weighed out
the pros and cons of using various distributed version control systems.
The fight quickly devolved to hg vs. git.
In the end we chose mercurial because
1. Hg did everything we could envision needing to do. Mostly through
simple prebuilt commands, infrequently by more advanced scripting see
"hg help templates" or "hg help revsets" to get a flavor of the power.
2. The commands and concepts of mercurial are closer to the cvs/svn
concepts we knew. Many of the commands are actually the same. This
minimized the cost of converting our coders, which far outweighs the
cost of converting our code.
3. Hg is simpler than git for doing common tasks ( or at least seemed so
to us -- see #2)
There were various other minor reasons that tipped us toward mercurial,
like cross-platform consistency and hg's habit of keeping the repo
compressed.
Let me end by applauding Boost for doing the right thing. Moving from
svn to any DVCS is a step in the right direction. The detail of which
one is a nuance.
Dave Abrahams
on Mon Mar 19 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
> On 19.03.2012 15:02, Daryle Walker wrote:
>>
>> Git has a competitor called Mercurial? If we're moving to a
>> Distributed-VCS, should we go to Mercurial instead of Git? They're
>> kind-of like CVS vs. Subversion, except I think they came up in
>> parallel. (While Subversion was designed as an updated CVS.) I
>> think Git was made up of a bunch of script hacks, while Mercurial
>> was a regimented single program.
>> I don't have a preference, but I want to make sure we consider the rival options.
>> Daryle W.
>
> While we're at it, Google's analysis of Git and Mercurial shouldn't be
> neglected:
>
> http://code.google.com/p/support/wiki/DVCSAnalysis
That analysis completely ignores the (most?) important factors,
mindshare and marketplace.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Mon Mar 19 2012, Daryle Walker <darylew-AT-hotmail.com> wrote:
> Git has a competitor called Mercurial? If we're moving to a
> Distributed-VCS, should we go to Mercurial instead of Git?
IMO, no. There are several reasons, but the main one is that Git is
winning in the marketplace.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Sergiu Dotenco
>
> on Mon Mar 19 2012, Daryle Walker <darylew-AT-hotmail.com> wrote:
>
>> Git has a competitor called Mercurial? If we're moving to a
>> Distributed-VCS, should we go to Mercurial instead of Git?
>
> IMO, no. There are several reasons, but the main one is that Git is
> winning in the marketplace.
>
What reasons exactly? "Git is the most powerful versioning system
today", "is increasingly popular", "Git has built-in support for more
advanced features", "is more popular in the open-source world", "Git is
winning in the marketplace"? Sounds more like a propaganda, which isn't
even convincing.
Bruno Santos
On 19/03/2012, at 18:24, Sergiu Dotenco wrote:
> On 3/19/2012 6:15 PM, Dave Abrahams wrote:
>>
>> on Mon Mar 19 2012, Daryle Walker <darylew-AT-hotmail.com> wrote:
>>
>>> Git has a competitor called Mercurial? If we're moving to a
>>> Distributed-VCS, should we go to Mercurial instead of Git?
>>
>> IMO, no. There are several reasons, but the main one is that Git is
>> winning in the marketplace.
>>
>
> What reasons exactly? "Git is the most powerful versioning system
> today", "is increasingly popular", "Git has built-in support for more
> advanced features", "is more popular in the open-source world", "Git is
> winning in the marketplace"? Sounds more like a propaganda, which isn't
> even convincing.
The community around git completely overshadows any other DCVS. This is not propaganda but a fact.
Popularity is the winning decision factor. Can you convince us why not?
Mark Borgerding
I don't understand. Mercurial chose to adopt cvs/svn commands and
nomenclature when it made sense. Git chose to reinvent everything.
Migrating developers from svn to mercurial should be much easier.
re marketplace:
Google trends shows. "git" outpaces "mercurial" by roughly 2:1.
Although I'd guess that number is somewhat skewed by people using
"git-r-done" in their blogs than "mercurial"
Does it matter which is more popular? As long as the choice is popular
*enough* that it won't vanish.
On 03/19/2012 01:17 PM, Dave Abrahams wrote:
> on Mon Mar 19 2012, Sergiu Dotenco<sergiu.dotenco-AT-gmail.com> wrote:
>
>> On 19.03.2012 15:02, Daryle Walker wrote:
>>> Git has a competitor called Mercurial? If we're moving to a
>>> Distributed-VCS, should we go to Mercurial instead of Git? They're
>>> kind-of like CVS vs. Subversion, except I think they came up in
>>> parallel. (While Subversion was designed as an updated CVS.) I
>>> think Git was made up of a bunch of script hacks, while Mercurial
>>> was a regimented single program.
>>> I don't have a preference, but I want to make sure we consider the rival options.
>>> Daryle W.
>> While we're at it, Google's analysis of Git and Mercurial shouldn't be
>> neglected:
>>
>> http://code.google.com/p/support/wiki/DVCSAnalysis
> That analysis completely ignores the (most?) important factors,
> mindshare and marketplace.
>
Sergiu Dotenco
The alleged fact is probably a fact only iff you mean the Linux (kernel)
community. Besides, why is the popularity important considering that
both version control systems are comparable?
Hartmut Kaiser
> on Mon Mar 19 2012, Daryle Walker <darylew-AT-hotmail.com> wrote:
>
> > Git has a competitor called Mercurial? If we're moving to a
> > Distributed-VCS, should we go to Mercurial instead of Git?
>
> IMO, no. There are several reasons, but the main one is that Git is
> winning in the marketplace.
You're kidding right? If not - let's switch Boost to Java - it's way more
popular!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
Thomas Klimpel
> Dave Abrahams wrote:
> > IMO, no. There are several reasons, but the main one is that Git is
> > winning in the marketplace.
>
> You're kidding right? If not - let's switch Boost to Java - it's way
> more popular!
As a first step, boost could provide Java bindings similar to the existing python bindings. Anyone?
Regards,
Thomas
Mathias Gaunard
>
>> on Mon Mar 19 2012, Daryle Walker<darylew-AT-hotmail.com> wrote:
>>
>>> Git has a competitor called Mercurial? If we're moving to a
>>> Distributed-VCS, should we go to Mercurial instead of Git?
>>
>> IMO, no. There are several reasons, but the main one is that Git is
>> winning in the marketplace.
>
> You're kidding right? If not - let's switch Boost to Java - it's way more
> popular!
Using Java makes sense if Java is a suitable tools to your purposes.
Clearly that's not the case of Boost.
When in comes to versioning systems, however, both mercurial and git are
suitable; I think choosing based on which is more popular is a good idea.
I certainly don't want Boost to end up using a tool that few people are
familiar with. Boost.Build is bad enough at that.
Bryce Lelbach
>
> on Mon Mar 19 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
>
> > On 19.03.2012 15:02, Daryle Walker wrote:
> >>
> >> Git has a competitor called Mercurial? If we're moving to a
> >> Distributed-VCS, should we go to Mercurial instead of Git? They're
> >> kind-of like CVS vs. Subversion, except I think they came up in
> >> parallel. (While Subversion was designed as an updated CVS.) I
> >> think Git was made up of a bunch of script hacks, while Mercurial
> >> was a regimented single program.
> >> I don't have a preference, but I want to make sure we consider the rival options.
> >> Daryle W.
> >
> > While we're at it, Google's analysis of Git and Mercurial shouldn't be
> > neglected:
> >
> > http://code.google.com/p/support/wiki/DVCSAnalysis
>
> That analysis completely ignores the (most?) important factors,
> mindshare and marketplace.
Uh, can you provide some data for this, please?
The two major surveys I know contradict this.
http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report.pdf, page 16
http://blogs.forrester.com/application_development/2010/01/forrester-databyte-developer-scm-tool-adoption-and-use.html
--
Bryce Lelbach aka wash
STE||AR Group, Center for Computation and Science, LSU
--
boost-spirit.com
stellar.cct.lsu.edu
llvm.wiki.kernel.org
Bryce Lelbach
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Mathias Gaunard
> Uh, can you provide some data for this, please?
>
> The two major surveys I know contradict this.
>
> http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report.pdf, page 16
> http://blogs.forrester.com/application_development/2010/01/forrester-databyte-developer-scm-tool-adoption-and-use.html
Git is the first DVCS according to both those surveys.
What were you trying to say? That subversion is still a lot more popular
than Git?
Dave Abrahams
on Mon Mar 19 2012, "Hartmut Kaiser" <hartmut.kaiser-AT-gmail.com> wrote:
>> on Mon Mar 19 2012, Daryle Walker <darylew-AT-hotmail.com> wrote:
>>
>> > Git has a competitor called Mercurial? If we're moving to a
>> > Distributed-VCS, should we go to Mercurial instead of Git?
>>
>> IMO, no. There are several reasons, but the main one is that Git is
>> winning in the marketplace.
>
> You're kidding right?
No.
> If not - let's switch Boost to Java - it's way more popular!
Is switching to Java compatible with Boost's goals in some way that I
haven't yet considered?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Mon Mar 19 2012, Bryce Lelbach <blelbach-AT-cct.lsu.edu> wrote:
> On 2012.03.19 13.17, Dave Abrahams wrote:
>>
>> on Mon Mar 19 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
>>
>> > On 19.03.2012 15:02, Daryle Walker wrote:
>> >>
>
>> >> Git has a competitor called Mercurial? If we're moving to a
>> >> Distributed-VCS, should we go to Mercurial instead of Git? They're
>> >> kind-of like CVS vs. Subversion, except I think they came up in
>> >> parallel. (While Subversion was designed as an updated CVS.) I
>> >> think Git was made up of a bunch of script hacks, while Mercurial
>> >> was a regimented single program.
>> >> I don't have a preference, but I want to make sure we consider the rival options.
>> >> Daryle W.
>> >
>> > While we're at it, Google's analysis of Git and Mercurial shouldn't be
>> > neglected:
>> >
>> > http://code.google.com/p/support/wiki/DVCSAnalysis
>>
>> That analysis completely ignores the (most?) important factors,
>> mindshare and marketplace.
>
> Uh, can you provide some data for this, please?
Data? All you have to do is read the article to see that it ignores
those factors.
> The two major surveys I know contradict this.
>
> http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report.pdf, page 16
> http://blogs.forrester.com/application_development/2010/01/forrester-databyte-developer-scm-tool-adoption-and-use.html
Contradict what?
Dave Abrahams
More attention from the community, more support, more tools work with
it, more money behind it, more people will be familiar with it in the
long run, etc., etc.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Hartmut Kaiser
Well, it contradicts your claim that 'Git is winning in the marketplace',
which is total nonsense if you look at the surveys (SVN 50% vs. GIT 13%
'marketshare').
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
Jim Bosch
>
> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git? They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.) I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
> I don't have a preference, but I want to make sure we consider the rival options.
My organization recently switched from SVN to git. Pretty much everyone
was very happy with the result. We also considered mercurial, and we
all agreed that choosing between git and mercurial wasn't nearly as
important as choosing either of them instead of svn.
That said, there are differences, and I'm glad we picked git. I think
the market- and mind-share arguments are real, and in git's favor.
Anecdotally at least, it's interesting that bitbucket - which started as
an all-mercurial hosting site - has more recently added git support:
http://blog.bitbucket.org/2009/04/01/announcing-git-support/
And I think it's also telling that while git's branching model - one of
the most important aspects of a VCS - is basically the same one it has
always had, mercurial's branching model has evolved towards the git
model (mercurial bookmarks == git branches).
So I think there's circumstantial evidence that git is a better design
in some ways. Mercurial is superficially more similar to svn, but given
that they're both architecturally very different from svn, I think that
could just as easily be seen as an advantage for git.
Jim Bosch
Nathan Ridge
> > > IMO, no. There are several reasons, but the main one is that Git is
> > > winning in the marketplace.
> >
> > You're kidding right? If not - let's switch Boost to Java - it's way
> > more popular!
>
> As a first step, boost could provide Java bindings similar to the existing python bindings. Anyone?
standard library, and for the rest, the concepts don't map well to Java (try writing
Java bindings to MPL...).
Regards,
Nate
Anthony Williams
> On 03/19/2012 10:02 AM, Daryle Walker wrote:
>>
>> Git has a competitor called Mercurial? If we're moving to a
>> Distributed-VCS, should we go to Mercurial instead of Git? They're
>> kind-of like CVS vs. Subversion, except I think they came up in
>> parallel. (While Subversion was designed as an updated CVS.) I think
>> Git was made up of a bunch of script hacks, while Mercurial was a
>> regimented single program.
>> I don't have a preference, but I want to make sure we consider the
>> rival options.
>
> My organization recently switched from SVN to git. Pretty much everyone
> was very happy with the result. We also considered mercurial, and we all
> agreed that choosing between git and mercurial wasn't nearly as
> important as choosing either of them instead of svn.
I've had numerous problems with git, including getting my local git repo
into a state where it would neither push to nor pull from the remote
repo. On the other hand, I've had no problems with Mercurial, even
though I've used it on more projects, with more branching and merging.
In one case, I was having such difficulty with git that I used hg-git to
import my git repo into mercurial, so I could deal with the branches and
merges in a sane fashion, then exported back to git.
All my problems basically boil down to one thing though: the user
interface (command line) to git doesn't map cleanly to the way I think
about stuff, or the operations I wish to do, whereas the user interface
for mercurial does. For me, mercurial is intuitive, whereas git is not,
in a big way.
Technically, they're on a par, and there are additional scripts and
plugins for git that help with the UI.
As for mindshare and marketplace, there is widespread support and usage
of both, and both are used by major projects.
Given the choice, I'd go for Mercurial every time, but either is better
than subversion.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Sergiu Dotenco
>
> on Mon Mar 19 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
>
>> On 3/19/2012 7:46 PM, Bruno Santos wrote:
>>
>>> The community around git completely overshadows any other DCVS. This is not propaganda but a fact.
>>> Popularity is the winning decision factor. Can you convince us why not?
>>
>> The alleged fact is probably a fact only iff you mean the Linux (kernel)
>> community. Besides, why is the popularity important considering that
>> both version control systems are comparable?
>
> More attention from the community, more support, more tools work with
> it, more money behind it, more people will be familiar with it in the
> long run, etc., etc.
So, this is the reason why Git developers treat Windows as a second
class citizen, i.e., there's no official Windows support? Also, the last
time I checked, TortoiseGit looked like a major hack compared to TortoiseHg.
Sergey Popov
Dave Abrahams <da...@boostpro.com> wrote:
> More attention from the community, more support, more tools work with
> it, more money behind it, more people will be familiar with it in the
> long run, etc., etc.
>
Both of hg and git have large enough communities so in this particular
case popularity alone cannot be deciding factor. Wrt support and tools
you're unlikely to notice much difference due to diminishing returns.
Thomas Klimpel
> > > You're kidding right? If not - let's switch Boost to Java - it's
> > > way more popular!
> >
> > As a first step, boost could provide Java bindings similar to the
> > existing python bindings. Anyone?
>
> What purpose would that serve? A lot of Boost's functionality is
> covered by the Java
> standard library, and for the rest, the concepts don't map well to Java
> (try writing Java bindings to MPL...).
But wouldn't your arguments apply to the existing python bindings in the same way?
Anyway, that suggestion wasn't meant too serious. (More precisely, I know too little about this subject for being able to judge whether this suggestion could make sense or not.)
Regards,
Thomas
Eric Niebler
>
> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git? They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.) I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
> I don't have a preference, but I want to make sure we consider the rival options.
As with everything in open source, it comes down to: who is willing and
able to do the work? If nobody advocates for Mercurial *and* is willing
to do the work to make it happen, then it won't happen.
FWIW, I sympathize with the folks complaining about git's complicated
interface/mental model and with its poor Windows support. I've never
used Mercurial. If it's simpler to use and has solid windows support,
those are two strong argument in its favor. But again, someone needs to
step up to the plate, and AFAICT nobody has.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
Sergiu Dotenco
> On 3/19/2012 9:34 PM, Dave Abrahams wrote:
>>
>> on Mon Mar 19 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
>>
>>> On 3/19/2012 7:46 PM, Bruno Santos wrote:
>>>
>>>> The community around git completely overshadows any other DCVS. This is not propaganda but a fact.
>>>> Popularity is the winning decision factor. Can you convince us why not?
>>>
>>> The alleged fact is probably a fact only iff you mean the Linux (kernel)
>>> community. Besides, why is the popularity important considering that
>>> both version control systems are comparable?
>>
>> More attention from the community, more support, more tools work with
>> it, more money behind it, more people will be familiar with it in the
>> long run, etc., etc.
>
> So, this is the reason why Git developers treat Windows as a second
> class citizen, i.e., there's no official Windows support? Also, the last
> time I checked, TortoiseGit looked like a major hack compared to TortoiseHg.
TortoiseHg is also available for Gnome/Nautilus. I'm not aware of
similar Git tools for Linux though.
Bruno Santos
Only the Linux community? are you serious?
Bruno Santos
On 19/03/2012, at 22:49, Eric Niebler wrote:
> On 3/19/2012 7:02 AM, Daryle Walker wrote:
>>
>> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS, should we go to Mercurial instead of Git? They're kind-of like CVS vs. Subversion, except I think they came up in parallel. (While Subversion was designed as an updated CVS.) I think Git was made up of a bunch of script hacks, while Mercurial was a regimented single program.
>> I don't have a preference, but I want to make sure we consider the rival options.
>> Daryle W.
>
> As with everything in open source, it comes down to: who is willing and
> able to do the work? If nobody advocates for Mercurial *and* is willing
> to do the work to make it happen, then it won't happen.
>
> FWIW, I sympathize with the folks complaining about git's complicated
> interface/mental model and with its poor Windows support. I've never
> used Mercurial. If it's simpler to use and has solid windows support,
> those are two strong argument in its favor. But again, someone needs to
> step up to the plate, and AFAICT nobody has.
I don't think mercurial is simpler to use. It just makes it harder to edit history, which is only advantageous for someone completely clueless about it.
Dave Abrahams
on Mon Mar 19 2012, "Hartmut Kaiser" <hartmut.kaiser-AT-gmail.com> wrote:
>> on Mon Mar 19 2012, Bryce Lelbach <blelbach-AT-cct.lsu.edu> wrote:
>>
>> > The two major surveys I know contradict this.
>> >
>> > http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report
>> > .pdf, page 16
>> > http://blogs.forrester.com/application_development/2010/01/forrester-d
>> > atabyte-developer-scm-tool-adoption-and-use.html
>>
>> Contradict what?
>
> Well, it contradicts your claim that 'Git is winning in the marketplace',
> which is total nonsense if you look at the surveys (SVN 50% vs. GIT 13%
> 'marketshare').
If you read the thread carefully, you'll see I was talking about the
DVCS marketplace (in fact, just about Git vs Mercurial), where SVN is
not a contender. Please tone down the 'tude, friend.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Mon Mar 19 2012, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
> I've had numerous problems with git, including getting my local git
> repo into a state where it would neither push to nor pull from the
> remote repo. On the other hand, I've had no problems with Mercurial,
> even though I've used it on more projects, with more branching and
> merging.
>
> In one case, I was having such difficulty with git that I used hg-git
> to import my git repo into mercurial, so I could deal with the
> branches and merges in a sane fashion, then exported back to git.
>
> All my problems basically boil down to one thing though: the user
> interface (command line) to git doesn't map cleanly to the way I think
> about stuff, or the operations I wish to do, whereas the user
> interface for mercurial does. For me, mercurial is intuitive, whereas
> git is not, in a big way.
But for every story like that, there's an opposite one from the other
community. For example, I find Mercurial's branch model completely
insane. Multiple heads on a branch? What on earth were they thinking?!
So on one project I used git-Hg to make the transition in the other
direction.
But seriously, if I thought Hg was winning in the DVCS marketplace I
would choose it over Git, even though I find it difficult to use and
ugly to think about. That's easy for me to say, I know. I'm just lucky
that I perceive the marketplace winner to be the tool I like better.
Oh, and please don't think me a Git zealot. There are some things about
the design I quite disagree with, and the UI certainly can be harder to
grasp than necessary. More than a little, that's the community's fault
for not explaining Git well. But that situation is improving...
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Klaim - Joël Lamotte
May I ask:
- what is the current state of git concerning error reporting? Last time I
checked, git still had no reports when something gone wrong and that was a
major concern to me.
- what is the current state of git concerning windows support? As someone
pointed out, there is no official efforts to make it easily portable to
windows and tools are problematic on windows.
I don't care if boost goes with git or mercurial, but AFAIK, error
reporting and windows support is far worst than git's (hard to grasp) ui.
I hope it have been fixed since last time I checked (in the middle of the
last year).
Joël Lamotte
John Wiegley
> More attention from the community, more support, more tools work with it,
> more money behind it, more people will be familiar with it in the long run,
> etc., etc.
Example: compare the number of commercial tools for working with Git, compared
to those available for working with Mercurial. On OS X along I can use:
SourceTree, Tower, GitHub, GitBox, GitDiary, QuickHub, Octopus, and that's
only the commercial tools!
By contrast, if I search for "mercurial" in the AppStore, I can only use
SourceTree (which works with both).
--
John Wiegley
BoostPro Computing, Inc.
Rene Rivera
>>>>>> Dave Abrahams<da...@boostpro.com> writes:
>
>> More attention from the community, more support, more tools work with it,
>> more money behind it, more people will be familiar with it in the long run,
>> etc., etc.
>
> Example: compare the number of commercial tools for working with Git, compared
> to those available for working with Mercurial. On OS X along I can use:
> SourceTree, Tower, GitHub, GitBox, GitDiary, QuickHub, Octopus, and that's
> only the commercial tools!
The argument could also be made that the number of alternate Git tools
available speaks to the lack of good tools for it. As people keep trying
to make the "better" tool for dealing with it.
Not sure how you searched.. But mercurial has a page listing some of the
tools available for it <http://mercurial.selenic.com/wiki/OtherTools>.
Seems like a rich set of external tools to me.
> By contrast, if I search for "mercurial" in the AppStore, I can only use
> SourceTree (which works with both).
I don't see how searching in a mobile device application store is
relevant. Did you mean something else?
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Nathan Ridge
> Nathan Ridge wrote:
> > > > You're kidding right? If not - let's switch Boost to Java - it's
> > > > way more popular!
> > >
> > > As a first step, boost could provide Java bindings similar to the
> > > existing python bindings. Anyone?
> >
> > What purpose would that serve? A lot of Boost's functionality is
> > covered by the Java
> > standard library, and for the rest, the concepts don't map well to Java
> > (try writing Java bindings to MPL...).
>
> But wouldn't your arguments apply to the existing python bindings in the same way?
>
> Anyway, that suggestion wasn't meant too serious. (More precisely, I know too little about this subject for being able to judge whether this suggestion could make sense or not.)
I confess, I do not know anything about the existing python bindings. I'm
aware of a library called Boost.Python, but my understanding is that this
is a library for creating python bindings to any C++ library, rather than
being python bindings for Boost itself. Could you provide a link to the
existing python bindings?
Thanks,
Nate
Thomas Heller
>
> on Mon Mar 19 2012, "Hartmut Kaiser"<hartmut.kaiser-AT-gmail.com> wrote:
>
>>> on Mon Mar 19 2012, Bryce Lelbach<blelbach-AT-cct.lsu.edu> wrote:
>>>
>>>> The two major surveys I know contradict this.
>>>>
>>>> http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report
>>>> .pdf, page 16
>>>> http://blogs.forrester.com/application_development/2010/01/forrester-d
>>>> atabyte-developer-scm-tool-adoption-and-use.html
>>>
>>> Contradict what?
>>
>> Well, it contradicts your claim that 'Git is winning in the marketplace',
>> which is total nonsense if you look at the surveys (SVN 50% vs. GIT 13%
>> 'marketshare').
>
> If you read the thread carefully, you'll see I was talking about the
> DVCS marketplace (in fact, just about Git vs Mercurial), where SVN is
> not a contender. Please tone down the 'tude, friend.
Let me try to wrap my head around all this...
So essentially, the argument is to choose git over whatever is because
of its marketshare, right?
The only reason behind this i can think of is to attract new boost
contributors (yeah ... I know, I am one of those hippies completely
neglecting the commercial interest behind boost).
Ok, I can see that as a possible advantage for git. Especially since a
lot of people expressed themselves that svn is _the_ major blocker for
not contributing.
So far so good, this is the argument for people already familiar with
git. Let's check the statistics again:
https://github.com/languages
Right ... so many potential new developers ... Maybe we should provide
Javascript bindings ...
So, what about persons who are infected by their favorite poison and
have to learn the VCS tool of choice. I keep reading about git having a
steep learning curve, so maybe we won't attract those developers either ...
I'd argue that writing code is not done in the VCS. Be it writing a
patch for an existing software or a completely new library. The
complexity is in writing the code itself. Or applying the patch and
verify it.
FWIW, I am the last person who will oppose such a change.
But currently, noone presented a fair reasoning in favor for git, or how
such a transition could be done. No one. The only things that have been
discussed on this list is FUD from both sides. And this marketshare
argument, completely disregarding a possible other option ... wow. Maybe
you did the comparison once. Somehow people tend to forget in their Git
crusade that other people didn't go through the transition yet, and are
searching for arguments to actually make such a change.
Regards,
Thomas
Sergiu Dotenco
You think? How about sticking to the facts? Moreover, why would you even
want to edit already shared history? Seems like there are much more
clueless Git users who are not able to handle the tool in the first place.
Anthony Williams
>
> on Mon Mar 19 2012, Anthony Williams<anthony.ajw-AT-gmail.com> wrote:
>
>> I've had numerous problems with git, including getting my local git
>> repo into a state where it would neither push to nor pull from the
>> remote repo. On the other hand, I've had no problems with Mercurial,
>> even though I've used it on more projects, with more branching and
>> merging.
>>
>> In one case, I was having such difficulty with git that I used hg-git
>> to import my git repo into mercurial, so I could deal with the
>> branches and merges in a sane fashion, then exported back to git.
>>
>> All my problems basically boil down to one thing though: the user
>> interface (command line) to git doesn't map cleanly to the way I think
>> about stuff, or the operations I wish to do, whereas the user
>> interface for mercurial does. For me, mercurial is intuitive, whereas
>> git is not, in a big way.
>
> But for every story like that, there's an opposite one from the other
> community. For example, I find Mercurial's branch model completely
> insane. Multiple heads on a branch? What on earth were they thinking?!
> So on one project I used git-Hg to make the transition in the other
> direction.
Totally agreed. I was just sharing my experience. I find git
unintuitive. YMMV, and apparently it does. I actually find the "multiple
heads" thing quite intuitive!
Anyway, as I said in the paragraph you skipped: git is better than
subversion, so I'd rather use git than not change to a DVCS.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
_______________________________________________
Bjørn Roald
> Hi,
>
> May I ask:
>
> - what is the current state of git concerning error reporting? Last time I
> checked, git still had no reports when something gone wrong and that was a
> major concern to me.
I have no idea, what kind of missing error reporting are you referring too?
> - what is the current state of git concerning windows support? As someone
> pointed out, there is no official efforts to make it easily portable to
> windows and tools are problematic on windows.
If it helps anything, we have been using Git on Windows in a small team
but on a large codebase for several years. No real problems, and I must
say it is huge improvement in usabillity over ClearCase, our legacy,
which have quite complete GUI and Windows support. Some of the
developers use TourtoiseGIT, I use it occasionally. Mostly I use git
support in emacs and the command line support and built in gitk and
git-gui. On emacs I have settled with egg.el which work on all
platforms and support most of my tasks. So even if there are
alternatives I have not tried, I have no need to look further.
I would not be concerned with Windows support for Git. Why there is
still no official release for Windows does however puzzle me a bit. Is
there any official statements why they release the git windows ports
labeled as previews?
>
> I don't care if boost goes with git or mercurial, but AFAIK, error
> reporting and windows support is far worst than git's (hard to grasp) ui.
> I hope it have been fixed since last time I checked (in the middle of the
> last year).
Well, if I had to choose I would go for Git, without really having any
strong opinion against Hg. One of my main reasons would be the fact
that even as Git has been solid all along for us, it has improved a lot
on its support for its weaker aspects over the last few years. I
strongly feel any remaining problems, if any, that should concern boost
will be fixed sooner rather than later.
--
Bjørn
Sergiu Dotenco
You bet I'm serious, unless you want to argue whether the surveys you
refer to (?) are representative.
Philippe Vaucher
> - what is the current state of git concerning windows support? As someone
> pointed out, there is no official efforts to make it easily portable to
> windows and tools are problematic on windows.
>
I use git on windows, linux and OSX on a regular basis and windows support
is fine. MSysGit combined with TortoiseGit makes it easy to use for
beginners, tho sometimes git's performance on windows is a bit slow.
Linux lacks a good TortoiseGit equivalent that integrates with the file
explore imho, but this is improving with RabbitCVS & GitG.
Philippe
Dave Abrahams
on Tue Mar 20 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>> By contrast, if I search for "mercurial" in the AppStore, I can only use
>> SourceTree (which works with both).
>
> I don't see how searching in a mobile device application store is
> relevant. Did you mean something else?
Apple's AppStore application for MacOS is for downloading MacOS
applications. If you want to download iOS apps you need to use iTunes.
Makes perfect sense, I know... ;-)
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Tue Mar 20 2012, Thomas Heller <thom.heller-AT-googlemail.com> wrote:
> On 03/20/2012 02:52 AM, Dave Abrahams wrote:
>>
>> on Mon Mar 19 2012, "Hartmut Kaiser"<hartmut.kaiser-AT-gmail.com> wrote:
>>
>>>> on Mon Mar 19 2012, Bryce Lelbach<blelbach-AT-cct.lsu.edu> wrote:
>>>>
>
>>>>> The two major surveys I know contradict this.
>>>>>
>>>>> http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Report
>>>>> .pdf, page 16
>>>>> http://blogs.forrester.com/application_development/2010/01/forrester-d
>>>>> atabyte-developer-scm-tool-adoption-and-use.html
>>>>
>>>> Contradict what?
>>>
>>> Well, it contradicts your claim that 'Git is winning in the marketplace',
>>> which is total nonsense if you look at the surveys (SVN 50% vs. GIT 13%
>>> 'marketshare').
>>
>> If you read the thread carefully, you'll see I was talking about the
>> DVCS marketplace (in fact, just about Git vs Mercurial), where SVN is
>> not a contender. Please tone down the 'tude, friend.
>
> Let me try to wrap my head around all this...
> So essentially, the argument is to choose git over whatever is because
> of its marketshare, right?
>
> The only reason behind this i can think of is to attract new boost
> contributors (yeah ... I know, I am one of those hippies completely
> neglecting the commercial interest behind boost).
That's just one of many reasons. If you mentally amplify the difference
in popularity between Mercurial and Git, I'm sure some of the others
will become more apparent to you. It's all a matter of degrees.
> FWIW, I am the last person who will oppose such a change.
> But currently, noone presented a fair reasoning in favor for git, or
> how such a transition could be done. No one. The only things that have
> been discussed on this list is FUD from both sides.
Careful; I'm sure you didn't mean it that way, but that term is quite
inflammatory---to some people it means a lot more (and much worse) than
to others. And besides, I totally disagree with you. Personal
anecdotes of frustration with a tool are not FUD, no matter how you
interpret the term. Arguments that it is easier to make a transition to
a tool with similar commands (e.g. SVN->Hg) are not FUD. Human factors
count---a lot. That's part of the reason the popularity measuremnet is
important to me.
> And this marketshare argument, completely disregarding a possible
> other option ... wow.
I'm not completely disregarding it. I've done enough evaluation to
satisfy myself of the answer.
> Maybe you did the comparison once.
Yes.
> Somehow people tend to forget in their Git crusade that other people
> didn't go through the transition yet, and are searching for arguments
> to actually make such a change.
I'm not on a Git crusade. And I'm sorry that I can't help you further
to find a killer argument for yourself; in the end, everyone makes his
own choice of favorite.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Thijs (M.A.) van den Berg
Dave Abrahams
on Tue Mar 20 2012, Klaim - Joël Lamotte <mjklaim-AT-gmail.com> wrote:
> Hi,
>
> May I ask:
>
> - what is the current state of git concerning error reporting? Last time I
> checked, git still had no reports when something gone wrong and that was a
> major concern to me.
I don't know. A more specific question would help---"when something
gone wrong" leaves a lot of room for interpretation. But then, you
could probably do a quick experiment yourself and quickly get a clear
answer.
> - what is the current state of git concerning windows support? As
> someone pointed out, there is no official efforts to make it easily
> portable to windows and tools are problematic on windows.
http://help.github.com/win-set-up-git/
It's well supported, and support is not going away.
> I don't care if boost goes with git or mercurial, but AFAIK, error
> reporting and windows support is far worst than git's (hard to grasp) ui.
> I hope it have been fixed since last time I checked (in the middle of the
> last year).
I personally doubt much has changed in those areas since the middle of
last year. But then, I never had problems with either of those things.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Tue Mar 20 2012, Bjørn Roald <bjorn-AT-4roald.org> wrote:
> On emacs I have settled with egg.el which work on all
> platforms and support most of my tasks. So even if there are
> alternatives I have not tried, I have no need to look further.
IMO you absolutely *must* try Magit if you are an emacs user. Oh, wow,
egg calls itself a "clone of Marius' excellent magit." According to
http://alexott.net/en/writings/emacs-vcs/EmacsGit.html#sec18 it adds
Windows portability to magit, so that's something interesting. I wish
the differences were more clearly laid out. Well, according to
https://github.com/bogolisk/egg/commits/master, egg hasn't been changed
in 3 years, while https://github.com/magit/magit/commits/master shows
that magit is still quite actively maintained.
> Well, if I had to choose I would go for Git, without really having any
> strong opinion against Hg. One of my main reasons would be the fact
> that even as Git has been solid all along for us, it has improved a
> lot on its support for its weaker aspects over the last few years. I
> strongly feel any remaining problems, if any, that should concern
> boost will be fixed sooner rather than later.
And this rate of improvement is in no small measure due to Git's
popularity. It's a self-reinforcing cycle.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Tue Mar 20 2012, Nathan Ridge <zeratul976-AT-hotmail.com> wrote:
>> Nathan Ridge wrote:
>> > > > You're kidding right? If not - let's switch Boost to Java - it's
>> > > > way more popular!
>> > >
>> > > As a first step, boost could provide Java bindings similar to the
>
>> > > existing python bindings. Anyone?
>> >
>> > What purpose would that serve? A lot of Boost's functionality is
>> > covered by the Java
>> > standard library, and for the rest, the concepts don't map well to Java
>> > (try writing Java bindings to MPL...).
>>
>> But wouldn't your arguments apply to the existing python bindings in the same way?
>>
>> Anyway, that suggestion wasn't meant too serious. (More precisely, I
>> know too little about this subject for being able to judge whether
>> this suggestion could make sense or not.)
>
> I confess, I do not know anything about the existing python bindings. I'm
> aware of a library called Boost.Python, but my understanding is that this
> is a library for creating python bindings to any C++ library, rather than
> being python bindings for Boost itself. Could you provide a link to the
> existing python bindings?
Several Boost libraries have Python bindings in Boost using
Boost.Python. IIRC, MPI, MultiArray, and Graph are examples.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Philippe Vaucher
> Well, according to https://github.com/bogolisk/egg/commits/master, egg
> hasn't been changed
> in 3 years, while https://github.com/magit/magit/commits/master shows
> that magit is still quite actively maintained.
>
FYI, The "up to date" egg page is at
https://github.com/byplayer/egg/commits/master
Philippe
Beren Minor
that the initial question is just another dead-end question, like VI
vs Emacs.
The scope is reduced here to Mercurial vs Git, but why? There are so
many more alternatives to these two tools, Bazaar, Veracity, Monotone,
Fossil... Why not considering and arguing on these tools as well?
The answer is very simple: nobody will never be able to make up an
objective argumentation in favor of one of these tools (or at least an
argumentation that everybody agree on). There will always be some
people preferring one against the other, and giving very valid points
in favor of it.
I think this is just a choice that has to be done, and that can't be
done in an objective way. In my opinion, the only thing that matters
here, is not how hard it is to use the tool, because none of them are
hard to use (seriously, it's just a matter of getting used to it) and
because this will depend on individuals and how hard people try to
understand how the tool works and what previous tools they were used
to (coming from svn or from p4, etc...). The only thing that really
matters is how easy it is for developers (old or potentially new to
Boost) to find information, help or training about the tool, and how
easy it integrates with any system. This is what tool popularity and
marketshare reflects (2.300k results for "Git Version Control" vs 600k
for "Mercurial Version Control" on Google).
Regarding new developers, I would give my point of view as being part
of this category: I'm not a Boost contributor, but I like to checkout
open-source projects sources, and to build them from scratch. Having
Boost running mercurial would certainly be a pain, because I don't
have mercurial installed and I feel already tired of having to install
another software to fetch Boost sources. For all open-source projects
I'm following, none use mercurial, and more than half use Git,
therefore I've got Git installed and I know how to use it (and I've
got SVN for the other half). If Mercurial was more used/popular than
Git, then I would have it instead of Git, and I would have learned to
use it. It's not the case.
My 2¢.
--
Beren Minor
Dave Abrahams
on Tue Mar 20 2012, Philippe Vaucher <philippe.vaucher-AT-gmail.com> wrote:
> On Tue, Mar 20, 2012 at 10:13 AM, Dave Abrahams <da...@boostpro.com> wrote:
>
>> Well, according to https://github.com/bogolisk/egg/commits/master, egg
>> hasn't been changed
>> in 3 years, while https://github.com/magit/magit/commits/master shows
>> that magit is still quite actively maintained.
>>
>
> FYI, The "up to date" egg page is at
> https://github.com/byplayer/egg/commits/master
Oh. Wow, well it's prettier than Magit in some ways, I'll give it
that. It's too bad the projects have diverged so much, though. My
Magit instincts don't translate very well to egg, and the keybindings
are no longer identical.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Sergiu Dotenco
> I think this is just a choice that has to be done, and that can't be
> done in an objective way. In my opinion, the only thing that matters
> here, is not how hard it is to use the tool, because none of them are
> hard to use (seriously, it's just a matter of getting used to it) and
> because this will depend on individuals and how hard people try to
> understand how the tool works and what previous tools they were used
> to (coming from svn or from p4, etc...). The only thing that really
> matters is how easy it is for developers (old or potentially new to
> Boost) to find information, help or training about the tool, and how
> easy it integrates with any system. This is what tool popularity and
> marketshare reflects (2.300k results for "Git Version Control" vs 600k
> for "Mercurial Version Control" on Google).
The interpretation of Google hits as a popularity measure is very bold.
The results you're mentioning can also suggest that Git users are more
likely to require additional support. In previous comments, which you
haven't read, it has been pointed out that the perceivable market share
does not correlate with how well a tool integrates with a system. This
is especially true when comparing Git and Mercurial.
Dave Abrahams
on Tue Mar 20 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
> I must admit I haven't read every comment on this topic but I think
> that the initial question is just another dead-end question, like VI
> vs Emacs.
>
> The scope is reduced here to Mercurial vs Git, but why? There are so
> many more alternatives to these two tools, Bazaar, Veracity, Monotone,
> Fossil... Why not considering and arguing on these tools as well?
>
> The answer is very simple: nobody will never be able to make up an
> objective argumentation in favor of one of these tools (or at least an
> argumentation that everybody agree on). There will always be some
> people preferring one against the other, and giving very valid points
> in favor of it.
That's right. As Eric wrote, it comes down (at least in part) to who's
willing to do the work. So far, those people chose Git.
> I think this is just a choice that has to be done, and that can't be
> done in an objective way.
> In my opinion, the only thing that matters here, is not how hard it is
> to use the tool, because none of them are hard to use (seriously, it's
> just a matter of getting used to it) and because this will depend on
> individuals and how hard people try to understand how the tool works
> and what previous tools they were used to (coming from svn or from p4,
> etc...). The only thing that really matters is how easy it is for
> developers (old or potentially new to Boost) to find information, help
> or training about the tool, and how easy it integrates with any
> system. This is what tool popularity and marketshare reflects (2.300k
> results for "Git Version Control" vs 600k for "Mercurial Version
> Control" on Google).
Also right. Of course, as I'm sure you'll acknowledge, different things
matter to other people.
> Regarding new developers, I would give my point of view as being part
> of this category: I'm not a Boost contributor, but I like to checkout
> open-source projects sources, and to build them from scratch. Having
> Boost running mercurial would certainly be a pain, because I don't
> have mercurial installed and I feel already tired of having to install
> another software to fetch Boost sources. For all open-source projects
> I'm following, none use mercurial, and more than half use Git,
> therefore I've got Git installed and I know how to use it (and I've
> got SVN for the other half). If Mercurial was more used/popular than
> Git, then I would have it instead of Git, and I would have learned to
> use it. It's not the case.
Spot-on again.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Beren Minor
Let's compare open-source projects on Ohloh then instead of Google if
you like it more http://www.ohloh.net/repositories/compare, but's it's
not what I wanted to point out. As I said, I won't be able to provide
any argument convincing everyone anyway.
--
Beren Minor
Philippe Vaucher
> > FYI, The "up to date" egg page is at
> > https://github.com/byplayer/egg/commits/master
>
> Oh. Wow, well it's prettier than Magit in some ways, I'll give it
> that. It's too bad the projects have diverged so much, though. My
> Magit instincts don't translate very well to egg, and the keybindings
> are no longer identical.
I have trouble deciding between the two. Egg has a nice recapitulation of
the available keybindings, but magit seems a bit more popular... also it's
hard to find the differences between the two projects. Well, we're offtopic
now :)
Philippe
Bruno Santos
I wasn't referring to mercurial, I was referring to the history. So you're are well aware of how history works you don't mess up things like Anthony exemplified.
I don't what to edit shared history, I want to edit what's not shared or even deleted it.
The fact is mercurial resembles to much of svn. I didn't appreciate svn, I always regard it a very poor thing and I hated it when working with teams.
When git come out finally had something that was really nice: branching and merging become useful and amazing.
The branching model in mercurial is very poor, the multiple heads concept is just stupid. I like to treat branches as individual entities.
And worst part is mercurial forces you and doesn't give any other choice. Why would I want to use a tool that forces me to such idiocracies?
And it becomes really frustrating was you become a more advance user. The mercurial mentality reminds of the same mentality of managed languages.
Julian Gonggrijp
important arguments are overlooked while other, less important
arguments are being exaggerated.
Thomas Heller wrote:
> Let me try to wrap my head around all this...
> So essentially, the argument is to choose git over whatever is because of its marketshare, right?
I don't think this is the only argument, but you do agree that
marketshare can make a difference, right?
> The only reason behind this i can think of is to attract new boost contributors [...]
> Ok, I can see that as a possible advantage for git. Especially since a lot of people expressed themselves that svn is _the_ major blocker for not contributing.
> So far so good, this is the argument for people already familiar with git. Let's check the statistics again:
> https://github.com/languages
> Right ... so many potential new developers ... Maybe we should provide Javascript bindings ...
This is a false comparison. The first line on boost.org is literally
"Boost provides free peer-reviewed portable C++ source libraries".
So it's not among the goals of Boost to provide Java, JavaScript or
even Intercal bindings. Using any kind of VCS, on the other hand, is
a means to the end of producing free peer-reviewed portable C++
source libraries.
> So, what about persons who are infected by their favorite poison and have to learn the VCS tool of choice. I keep reading about git having a steep learning curve, so maybe we won't attract those developers either ...
I really don't see why there's such a fuss about git having a steep
learning curve. Basic usage of git isn't any harder than basic usage
of svn -- or probably any other VCS; you always need to cover about
eight commands, two configuration files and a bunch of options.
People tend to learn only basic usage at first (whatever VCS they're
learning) and the more advanced stuff is only covered when we feel we
need it. Perhaps the learning curve is steep if you want to become a
black belt git master, but that's irrelevant for most Boost
developers.
Basic usage of git is different from basic usage of svn in some
crucial aspects, but similar enough for anyone to be able to adjust
even if you don't like it. It can definitely be learnt within a day.
Why don't you just give it a try? It never hurts to learn something
new.
> I'd argue that writing code is not done in the VCS. Be it writing a patch for an existing software or a completely new library. The complexity is in writing the code itself. Or applying the patch and verify it.
I think I'm missing your point here. Is it just an aside, or did you
mean to argue for or against a particular VCS?
> FWIW, I am the last person who will oppose such a change.
> But currently, noone presented a fair reasoning in favor for git,
Well, allow me to present some fair reasoning to you.
With regard to git versus svn: I think enough fair reasons have been
given why git (or a DVCS in general) is better than svn. I'm not
going to repeat those arguments here.
With regard to git versus mercurial: given that it's probably a good
idea to switch to a DVCS, git and mercurial seem to be the primary
candidates. I think everyone in this thread should be more willing to
admit that they're close competitors. In many ways they're about
equally "good", and when they aren't the differences are quite moot:
- mercurial has native support for Windows, but git is also fairly
well supported on Windows and seems to be rapidly improving;
- git allows you to edit history while mercurial doesn't, but which
you like better is a matter of preference;
- they seem to treat heads and branches differently, but again that
appears to be mostly a matter of preference;
- git seems to be more "powerful" and less susceptible to errors,
while mercurial is said to have better documentation -- while this
doesn't make either objectively better than the other in the first
place, they're also both catching up on their weaker side;
- they are built with very different architectures (many executables
written in C versus a monolithic program in Python), but in the end
both work well enough and both seem extensible enough for most
purposes.
At this point one could say that it doesn't matter whether we pick
git or mercurial, as long as we actually do it and move away from svn
(preferably as soon as possible). However, as far as popularity and
enthousiasm is concerned git seems to win:
- Within the existing Boost community, git seems to be more popular
than mercurial. I've seen several library proposals pass by that
were versioned with git. I'm also sure that at least one existing
Boost library is being maintained in a GitHub repository. AFAICT
mercurial scores a solid zero on both of those.
- A lot of work has already been done in order to transition Boost
from svn to git. From what I read in the "neglected aspects"
thread, John Wiegley's subconvert tool seems to be almost ready and
that also seems to be the last (only?) thing we need in order to
switch. For mercurial no work has been done yet.
- Git is also more popular than mercurial outside Boost. Like it or
not, this simply means that git is a better bet.
> or how such a transition could be done.
To me, that doesn't seem like a hard problem. With some more thought
one could probably produce a more robust plan, but basically I think
it would be something like this:
1. Finish the subconvert tool.
2. Verify that everything builds and that all unit tests run as
expected.
3. Give library maintainers a grace period in which they can switch
development from svn to git. Keep syncing with subconvert in the
meanwhile.
4. Once all libraries have transitioned, we can probably establish
that the switch was successful and abandon the svn repository.
> [...] Somehow people tend to forget in their Git crusade that other people didn't go through the transition yet, and are searching for arguments to actually make such a change.
Here's an argument for just learning the basics of git: most people
who tried both svn and git seem to agree that git is sufficiently
better than svn to make the switch. Surely you want to have a look?
I recommend that you try the tutorial at http://gitimmersion.com/ .
It doesn't have to take much of your time.
-Julian
Christopher Jefferson
On 20 Mar 2012, at 11:03, Julian Gonggrijp wrote:
I feel two points from this email are the most important ones:
>
> - Within the existing Boost community, git seems to be more popular
> than mercurial. I've seen several library proposals pass by that
> were versioned with git. I'm also sure that at least one existing
> Boost library is being maintained in a GitHub repository. AFAICT
> mercurial scores a solid zero on both of those.
> - A lot of work has already been done in order to transition Boost
> from svn to git. From what I read in the "neglected aspects"
> thread, John Wiegley's subconvert tool seems to be almost ready and
> that also seems to be the last (only?) thing we need in order to
> switch. For mercurial no work has been done yet.
At the end of the day, no-one is paid to work on boost, and the people who are willing to put the work in all want to use git. Unless mercurial fans are willing to put serious work into building the infrastructure required for boost, then the idea is a non-starter.
Having used both git and mercurial extensively, I believe the differences in practice to boost of which was chosen would be minimal. They both accomplish broadly the same goals in broadly the same way.
Chris
Bronek Kozicki
> On 3/20/2012 2:41 AM, Bruno Santos wrote:
>> I don't think mercurial is simpler to use. It just makes it harder
>> to edit history, which is only advantageous for someone completely
>> clueless about it.
>
> You think? How about sticking to the facts? Moreover, why would you
> even want to edit already shared history? Seems like there are much
> more clueless Git users who are not able to handle the tool in the
> first place.
"already shared" is implied and unnecessary. If you remove this bit,
editing history in git starts to make perfect sense.
When you want history to be readable and logical to other contributors,
you will likely want to use "git rebase -i" to tidy up or roll up your
*local* commits *before* you share them with others. It is your private
repository and private changes, until you share it.
This enables tight private iteration loop while keeping the noise off
public repository. Eg. you can do commit small change, run test, commit
more changes, run more tests, to eventually find out that the first
change had a fatal bug. Edit first commit, add necessary comment, rinse
and repeat as necessary. When done and tested, roll up your commits and
share with others.
Just an example of style really, the important point is that your
development style will not create unnecessary commits in shared
repository. Well at least this is my experience from using git, and it
seems to work well for my (very distributed) team.
B.
Bronek Kozicki
> Here's an argument for just learning the basics of git: most people
> who tried both svn and git seem to agree that git is sufficiently
> better than svn to make the switch. Surely you want to have a look?
>
> I recommend that you try the tutorial at http://gitimmersion.com/ .
> It doesn't have to take much of your time.
I personally recommend this book: http://progit.org/book/ (paid &
printed version available for those who want to support the author) .
There is also quite useful blog on the same site.
B.
Thomas Heller
<snip>
> Basic usage of git is different from basic usage of svn in some
> crucial aspects, but similar enough for anyone to be able to adjust
> even if you don't like it. It can definitely be learnt within a day.
> Why don't you just give it a try? It never hurts to learn something
> new.
*SIGH* you keep assuming that i never tried git. My last adventure with
trying to use git was around half a year ago. I still have nightmares
from that.
>> I'd argue that writing code is not done in the VCS. Be it writing a patch for an existing software or a completely new library. The complexity is in writing the code itself. Or applying the patch and verify it.
>
> I think I'm missing your point here. Is it just an aside, or did you
> mean to argue for or against a particular VCS?
No, I was trying to show how nonsensical the argument is that more
patches get applied when switching to git or any other VCS, be it
centralized or not. Maybe switching to a DCVS might increase the
quantity of contributions. quantity != quality. And that is what i
personally fear most. Tons of low quality "forks" sprouting out of the
ground.
But really, the complexity of maintaining a boost library lies not in
the version control system. With that being said, I am ready to admit
that something like git might improve the handling of patches etc. but
it should be clear that this is totally unrelated to actually applying
and verifying those patches.
>> FWIW, I am the last person who will oppose such a change.
*Nuff said*.
Neal Becker
> On 19/03/12 15:02, Daryle Walker wrote:
>>
>> Git has a competitor called Mercurial? If we're moving to a Distributed-VCS,
>> should we go to Mercurial instead of Git?
>> They're kind-of like CVS vs. Subversion, except I think they came up in
>> parallel. (While Subversion was designed as an updated CVS.)
>
> It's not at all like CVS vs Subversion, in part for the reason you
> mentioned...
>
>
>> I think Git was made up of a bunch of script hacks, while Mercurial was a
>> regimented single program.
>
> That is incorrect.
> It's simply following the UNIX philosophy.
>
>
>> I don't have a preference, but I want to make sure we consider the rival
>> options.
>
> How about we stop wasting time discussing this?
> It has been way too long already.
>
> Git is the most powerful versioning system today, is increasingly
> popular, and has a vibrant community around it.
> While Mercurial is comparable, Git has built-in support for more
> advanced features and is more popular in the open-source world.
>
This is unsupportable nonsense. Neither is more powerful. They are both quite
comparable. If you believe one is more 'powerful', whatever that means, I
suspect you are not looking at current information. For example, it's been
quite some time since hg supported rebase.
Oliver Kullmann
> On 03/20/2012 12:03 PM, Julian Gonggrijp wrote:
> <snip>
> >Basic usage of git is different from basic usage of svn in some
> >crucial aspects, but similar enough for anyone to be able to adjust
> >even if you don't like it. It can definitely be learnt within a day.
> >Why don't you just give it a try? It never hurts to learn something
> >new.
>
> *SIGH* you keep assuming that i never tried git. My last adventure
> with trying to use git was around half a year ago. I still have
> nightmares from that.
>
Could you please give some example for that?
Git is so easy to learn and use, that is is possible that it could be
your "incompetence" which created your nightmares. "Incompetence"
could have many meanings, good and bad ones. But, as an outsider who
follows discussions on the Boost mailing list, what I can see in
this thread is that people arguing in favour of Git mostly use
concrete arguments, supported by apparently quite some work done
regarding the Boost-Git connection, while people arguing against it
do not seem to present arguments, but mostly only negative emotions.
Like the statement above --- where is some evidence?
I can understand that discussions get a bit heated, and then one reacts
quickly. So no need for big elaborations, only some more concrete hints
under which circumstances you applied Git, what were your expectations,
and where were your problems, so that we can better understand the
above statement.
Oliver
Julien Nitard
>
> are willing to put the work in all want to use git. Unless mercurial fans
> are willing to put serious work into building the infrastructure required
> for boost, then the idea is a non-starter.
>
This is not true. Have look at boostpro.com. Some people _are_ paid to work
on boost even though it may be indirectly.
Julien
Thomas Heller
> On Tue, Mar 20, 2012 at 12:30:31PM +0100, Thomas Heller wrote:
>> On 03/20/2012 12:03 PM, Julian Gonggrijp wrote:
>> <snip>
>>> Basic usage of git is different from basic usage of svn in some
>>> crucial aspects, but similar enough for anyone to be able to adjust
>>> even if you don't like it. It can definitely be learnt within a day.
>>> Why don't you just give it a try? It never hurts to learn something
>>> new.
>>
>> *SIGH* you keep assuming that i never tried git. My last adventure
>> with trying to use git was around half a year ago. I still have
>> nightmares from that.
>>
>
> Could you please give some example for that?
> Git is so easy to learn and use, that is is possible that it could be
> your "incompetence" which created your nightmares. "Incompetence"
> could have many meanings, good and bad ones. But, as an outsider who
> follows discussions on the Boost mailing list, what I can see in
> this thread is that people arguing in favour of Git mostly use
> concrete arguments, supported by apparently quite some work done
> regarding the Boost-Git connection, while people arguing against it
> do not seem to present arguments, but mostly only negative emotions.
> Like the statement above --- where is some evidence?
Well the evidence is hard ... but let me try to replay my experience. I
am sure, the next guy will step up and tell me that i did it totally
wrong (actually happened when i tried to collaborate on said project
using git).
So, the journey starts about a year ago or so. I decided i need to check
out this new project i heard about. I was (actually still am) very
determined to contribute to that project, so i cloned the repository,
browsed the code etc. eventually i decided to fork this project cause i
wanted to get some hacking done. That is what i did. Then life happened
and i had to postpone the work on the project.
A few months later, I got a new assignment to contribute a module for
that project. Remember, i still got that (public) fork lying around.
So i tried to get it up to date. First bummer. I don't remember which
commands i tried in which order, but merge didn't really work, and i
messed up during rebase. the result was, that i spent an entire day
trying to figure out how to get this outdated fork uptodate to start
hacking again. Also, since trying to learn this new git tool and its
cool branches and stuff, i had of course multiple local branches lying
around, never really figured how to properly maintain that (origin
branch, master fork branch, origin feature branch1, etc. ...) and
constantly pushed to the wrong branches and/or repos (luckily, I didn't
have any write rights to the repository i forked from). And not to
forget that i wanted to try some feature X from branch Y, but needed to
combine that with my feature Z on branch U.
Essentially, whenever I tried to publicly show my progress to someone, I
ended up totally confused, and in a complete local litter box of
branches, where half of them didn't really do what they were supposed to
(like remote tracking).
I needed to search the internets for how to accomplish task X that
wasn't a simple "git add" or "git commit". Asking people after i didn't
know any further lead to the answer that i shouldn't have executed
command X in the first place. D'oh, that was how i read it on the
internets ...
I am sorry, this isn't a really detailed usage story, missing all the
commands etc. that is why I wasn't clearer in the first place. To be
perfectly honest, i even forgot most of the git usage i learned back
then. I hope you can still relate a little to what I am talking about.
But yeah ... this is the memory that makes me arguing against git. Also,
it is the reason why i argue against all those "advantages" people see
over using git. I clearly fail to see them cause i miserably failed in
actually trying to use them.
My $0.02 ...
P.S.: In this case, the usage of git actually prevented me to make the
contribution i wanted to do. Nevertheless I was able to contribute a
tiny bit. But well ...
Hartmut Kaiser
> >> >
> >> > http://www.eclipse.org/org/community_survey/Eclipse_Survey_2011_Rep
> >> > ort
> >> > .pdf, page 16
> >> > http://blogs.forrester.com/application_development/2010/01/forreste
> >>
> >> Contradict what?
> >
> > Well, it contradicts your claim that 'Git is winning in the
> > marketplace', which is total nonsense if you look at the surveys (SVN
> > 50% vs. GIT 13% 'marketshare').
>
> If you read the thread carefully, you'll see I was talking about the DVCS
> marketplace (in fact, just about Git vs Mercurial), where SVN is not a
> contender.
Ahh, so it's already a done deal to switch Boost to a DVCS? I was not aware
of this. Interesting...
> Please tone down the 'tude, friend.
The fact that you were referring to DVCS only was not obvious to me, even
after rereading the thread from a-z.
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
Christof Donat
> > IMO, no. There are several reasons, but the main one is that Git is
> > winning in the marketplace.
>
> What reasons exactly?
I was using mercurial in a project a while ago. I as a command line user was
pretty happy with it, but our eclipse users where not. That may have changed,
since my experience is not really up to date. I have also worked on a git
project, but there we did not have eclipse users, so I don't know how the well
the eclipse integration works.
I could live happily with either of the two systems. From my gutt feeling I
tend to prefer git a little bit.
Christof
--
okunah gmbh Software nach Maß
Werner-Haas-Str. 8 www.okunah.de
86153 Augsburg c...@okunah.de
Registergericht Augsburg
Geschäftsführer Augsburg HRB 21896
Christof Donat UStID: DE 248 815 055
Rene Rivera
>
> on Tue Mar 20 2012, Rene Rivera<grafikrobot-AT-gmail.com> wrote:
>
>>> By contrast, if I search for "mercurial" in the AppStore, I can only use
>>> SourceTree (which works with both).
>>
>> I don't see how searching in a mobile device application store is
>> relevant. Did you mean something else?
>
> Apple's AppStore application for MacOS is for downloading MacOS
> applications. If you want to download iOS apps you need to use iTunes.
> Makes perfect sense, I know... ;-)
As a person having published games in the iPhone AppStore I know that
difference.. But the iPhone AppStore came first. Hence you can
understand my confusion. I naturally assigned the reference to the
original instead. As most people "in the know" refer to the late comer
as the "Mac AppStore".
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Julien Nitard
… Git is so easy to learn and use ...
Some stats first:
Stackoverflow.com
- git 14000 questions
- svn 11000 questions
If you consider the ratio (question / market share), git is a clear loser.
Even the people pushing for git on this ML tend to agree that it is not the
simplest in terms of usage.
Julien
Oliver Kullmann
> I can't believe you said that:
>
> … Git is so easy to learn and use ...
>
> Some stats first:
> Stackoverflow.com
> - git 14000 questions
> - svn 11000 questions
>
> If you consider the ratio (question / market share), git is a clear loser.
>
Intuitively, the above is quite clear to me: Git is the future, so
many people explore it, want to know about it. Svn is the past, not
of so much interest anymore.
And Git is also more powerful than Svn (I think that's undisputable), so
there are bound to be more question (e.g., there should be more questions
on C++ than on C).
One could make an empirical study ... (not me).
> Even the people pushing for git on this ML tend to agree that it is not the
> simplest in terms of usage.
>
I don't think that this was said: the task *is complex*, that's the point!
Git is appropriate to the task, and thus it must be complex.
The basic usage is unquestionable simple (using simple tools like
git-gui and gitk), and then comes the rest --- and who wants power has
first to practice.
If Boost would provide good recommendations (best practice) for the common
(Boost!) workflows, that would definitely be of great help, and I think
that would sort out most of the problems.
Oliver
--
Dr. Oliver Kullmann
Department of Computer Science
College of Science, Swansea University
Faraday Building, Singleton Park
Swansea SA2 8PP, UK
http://cs.swan.ac.uk/~csoliver/
Sergiu Dotenco
> I wasn't referring to mercurial, I was referring to the history. So you're are well aware of how history works you don't mess up things like Anthony exemplified.
> I don't what to edit shared history, I want to edit what's not shared or even deleted it.
>
This statement is not only wrong but actually demonstrates that you have
absolutely no idea what you are talking about.
Sergiu Dotenco
Everything you described works in Mercurial as well, probably much better.
Bronek Kozicki
You should have used rebase to refresh your repository, not merge :)
Also when things are really starting to look bad, your best help are two
commands "git reflog" and "git reset --hard" :)
B.
Oliver Kullmann
Thanks a lot!
My first thought here is: It's all about the mental concepts!
Just a little, perhaps commonly understandable, example before coming
to Git etc.: Starting with C++, I found it fascinating (especially
templates), and at the beginning it was all hard work --- but at some
point things started to flow, I got an intuitive feeling for it, and could
just "write" code (with templates). That's an example for the mental
concepts, or perhaps "mental images", mental maps, I'm referring to,
and which one needs to work (live).
Also a disclosure: I personally use Git all over the place, private projects,
software projects, university work, and I am very satisfied with it.
In the same sense, it flows, things work out (mostly) as expected, it
helps me a lot. Compared to what you describe above, I am perhaps a more
conservative user --- if I really want to use a new feature, I better create
some experimental repositories first, make experiments, until I start being
able to predict what should happen.
It has been said that Mercurial and Git aren't that different: I think in a certain
sense that's true, but then, more fundamentally, it's very misleading.
Branching and the understanding of what is "history" are such complicated concepts
(inherently!), that the differences crucially matter, make a big difference, when it comes
to the point that you want to do more complicated things, and this in a
*comfortable* way (that you (intuitively) know what you are doing).
Unfortunately in the whole literature on computing (and also mathematics; sometimes
computer science is a bit better, at least wants to do things better) little
attention is on concepts: a stream of commands / actions is shown to you,
and from that you are supposed to learn something. The Internet is great for
technical details (amazing StackOverflow and related sides), but when it comes
to greater pictures, the underlying world models, there is not much (though, again,
on StackOverflow there is some help).
It would be a great thing if Boost could come up with "best practice", mental
maps, advice and role models how to do the standard actions required to work
with Git (w.r.t. Boost).
If you really jump into the complexity of the world of SCM, which Git I believe offers you,
without careful preparations, huhuhu, if I may say, there you go and the sharks are
waiting. You can branch, stash, sub-something, remote here and there, a bit of history surgery,
and this all at once, all mixed together ...
And there are also practical problems: you mention pushing to the wrong branches ---
this can happen, and one has to develop a certain discipline to avoid that. Before
starting to work, "git status" on the command line, or rescanning with git-gui
is a must.
So, to conclude, I believe that if Boost provides workflow models, with
general explanations and examples how to do it (command-line *and* git-gui+gitk
would be great --- git-gui and gitk are such a great help, but they are overlooked
so often), for the common actions, and there is a bit of culture to sustain
these efforts, expand and improve it, then Git will be a great tool for Boost.
(There is, of course, a little devil in Git, the seduction by all these possibilities,
and a bit care is needed.)
Oliver
Hartmut Kaiser
>
> Also when things are really starting to look bad, your best help are two
> commands "git reflog" and "git reset --hard" :)
Hmm strange - I never ran into something like that with SVN, where somebody
told me 'you should have done it this way and not that way' (and yes, before
you ask, I've had quite a bit of exposure to GIT myself).
Let's face it, GIT is a usability nightmare (IMHO) and it will not enable
anything we couldn't do with SVN (or with Mercurial for that matter) if we
only wanted to (IHMO, at least I still have to see somebody giving me that
use case).
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
_______________________________________________
Bruno Santos
On 20/03/2012, at 12:59, Sergiu Dotenco wrote:
> On 20.03.2012 12:01, Bruno Santos wrote:
>> I wasn't referring to mercurial, I was referring to the history. So you're are well aware of how history works you don't mess up things like Anthony exemplified.
>> I don't what to edit shared history, I want to edit what's not shared or even deleted it.
>>
>> The fact is mercurial resembles to much of svn. [...]
>
> This statement is not only wrong but actually demonstrates that you have
> absolutely no idea what you are talking about.
There is no point in arguing with someone that only dismiss other people arguments and to that end will pick a specific sentence and disregard the rest to take it out of context.
You have yet to provided an argument/opinion in favor of mercurial. So unless you have something to say about mercurial there is no point in this discussion, I have better things to do.
Bruno Santos
On 20/03/2012, at 13:45, Hartmut Kaiser wrote:
>> You should have used rebase to refresh your repository, not merge :)
>>
>> Also when things are really starting to look bad, your best help are two
>> commands "git reflog" and "git reset --hard" :)
>
> Hmm strange - I never ran into something like that with SVN, where somebody
> told me 'you should have done it this way and not that way' (and yes, before
> you ask, I've had quite a bit of exposure to GIT myself).
>
> Let's face it, GIT is a usability nightmare (IMHO) and it will not enable
> anything we couldn't do with SVN (or with Mercurial for that matter) if we
> only wanted to (IHMO, at least I still have to see somebody giving me that
> use case).
And SVN is nightmare for team work. Thats how I started to hate it.
The simple fact that you can't commit before an update is a complete nightmare and production killer.
Not to mention the nightmare of having to resolve conflicts before you could commit.
With git i can commit, commit, commit… and at the end day push it to central repo and solve conflicts in one go if necessary,
and if a screw up I have the complete history of change sets.
SVN is very poor in this regards, before git come out I had to resort to bash scripts and patch files to overcome svn limitations.
Sergiu Dotenco
>
> On 20/03/2012, at 12:59, Sergiu Dotenco wrote:
>
>> On 20.03.2012 12:01, Bruno Santos wrote:
>>> I wasn't referring to mercurial, I was referring to the history. So you're are well aware of how history works you don't mess up things like Anthony exemplified.
>>> I don't what to edit shared history, I want to edit what's not shared or even deleted it.
>>>
>>> The fact is mercurial resembles to much of svn. [...]
>>
>> This statement is not only wrong but actually demonstrates that you have
>> absolutely no idea what you are talking about.
>
> There is no point in arguing with someone that only dismiss other people arguments and to that end will pick a specific sentence and disregard the rest to take it out of context.
You didn't provide any valid arguments, only self-proclaimed facts.
Unless I'm missing something, there's also no specific context.
> You have yet to provided an argument/opinion in favor of mercurial. So unless you have something to say about mercurial there is no point in this discussion, I have better things to do.
_______________________________________________
Hartmut Kaiser
> >> You should have used rebase to refresh your repository, not merge :)
> >>
> >> Also when things are really starting to look bad, your best help are
> >> two commands "git reflog" and "git reset --hard" :)
> >
> > Hmm strange - I never ran into something like that with SVN, where
> > somebody told me 'you should have done it this way and not that way'
> > (and yes, before you ask, I've had quite a bit of exposure to GIT
> myself).
> >
> > Let's face it, GIT is a usability nightmare (IMHO) and it will not
> > enable anything we couldn't do with SVN (or with Mercurial for that
> > matter) if we only wanted to (IHMO, at least I still have to see
> > somebody giving me that use case).
>
> convincing arguments for you, I don't know what will.
Nobody has shown to me that SVN is not capable of doing this - or Mercurial
or ...put your favorite VCS name here...
If the community decides we need to switch, then GIT is definitely the worst
possible choice in terms of usability, code quality, error messages,
robustness, user friendliness, etc. Again, all of this IMHO.
> Yes you have to
> learn git in order to use it efficiently, just as you once learned basics
> of version control. Some of these basics no longer apply when you switch
> to DVCS and whilst some tools (e.g. hg) try to follow old habits, such
> approach brings its own idiosyncrasies (many heads to branch).
Sure. The question is whether you need to switch in the first place.
> Anyway I'm not going to try to convince anybody. There are people doing
> the work to ensure future scalability of boost version control, I'm
> grateful for that and not going to stifle the effort. There will be always
> people complaining about necessity to unlearn old habits and learn new
> tools, but I think in this case it's just this: necessity. I believe boost
> code base simply won't scale without better version control.
Your implicit assumptions related to my 'unwillingness' to learn new things
are wrong and I don't know where you got those from.
Dave Abrahams
on Tue Mar 20 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
>> When you want history to be readable and logical to other contributors,
>> you will likely want to use "git rebase -i" to tidy up or roll up your
>> *local* commits *before* you share them with others. It is your private
>> repository and private changes, until you share it.
>>
>> This enables tight private iteration loop while keeping the noise off
>> public repository. Eg. you can do commit small change, run test, commit
>> more changes, run more tests, to eventually find out that the first
>> change had a fatal bug. Edit first commit, add necessary comment, rinse
>> and repeat as necessary. When done and tested, roll up your commits and
>> share with others.
>>
>> Just an example of style really, the important point is that your
>> development style will not create unnecessary commits in shared
>> repository. Well at least this is my experience from using git, and it
>> seems to work well for my (very distributed) team.
>
> Everything you described works in Mercurial as well, probably much better.
For what it's worth, I found history rewriting to be quite a bit more
difficult in Mercurial than in Git. I don't know why; it may be that I
never learned the magic incantation that made it easy. Like I said,
these stories exist in both directions.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Tue Mar 20 2012, Sergiu Dotenco <sergiu.dotenco-AT-gmail.com> wrote:
> On 20.03.2012 12:01, Bruno Santos wrote:
>> I wasn't referring to mercurial, I was referring to the history. So
>> you're are well aware of how history works you don't mess up things
>> like Anthony exemplified.
>> I don't what to edit shared history, I want to edit what's not shared or even deleted it.
>>
>> The fact is mercurial resembles to much of svn. [...]
>
> This statement is not only wrong but actually demonstrates that you have
> absolutely no idea what you are talking about.
People, please. I don't mean to pick on Sergiu specifically---it's just
an example---but this discussion has become needlessly heated. Please
exercise some restraint.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Thomas Heller
>
> on Tue Mar 20 2012, Sergiu Dotenco<sergiu.dotenco-AT-gmail.com> wrote:
>
>>> When you want history to be readable and logical to other contributors,
>>> you will likely want to use "git rebase -i" to tidy up or roll up your
>>> *local* commits *before* you share them with others. It is your private
>>> repository and private changes, until you share it.
>>>
>>> This enables tight private iteration loop while keeping the noise off
>>> public repository. Eg. you can do commit small change, run test, commit
>>> more changes, run more tests, to eventually find out that the first
>>> change had a fatal bug. Edit first commit, add necessary comment, rinse
>>> and repeat as necessary. When done and tested, roll up your commits and
>>> share with others.
>>>
>>> Just an example of style really, the important point is that your
>>> development style will not create unnecessary commits in shared
>>> repository. Well at least this is my experience from using git, and it
>>> seems to work well for my (very distributed) team.
>>
>> Everything you described works in Mercurial as well, probably much better.
>
> For what it's worth, I found history rewriting to be quite a bit more
> difficult in Mercurial than in Git. I don't know why; it may be that I
> never learned the magic incantation that made it easy. Like I said,
> these stories exist in both directions.
I am curios now ... I get the feeling that history rewriting is one of
the git killer features. Can someone enlighten me what the fuss is
about? What is the usecase?
Philippe Vaucher
> Nobody has shown to me that SVN is not capable of doing this - or Mercurial
> or ...put your favorite VCS name here...
>
Here is a (simple innacurate) list of what a DCVS can do that a VCS usually
cannot do:
1. commit when you don't have a working internet connection
2. see the diffs between two very old revisions without a working
internet connection
3. don't wait 5-10 seconds to see the diffs between old revisions
because of the internet latency
4. use branches and merge them without fear of making mistakes (because
you can simply undo what you did before pushing to the remote)
About the two first point, if you suggest that you can do it with svn by
setting up your own local svn server and do a deep copy of the svn server
and then using that one to commit/view diffs when you don't have a working
internet connection this is just too much work compared to a DCVS for it to
be a real alternative.
Point 1 & 2 are more important than you think, it frees people to hack &
work on the project without bothering others on the central repo. They can
hack & throw away changes and only present stuffs when it's ready (because
you can throw away unpushed commits).
Point 3 is not crucial but in the long run it's very nice to have, now when
I switch back to projects using SVN I get frustrated having to wait.
Point 4 is the real important point here imho.
My 0.02$
Philippe
Philippe Vaucher
> I am curios now ... I get the feeling that history rewriting is one of the
> git killer features. Can someone enlighten me what the fuss is about? What
> is the usecase?
>
http://sethrobertson.github.com/GitBestPractices/#sausage
Basically, it allows developpers to polish their commits before pushing so
the repository history looks very clean. No more "oops commits".
Very often in projects even with the best intentions you eventually do a
mistake and realise that this commits should have been appended to a
previous (unpushed) one, or that the commit message is innacurate, or
whatever. The hability to rewrite those commits without fear of losing
changes if you know the basics of getting out of trouble with git
(reflog+reset)) produces nice repository histories where it's much easier
to pick up on a new project aftwerwards.
Philippe
Bronek Kozicki
>>
>> Also when things are really starting to look bad, your best help are two
>> commands "git reflog" and "git reset --hard" :)
>
> Hmm strange - I never ran into something like that with SVN, where somebody
> told me 'you should have done it this way and not that way' (and yes, before
> you ask, I've had quite a bit of exposure to GIT myself).
>
> Let's face it, GIT is a usability nightmare (IMHO) and it will not enable
> anything we couldn't do with SVN (or with Mercurial for that matter) if we
> only wanted to (IHMO, at least I still have to see somebody giving me that
> use case).
If ability to do distributed development and scalability are not
convincing arguments for you, I don't know what will. Yes you have to
learn git in order to use it efficiently, just as you once learned
basics of version control. Some of these basics no longer apply when you
switch to DVCS and whilst some tools (e.g. hg) try to follow old habits,
such approach brings its own idiosyncrasies (many heads to branch).
Anyway I'm not going to try to convince anybody. There are people doing
the work to ensure future scalability of boost version control, I'm
grateful for that and not going to stifle the effort. There will be
always people complaining about necessity to unlearn old habits and
learn new tools, but I think in this case it's just this: necessity. I
believe boost code base simply won't scale without better version control.
B.
Neal Becker
This is one of the discrimators between git and hg. git encourages the use of
rebase (at least, it does socially). hg discourages it (but it is possible).
There are arguments that rebase is dangerous, and that a different workflow is
preferrable.
Dave Abrahams
It's primarily about presenting a logical series of changes to the world
without exposing distracting hiccups like fixes for typos and bugs,
decisions to try a different approach in one part of your new material,
etc. Rebasing in particular (a special case of history rewriting) is
useful for removing merge commits, presenting a linear history, and
making it easier for upstream maintainers to evaluate your changes.
After rebasing your series of changes on the latest upstream work
(during which process you resolve any conflicts that arise) you have
incorporated upstream work and are left with a clean set of changes on
top of it.
I believe sophisticated branch management tools like topgit may rely on
this capability, but I admit that I'm not 100% sure.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Julian Gonggrijp
> *SIGH* you keep assuming that i never tried git. My last adventure with trying to use git was around half a year ago. I still have nightmares from that.
I'm sorry, I thought you didn't try it because you said you didn't go
through the transition yet and that you were searching for arguments
to make such a change. My (naieve) assumption was that if you'd tried
it you'd at least know about the arguments and either agree or
disagree with them, but either way you wouldn't be searching for the
arguments anymore.
The description of your nightmare in your next post was very
illuminating, thank you for that.
> [...] Maybe switching to a DCVS might increase the quantity of contributions. quantity != quality.
I couldn't agree more. Though quantity can be good too, as long as
the quality doesn't go down. That seems to be mostly a matter of
peer-review.
> [...] With that being said, I am ready to admit that something like git might improve the handling of patches etc. but it should be clear that this is totally unrelated to actually applying and verifying those patches.
How is handling patches not related to applying and verifying
patches?
>>> FWIW, I am the last person who will oppose such a change.
>
> *Nuff said*.
Alright, I get your point.
-Julian
Bronek Kozicki
>> If ability to do distributed development and scalability are not
>> convincing arguments for you, I don't know what will.
>
> Nobody has shown to me that SVN is not capable of doing this - or Mercurial
> or ...put your favorite VCS name here...
I think points of distributed development (fast or offline work, freedom
to experiment) have been already expressed in this thread. As for
performance, hope you will trust http://git-scm.com/about (since I can't
be bothered to find benchmarks for you).
> Sure. The question is whether you need to switch in the first place.
I believe we do, and base this on trust I place on Dave's judgment on
this. He knows the pains of maintaining existing boostcode base, just as
many of us know pains of maintaining any large codebase in a central
source control repository.
>> Anyway I'm not going to try to convince anybody. There are people doing
>> the work to ensure future scalability of boost version control, I'm
>> grateful for that and not going to stifle the effort. There will be always
>> people complaining about necessity to unlearn old habits and learn new
>> tools, but I think in this case it's just this: necessity. I believe boost
>> code base simply won't scale without better version control.
>
> Your implicit assumptions related to my 'unwillingness' to learn new things
> are wrong and I don't know where you got those from.
Apologies if this was implied. I literally meant "people", not you.
B.
Nathan Ridge
> I was using mercurial in a project a while ago. I as a command line user was
> pretty happy with it, but our eclipse users where not. That may have changed,
> since my experience is not really up to date. I have also worked on a git
> project, but there we did not have eclipse users, so I don't know how the well
> the eclipse integration works.
There is now an eclipse plugin called eGit (http://www.eclipse.org/egit/) that
integrates git support into eclipse. In fact, one of the major eclipse plugins
(CDT, the C++ Development Tools) has recently transitioned from using CVS
to using eGit.
Regards,
Nate
Christof Donat
> > I was using mercurial in a project a while ago. I as a command line user
> > was pretty happy with it, but our eclipse users where not. That may
> > have changed, since my experience is not really up to date. I have also
> > worked on a git project, but there we did not have eclipse users, so I
> > don't know how the well the eclipse integration works.
>
> There is now an eclipse plugin called eGit (http://www.eclipse.org/egit/)
Yes, back then there was also a mercurial plugin, which I don't think has gone
now. It is not about the existence of such a plugin but about its quality.
Maybe some eclipse users around here (and of course those using other IDEs)
can test either plugin and report about the quality they experience.
For me as a CLI user git as well as mercurial are fine.
Christof
--
okunah gmbh Software nach Maß
Werner-Haas-Str. 8 www.okunah.de
86153 Augsburg c...@okunah.de
Registergericht Augsburg
Geschäftsführer Augsburg HRB 21896
Christof Donat UStID: DE 248 815 055
_______________________________________________
Nathan Ridge
> > > I was using mercurial in a project a while ago. I as a command line user
> > > was pretty happy with it, but our eclipse users where not. That may
> > > have changed, since my experience is not really up to date. I have also
> > > worked on a git project, but there we did not have eclipse users, so I
> > > don't know how the well the eclipse integration works.
> >
> > There is now an eclipse plugin called eGit (http://www.eclipse.org/egit/)
>
> Yes, back then there was also a mercurial plugin, which I don't think has gone
> now. It is not about the existence of such a plugin but about its quality.
> Maybe some eclipse users around here (and of course those using other IDEs)
> can test either plugin and report about the quality they experience.
This is why I mentioned that a major eclipse project (CDT) has adopted eGit.
I think that's an indication of good quality.
Regards,
Nate
Topher Cooper
> Nobody has shown to me that SVN is not capable of doing this - or Mercurial
> or ...put your favorite VCS name here...
>
this was too bizarre to go past.
As is usual with "Turing equivalency" statements it is irrelevant in
practice. Yes, everything that is done in C++ can be done in C, or in
Basic, or in JavaScript, or in Cobol, or in Assembly, or on a Turing
machine with I/O added. But that doesn't make those alternatives a
convenient or even practical replacement for C++ in all cases.
Similarly, there is nothing that any version control system does that
cannot be done with a network file server. The question is not what any
of them *can* do its how convenient, pleasant, reliable and efficient it
is to do what is needed with each of them (I include the learning curve
issue under "convenient").
I'm really quite agnostic on the issue -- the limited amount of
experience I have with git does not weigh heavily against learning
Mercurial from scratch. So far, though, there really has not been a
single substantive argument that I can remember being made for Mercurial
-- only *against* git, apparently based on atypical personal experience
including the blunder of trying to pick up use of a tool never mastered
after several months without the elementary precaution of copying the
local repository first. (Coincidentally, I was in pretty much the same
situation only a few days ago. An old client using git to distribute to
Heroku asked me to add some patches. Since I had some tests and tools
in there I updated my old repository rather than cloning a new one --
after backing it up for safety, which is just a matter of copying the
top directory). Note that this would not be an option with a
non-distributed VCS like svn -- the best you can do is back up your
local sandbox.
I do have sympathy for your stance given your experience, but it does
seem to be quite atypical. I have to wonder whether at least part of
the problem wasn't a poorly structured repository.
Topher Cooper
Edward Diener
... snip
>
> Well, allow me to present some fair reasoning to you.
>
> With regard to git versus svn: I think enough fair reasons have been
> given why git (or a DVCS in general) is better than svn. I'm not
> going to repeat those arguments here.
I have never heard a single technical argument, in all the endless
mentions of Git among the people riding that bandwagon, why Git is
better than SVN, or even why any DVCS is better than a centralized SCCS.
I consider this whole move to Git and/or DVCS among "hip" programmers
little more than a move to conform with what others are doing and feel
"cool".
I am perfectly willing to read well-chosen technical arguments but not
from people already sold on one side or the other. But I really despair
of anyone being able to present such arguments in the atmosphere created
by Git fanatics and DVCS fanatics. The only thing I have gotten from all
this is "I've tried it, I like it, and therefore its superior".
Feel free, anyone, to point me to a purely technical discussion,
article, whatnot, explaining the practical reasons why using a DVCS, or
Git, is more productive and more pleasurable than using a centralized
SCCS like Subversion.
David Bergman
This sounds like a "Turing Completeness" argument held by a Pascal programmer when hearing about that "cool" language called C a few decades ago.
Ask people who have extensively used both, and they will tell you. C is better. Period. Git is better.
There exists a simple litmus test for these kinds of comparisons: if a developer has used X and Y extensively and is to embark on a new venture, with no legacy or political ties enforcing one or the other; which one would he use? I am pretty certain that for X and Y being Git and SVN, the answer would dominantly be Git.
And, I am not a "cool programmer," unless you consider having developed code for 30+ years in 20 languages, commercially, cool.
/David
David Bergman
I spend around 50 hours in the air every month; yes, a full working week. I rarely have - or want - Internet access on those trips.
Git (and most other DVCSes) allows me to work revisioned, trying our various paths of development, during that working week.
Related, I like to test branches and ideas without having anyone else observing my moves or caring about what I do; so, I can do that, locally, instead of creating obscure or sacred branches in SVN in a common repository.
There are a bunch of more technical reasons why Git is superior to SVN, related to the snapshot representation of files and trees of files, and commits, instead of deltas (such as in SVN.) If a delta chain (or poset...) gets out of sync, you are kind of lost; very hard to recreate the current (or any) consistent state of files.
/David
Julien Nitard
> I spend around 50 hours in the air every month; yes, a full working week.
> I rarely have - or want - Internet access on those trips.
You are an exception. Very, very few coders travel by plane that much.
> Git (and most other DVCSes) allows me to work revisioned, trying our
> various paths of development, during that working week.
Local work is not a unique property of DVCSes. (See shelving /
checkpointing planned features in SVN 1.8).
> Related, I like to test branches and ideas without having anyone else
> observing my moves or caring about what I do; so, I can do that, locally,
> instead of creating obscure or sacred branches in SVN in a common
> repository.
>
This is a very good point. Though it is still a specific need. The VCS is
here to help the team. If individuals want to play on their own, it's only
"nice to have" IMHO and shouldn't make the other part of the process more
complex.
> There are a bunch of more technical reasons why Git is superior to SVN,
> related to the snapshot representation of files and trees of files, and
> commits, instead of deltas (such as in SVN.) If a delta chain (or poset...)
> gets out of sync, you are kind of lost; very hard to recreate the current
> (or any) consistent state of files.
>
One could argue that it takes a bug in SVN to get stuff out of sync while
it only requires a user error in git, but yes that's a valid argument. Not
as strong as you say because whether you have a SVN or git repos it would
be very stupid not to have automatic backups for it. I'd be happy to see
more details on that point.
Julien