Moving Lucene / Solr from SVN to Git

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Moving Lucene / Solr from SVN to Git

Mark Miller-3
We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

LUCENE-6937: Migrate Lucene project from SVN to Git.

INFRA-11056: Migrate Lucene project from SVN to Git.

Everyone knows about rebase and linear history right ;)

- Mark
--
Reply | Threaded
Open this post in threaded view
|

RE: Moving Lucene / Solr from SVN to Git

Uwe Schindler

Hi Mark,

 

thanks for starting this! Looking forward to the whole process. When Infra is about to “activate” the new GIT repo, I will take care of Policeman Jenkins and fix the remaining validation tasks. I don’t want to do this. I think your commit is fine.

 

We now need some workflows how to merge between master/trunk and the release branches. Projects do this in different ways (cherry-picking,…). I have no preference or idea, sorry! I only know how to merge feature branches into master J

 

You mentioned that we should make the old svn read only. Maybe do it similar like we did during LuSolr merge: Add a final commit removing everything from trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x pointing to Git. All other branches stay alive. After that we could make it read only – but it is not really needed. What do others think?

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: [hidden email]

 

From: Mark Miller [mailto:[hidden email]]
Sent: Saturday, January 09, 2016 10:55 PM
To: java-dev <[hidden email]>
Subject: Moving Lucene / Solr from SVN to Git

 

We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

 

LUCENE-6937: Migrate Lucene project from SVN to Git.

 

INFRA-11056: Migrate Lucene project from SVN to Git.

 

Everyone knows about rebase and linear history right ;)

 

- Mark

--

Reply | Threaded
Open this post in threaded view
|

RE: Moving Lucene / Solr from SVN to Git

Uwe Schindler

Sorry:

 

> … I don’t want to do this. I think your commit is fine. …

 

I want to do this – of course, but not now. After the migration! J Sorry, I was interrupted in the middle of sentence.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: [hidden email]

 

From: Uwe Schindler [mailto:[hidden email]]
Sent: Saturday, January 09, 2016 11:53 PM
To: [hidden email]
Subject: RE: Moving Lucene / Solr from SVN to Git

 

Hi Mark,

 

thanks for starting this! Looking forward to the whole process. When Infra is about to “activate” the new GIT repo, I will take care of Policeman Jenkins and fix the remaining validation tasks. I don’t want to do this. I think your commit is fine.

 

We now need some workflows how to merge between master/trunk and the release branches. Projects do this in different ways (cherry-picking,…). I have no preference or idea, sorry! I only know how to merge feature branches into master J

 

You mentioned that we should make the old svn read only. Maybe do it similar like we did during LuSolr merge: Add a final commit removing everything from trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x pointing to Git. All other branches stay alive. After that we could make it read only – but it is not really needed. What do others think?

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: [hidden email]

 

From: Mark Miller [[hidden email]]
Sent: Saturday, January 09, 2016 10:55 PM
To: java-dev <
[hidden email]>
Subject: Moving Lucene / Solr from SVN to Git

 

We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

 

LUCENE-6937: Migrate Lucene project from SVN to Git.

 

INFRA-11056: Migrate Lucene project from SVN to Git.

 

Everyone knows about rebase and linear history right ;)

 

- Mark

--

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Erick Erickson
In reply to this post by Uwe Schindler
I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or....

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:

> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Mark Miller [mailto:[hidden email]]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev <[hidden email]>
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Mark Miller-3
I think we will update much of the doc as we go, but I'm sure there are plenty of people that can help on the list with any questions. We can probably get some basics up relatively painlessly. I'd guess the number of committers that have not worked with Git yet is very small.

As a start, my recommendation would be to Google Git for SVN users and look at some of those resources though. It's probably better than what we will subset.

Personally, I like to just use SmartGit and mostly ignore command line Git :)

How have you been able to ignore GitHub for so long :)

Mark
On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]> wrote:
I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or....

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:
> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Mark Miller [mailto:[hidden email]]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev <[hidden email]>
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Prasanna Dangalla
Hi All,
I'm a new member to this project. I was reading the mails previously. Thiught leeHere if we migrate from svn its better to migrate the history as well. I meant the commit history. How do we migrate the SVN commit log from svn to git ? 

On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
I think we will update much of the doc as we go, but I'm sure there are plenty of people that can help on the list with any questions. We can probably get some basics up relatively painlessly. I'd guess the number of committers that have not worked with Git yet is very small.

As a start, my recommendation would be to Google Git for SVN users and look at some of those resources though. It's probably better than what we will subset.

Personally, I like to just use SmartGit and mostly ignore command line Git :)

How have you been able to ignore GitHub for so long :)

Mark
On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;erickerickson@gmail.com&#39;);" target="_blank">erickerickson@...> wrote:
I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or....

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;uwe@thetaphi.de&#39;);" target="_blank">uwe@...> wrote:
> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;uwe@thetaphi.de&#39;);" target="_blank">uwe@...
>
>
>
> From: Mark Miller [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;markrmiller@gmail.com&#39;);" target="_blank">markrmiller@...]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;java-dev@lucene.apache.org&#39;);" target="_blank">java-dev@...>
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dev-unsubscribe@lucene.apache.org&#39;);" target="_blank">dev-unsubscribe@...
For additional commands, e-mail: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dev-help@lucene.apache.org&#39;);" target="_blank">dev-help@...

--


--
Prasanna Dangalla
Software Engineer, WSO2, Inc.; http://wso2.com/
http://wso2.com/about/team/prasanna-dangalla
lean.enterprise.middleware

cell: +94 777 55 80 30 | +94 718 11 27 51
twitter: @prasa77

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Prasanna Dangalla


On Sunday, 10 January 2016, Prasanna Dangalla <[hidden email]> wrote:
Hi All,
I'm a new member to this project. I was reading the mails previously. Thiught leeHere if we migrate

mails previously. Thought of giving an input. Here if we migrate
Sorry for the typo... 

from svn its better to migrate the history as well. I meant the commit history. How do we migrate the SVN commit log from svn to git ? 

On Sunday, 10 January 2016, Mark Miller <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;markrmiller@gmail.com&#39;);" target="_blank">markrmiller@...> wrote:
I think we will update much of the doc as we go, but I'm sure there are plenty of people that can help on the list with any questions. We can probably get some basics up relatively painlessly. I'd guess the number of committers that have not worked with Git yet is very small.

As a start, my recommendation would be to Google Git for SVN users and look at some of those resources though. It's probably better than what we will subset.

Personally, I like to just use SmartGit and mostly ignore command line Git :)

How have you been able to ignore GitHub for so long :)

Mark
On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]> wrote:
I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or....

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:
> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Mark Miller [mailto:[hidden email]]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev <[hidden email]>
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--


--
Prasanna Dangalla
Software Engineer, WSO2, Inc.; http://wso2.com/
http://wso2.com/about/team/prasanna-dangalla
lean.enterprise.middleware

cell: +94 777 55 80 30 | +94 718 11 27 51
twitter: @prasa77



--
Prasanna Dangalla
Software Engineer, WSO2, Inc.; http://wso2.com/
http://wso2.com/about/team/prasanna-dangalla
lean.enterprise.middleware

cell: +94 777 55 80 30 | +94 718 11 27 51
twitter: @prasa77

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Erick Erickson
In reply to this post by Mark Miller-3
bq: How have you been able to ignore GitHub for so long :)

Willful ignorance and not being forced to ;)

I already have the "Git for SVN users" and similar. They're kinda
helpful but I'm still flying blind. I mean apparently "git cherry-pick
rev" is equivalent to the merge command I've been using to merge trunk
changes into 5x.

The key here is "apparently". It would be comforting to know what
others do that works in our (future) environment before taking
"somebody's blog's" word for it.

