Yes. Thank you! From my experience multi-repo doesn’t make problems go away, it just defers them and introduces others. I’m not against multi-repo or a strong proponent of monorepos... each have their strengths and drawbacks and there is a time and place for either. I struggle to deal with folks who firmly lie in one camp or the other.
Multi-repo makes integrations harder, because you find out about breakages later -- which means that it might be harder to identify the cause and more likely that someone depends on the behavior that broke you by the time you notice it.
But, multi-repo makes local development faster and cheaper -- you're insulated from the churn of everybody else's check-ins. You don't have to constantly refactor everything every time some dependency makes a minor tweak.
You get more done and have a smoother development lifecycle -- but you're going to keep falling behind your dependencies unless you invest in keeping up -- and that part of the process is more unfun the less often you do it.
I currently live in a monorepo. I don't love it. But I've also not loved the multi-repos I've lived in, so... shrug
I’m not sure I understand what branching monotonically means, could you explain that? I’m not disagreeing with you - but is this something that can be done with googles monorepo? And when would I want to do so?
I meant to say "atomically commit", but my brain mixed it with mono-repo, to come up with monotonically, which is a math word w/ no relevance to branching (afaik!)
For branching, I just meant there's no easy way to branch everything at once. If you want to have "weirdExperiment" branch that affects code in 4 repos, you have to go branch 4 different times. For committing, same deal. You can't easily tag a single snapshot of the state of all projects. Etc.
I agree. I will say the price was at a point that I didn’t even have to think about it at 1$/month.
I looked at the features, signed up promptly, and wired up a custom domain. The only thing I’m not excited about is rotating all my emails...
Thank you for putting this together. I love that you even have 2fa support.
Would you be making the same argument if we were talking about your bank's website?
IMO Effective access control works both ways. you can't send the ALL of the content back and then have the access control work on the client machine.
What if i just used curl and viewed the HTML raw to read the article?
I'm less concerned with the implementation than I am with the principle.
In principle, I have reservations about exposing content to search engines but then requiring payment to read it. Especially if it's non-trivial to filter out the sources that require payment.
But a plugin which works around an attempt to restrict visibility of content to those who've paid for it ... I thnk the intent here is wrong.
I think it's ok to have information that's only accessible to a restricted set of viewers.
It's not that it's not possible. It's not that the implementations aren't dumb. It's that the principle of "if I want it, and I can do it, then it's ok" doesn't really hold up, IMO.
