I've followed this thread with interest, and although I'm (sadly) a
lapsed Apache committer (not Lucene/Solr), I finally had to comment as
I've just gone through the pain of learning git after many happy years
with svn.
In my long experience in IT I've learned one incontrovertible fact: most
times, the technical merits of one technology over another are not
nearly as important as everyone thinks. It is really all about how WELL
you use a given technology to get the job done. The stuff I do in git
now, I could do in SVN, and vice versa. I'd wager I could do the same in
CVS or even older technologies. It like Ant versus Maven versus Gradle.
I can do the same in each of these. Each has their own good and bad
points. I'll stick with Ant and SVN to the end but hey, if a client
works only with Gradle and Git and XYZ technology and has an
intellectual investment there, I'm not gonna argue the point on
technical merits.
That being said, I think the worst argument one could make about
anything is that "we should move to it because everyone else is". People
will flock to fads as much (I could argue: more) than to genuine
technical improvements (anyone remember the 70s? 80s? 90s?). Git feels a
bit faddish to me, and is definitely immature. I get some of the
advantages, but I don't think I should have to be a gitk expert to use
the damn software - its over-engineered and actually opens up the door
to more convoluted development processes.
Whether Git is a fad or not, the issue, as pointed out below, is
supporting the way contributors work. The win-win situation would be to
keep the core based on SVN but support git contributions (as I know
someone else suggested). SVN is a technology that is stable and which
all core committers know like the back of their hands - no sense in
wasting time learning git when people are donating time and that time is
better spent on JIRAs. What I don't know is how this GIT integration
would work, but I'd hope it could be done.
Just to push home the point, I'll bet most of us who have been around a
while have plenty of stories of IT shops moving from one technology to
another ... and then in a few years to another ... and then to another -
all because some manager got a burr up his rear or was wined and dined
by a vendor. Why? Why hurt productivity for the sake of keep up with the
times? How about setting an example of sticking with what works despite
the made rush to github?
My €.02.
Lajos Moczar
On 06/01/2014 17:01, Robert Muir wrote:
On Sun, Jan 5, 2014 at 12:07 PM, Mark Miller <markrmil...@gmail.com> wrote:
My point here is not really to discuss the merits of Git VS SVN on a feature
/ interface basis. We might as well talk about MySQL vs Postgres.
Personally, I prefer GIT. It feels good when I use it. SVN feels like crap.
That doesn't make me want to move. I've used SVN for years with Lucene/Solr,
and like everyone, it's pretty much second nature.
The problem is the world is moving. It may not be clear to everyone yet, but
give it a bit more time and it will be.
Git already owns the open source world. It rivals SVN by most guesses in the
proprietary world. This is a strong hard trend. The same trend that saw SVN
eat CVS. I think clearly, a distributed version control system will
dominate. And clearly Git has won.
I'm not ready to call a vote, because I don't think it's critical we switch
yet. But I wanted to continue the discussion, as obviously, plenty of it
will be needed over time before we made such a switch.
It's not about one thing being better than the other. It's about using what
everyone else uses so you don't provide a barrier to contribution. It's
about the post I linked to when I started this thread.
I personally don't care about pull requests and Github. I don't think any of
it's features are that great, other than it acts as a central repo. Git is
not good because of Github IMO. But Git and Github are eating the world.
Most of the patches I have processed now are made against Git. Jumping from
SVN to Git and back is very annoying IMO though. There are plenty of tools
and workflows for it and they all suck.
Anyway, as the trend continues, it will become even more obvious that
Lucene/Solr will start looking stale on SVN. We have enough image problems
in terms of being modern at Apache. We will need to manage the ones we can.
We should not choose the tools that simply make us fuzzy and comfortable.
We should choose the tools that are best for the project and future
contributions in the long term.
- Mark
The idea that this has anything to do with contributors is misleading.
Today contributors can use either SVN or GIT. They have their choice.
How can it be any better than that for contributors?
As demonstrated over the weekend, its also possible today for
contributors to use svn+jira or git+pull request workflow.
As i said earlier, why not spend our time trying to make it easier on
contributors and support git/github workflows (e.g. just hashing shit
out, fixing contribution docs, making it clear we accept pull
requests, and so on).
Because after all, this whole discussion is only about what the
committers use... we should focus on the contributor first.
This is significantly less controversial (e.g. doesn't require me nor
Uwe to use overcomplicated tools with a steaming-pile-of-shit API) and
we can make real progress on it today.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
