On Wed, 10 Sep 2014 11:55:52 +0200, Luc Maisonobe wrote:
Hi Gilles,
Le 10/09/2014 11:43, Gilles a écrit :
On Wed, 10 Sep 2014 07:49:13 +0300, Silviu Burcea wrote:
This is the killer feature for Git, because many of us, the
newcomers,
like
me, will want to experiment a little before submitting a patch.
This
way, I
can create a local branch and I'm free to do whatever I want. The
SVN
branch is visible on the server, I don't want to publish my crappy
code
before I feel that the feature or the bugfix has high quality and
is
readable enough.
This use case does not convince me at all: when working on a
feature,
you always do it locally (modifying code, preparing unit tests), and
SVN certainly does not force you to experiment publicly; it's rather
the project's policy that forbids you to commit crappy code. :-)
[The advantages of "git" must be somewhere else.]
The advantages are that while doing so you do use git and all its
features (you do local commits, you do diffs between several things
you
try at home, you do branches, you do forward your changes between
several clones you may have (typically a laptop and a desktop
computer,
or a computer at work and another at home). With SVN, you only have
the
workspace, you cannot do local commits. Either your modifications are
on
the single workspace you have, or you commit them to the central
server.
This means that if you want to test several different approaches with
SVN, you end up doing copies of your workspace, which is a pity since
you do have a version control system.
You do not have to convince me that "git" can do more than
"subversion".
I am convinced; I've always been.[1] But that's not the same as feeling
that a Commons project should absolutely use it.
The "crappy code" argument is not the same as those which you
presented.
I would not mix "efficiency" arguments with principles.
Best,
Gilles
[1] So, let's tackle the next release of Commons Math, with "git",
rather
than continue a hazy discussion for the non-initiated. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
