Hi, I am Software Engineer from India, I am working on https://shoutmemo.com to collect, manage and showcase customers testimonials using embed widget on website. It can also import testimonials from socials like twitter. This is my first side hustle. It is still in beta stage.
Thank you so much. You bet! I spent 120 straight days while finishing up the development of the website and it was just too exciting for me to stop. There is still tons of stuff we are working on right now e.g using GANs to create icons from scratch, using Conv Nets to color the icons etc. Very excited for the future!
Probably because Perforce scales to truly massive monolithic repos while git traditionally doesn't (the insanity going on at Microsoft notwithstanding.)
Personally I feel the best method is using lots of small repos, one for each service or library, that get stitched together by the build system. I know some large tech companies have created such systems and I have experience with one of them working very well (they migrated from perforce). But this is a big change from the monolithic repository model and institutional inertia is very real.
(Perforce will eventually start to hit a wall when you get to the point where money won't buy hardware big enough for Perforce to serve your repo fast, but that's a very long way off for most organizations and I believe there are some mitigations for it.)
> Personally I feel the best method is using lots of small repos, one for each service or library, that get stitched together by the build system.
But then your teams have to manage dependencies - or your release team has to do it for them. It's very easy to run into diamond-dependency problems or runtime classpath issues.
Then some user will copy a directory, check it in, and declare that s/he «has branched the code». Oh, and quietly pull in some other directory, which is clearly not branched. This is just broken IMHO.