Although I guess we're all really flying blind in that so far the
people who use the Git repo still have to merge via SVN to get code
committed.

Anyway, it'll work out I'm sure.

Prasanna:

The history question has been discussed at some length, here's a place
to start reviewing what's been done so far:
https://issues.apache.org/jira/browse/LUCENE-6933

Best,
Erick

On Sat, Jan 9, 2016 at 4:40 PM, Mark Miller <[hidden email]> wrote:

> I think we will update much of the doc as we go, but I'm sure there are
> plenty of people that can help on the list with any questions. We can
> probably get some basics up relatively painlessly. I'd guess the number of
> committers that have not worked with Git yet is very small.
>
> As a start, my recommendation would be to Google Git for SVN users and look
> at some of those resources though. It's probably better than what we will
> subset.
>
> Personally, I like to just use SmartGit and mostly ignore command line Git
> :)
>
> How have you been able to ignore GitHub for so long :)
>
> Mark
> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]>
> wrote:
>>
>> I'm a little confused. A while ago I asked about whether I had to
>> learn all about Git, and as I remember the reply was "this is just
>> about the build process". Perhaps I mis-interpreted or that was
>> referring only to the bits Dawid was working on at that instant or....
>>
>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>> our commits need to happen in Git, right? There are still some "git
>> challenged" curmudgeons out there (like me) who really haven't much of
>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>> clear signal that "Now you have to figure it out because you can't
>> commit to the SVN repo any more".
>>
>> And the "how to contribute" page is all about SVN:
>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>> at all close that page needs some significant editing.
>>
>> Personally, before I screw up my first commit under Git, it would be
>> super helpful if there were a step-by-step. No doubt that really
>> amounts to three commands or something, but before "just trying stuff"
>> it would be nice to have the steps for committing (pushing?) to trunk
>> and then getting those changes into 5x (well, maybe 6.0 by then)
>> outlined...
>>
>> Or I'm off in the weeds here, always a possibility.
>>
>> FWIW,
>> Erick
>>
>>
>>
>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:
>> > Hi Mark,
>> >
>> >
>> >
>> > thanks for starting this! Looking forward to the whole process. When
>> > Infra
>> > is about to “activate” the new GIT repo, I will take care of Policeman
>> > Jenkins and fix the remaining validation tasks. I don’t want to do this.
>> > I
>> > think your commit is fine.
>> >
>> >
>> >
>> > We now need some workflows how to merge between master/trunk and the
>> > release
>> > branches. Projects do this in different ways (cherry-picking,…). I have
>> > no
>> > preference or idea, sorry! I only know how to merge feature branches
>> > into
>> > master J
>> >
>> >
>> >
>> > You mentioned that we should make the old svn read only. Maybe do it
>> > similar
>> > like we did during LuSolr merge: Add a final commit removing everything
>> > from
>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>> > pointing to Git. All other branches stay alive. After that we could make
>> > it
>> > read only – but it is not really needed. What do others think?
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -----
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: [hidden email]
>> >
>> >
>> >
>> > From: Mark Miller [mailto:[hidden email]]
>> > Sent: Saturday, January 09, 2016 10:55 PM
>> > To: java-dev <[hidden email]>
>> > Subject: Moving Lucene / Solr from SVN to Git
>> >
>> >
>> >
>> > We have done almost all of the work necessary for a move and I have
>> > filed an
>> > issue with INFRA.
>> >
>> >
>> >
>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6937
>> >
>> >
>> >
>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/INFRA-11056
>> >
>> >
>> >
>> > Everyone knows about rebase and linear history right ;)
>> >
>> >
>> >
>> > - Mark
>> >
>> > --
>> >
>> > - Mark
>> >
>> > about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Steve Davids
In reply to this post by Prasanna Dangalla
@Prasanna you can follow along with the SVN -> GIT history migration in https://issues.apache.org/jira/browse/LUCENE-6933

@Erick for some basics you can checkout these interactive git guides, either https://www.codecademy.com/learn/learn-git or http://gitreal.codeschool.com/ though as Mark said if you find a decent UI you rarely need to use the command line. I’ve been fond of IntelliJ’s git support, but I have found Eclipse’s to be absolutely terrible (egit). 

-Steve

On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla <[hidden email]> wrote:



On Sunday, 10 January 2016, Prasanna Dangalla <[hidden email]> wrote:
Hi All,
I'm a new member to this project. I was reading the mails previously. Thiught leeHere if we migrate

mails previously. Thought of giving an input. Here if we migrate
Sorry for the typo... 

from svn its better to migrate the history as well. I meant the commit history. How do we migrate the SVN commit log from svn to git ? 

On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
I think we will update much of the doc as we go, but I'm sure there are plenty of people that can help on the list with any questions. We can probably get some basics up relatively painlessly. I'd guess the number of committers that have not worked with Git yet is very small.

As a start, my recommendation would be to Google Git for SVN users and look at some of those resources though. It's probably better than what we will subset.

Personally, I like to just use SmartGit and mostly ignore command line Git :)

How have you been able to ignore GitHub for so long :)

Mark
On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]> wrote:
I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or....

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:

> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Mark Miller [mailto:[hidden email]]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev <[hidden email]>
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

-- 


-- 
Prasanna Dangalla
Software Engineer, WSO2, Inc.; http://wso2.com/
http://wso2.com/about/team/prasanna-dangalla
lean.enterprise.middleware

cell: +94 777 55 80 30 | +94 718 11 27 51
twitter: @prasa77



-- 
Prasanna Dangalla
Software Engineer, WSO2, Inc.; http://wso2.com/
http://wso2.com/about/team/prasanna-dangalla
lean.enterprise.middleware

cell: +94 777 55 80 30 | +94 718 11 27 51
twitter: @prasa77

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Dawid Weiss-2
A few unrelated answers:

1) I would remove everything from SVN, add a commit informing about
the move to git, then import all this up-to-date history into git (I
volunteer to do this) and revert the last commit (in git). This way
the history is complete, including SVN->git move.

Note this would require a few hours of stop-the-world on commits.

2. Contrary to Mark I use git command line only. And gitk (--all) to
visualize the history. git is really simple conceptually, I strongly
recommend reading this:

http://eagain.net/articles/git-for-computer-scientists/

or this, which is slightly more verbose:
http://nyuccl.org/pages/gittutorial/

Once you get the idea that everything is in git is basically a set of
"states" of blobs (files, file sets, commit info history) everything
becomes much simpler. For example a cherry pick of commit X to branch
Y is basically applying X's diff from its parent commit to the current
state of Y. It's not a merge. It's svn's equivalent of svn diff >
patch, svn switch Y, svn apply patch. A merge is applying patches from
two separate lines of development that consolidate them. If there's a
conflict you add a third patch to resolve this conflict.

We can definitely put up some beginner-level workflows, but the
understanding of what git is simplifies life greatly.

In any case, Mark -- let me know (directly or on the list) when you
need me to perform the final git conversion. Once the infra has set up
a git repo it's all about one push from github to it (--mirror) and
we're set.

Dawid



On Sun, Jan 10, 2016 at 2:16 AM, Steve Davids <[hidden email]> wrote:

