[Feedhenry-raincatcher] RainCatcher Monorepo

[Peter Darrow]

Wojciech as I mentioned the tool is buggy and really doesn't make a master
branch, I think it leaves that up to us. I was mostly looking for feedback
on the approach. So is this what you're proposing:

   1. Move the demo apps into a "apps" subdirectory
   2. Move the modules into a "packages" subdirectory
   3. Move the documentation into a "docs" subdirectory
   4. Combine all branches named "master" from each individual repo into
   one master branch
   5. Combine all branches named "development" from each individual repo
   into one master branch
   6. Copy the tags from each individual repo to the monorepo with the
   following naming scheme: "<original tag name>-<original repo name>"
   7. Ensured the history stays intact.

#6 is the one I'm most curious about—how should we attempt to migrate these
tags? Or do we not migrate at all as Emilio suggests and just keep the old
repos around for resurrecting old tags, etc.?

Emilio as far as building and running the apps, https://lernajs.io/ should
help us with some of this but we may need a small script to help devs run
all the apps at once (a slimmed down raincatcher-cli maybe?). Any
suggestions there?

Peter

On Thu, Feb 23, 2017 at 10:49 AM, Wojciech Trocki <wtrocki at redhat.com>
wrote:

> Where is master :P ?
>
> Import seems to be doing something we do not want - creating new branch
> for each of the module. Best would be to have only 2 branches for that mono
> repo:
> - master (containing all modules from master with history)
> - development (with all modules from development branch)
>
> Having it this way would mean that we would not be able to have every
> component on development branch.
> If perl is a problem maybe we should use some different tools. Fastline
> migration seems to be something we can use:
>
> https://github.com/fastlane/monorepo/
>
> Regards
>
>
> Wojciech Trocki
> Red Hat Mobile
>
> On Thu, Feb 23, 2017 at 2:21 PM, Peter Darrow <pdarrow at redhat.com> wrote:
>
>> Hey all,
>>
>> I spent a bunch of time yesterday stitching together our repos into a
>> single repo. My goal was to try and identify issues that might make this
>> challenging. You can see the results here: https://github.com/feedh
>> enry-raincatcher/raincatcher-stitched/. My approach was the following:
>>
>>
>>    1. Move the demo apps into a "apps" subdirectory
>>    2. Move the modules into a "packages" subdirectory
>>    3. Move the documentation into a "docs" subdirectory
>>    4. Copy the branches from each individual repo to a branch on the
>>    monorepo with the following naming scheme: "<original branch
>>    name>-<original repo name>".
>>    5. Copy the tags from each individual repo to the monorepo with the
>>    following naming scheme: "<original tag name>-<original repo name>"
>>    6. Ensured the history stays intact.
>>
>> I found a tool that promised to implement this exact approach (
>> http://search.cpan.org/dist/Git-FastExport/script/git-stitch-repo). It's
>> written in Perl and I spent an unreasonable amount of time yesterday trying
>> to configure my system to install CPAN modules :/. Eventually I got it
>> working, but if you take a look at the stitched repo, it seems to have done
>> an incomplete job. I'm not a Perl developer so I don't think it would be
>> worth my time to try to contribute a fix, but I think I could implement
>> something similar with a bit of effort.
>>
>> What do you guys think—do we need to migrate all of the branches from
>> each repo, or just the master from each one? Do we care about the history?
>> Is it important to keep every single tag? Let me know what you think!
>>
>> Peter
>>
>> _______________________________________________
>> Feedhenry-raincatcher mailing list
>> Feedhenry-raincatcher at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170223/2e45617b/attachment.htm>