We use this. It's much better then bitbucket. We are a distributed team of about 15ish devs. It has had some growing pains, but the support team is top notch and extremely responsive.
I agree with both (1) and (2). We require all devs, as a part of the onboarding process to read, improve and correct the docs for onboarding for each new hire. A PR is required. This forces all developers to understand what happens when something actually breaks and also how to locate the information, should the need arise.
This is also why we've never Dockerized. It masks too many issues and no one seems to have a clear understanding of how all the garments are stitched together.
Very much this. New hires must always be tasked to improve onboarding documentation. At a previous place I worked, I went from expecting it to take a new hire several months to be productive to less than a couple weeks and a big reason was continuing to have newbies tweak docs and fill in details that might be easy to gloss over by soneone who already knows the tech.
As for containers, I’m not sure I follow. We ended up using vagrant and then test kitchen for our VMs, which really helped with on boarding. The team had too many people who couldn’t be expected to troubleshoot much of the backend anyways. We had stayed away from containerization because it added complexity without any clear benefits for our use cases. But test kitchen definitely papered over the need to get a local environment running with all the dependencies, which might change with different services, and that seemed like a good thing.
I can maybe give some idea of what he's saying about containers. We do use Docker, and when I mentioned in my original comment that I aimed to lower the skill required to come onto a project, Docker is the primary vehicle for that effort. Here are my reasons:
1. Nobody has to install dependencies. Docker is the only dependency (with compose).
2. Everybody has the same configuration.
3. Software versions are (mostly) tightly controlled. This requires whoever sets up the dev environment to make sure they use specific versions, and not :latest.
4. Devs don't need to spend time worrying about how the dev
environment works, just the code.
This means that my README for a project usually has a section describing setup that just says:
1. run `dev/install` (any libraries from eg. NPM, go modules, etc.)
2. run `docker-compose up`
3. Check that the application is running on port XX.
This actually works great, and it does allow new devs to get to work quickly, and it does allow us to use devs that know very little about the underlying software that we're using, unless something doesn't work correctly. And that does happen, much more often than I would like. Then it takes my time and theirs to get up and running, and that was definitely not the goal.
When I'm asked a question I often respond it is on the wiki. If it isn't on the wiki it is your job to put it there. If it is wrong and you know why fix it. If it is wrong and you fail to figure out why, then talk to me, but I won't respond except to say I fixed the wiki.
That way the wiki stays up to date. Most corporate documents/wikis are worthless after a few years because things change but the wiki didn't. You need to constantly update it.
I would advise to be cautious with cast. It can be powerful and mask bugs if you arent careful (ie, type checker said it's ok, so it must be ok!). You may also want to drop a comment if you use it.
Most people who go on about "the trades", I find, it's unlikely they ever personally worked them. Maybe their Father's. I doubt Marco Rubio has ever touched a hammer, let alone worked as a real laborer.
As for me, going to college was absolutley the thing that really changed my life course.
I grew up on a dairy farm in northern New York. Milked cows until I was 18 and then my dad sold the farm. So I joined the Navy. I did that for 6 years and then when I was about to get out in 2002, I can still remember an officer (you know, a guy with a degree) explaining to me that I was making this huge mistake getting out. Because I was successful in the Navy. Already an E6/FC1. My career was made.
So I asked him, if I'm successful on the inside, what makes you think I cant be successful on the outside? So I got a lot of reasons. It was a good pitch. He even talked to me about getting an associate's at the local college. I was almost there anyway, just a couple classes and I'd be done. At the end, he questioned if Bard, a private liberal arts school I was accepted to, was even accredited.
That's when I knew, not only did he not care, but he would seek to harm my potential future growth just for some metric.
Anyway, so I did go to Bard college. Graduated with a degree in economics, now I'm the CTO / CPO of a middle market company (7 or so years after graduating college).
Had I of stayed, I could have done other blue jobs on the outside someday. I know a guy who works on powerlines in Texas. Says he likes his job. Takes advil like its candy. It pays the bills.
My wife and I have saved a lot, even with two kids. Last year, after our company consummated its sale to a PE company, we've been able to buy our own house in Brooklyn.
If I became a truck driver like my dad did after the sale of the farm, I'm not sure I'd be in the same place today - but it's possible I suppose.
My brother is in the trades. Hes a master plumber and runs his own plumbing company. He's also been successful. His back is also totally shot.
I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work.
But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with.
With evolve + topics, many of the critiques of mercurial go away:
* Light weight branches for short development
* Ability to squash / fold - mutability
* Ability to rebase - mutability
With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.
That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta).
With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable.
Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”.
We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.
So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar)
Pain Points:
* Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”.
* Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero.
* Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial.
Benefits:
* In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble
* TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics.
* All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones.
* Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.
Your comment is criminally low. Every other comment is 'Git vs. Mercurial' and speculation as to why git has "won". Their not useless, but they are uninteresting technically. So, as a git aficionado, I thank you for a detailed analysis of Mercurial and this proposal.
Personally, I've only used Mercurial to check out some projects that use it exclusively (i.e. (previously) Python and Firefox) and to create a toy repo of no significance (to learn its CLI interface).
Just to highlight a couple things from your comment:
> Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.
By far the most annoying thing about going from git to mercurial is the overloaded concept of a 'branch'. I couldn't care less about the continued existence of my one-off, topic branch. TBH, I prefer the git concept of the reference pointer being culled in the process. The (git) branch's existence continues on only in the merge commit message. Although this assumes 1) an actual merge was committed (not rebased), 2) the merge wasn't fast-forwarded (--no-ff), and 3) the default merge message format was used.
> With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”.
> Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.
We use Github. IMO, Github made a HUGE mistake when they added the options to Rebase and Squash in-lieu of the only sane option, Merge. I suspect that a lot of users wanted these options because Github (still) refuses to drop the --no-ff from their Merge strategy. I prefer --no-ff, but I do agree that it does make for an ugly log graph; Unlike most people, I couldn't care less about pretty graphs.) Rebase and Squash shouldn't be considered "Merge" strategies. They're for cleanliness, but only prior to sharing changes. Having them in Github has made the process of figuring out what has (and hasn't) been merged just absolutely atrocious. I'll leave it at that, but needless to say my arguments haven't convinced my peers' desire for pretty graphs.
As far as other user comments, I think the most egregious suggestion has been (paraphrasing):
> Mercurial has (had) better documentation.
Which I think is patently false. Git' manpages are (and always have been) fantastic. git-scm.com has been around for as long as I can remember. If you really want to do so, you can get yourself deep into the git's technical documentation which will teach you everything about the file formats and algorithms that are being used. All of this documentation has been around since git maintenance was handed over to Junio Hamano (circa May, 2005); Long before it's popularity explosion.
