4 ms·
Imo, it's better to keep all components separated in their own repos for any project which can really be described as 'large'. What if, for example, you comple
by BillinghamJ 12y ago
Imo, it's better to keep all components separated in their own repos for any project which can really be described as 'large'.
What if, for example, you completely rewrite your backend system without changing its API spec at all? Having the history of the backend and mobile app linked becomes a bit odd at this point.
What if you're using a system which deploys your repo? It may expect certain things to be in the root of the repo, and you certainly don't want your mobile app code to end up on your application servers.
Honestly, I'm not really aware of any instance where it is actually better to lump together multiple parts of a system into one repository. Maybe you made some bad architectural decisions which makes it easier to do so, but I don't consider that 'better'.
- taeric 12y agoThis does go counter to the way that it is described that both Google and Facebook have been reported to do things. The specific problem usually comes down to the extra work necessary to correlate changes between repositories.
- BillinghamJ 12y agoI kinda get the impression that some of the very large, very fast growing companies have ended up like that by necessity because they've dug themselves into a hole they can't get out of. e.g. Facebook building HHVM instead of not using PHP.
- taeric 12y agoI do not at all disagree with this impression. The question, though, is why are the major successes counter to the "best practice" that so many folk like to cite? Consider, even the linux kernel is counter to the best practices as they were thought at the time. I also realize that they could just be an unrelated data point. I just have grown weary of every success story I know about being "in spite of terrible practices." At some point, the best practices theory bows to the results of actual practices.