> @Prasanna you can follow along with the SVN -> GIT history migration in
> https://issues.apache.org/jira/browse/LUCENE-6933
>
> @Erick for some basics you can checkout these interactive git guides, either
> https://www.codecademy.com/learn/learn-git or http://gitreal.codeschool.com/
> though as Mark said if you find a decent UI you rarely need to use the
> command line. I’ve been fond of IntelliJ’s git support, but I have found
> Eclipse’s to be absolutely terrible (egit).
>
> -Steve
>
> On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla <[hidden email]>
> wrote:
>
>
>
> On Sunday, 10 January 2016, Prasanna Dangalla <[hidden email]>
> wrote:
>>
>> Hi All,
>> I'm a new member to this project. I was reading the mails previously.
>> Thiught leeHere if we migrate
>>
>> mails previously. Thought of giving an input. Here if we migrate
>
> Sorry for the typo...
>>
>>
>> from svn its better to migrate the history as well. I meant the commit
>> history. How do we migrate the SVN commit log from svn to git ?
>>
>> On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
>>>
>>> I think we will update much of the doc as we go, but I'm sure there are
>>> plenty of people that can help on the list with any questions. We can
>>> probably get some basics up relatively painlessly. I'd guess the number of
>>> committers that have not worked with Git yet is very small.
>>>
>>> As a start, my recommendation would be to Google Git for SVN users and
>>> look at some of those resources though. It's probably better than what we
>>> will subset.
>>>
>>> Personally, I like to just use SmartGit and mostly ignore command line
>>> Git :)
>>>
>>> How have you been able to ignore GitHub for so long :)
>>>
>>> Mark
>>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]>
>>> wrote:
>>>>
>>>> I'm a little confused. A while ago I asked about whether I had to
>>>> learn all about Git, and as I remember the reply was "this is just
>>>> about the build process". Perhaps I mis-interpreted or that was
>>>> referring only to the bits Dawid was working on at that instant or....
>>>>
>>>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>>>> our commits need to happen in Git, right? There are still some "git
>>>> challenged" curmudgeons out there (like me) who really haven't much of
>>>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>>>> clear signal that "Now you have to figure it out because you can't
>>>> commit to the SVN repo any more".
>>>>
>>>> And the "how to contribute" page is all about SVN:
>>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>>>> at all close that page needs some significant editing.
>>>>
>>>> Personally, before I screw up my first commit under Git, it would be
>>>> super helpful if there were a step-by-step. No doubt that really
>>>> amounts to three commands or something, but before "just trying stuff"
>>>> it would be nice to have the steps for committing (pushing?) to trunk
>>>> and then getting those changes into 5x (well, maybe 6.0 by then)
>>>> outlined...
>>>>
>>>> Or I'm off in the weeds here, always a possibility.
>>>>
>>>> FWIW,
>>>> Erick
>>>>
>>>>
>>>>
>>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:
>>>> > Hi Mark,
>>>> >
>>>> >
>>>> >
>>>> > thanks for starting this! Looking forward to the whole process. When
>>>> > Infra
>>>> > is about to “activate” the new GIT repo, I will take care of Policeman
>>>> > Jenkins and fix the remaining validation tasks. I don’t want to do
>>>> > this. I
>>>> > think your commit is fine.
>>>> >
>>>> >
>>>> >
>>>> > We now need some workflows how to merge between master/trunk and the
>>>> > release
>>>> > branches. Projects do this in different ways (cherry-picking,…). I
>>>> > have no
>>>> > preference or idea, sorry! I only know how to merge feature branches
>>>> > into
>>>> > master J
>>>> >
>>>> >
>>>> >
>>>> > You mentioned that we should make the old svn read only. Maybe do it
>>>> > similar
>>>> > like we did during LuSolr merge: Add a final commit removing
>>>> > everything from
>>>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>>>> > pointing to Git. All other branches stay alive. After that we could
>>>> > make it
>>>> > read only – but it is not really needed. What do others think?
>>>> >
>>>> >
>>>> >
>>>> > Uwe
>>>> >
>>>> >
>>>> >
>>>> > -----
>>>> >
>>>> > Uwe Schindler
>>>> >
>>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>>> >
>>>> > http://www.thetaphi.de
>>>> >
>>>> > eMail: [hidden email]
>>>> >
>>>> >
>>>> >
>>>> > From: Mark Miller [mailto:[hidden email]]
>>>> > Sent: Saturday, January 09, 2016 10:55 PM
>>>> > To: java-dev <[hidden email]>
>>>> > Subject: Moving Lucene / Solr from SVN to Git
>>>> >
>>>> >
>>>> >
>>>> > We have done almost all of the work necessary for a move and I have
>>>> > filed an
>>>> > issue with INFRA.
>>>> >
>>>> >
>>>> >
>>>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>>>> >
>>>> > https://issues.apache.org/jira/browse/LUCENE-6937
>>>> >
>>>> >
>>>> >
>>>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>>>> >
>>>> > https://issues.apache.org/jira/browse/INFRA-11056
>>>> >
>>>> >
>>>> >
>>>> > Everyone knows about rebase and linear history right ;)
>>>> >
>>>> >
>>>> >
>>>> > - Mark
>>>> >
>>>> > --
>>>> >
>>>> > - Mark
>>>> >
>>>> > about.me/markrmiller
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>>
>>
>> --
>> Prasanna Dangalla
>> Software Engineer, WSO2, Inc.; http://wso2.com/
>> http://wso2.com/about/team/prasanna-dangalla
>> lean.enterprise.middleware
>>
>> cell: +94 777 55 80 30 | +94 718 11 27 51
>> twitter: @prasa77
>>
>
>
> --
> Prasanna Dangalla
> Software Engineer, WSO2, Inc.; http://wso2.com/
> http://wso2.com/about/team/prasanna-dangalla
> lean.enterprise.middleware
>
> cell: +94 777 55 80 30 | +94 718 11 27 51
> twitter: @prasa77
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Karl Wright-2
Hi Dawid,

The problem I've had with Git is not that the basic model is hard to understand -- it's that the basic model seems inadequate for many things, so there's been a huge proliferation of mysterious switches that are poorly documented and also very very powerful.  svn has a few of these, but nowhere near the number or the opacity.  Do you have a decent online resource that explains how these are meant to be used?

Karl


On Sun, Jan 10, 2016 at 4:25 AM, Dawid Weiss <[hidden email]> wrote:
A few unrelated answers:

1) I would remove everything from SVN, add a commit informing about
the move to git, then import all this up-to-date history into git (I
volunteer to do this) and revert the last commit (in git). This way
the history is complete, including SVN->git move.

Note this would require a few hours of stop-the-world on commits.

2. Contrary to Mark I use git command line only. And gitk (--all) to
visualize the history. git is really simple conceptually, I strongly
recommend reading this:

http://eagain.net/articles/git-for-computer-scientists/

or this, which is slightly more verbose:
http://nyuccl.org/pages/gittutorial/

Once you get the idea that everything is in git is basically a set of
"states" of blobs (files, file sets, commit info history) everything
becomes much simpler. For example a cherry pick of commit X to branch
Y is basically applying X's diff from its parent commit to the current
state of Y. It's not a merge. It's svn's equivalent of svn diff >
patch, svn switch Y, svn apply patch. A merge is applying patches from
two separate lines of development that consolidate them. If there's a
conflict you add a third patch to resolve this conflict.

We can definitely put up some beginner-level workflows, but the
understanding of what git is simplifies life greatly.

In any case, Mark -- let me know (directly or on the list) when you
need me to perform the final git conversion. Once the infra has set up
a git repo it's all about one push from github to it (--mirror) and
we're set.

Dawid



