lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Source Control
Date Sun, 28 Oct 2012 12:38:37 GMT
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 <serera@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.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
>>> 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
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message