lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Source Control
Date Sun, 28 Oct 2012 12:04:21 GMT
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.wechner@wyona.com>wrote:

> Am 28.10.12 10:57, schrieb Robert Muir:
>
>  On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
>> <michael.wechner@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<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-unsubscribe@lucene.apache.**org<dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message