On Sun, Jan 10, 2016 at 2:16 AM, Steve Davids <[hidden email]> wrote:
> @Prasanna you can follow along with the SVN -> GIT history migration in
> https://issues.apache.org/jira/browse/LUCENE-6933
>
> @Erick for some basics you can checkout these interactive git guides, either
> https://www.codecademy.com/learn/learn-git or http://gitreal.codeschool.com/
> though as Mark said if you find a decent UI you rarely need to use the
> command line. I’ve been fond of IntelliJ’s git support, but I have found
> Eclipse’s to be absolutely terrible (egit).
>
> -Steve
>
> On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla <[hidden email]>
> wrote:
>
>
>
> On Sunday, 10 January 2016, Prasanna Dangalla <[hidden email]>
> wrote:
>>
>> Hi All,
>> I'm a new member to this project. I was reading the mails previously.
>> Thiught leeHere if we migrate
>>
>> mails previously. Thought of giving an input. Here if we migrate
>
> Sorry for the typo...
>>
>>
>> from svn its better to migrate the history as well. I meant the commit
>> history. How do we migrate the SVN commit log from svn to git ?
>>
>> On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
>>>
>>> I think we will update much of the doc as we go, but I'm sure there are
>>> plenty of people that can help on the list with any questions. We can
>>> probably get some basics up relatively painlessly. I'd guess the number of
>>> committers that have not worked with Git yet is very small.
>>>
>>> As a start, my recommendation would be to Google Git for SVN users and
>>> look at some of those resources though. It's probably better than what we
>>> will subset.
>>>
>>> Personally, I like to just use SmartGit and mostly ignore command line
>>> Git :)
>>>
>>> How have you been able to ignore GitHub for so long :)
>>>
>>> Mark
>>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson <[hidden email]>
>>> wrote:
>>>>
>>>> I'm a little confused. A while ago I asked about whether I had to
>>>> learn all about Git, and as I remember the reply was "this is just
>>>> about the build process". Perhaps I mis-interpreted or that was
>>>> referring only to the bits Dawid was working on at that instant or....
>>>>
>>>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>>>> our commits need to happen in Git, right? There are still some "git
>>>> challenged" curmudgeons out there (like me) who really haven't much of
>>>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>>>> clear signal that "Now you have to figure it out because you can't
>>>> commit to the SVN repo any more".
>>>>
>>>> And the "how to contribute" page is all about SVN:
>>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>>>> at all close that page needs some significant editing.
>>>>
>>>> Personally, before I screw up my first commit under Git, it would be
>>>> super helpful if there were a step-by-step. No doubt that really
>>>> amounts to three commands or something, but before "just trying stuff"
>>>> it would be nice to have the steps for committing (pushing?) to trunk
>>>> and then getting those changes into 5x (well, maybe 6.0 by then)
>>>> outlined...
>>>>
>>>> Or I'm off in the weeds here, always a possibility.
>>>>
>>>> FWIW,
>>>> Erick
>>>>
>>>>
>>>>
>>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]> wrote:
>>>> > Hi Mark,
>>>> >
>>>> >
>>>> >
>>>> > thanks for starting this! Looking forward to the whole process. When
>>>> > Infra
>>>> > is about to “activate” the new GIT repo, I will take care of Policeman
>>>> > Jenkins and fix the remaining validation tasks. I don’t want to do
>>>> > this. I
>>>> > think your commit is fine.
>>>> >
>>>> >
>>>> >
>>>> > We now need some workflows how to merge between master/trunk and the
>>>> > release
>>>> > branches. Projects do this in different ways (cherry-picking,…). I
>>>> > have no
>>>> > preference or idea, sorry! I only know how to merge feature branches
>>>> > into
>>>> > master J
>>>> >
>>>> >
>>>> >
>>>> > You mentioned that we should make the old svn read only. Maybe do it
>>>> > similar
>>>> > like we did during LuSolr merge: Add a final commit removing
>>>> > everything from
>>>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>>>> > pointing to Git. All other branches stay alive. After that we could
>>>> > make it
>>>> > read only – but it is not really needed. What do others think?
>>>> >
>>>> >
>>>> >
>>>> > Uwe
>>>> >
>>>> >
>>>> >
>>>> > -----
>>>> >
>>>> > Uwe Schindler
>>>> >
>>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>>> >
>>>> > http://www.thetaphi.de
>>>> >
>>>> > eMail: [hidden email]
>>>> >
>>>> >
>>>> >
>>>> > From: Mark Miller [mailto:[hidden email]]
>>>> > Sent: Saturday, January 09, 2016 10:55 PM
>>>> > To: java-dev <[hidden email]>
>>>> > Subject: Moving Lucene / Solr from SVN to Git
>>>> >
>>>> >
>>>> >
>>>> > We have done almost all of the work necessary for a move and I have
>>>> > filed an
>>>> > issue with INFRA.
>>>> >
>>>> >
>>>> >
>>>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>>>> >
>>>> > https://issues.apache.org/jira/browse/LUCENE-6937
>>>> >
>>>> >
>>>> >
>>>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>>>> >
>>>> > https://issues.apache.org/jira/browse/INFRA-11056
>>>> >
>>>> >
>>>> >
>>>> > Everyone knows about rebase and linear history right ;)
>>>> >
>>>> >
>>>> >
>>>> > - Mark
>>>> >
>>>> > --
>>>> >
>>>> > - Mark
>>>> >
>>>> > about.me/markrmiller
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>>
>>
>> --
>> Prasanna Dangalla
>> Software Engineer, WSO2, Inc.; http://wso2.com/
>> http://wso2.com/about/team/prasanna-dangalla
>> lean.enterprise.middleware
>>
>> cell: <a href="tel:%2B94%20777%2055%2080%2030" value="+94777558030">+94 777 55 80 30 | <a href="tel:%2B94%20718%2011%2027%2051" value="+94718112751">+94 718 11 27 51
>> twitter: @prasa77
>>
>
>
> --
> Prasanna Dangalla
> Software Engineer, WSO2, Inc.; http://wso2.com/
> http://wso2.com/about/team/prasanna-dangalla
> lean.enterprise.middleware
>
> cell: <a href="tel:%2B94%20777%2055%2080%2030" value="+94777558030">+94 777 55 80 30 | <a href="tel:%2B94%20718%2011%2027%2051" value="+94718112751">+94 718 11 27 51
> twitter: @prasa77
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Erick Erickson
So Karl, are you really the one who gave Monroe this idea?
https://xkcd.com/1597/

don't forget hover the mouse for the pop-up.... ;)

On Sun, Jan 10, 2016 at 1:52 AM, Karl Wright <[hidden email]> wrote:

