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 <m...@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
