On 5/30/2015 6:59 AM, Adrien Grand wrote: > The main benefit I see is that external contributors would get their > name in the commit log. > > However on the other hand, I'm a bit annoyed that people easily > disagree on the workflow: some people merge into the maintenance > branch first and then to master, other people merge into master first > and then cherry-pick, other people prefer rebasing instead of merging, > etc. I personally don't really care but if we agree on moving to Git, > I hope we can agree on the workflow at the same time. At least today > with svn we have something simple that everybody agrees on. > > -0: I'm not against it but Subversion works well for me today. If > everybody else agrees on switching to Git I would like us to agree on > the workflow as well.
-0 is my vote as well, as long as we take Adrien's advice about the workflow. The normal workflow must be thoroughly documented if we are going to change our version control tool. There will likely be deviations from that workflow required, and if specific deviations are required for common-but-not-entirely-normal situations, those should be documented as well. Additional TL;DR detail about my thoughts and findings below: The impression that I have gotten from watching these religious wars over version control is that subversion is superior at absolute correctness and faithful maintenance of the version history in the face of problems, while git excels when you have a very large number of people who contribute code but only a few who have write access, or for people who work on a lot of different things in different branches. My impression may not be correct, and I'm absolutely sure that reality is a lot more complex. I was not aware of the speed differences Robert noted. I conducted my own timing tests on my 7 megabit DSL connection: time git clone git://git.apache.org/lucene-solr.git test.git real 9m20.437s user 0m43.288s sys 0m12.192s time svn co https://svn.apache.org/repos/asf/lucene/dev/trunk test.svn real 2m16.505s user 0m6.794s sys 0m5.267s If I ever reach a point where I am working on multiple code trees, I expect that I will have them in separate directories because that will help me keep them straight. I gather from comments on this thread that git will let you keep them all in one repo, but I think I would get myself into trouble doing that, working on the wrong one accidentally. There is a significant (nearly two to one) size difference between the cloned git repo and an equivalent svn checkout, although to be honest, with today's typical storage sizes, this doesn't matter all that much, unless you are maintaining separate directories for multiple git code trees, as I probably would. elyograg@sauron:~/asf$ du -sm test.* 498 test.git 252 test.svn I ran "git gc --aggressive" which reduced the repo by 55MB. I do use git at work for the code that I write there, and for version control on configuration files for various server installations. Those repos are *nowhere* near as big as lucene-solr, though. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