> Hi Dawid,
>
> The problem I've had with Git is not that the basic model is hard to
> understand -- it's that the basic model seems inadequate for many things, so
> there's been a huge proliferation of mysterious switches that are poorly
> documented and also very very powerful.  svn has a few of these, but nowhere
> near the number or the opacity.  Do you have a decent online resource that
> explains how these are meant to be used?
>
> Karl
>
>
> On Sun, Jan 10, 2016 at 4:25 AM, Dawid Weiss <[hidden email]> wrote:
>>
>> A few unrelated answers:
>>
>> 1) I would remove everything from SVN, add a commit informing about
>> the move to git, then import all this up-to-date history into git (I
>> volunteer to do this) and revert the last commit (in git). This way
>> the history is complete, including SVN->git move.
>>
>> Note this would require a few hours of stop-the-world on commits.
>>
>> 2. Contrary to Mark I use git command line only. And gitk (--all) to
>> visualize the history. git is really simple conceptually, I strongly
>> recommend reading this:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
>>
>> or this, which is slightly more verbose:
>> http://nyuccl.org/pages/gittutorial/
>>
>> Once you get the idea that everything is in git is basically a set of
>> "states" of blobs (files, file sets, commit info history) everything
>> becomes much simpler. For example a cherry pick of commit X to branch
>> Y is basically applying X's diff from its parent commit to the current
>> state of Y. It's not a merge. It's svn's equivalent of svn diff >
>> patch, svn switch Y, svn apply patch. A merge is applying patches from
>> two separate lines of development that consolidate them. If there's a
>> conflict you add a third patch to resolve this conflict.
>>
>> We can definitely put up some beginner-level workflows, but the
>> understanding of what git is simplifies life greatly.
>>
>> In any case, Mark -- let me know (directly or on the list) when you
>> need me to perform the final git conversion. Once the infra has set up
>> a git repo it's all about one push from github to it (--mirror) and
>> we're set.
>>
>> Dawid
>>
>>
>>
>> On Sun, Jan 10, 2016 at 2:16 AM, Steve Davids <[hidden email]> wrote:
>> > @Prasanna you can follow along with the SVN -> GIT history migration in
>> > https://issues.apache.org/jira/browse/LUCENE-6933
>> >
>> > @Erick for some basics you can checkout these interactive git guides,
>> > either
>> > https://www.codecademy.com/learn/learn-git or
>> > http://gitreal.codeschool.com/
>> > though as Mark said if you find a decent UI you rarely need to use the
>> > command line. I’ve been fond of IntelliJ’s git support, but I have found
>> > Eclipse’s to be absolutely terrible (egit).
>> >
>> > -Steve
>> >
>> > On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla
>> > <[hidden email]>
>> > wrote:
>> >
>> >
>> >
>> > On Sunday, 10 January 2016, Prasanna Dangalla
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Hi All,
>> >> I'm a new member to this project. I was reading the mails previously.
>> >> Thiught leeHere if we migrate
>> >>
>> >> mails previously. Thought of giving an input. Here if we migrate
>> >
>> > Sorry for the typo...
>> >>
>> >>
>> >> from svn its better to migrate the history as well. I meant the commit
>> >> history. How do we migrate the SVN commit log from svn to git ?
>> >>
>> >> On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
>> >>>
>> >>> I think we will update much of the doc as we go, but I'm sure there
>> >>> are
>> >>> plenty of people that can help on the list with any questions. We can
>> >>> probably get some basics up relatively painlessly. I'd guess the
>> >>> number of
>> >>> committers that have not worked with Git yet is very small.
>> >>>
>> >>> As a start, my recommendation would be to Google Git for SVN users and
>> >>> look at some of those resources though. It's probably better than what
>> >>> we
>> >>> will subset.
>> >>>
>> >>> Personally, I like to just use SmartGit and mostly ignore command line
>> >>> Git :)
>> >>>
>> >>> How have you been able to ignore GitHub for so long :)
>> >>>
>> >>> Mark
>> >>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I'm a little confused. A while ago I asked about whether I had to
>> >>>> learn all about Git, and as I remember the reply was "this is just
>> >>>> about the build process". Perhaps I mis-interpreted or that was
>> >>>> referring only to the bits Dawid was working on at that instant
>> >>>> or....
>> >>>>
>> >>>> Anyway, assuming the SVN repo becomes read-only, that implies that
>> >>>> all
>> >>>> our commits need to happen in Git, right? There are still some "git
>> >>>> challenged" curmudgeons out there (like me) who really haven't much
>> >>>> of
>> >>>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>> >>>> clear signal that "Now you have to figure it out because you can't
>> >>>> commit to the SVN repo any more".
>> >>>>
>> >>>> And the "how to contribute" page is all about SVN:
>> >>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>> >>>> at all close that page needs some significant editing.
>> >>>>
>> >>>> Personally, before I screw up my first commit under Git, it would be
>> >>>> super helpful if there were a step-by-step. No doubt that really
>> >>>> amounts to three commands or something, but before "just trying
>> >>>> stuff"
>> >>>> it would be nice to have the steps for committing (pushing?) to trunk
>> >>>> and then getting those changes into 5x (well, maybe 6.0 by then)
>> >>>> outlined...
>> >>>>
>> >>>> Or I'm off in the weeds here, always a possibility.
>> >>>>
>> >>>> FWIW,
>> >>>> Erick
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]>
>> >>>> wrote:
>> >>>> > Hi Mark,
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > thanks for starting this! Looking forward to the whole process.
>> >>>> > When
>> >>>> > Infra
>> >>>> > is about to “activate” the new GIT repo, I will take care of
>> >>>> > Policeman
>> >>>> > Jenkins and fix the remaining validation tasks. I don’t want to do
>> >>>> > this. I
>> >>>> > think your commit is fine.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > We now need some workflows how to merge between master/trunk and
>> >>>> > the
>> >>>> > release
>> >>>> > branches. Projects do this in different ways (cherry-picking,…). I
>> >>>> > have no
>> >>>> > preference or idea, sorry! I only know how to merge feature
>> >>>> > branches
>> >>>> > into
>> >>>> > master J
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > You mentioned that we should make the old svn read only. Maybe do
>> >>>> > it
>> >>>> > similar
>> >>>> > like we did during LuSolr merge: Add a final commit removing
>> >>>> > everything from
>> >>>> > trunk/branch_5x and leaving a readme.txt file in trunk and
>> >>>> > branch_5x
>> >>>> > pointing to Git. All other branches stay alive. After that we could
>> >>>> > make it
>> >>>> > read only – but it is not really needed. What do others think?
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > Uwe
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > -----
>> >>>> >
>> >>>> > Uwe Schindler
>> >>>> >
>> >>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >>>> >
>> >>>> > http://www.thetaphi.de
>> >>>> >
>> >>>> > eMail: [hidden email]
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > From: Mark Miller [mailto:[hidden email]]
>> >>>> > Sent: Saturday, January 09, 2016 10:55 PM
>> >>>> > To: java-dev <[hidden email]>
>> >>>> > Subject: Moving Lucene / Solr from SVN to Git
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > We have done almost all of the work necessary for a move and I have
>> >>>> > filed an
>> >>>> > issue with INFRA.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>> >>>> >
>> >>>> > https://issues.apache.org/jira/browse/LUCENE-6937
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>> >>>> >
>> >>>> > https://issues.apache.org/jira/browse/INFRA-11056
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > Everyone knows about rebase and linear history right ;)
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > - Mark
>> >>>> >
>> >>>> > --
>> >>>> >
>> >>>> > - Mark
>> >>>> >
>> >>>> > about.me/markrmiller
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [hidden email]
>> >>>> For additional commands, e-mail: [hidden email]
>> >>>>
>> >>> --
>> >>> - Mark
>> >>> about.me/markrmiller
>> >>
>> >>
>> >>
>> >> --
>> >> Prasanna Dangalla
>> >> Software Engineer, WSO2, Inc.; http://wso2.com/
>> >> http://wso2.com/about/team/prasanna-dangalla
>> >> lean.enterprise.middleware
>> >>
>> >> cell: +94 777 55 80 30 | +94 718 11 27 51
>> >> twitter: @prasa77
>> >>
>> >
>> >
>> > --
>> > Prasanna Dangalla
>> > Software Engineer, WSO2, Inc.; http://wso2.com/
>> > http://wso2.com/about/team/prasanna-dangalla
>> > lean.enterprise.middleware
>> >
>> > cell: +94 777 55 80 30 | +94 718 11 27 51
>> > twitter: @prasa77
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Malcolm Upayavira Holmes
Erick,

I found this tutorial really helped me to get my head around git:

http://pcottle.github.io/learnGitBranching/

You get to play making commits directly via that web UI, which shows you
how commits happen, merges, etc.

Upayavira

On Sun, Jan 10, 2016, at 06:15 PM, Erick Erickson wrote:

