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/20 15:15:11 UTC
2 ways to merge uimaj v2 and v3
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: 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