You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2019/08/19 15:37:28 UTC
moving uimaj to git repo?
Hi,
There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
to do some svn work to merge the uimaj v2 and v3 repositories.
Now that we have new versions of both uimaj v2 and v3 recently released, I'm
thinking of skipping that Jira, and doing this instead:
1) converting the uima-uimaj existing git read-only-mirror repo to a git
read/write repo.
2) once that happens, updating it by adding to it the data from the existing
uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
master, to reflect that the main new dev work is in the 3.x stream.
Does this sound reasonable? Have I overlooked something important?
-Marshall
Re: moving uimaj to git repo?
Posted by Marshall Schor <ms...@schor.com>.
Submitted an INFRA Jira request for this:
https://issues.apache.org/jira/browse/INFRA-18922
-Marshall
]
On 8/19/2019 11:37 AM, Marshall Schor wrote:
> Hi,
>
> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
> to do some svn work to merge the uimaj v2 and v3 repositories.
>
> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
> thinking of skipping that Jira, and doing this instead:
>
> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
> read/write repo.
>
> 2) once that happens, updating it by adding to it the data from the existing
> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>
> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
> master, to reflect that the main new dev work is in the 3.x stream.
>
> Does this sound reasonable? Have I overlooked something important?
>
> -Marshall
>
>
>
Re: 2 ways to merge uimaj v2 and v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 20. Aug 2019, at 21:06, Marshall Schor <ms...@schor.com> wrote:
>
> So, I think doing the svn copy of v2 into v3 as a new branch is the way to go.
... or copy v3 into a branch of v2 ;)
But anyway, you have already done it :P
-- Richard
Re: 2 ways to merge uimaj v2 and v3
Posted by Marshall Schor <ms...@schor.com>.
A big error: although svn copy from one svn repo to another doesn't preserve
history,
it turns out our projects in the Apache SVN are all in on giant repository,
so that doing the svn copy does preserve history.
I can in fact go back in the history of some uima v3 files, and see the v2 history,
from before I made the v3 copy.
So, I think doing the svn copy of v2 into v3 as a new branch is the way to go.
Anyone agree/disagree? -Marshall
On 8/20/2019 11:15 AM, Marshall Schor wrote:
> svn copy from one repo to another doesn't preserve history. So if I do things
> with svn copy, that will lose history.
>
> =============================
>
> I have a confusion on the merge of uima v2 and v3 in git. There's two ways:
>
> 1) have one master, with folders v2/ and v3/, and lots of "duplicated" files
> in each
>
> 2) have two branches, master and 2.x, with the intent to never "merge" these
> branches back together.
>
> 2) seems to be the direction others are taking.
>
> The articles on how to merge multiple GIT repos - preserving history - all seem
> to focus on 1).
>
> Still looking for ways to do (2) with history preserved, advice appreciated :-).
> -Marshall
>
>
> On 8/20/2019 8:54 AM, Marshall Schor wrote:
>> Thanks for pointing that out.
>>
>> I'll investigate how to preserve the history, probably by testing doing an
>> svn-copy from v2 to v3 as the 2.x branch, before moving to git.
>>
>> -Marshall
>>
>> On 8/20/2019 8:28 AM, Richard Eckart de Castilho wrote:
>>> If you manually import the v3 into the converted v2-git-repo, then we'd loose the version history of v3.
>>>
>>> -- Richard
>>>
>>>> On 19. Aug 2019, at 17:37, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
>>>> to do some svn work to merge the uimaj v2 and v3 repositories.
>>>>
>>>> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
>>>> thinking of skipping that Jira, and doing this instead:
>>>>
>>>> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
>>>> read/write repo.
>>>>
>>>> 2) once that happens, updating it by adding to it the data from the existing
>>>> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>>>>
>>>> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
>>>> master, to reflect that the main new dev work is in the 3.x stream.
>>>>
>>>> Does this sound reasonable? Have I overlooked something important?
>>>>
>>>> -Marshall
2 ways to merge uimaj v2 and v3
Posted by Marshall Schor <ms...@schor.com>.
svn copy from one repo to another doesn't preserve history. So if I do things
with svn copy, that will lose history.
=============================
I have a confusion on the merge of uima v2 and v3 in git. There's two ways:
1) have one master, with folders v2/ and v3/, and lots of "duplicated" files
in each
2) have two branches, master and 2.x, with the intent to never "merge" these
branches back together.
2) seems to be the direction others are taking.
The articles on how to merge multiple GIT repos - preserving history - all seem
to focus on 1).
Still looking for ways to do (2) with history preserved, advice appreciated :-).
-Marshall
On 8/20/2019 8:54 AM, Marshall Schor wrote:
> Thanks for pointing that out.
>
> I'll investigate how to preserve the history, probably by testing doing an
> svn-copy from v2 to v3 as the 2.x branch, before moving to git.
>
> -Marshall
>
> On 8/20/2019 8:28 AM, Richard Eckart de Castilho wrote:
>> If you manually import the v3 into the converted v2-git-repo, then we'd loose the version history of v3.
>>
>> -- Richard
>>
>>> On 19. Aug 2019, at 17:37, Marshall Schor <ms...@schor.com> wrote:
>>>
>>> Hi,
>>>
>>> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
>>> to do some svn work to merge the uimaj v2 and v3 repositories.
>>>
>>> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
>>> thinking of skipping that Jira, and doing this instead:
>>>
>>> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
>>> read/write repo.
>>>
>>> 2) once that happens, updating it by adding to it the data from the existing
>>> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>>>
>>> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
>>> master, to reflect that the main new dev work is in the 3.x stream.
>>>
>>> Does this sound reasonable? Have I overlooked something important?
>>>
>>> -Marshall
Re: moving uimaj to git repo?
Posted by Marshall Schor <ms...@schor.com>.
Thanks for pointing that out.
I'll investigate how to preserve the history, probably by testing doing an
svn-copy from v2 to v3 as the 2.x branch, before moving to git.
-Marshall
On 8/20/2019 8:28 AM, Richard Eckart de Castilho wrote:
> If you manually import the v3 into the converted v2-git-repo, then we'd loose the version history of v3.
>
> -- Richard
>
>> On 19. Aug 2019, at 17:37, Marshall Schor <ms...@schor.com> wrote:
>>
>> Hi,
>>
>> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
>> to do some svn work to merge the uimaj v2 and v3 repositories.
>>
>> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
>> thinking of skipping that Jira, and doing this instead:
>>
>> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
>> read/write repo.
>>
>> 2) once that happens, updating it by adding to it the data from the existing
>> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>>
>> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
>> master, to reflect that the main new dev work is in the 3.x stream.
>>
>> Does this sound reasonable? Have I overlooked something important?
>>
>> -Marshall
>
Re: moving uimaj to git repo?
Posted by Richard Eckart de Castilho <re...@apache.org>.
If you manually import the v3 into the converted v2-git-repo, then we'd loose the version history of v3.
-- Richard
> On 19. Aug 2019, at 17:37, Marshall Schor <ms...@schor.com> wrote:
>
> Hi,
>
> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
> to do some svn work to merge the uimaj v2 and v3 repositories.
>
> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
> thinking of skipping that Jira, and doing this instead:
>
> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
> read/write repo.
>
> 2) once that happens, updating it by adding to it the data from the existing
> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>
> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
> master, to reflect that the main new dev work is in the 3.x stream.
>
> Does this sound reasonable? Have I overlooked something important?
>
> -Marshall
Re: [VOTE] moving uimaj to git repo?
Posted by Richard Eckart de Castilho <re...@apache.org>.
[X] +1 OK to move uimaj from SVN to (writable) GIT for source control
-- Richard
Re: [VOTE] moving uimaj to git repo?
Posted by Peter Klügl <pe...@averbis.com>.
[X] +1 OK to move uimaj from SVN to (writable) GIT for source control
Am 19.08.2019 um 20:13 schrieb Marshall Schor:
> Please respond with a +1 or other for the decision to move uimaj to a writable
> GIT repo, and
> switch to using GIT for the source code control system for uimaj.
>
> [X] +1 OK to move uimaj from SVN to (writable) GIT for source control
>
> [ ] 0 don't care
>
> [ ] -1 not OK to move uimaj from SVN to (writable) GIT for source control
> because...
>
> -Marshall
>
> On 8/19/2019 11:37 AM, Marshall Schor wrote:
>> Hi,
>>
>> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
>> to do some svn work to merge the uimaj v2 and v3 repositories.
>>
>> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
>> thinking of skipping that Jira, and doing this instead:
>>
>> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
>> read/write repo.
>>
>> 2) once that happens, updating it by adding to it the data from the existing
>> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>>
>> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
>> master, to reflect that the main new dev work is in the 3.x stream.
>>
>> Does this sound reasonable? Have I overlooked something important?
>>
>> -Marshall
>>
>>
>>
--
Peter Klügl
R&D Text Mining/Machine Learning
Averbis GmbH
Salzstr. 15
79098 Freiburg
Germany
Fon: +49 761 708 394 0
Fax: +49 761 708 394 10
Email: peter.kluegl@averbis.com
Web: https://averbis.com
Headquarters: Freiburg im Breisgau
Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó
[VOTE] moving uimaj to git repo?
Posted by Marshall Schor <ms...@schor.com>.
Please respond with a +1 or other for the decision to move uimaj to a writable
GIT repo, and
switch to using GIT for the source code control system for uimaj.
[X] +1 OK to move uimaj from SVN to (writable) GIT for source control
[ ] 0 don't care
[ ] -1 not OK to move uimaj from SVN to (writable) GIT for source control
because...
-Marshall
On 8/19/2019 11:37 AM, Marshall Schor wrote:
> Hi,
>
> There's currently a Jira issue https://issues.apache.org/jira/browse/UIMA-6115
> to do some svn work to merge the uimaj v2 and v3 repositories.
>
> Now that we have new versions of both uimaj v2 and v3 recently released, I'm
> thinking of skipping that Jira, and doing this instead:
>
> 1) converting the uima-uimaj existing git read-only-mirror repo to a git
> read/write repo.
>
> 2) once that happens, updating it by adding to it the data from the existing
> uima-uimaj-v3 existing git read-only-mirror, initially as a branch named 3.
>
> 3) renaming the master branch to the 2.x branch; renaming the 3.x branch to be
> master, to reflect that the main new dev work is in the 3.x stream.
>
> Does this sound reasonable? Have I overlooked something important?
>
> -Marshall
>
>
>