> So Karl, are you really the one who gave Monroe this idea?
> https://xkcd.com/1597/
>
> don't forget hover the mouse for the pop-up.... ;)
>
> On Sun, Jan 10, 2016 at 1:52 AM, Karl Wright <[hidden email]> wrote:
> > Hi Dawid,
> >
> > The problem I've had with Git is not that the basic model is hard to
> > understand -- it's that the basic model seems inadequate for many things, so
> > there's been a huge proliferation of mysterious switches that are poorly
> > documented and also very very powerful.  svn has a few of these, but nowhere
> > near the number or the opacity.  Do you have a decent online resource that
> > explains how these are meant to be used?
> >
> > Karl
> >
> >
> > On Sun, Jan 10, 2016 at 4:25 AM, Dawid Weiss <[hidden email]> wrote:
> >>
> >> A few unrelated answers:
> >>
> >> 1) I would remove everything from SVN, add a commit informing about
> >> the move to git, then import all this up-to-date history into git (I
> >> volunteer to do this) and revert the last commit (in git). This way
> >> the history is complete, including SVN->git move.
> >>
> >> Note this would require a few hours of stop-the-world on commits.
> >>
> >> 2. Contrary to Mark I use git command line only. And gitk (--all) to
> >> visualize the history. git is really simple conceptually, I strongly
> >> recommend reading this:
> >>
> >> http://eagain.net/articles/git-for-computer-scientists/
> >>
> >> or this, which is slightly more verbose:
> >> http://nyuccl.org/pages/gittutorial/
> >>
> >> Once you get the idea that everything is in git is basically a set of
> >> "states" of blobs (files, file sets, commit info history) everything
> >> becomes much simpler. For example a cherry pick of commit X to branch
> >> Y is basically applying X's diff from its parent commit to the current
> >> state of Y. It's not a merge. It's svn's equivalent of svn diff >
> >> patch, svn switch Y, svn apply patch. A merge is applying patches from
> >> two separate lines of development that consolidate them. If there's a
> >> conflict you add a third patch to resolve this conflict.
> >>
> >> We can definitely put up some beginner-level workflows, but the
> >> understanding of what git is simplifies life greatly.
> >>
> >> In any case, Mark -- let me know (directly or on the list) when you
> >> need me to perform the final git conversion. Once the infra has set up
> >> a git repo it's all about one push from github to it (--mirror) and
> >> we're set.
> >>
> >> Dawid
> >>
> >>
> >>
> >> On Sun, Jan 10, 2016 at 2:16 AM, Steve Davids <[hidden email]> wrote:
> >> > @Prasanna you can follow along with the SVN -> GIT history migration in
> >> > https://issues.apache.org/jira/browse/LUCENE-6933
> >> >
> >> > @Erick for some basics you can checkout these interactive git guides,
> >> > either
> >> > https://www.codecademy.com/learn/learn-git or
> >> > http://gitreal.codeschool.com/
> >> > though as Mark said if you find a decent UI you rarely need to use the
> >> > command line. I’ve been fond of IntelliJ’s git support, but I have found
> >> > Eclipse’s to be absolutely terrible (egit).
> >> >
> >> > -Steve
> >> >
> >> > On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla
> >> > <[hidden email]>
> >> > wrote:
> >> >
> >> >
> >> >
> >> > On Sunday, 10 January 2016, Prasanna Dangalla
> >> > <[hidden email]>
> >> > wrote:
> >> >>
> >> >> Hi All,
> >> >> I'm a new member to this project. I was reading the mails previously.
> >> >> Thiught leeHere if we migrate
> >> >>
> >> >> mails previously. Thought of giving an input. Here if we migrate
> >> >
> >> > Sorry for the typo...
> >> >>
> >> >>
> >> >> from svn its better to migrate the history as well. I meant the commit
> >> >> history. How do we migrate the SVN commit log from svn to git ?
> >> >>
> >> >> On Sunday, 10 January 2016, Mark Miller <[hidden email]> wrote:
> >> >>>
> >> >>> I think we will update much of the doc as we go, but I'm sure there
> >> >>> are
> >> >>> plenty of people that can help on the list with any questions. We can
> >> >>> probably get some basics up relatively painlessly. I'd guess the
> >> >>> number of
> >> >>> committers that have not worked with Git yet is very small.
> >> >>>
> >> >>> As a start, my recommendation would be to Google Git for SVN users and
> >> >>> look at some of those resources though. It's probably better than what
> >> >>> we
> >> >>> will subset.
> >> >>>
> >> >>> Personally, I like to just use SmartGit and mostly ignore command line
> >> >>> Git :)
> >> >>>
> >> >>> How have you been able to ignore GitHub for so long :)
> >> >>>
> >> >>> Mark
> >> >>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson
> >> >>> <[hidden email]>
> >> >>> wrote:
> >> >>>>
> >> >>>> I'm a little confused. A while ago I asked about whether I had to
> >> >>>> learn all about Git, and as I remember the reply was "this is just
> >> >>>> about the build process". Perhaps I mis-interpreted or that was
> >> >>>> referring only to the bits Dawid was working on at that instant
> >> >>>> or....
> >> >>>>
> >> >>>> Anyway, assuming the SVN repo becomes read-only, that implies that
> >> >>>> all
> >> >>>> our commits need to happen in Git, right? There are still some "git
> >> >>>> challenged" curmudgeons out there (like me) who really haven't much
> >> >>>> of
> >> >>>> a clue. I'll figure it out, mind you but it'd be nice if there were a
> >> >>>> clear signal that "Now you have to figure it out because you can't
> >> >>>> commit to the SVN repo any more".
> >> >>>>
> >> >>>> And the "how to contribute" page is all about SVN:
> >> >>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
> >> >>>> at all close that page needs some significant editing.
> >> >>>>
> >> >>>> Personally, before I screw up my first commit under Git, it would be
> >> >>>> super helpful if there were a step-by-step. No doubt that really
> >> >>>> amounts to three commands or something, but before "just trying
> >> >>>> stuff"
> >> >>>> it would be nice to have the steps for committing (pushing?) to trunk
> >> >>>> and then getting those changes into 5x (well, maybe 6.0 by then)
> >> >>>> outlined...
> >> >>>>
> >> >>>> Or I'm off in the weeds here, always a possibility.
> >> >>>>
> >> >>>> FWIW,
> >> >>>> Erick
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <[hidden email]>
> >> >>>> wrote:
> >> >>>> > Hi Mark,
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > thanks for starting this! Looking forward to the whole process.
> >> >>>> > When
> >> >>>> > Infra
> >> >>>> > is about to “activate” the new GIT repo, I will take care of
> >> >>>> > Policeman
> >> >>>> > Jenkins and fix the remaining validation tasks. I don’t want to do
> >> >>>> > this. I
> >> >>>> > think your commit is fine.
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > We now need some workflows how to merge between master/trunk and
> >> >>>> > the
> >> >>>> > release
> >> >>>> > branches. Projects do this in different ways (cherry-picking,…). I
> >> >>>> > have no
> >> >>>> > preference or idea, sorry! I only know how to merge feature
> >> >>>> > branches
> >> >>>> > into
> >> >>>> > master J
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > You mentioned that we should make the old svn read only. Maybe do
> >> >>>> > it
> >> >>>> > similar
> >> >>>> > like we did during LuSolr merge: Add a final commit removing
> >> >>>> > everything from
> >> >>>> > trunk/branch_5x and leaving a readme.txt file in trunk and
> >> >>>> > branch_5x
> >> >>>> > pointing to Git. All other branches stay alive. After that we could
> >> >>>> > make it
> >> >>>> > read only – but it is not really needed. What do others think?
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > Uwe
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > -----
> >> >>>> >
> >> >>>> > Uwe Schindler
> >> >>>> >
> >> >>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> >>>> >
> >> >>>> > http://www.thetaphi.de
> >> >>>> >
> >> >>>> > eMail: [hidden email]
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > From: Mark Miller [mailto:[hidden email]]
> >> >>>> > Sent: Saturday, January 09, 2016 10:55 PM
> >> >>>> > To: java-dev <[hidden email]>
> >> >>>> > Subject: Moving Lucene / Solr from SVN to Git
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > We have done almost all of the work necessary for a move and I have
> >> >>>> > filed an
> >> >>>> > issue with INFRA.
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
> >> >>>> >
> >> >>>> > https://issues.apache.org/jira/browse/LUCENE-6937
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > INFRA-11056: Migrate Lucene project from SVN to Git.
> >> >>>> >
> >> >>>> > https://issues.apache.org/jira/browse/INFRA-11056
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > Everyone knows about rebase and linear history right ;)
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > - Mark
> >> >>>> >
> >> >>>> > --
> >> >>>> >
> >> >>>> > - Mark
> >> >>>> >
> >> >>>> > about.me/markrmiller
> >> >>>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: [hidden email]
> >> >>>> For additional commands, e-mail: [hidden email]
> >> >>>>
> >> >>> --
> >> >>> - Mark
> >> >>> about.me/markrmiller
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Prasanna Dangalla
> >> >> Software Engineer, WSO2, Inc.; http://wso2.com/
> >> >> http://wso2.com/about/team/prasanna-dangalla
> >> >> lean.enterprise.middleware
> >> >>
> >> >> cell: +94 777 55 80 30 | +94 718 11 27 51
> >> >> twitter: @prasa77
> >> >>
> >> >
> >> >
> >> > --
> >> > Prasanna Dangalla
> >> > Software Engineer, WSO2, Inc.; http://wso2.com/
> >> > http://wso2.com/about/team/prasanna-dangalla
> >> > lean.enterprise.middleware
> >> >
> >> > cell: +94 777 55 80 30 | +94 718 11 27 51
> >> > twitter: @prasa77
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Dawid Weiss-2
In reply to this post by Karl Wright-2
> The problem I've had with Git is not that the basic model is hard to
> understand -- it's that the basic model seems inadequate for many things, so
> there's been a huge proliferation of mysterious switches that are poorly

