I don’t really buy the fad argument, but as I’ve said, I’m willing to wait a little longer for others to catch on. I try and follow the stats and reports and articles on this pretty closely.
As I mentioned early in the thread, by all appearances, the shift from SVN to GIT looks much like the shift from CVS to SVN. This was not a fad change, nor is the next mass movement likely to be. Just like no one starts a project on CVS anymore, we are almost already to the point where new projects start exclusive on GIT - especially open source. I’m happy to sit back and watch the trend continue though. The number of GIT users in the committee and among the committers only grows every time the discussion comes up. If this was 2009, 2010, 2011 … who knows, perhaps I would buy some fad argument. But it just doesn’t jive in 2014. - Mark On Jan 7, 2014, at 3:33 PM, Lajos <la...@protulae.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
