5 ms·

Company-wide code sharing is not always desired, especially if you want to protect IP.

by pulse7 9y ago

klodolph 9y ago
Monorepo doesn't imply read permissions for the entire repo for everyone in the company.
- codesnik 9y ago
  then again, point about "requesting access rights" as the downside of the multirepo is mute.
  - klodolph 9y ago
    From a broader perspective, most of these complaints are complaints about specific tooling (Git, Perforce, whatever build system or dependency management you use) rather than about multirepo or monorepo approaches.
  - pc86 9y ago
    Moot?
- lloeki 9y ago
  The natural namespacing of multirepo makes this (and many other things) much simpler and sometimes even almost zero effort through the repo-handling tool (like Git{Hub,Lab}). Over here we use both and make a call based on the project and team that will have to work on it. For a couple of projects we even went through mono->multi->mono (and kept the whole git history without history rewriting thanks to git-write-tree and git-commit-tree, see [0]). [0]: https://gist.github.com/lloeki/37044e3f28812ce4ced0d9924a65172f https://gist.github.com/lloeki/37044e3f28812ce4ced0d9924a651... PS: our history looks like this (yes, multiple starts of history, which as valid a git DAG as anything but throws some GUI tools off): P1 *---*---*---*---*---*---*---*---*---*---* \ /| P1 split --*---*---*------ | /| P2 *---*---*---*---*---*-- | / P3 *-------*---*---*
  - klodolph 9y ago
    That history graph looks pretty familiar :-) In our case, it went from app, to app with supporting library, the library got extracted into a module and used with multiple apps, tools and new libraries were added that got shared between multiple apps, and pretty soon it felt like everything was sized MxN. We ended up combining all of the source code into one Git repo and stashing the media assets in SVN. One of the primary driving factors here was the ability to refactor code between modules more easily. Code would show up in an app or two, and then get refactored into a common library.
- TheAceOfHearts 9y ago
  Based on what I've heard from people at Facebook and Google, they both grant engineers access to most code. I've read Apple doesn't provide full access. Personally, I'd find it a bit frustrating. It can be really interesting to poke around and learn how some internals or backend stuff works.

Company-wide code sharing is not always desired, especially if you want to protect IP.

by pulse7 9y ago

Company-wide code sharing is not always desired, especially if you want to protect IP.

klodolph 9y ago

Monorepo doesn't imply read permissions for the entire repo for everyone in the company.

codesnik 9y ago
then again, point about "requesting access rights" as the downside of the multirepo is mute.
- klodolph 9y ago
  From a broader perspective, most of these complaints are complaints about specific tooling (Git, Perforce, whatever build system or dependency management you use) rather than about multirepo or monorepo approaches.
- pc86 9y ago
  Moot?
lloeki 9y ago
The natural namespacing of multirepo makes this (and many other things) much simpler and sometimes even almost zero effort through the repo-handling tool (like Git{Hub,Lab}). Over here we use both and make a call based on the project and team that will have to work on it. For a couple of projects we even went through mono->multi->mono (and kept the whole git history without history rewriting thanks to git-write-tree and git-commit-tree, see [0]). [0]: https://gist.github.com/lloeki/37044e3f28812ce4ced0d9924a65172f https://gist.github.com/lloeki/37044e3f28812ce4ced0d9924a651... PS: our history looks like this (yes, multiple starts of history, which as valid a git DAG as anything but throws some GUI tools off): P1 *---*---*---*---*---*---*---*---*---*---* \ /| P1 split --*---*---*------ | /| P2 *---*---*---*---*---*-- | / P3 *-------*---*---*
- klodolph 9y ago
  That history graph looks pretty familiar :-) In our case, it went from app, to app with supporting library, the library got extracted into a module and used with multiple apps, tools and new libraries were added that got shared between multiple apps, and pretty soon it felt like everything was sized MxN. We ended up combining all of the source code into one Git repo and stashing the media assets in SVN. One of the primary driving factors here was the ability to refactor code between modules more easily. Code would show up in an app or two, and then get refactored into a common library.
TheAceOfHearts 9y ago
Based on what I've heard from people at Facebook and Google, they both grant engineers access to most code. I've read Apple doesn't provide full access. Personally, I'd find it a bit frustrating. It can be really interesting to poke around and learn how some internals or backend stuff works.