Can you give an example when it's "not adequate"? For what it's worth
-- there are typically only about five or six commands I use in git.
Sure, there is tons of switches and commands out there, but I wouldn't
read the docs of those switches without a special need (when you wish
you could do something and don't know how).

I suspect many people make the jump from CVS/SVN world and wish to
repeat the same kind of workflow they had in the past. This is a
mistake and it's not git-related. The workflow is going to be
different, it's a different tool with different capabilities. If you
transitioned to mercurial instead of git you'd face similar questions
and problems.

For example, one upside I see for people not familiar with git is that
they can clone the repo, mess and experiment with git commands all
they like and then invoke "gitk --all" and see whatever commits or
merges they've made without them being pushed to the remote
repository... Or, if you're not so sure about all this, you can fork
the project on github, work on your own repo all you like and then
simply file a pull request... even if you're a committer. Even if you
tragically mess up... well, with git there is always a way to revert
to a previous state -- it's not encouraged, but can be done. With SVN,
once you mess up, it's there forever...

Just to make it clear -- I had big doubts about the workflow when I
first started using git... I think I can even say I was skeptical
about the whole thing. But since then I learned to appreciate the
differences of distributed revision control (be it mercurial or git)
and I'd never, never want to go back to SVN. I don't qualify git as
"better", but for my workflows it's definitely more convenient (and
much, much faster).

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Jack Krupansky-3
In reply to this post by Mark Miller-3
Will anybody be able to create a pull request and then only committers perform the merge operation? (I presume so, but... just for clarity, especially for those not git-savvy yet.)

Would patches still be added to Jira requests, or simply a link to a pull request? (Again, I presume the latter, but the details of "submitting a patch" should be clearly documented.)

Then there is the matter of code review and whether to encourage comments in Jira. Comments can be made on pull requests, but should some external tool like reviewable.io be encouraged?

-- Jack Krupansky

On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]> wrote:
We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

LUCENE-6937: Migrate Lucene project from SVN to Git.

INFRA-11056: Migrate Lucene project from SVN to Git.

Everyone knows about rebase and linear history right ;)

- Mark
--

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Mark Miller-3
I don't think there is a current plan to change how we do business. Just a change in where the master copy is hosted.

We already have JIRA, dev, commit procedures, and integration with GitHub pull requests. All that will stay the same. No need to overthink it.

- Mark

On Sun, Jan 10, 2016 at 4:18 PM Jack Krupansky <[hidden email]> wrote:
Will anybody be able to create a pull request and then only committers perform the merge operation? (I presume so, but... just for clarity, especially for those not git-savvy yet.)

Would patches still be added to Jira requests, or simply a link to a pull request? (Again, I presume the latter, but the details of "submitting a patch" should be clearly documented.)

Then there is the matter of code review and whether to encourage comments in Jira. Comments can be made on pull requests, but should some external tool like reviewable.io be encouraged?

-- Jack Krupansky

On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]> wrote:
We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

LUCENE-6937: Migrate Lucene project from SVN to Git.

INFRA-11056: Migrate Lucene project from SVN to Git.

Everyone knows about rebase and linear history right ;)

- Mark
--

--
Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Shai Erera
I think it will be nice if we integrate a code review tool into our workflow, such as Gerrit maybe (even Github pull requests are good), instead of the patch workflow with JIRA.

But I agree we don't have to change that, not at start at least. The move to git will allow those who want it, to use the code review tool on Github (via pull requests).

Shai

On Mon, Jan 11, 2016 at 5:27 AM Mark Miller <[hidden email]> wrote:
I don't think there is a current plan to change how we do business. Just a change in where the master copy is hosted.

We already have JIRA, dev, commit procedures, and integration with GitHub pull requests. All that will stay the same. No need to overthink it.

- Mark

On Sun, Jan 10, 2016 at 4:18 PM Jack Krupansky <[hidden email]> wrote:
Will anybody be able to create a pull request and then only committers perform the merge operation? (I presume so, but... just for clarity, especially for those not git-savvy yet.)

Would patches still be added to Jira requests, or simply a link to a pull request? (Again, I presume the latter, but the details of "submitting a patch" should be clearly documented.)

Then there is the matter of code review and whether to encourage comments in Jira. Comments can be made on pull requests, but should some external tool like reviewable.io be encouraged?

-- Jack Krupansky

On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]> wrote:
We have done almost all of the work necessary for a move and I have filed an issue with INFRA.

LUCENE-6937: Migrate Lucene project from SVN to Git.

INFRA-11056: Migrate Lucene project from SVN to Git.

Everyone knows about rebase and linear history right ;)

- Mark
--

--
Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Dawid Weiss-2
Remember github is an external service, if it vanishes so would all
comments and discussion. I'd stick with Jira, at least for the time
being (until people get more familiar with git). Not everything at
once.

Dawid

On Mon, Jan 11, 2016 at 9:11 AM, Shai Erera <[hidden email]> wrote:

