81–90 of 128 posts
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
You don't have much history in git at the moment.
Earlier quoted context omitted.
The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + com…
Can you elaborate on what you mean by immutable history, and how git lacks it?
Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred" truthful account.
You still get the same flexibility as git if/when you need the above mutability: it's not 100% immutable, it supports local rebases, and also global mutablity via "phases" - see Marcin's post on this. In an absolute worst case scenario you can also coordinate reclones of a repo of course, but generally speaking the point is that immutability is "on by default".
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
That was a busy meeting and the developer mailing list is very busy. It's great to see continued investment from so many interested parties. Judging by the notes in the wiki [1], however, the purveyors of my preferred server, Kiln, are not so engaged lately: > Available hosting solutions: Bitbucket, Kallithea (self-hosted), Kiln (still exists?) I believe it is maintained and even if not maintained would continue to w…
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
You don't have much history in git at the moment.
The initial clone time for hg and git is within the same order of magnitude (order of an hour), though git manages to be about 50% faster at that too.
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
Where were and are you hosting it? SSH vs HTTPS? Client? OS? Any hooks?
Part of the reason for the move is that we wanted to take advantage of the corp-wide infrastructure of an Atlassian stash server hosted in the cloud and professionally maintained, so as to get away from maintaining our own repo.
But the speeds I quote above were for the initial phase of the conversion, when both repos ran on the same ESX VM and direct comparisons were meaningful. Now that its hosted professionally in the cloud, it seems even faster.
Note that I'm across ~2500 miles of VPN from the home office, and that surely has something to do with it.
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
Why do you need to keep all 25 years of commits?
I know this is slightly tangental but I'm always a little shocked that Facebook (and I think Google to some extent) have massive mono repositories. The benefits of having one repository do not seem to be worth the serious performance issues as well as potential coupling that can happen with a gigantic code base as well also making much more difficult to OSS certain parts. e.g. why doesn't FB use dependency management…
Anyone who is old enough to remember the pain of VCSes like CVS and RCS will note that the number one feature touted to move to any other VCS is invariably "atomic changesets"--all the necessary changes to files are listed in a single changeset. Monorepos are nothing less than remembering the value of those atomic changesets. An example of utility of monorepos is things like automation--if you change, for example, ho…
That said I have no idea how Netflix does source control, only that they use BitBucket/Stash on-prem and that supports both mercurial and git.
hg absorb sounds very useful. I'd like to know details, since I can imagine undesired results it might produce.
https://bitbucket.org/facebook/hg-experimental/src/default/h...
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
> 25 years of history Why do you need to keep all 25 years of commits?