I don't have stropng feelings either way. If it would allow better collaboration branch merging, etc., then sure.
I'm assuming we'd be able to do pre/post move diffs, right?. What about reformatting at that point? It'd be one of the few times when we would, I think, have all the code in the repository at once. Not insisting on this, I've actually grown used to avoiding re-formatting too much. But it'd be one of the least painful moments to reformat. Not painless, mind, but.... Erick On Sun, Oct 28, 2012 at 8:04 AM, Shai Erera <ser...@gmail.com> wrote: > What I wish we could do is to truly collaborate on these branches. For > instance, when we create a feature branch today (following an issue), then > people are free to commit changes to the branch, without worrying about > breaking the main branch or nightly builds. When it's time, the changes will > be merged to the main branch. But what we lack today is true collaboration > -- allow all those involved to commit changes to the branch, thereby > creating a healthier collaboration atmosphere. When the main people involved > are committers, this is not so felt, but if the main people involved are > non-committers, it's not so fun (to them mostly). > > Yet, I don't think that it can work otherwise, from the legal side. When > people post patches in JIRA, there's a little checkbox that they need to > tick, granting the ASF rights for this code. There's no checkbox to tick > when changes are committed (well, since committers sign an agreement with > the ASF about code rights, there's like a virtual tiny checkbox that they > tick at commit time). > > So, and without me being a lawyer or anything (!), how would that work if we > move to GIT? If we don't allow other people to commit to "feature branches", > because there might be code licensing issues, what will be the advantage of > moving to GIT? > > I'm asking because IMO if we cannot do that (let non-committers commit to > feature branches), there's no strong reason to move away from SVN. We all > know it, feel comfortable with it, and what's most important -- it does the > job that we need. > > Shai > > But throughout the development of a feature, it'd be great if we can let all > those involved to commit freely to the branch, without going through > patches. Is that possible with our current SVN setup (or can we modify it)? > Is that > > On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner <michael.wech...@wyona.com> > wrote: >> >> Am 28.10.12 10:57, schrieb Robert Muir: >> >>> On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner >>> <michael.wech...@wyona.com> wrote: >>> >>>> I also had/have quite some trouble to get used to the git commandline, >>>> although or maybe because I used SVN commandline for many years, but I >>>> am >>>> very glad now to be using git on other projects, because in particular >>>> the >>>> process in being able to do feature based branches with git helps so >>>> much, >>>> that I think it's definitely worth the price. >>>> >>> There's no one on this planet that can convince me git is technically >>> better. >> >> >> I am not talking about "technically better" (or maybe I misunderstand this >> term), but >> I am talking about "process". With git I can do the following: >> >> - Basically for every change (even in case it might just be a typo inside >> documentation) I am creating a branch (which I can a "feature" branch) >> - I can share these branches easily with other people even if they don't >> have commit/push access to the master branch and hence collaborate >> - I can merge branches easily and in particular merge the master branch >> into my feature branches, and hence keep my feature branches in sync, which >> greatly simplies merging later on into the master branch >> - I can commit stuff without having to be online, which is great when >> doing several steps on the code, e.g. >> - Commit one: Formatting changes >> - Commit two: Functional changes >> - Because of the above I can use a RTC (ReviewThenCommit) process, because >> "others" can commit to feature branches, where I can review the code changes >> and after successful review commit/push to the master branch. >> >> With SVN I couldn't do this that easily and because it wasn't easy, I >> didn't do it. But git allowed me/us to change the process and for me >> personally that is great. >> >> I think the question is what process do you want and what tool does make >> this process simple? >> >> Maybe before argueing SVN versus git you should specify how you want to >> collaborate and also specify requirements (as for example you point ou below >> about speed). Once you have a clear picture about this, then consider the >> various tools which exist. >> >> HTH >> >> Michael >> >>> I've used git on projects before. Its not that i have trouble getting >>> used to it, its command line is genuinely horrible. >>> >>> And svn is absurdly fast for me: >>> rmuir@beast:~/workspace$ time svn co >>> https://svn.apache.org/repos/asf/lucene/dev/trunk >>> real 0m23.454s >>> user 0m5.712s >>> sys 0m3.232s >>> >>> The speed of my internet connection makes git obselete. >>> >>> But if other people really like it, i won't stand in the way. >>> >>> --------------------------------------------------------------------- >>> 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