> I think it will be nice if we integrate a code review tool into our
> workflow, such as Gerrit maybe (even Github pull requests are good), instead
> of the patch workflow with JIRA.
>
> But I agree we don't have to change that, not at start at least. The move to
> git will allow those who want it, to use the code review tool on Github (via
> pull requests).
>
> Shai
>
> On Mon, Jan 11, 2016 at 5:27 AM Mark Miller <[hidden email]> wrote:
>>
>> I don't think there is a current plan to change how we do business. Just a
>> change in where the master copy is hosted.
>>
>> We already have JIRA, dev, commit procedures, and integration with GitHub
>> pull requests. All that will stay the same. No need to overthink it.
>>
>> - Mark
>>
>> On Sun, Jan 10, 2016 at 4:18 PM Jack Krupansky <[hidden email]>
>> wrote:
>>>
>>> Will anybody be able to create a pull request and then only committers
>>> perform the merge operation? (I presume so, but... just for clarity,
>>> especially for those not git-savvy yet.)
>>>
>>> Would patches still be added to Jira requests, or simply a link to a pull
>>> request? (Again, I presume the latter, but the details of "submitting a
>>> patch" should be clearly documented.)
>>>
>>> Then there is the matter of code review and whether to encourage comments
>>> in Jira. Comments can be made on pull requests, but should some external
>>> tool like reviewable.io be encouraged?
>>>
>>> -- Jack Krupansky
>>>
>>> On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> We have done almost all of the work necessary for a move and I have
>>>> filed an issue with INFRA.
>>>>
>>>> LUCENE-6937: Migrate Lucene project from SVN to Git.
>>>> https://issues.apache.org/jira/browse/LUCENE-6937
>>>>
>>>> INFRA-11056: Migrate Lucene project from SVN to Git.
>>>> https://issues.apache.org/jira/browse/INFRA-11056
>>>>
>>>> Everyone knows about rebase and linear history right ;)
>>>>
>>>> - Mark
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>>
>> --
>> - Mark
>> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Jan Høydahl / Cominvent
All discussion in the Github PR is captured in JIRA if the two are linked,
see https://issues.apache.org/jira/browse/SOLR-8166 as an example
If they are not linked, comments go to the dev list.
So we can keep it as today - allow people to choose freely to use patches and/or PRs.
NOTE: We should always create JIRA for PR’s that we want to fix.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 11. jan. 2016 kl. 09.13 skrev Dawid Weiss <[hidden email]>:
>
> Remember github is an external service, if it vanishes so would all
> comments and discussion. I'd stick with Jira, at least for the time
> being (until people get more familiar with git). Not everything at
> once.
>
> Dawid
>
> On Mon, Jan 11, 2016 at 9:11 AM, Shai Erera <[hidden email]> wrote:
>> I think it will be nice if we integrate a code review tool into our
>> workflow, such as Gerrit maybe (even Github pull requests are good), instead
>> of the patch workflow with JIRA.
>>
>> But I agree we don't have to change that, not at start at least. The move to
>> git will allow those who want it, to use the code review tool on Github (via
>> pull requests).
>>
>> Shai
>>
>> On Mon, Jan 11, 2016 at 5:27 AM Mark Miller <[hidden email]> wrote:
>>>
>>> I don't think there is a current plan to change how we do business. Just a
>>> change in where the master copy is hosted.
>>>
>>> We already have JIRA, dev, commit procedures, and integration with GitHub
>>> pull requests. All that will stay the same. No need to overthink it.
>>>
>>> - Mark
>>>
>>> On Sun, Jan 10, 2016 at 4:18 PM Jack Krupansky <[hidden email]>
>>> wrote:
>>>>
>>>> Will anybody be able to create a pull request and then only committers
>>>> perform the merge operation? (I presume so, but... just for clarity,
>>>> especially for those not git-savvy yet.)
>>>>
>>>> Would patches still be added to Jira requests, or simply a link to a pull
>>>> request? (Again, I presume the latter, but the details of "submitting a
>>>> patch" should be clearly documented.)
>>>>
>>>> Then there is the matter of code review and whether to encourage comments
>>>> in Jira. Comments can be made on pull requests, but should some external
>>>> tool like reviewable.io be encouraged?
>>>>
>>>> -- Jack Krupansky
>>>>
>>>> On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]>
>>>> wrote:
>>>>>
>>>>> We have done almost all of the work necessary for a move and I have
>>>>> filed an issue with INFRA.
>>>>>
>>>>> LUCENE-6937: Migrate Lucene project from SVN to Git.
>>>>> https://issues.apache.org/jira/browse/LUCENE-6937
>>>>>
>>>>> INFRA-11056: Migrate Lucene project from SVN to Git.
>>>>> https://issues.apache.org/jira/browse/INFRA-11056
>>>>>
>>>>> Everyone knows about rebase and linear history right ;)
>>>>>
>>>>> - Mark
>>>>> --
>>>>> - Mark
>>>>> about.me/markrmiller
>>>>
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving Lucene / Solr from SVN to Git

Sanne Grinovero
Thanks for finally switching, I have been looking forward to this.

I've been doing release management and generally helping with the
switch from SVN to Git for the Hibernate project in the past 5 years,
so I'm happy to share hints and tips from our experience there.

Feel free to ask me for help on IRC or emails if you get stuck: we
love Lucene, wouldn't want you to slow down ;)

One crucial concept: it might be obvious - although sometimes it's not
when people have been using SVN for a long time - but when you have a
local Git clone of a project, you can experiment a lot and play with
Git to see what would happen.
As long as you don't push changes, you can experiment branching,
merging and rebasing without making your experiments affect anyone
else.

Always create a new branch first, so you can play with the
experimental branch and maybe nuke it if you get lost, and start over.
So when reading the tutorials and references, don't be afraid to type
commands and check the results.

Thanks,
Sanne


On 11 January 2016 at 09:33, Jan Høydahl <[hidden email]> wrote:

> All discussion in the Github PR is captured in JIRA if the two are linked,
> see https://issues.apache.org/jira/browse/SOLR-8166 as an example
> If they are not linked, comments go to the dev list.
> So we can keep it as today - allow people to choose freely to use patches and/or PRs.
> NOTE: We should always create JIRA for PR’s that we want to fix.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>> 11. jan. 2016 kl. 09.13 skrev Dawid Weiss <[hidden email]>:
>>
>> Remember github is an external service, if it vanishes so would all
>> comments and discussion. I'd stick with Jira, at least for the time
>> being (until people get more familiar with git). Not everything at
>> once.
>>
>> Dawid
>>
>> On Mon, Jan 11, 2016 at 9:11 AM, Shai Erera <[hidden email]> wrote:
>>> I think it will be nice if we integrate a code review tool into our
>>> workflow, such as Gerrit maybe (even Github pull requests are good), instead
>>> of the patch workflow with JIRA.
>>>
>>> But I agree we don't have to change that, not at start at least. The move to
>>> git will allow those who want it, to use the code review tool on Github (via
>>> pull requests).
>>>
>>> Shai
>>>
>>> On Mon, Jan 11, 2016 at 5:27 AM Mark Miller <[hidden email]> wrote:
>>>>
>>>> I don't think there is a current plan to change how we do business. Just a
>>>> change in where the master copy is hosted.
>>>>
>>>> We already have JIRA, dev, commit procedures, and integration with GitHub
>>>> pull requests. All that will stay the same. No need to overthink it.
>>>>
>>>> - Mark
>>>>
>>>> On Sun, Jan 10, 2016 at 4:18 PM Jack Krupansky <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Will anybody be able to create a pull request and then only committers
>>>>> perform the merge operation? (I presume so, but... just for clarity,
>>>>> especially for those not git-savvy yet.)
>>>>>
>>>>> Would patches still be added to Jira requests, or simply a link to a pull
>>>>> request? (Again, I presume the latter, but the details of "submitting a
>>>>> patch" should be clearly documented.)
>>>>>
>>>>> Then there is the matter of code review and whether to encourage comments
>>>>> in Jira. Comments can be made on pull requests, but should some external
>>>>> tool like reviewable.io be encouraged?
>>>>>
>>>>> -- Jack Krupansky
>>>>>
>>>>> On Sat, Jan 9, 2016 at 4:54 PM, Mark Miller <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> We have done almost all of the work necessary for a move and I have
>>>>>> filed an issue with INFRA.
>>>>>>
>>>>>> LUCENE-6937: Migrate Lucene project from SVN to Git.
>>>>>> https://issues.apache.org/jira/browse/LUCENE-6937
>>>>>>
>>>>>> INFRA-11056: Migrate Lucene project from SVN to Git.
>>>>>> https://issues.apache.org/jira/browse/INFRA-11056
>>>>>>
>>>>>> Everyone knows about rebase and linear history right ;)
>>>>>>
>>>>>> - Mark
>>>>>> --
>>>>>> - Mark
>>>>>> about.me/markrmiller
>>>>>
>>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12