Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial 4.0 Sprint Notes

groups.google.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#61

Post by ngoldbaum »

Bjartr wrote: post #59
marcinkuzminski wrote: post #14

Earlier quoted context omitted.

CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only…

Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.

This workflow is described in the documentation for the mercurial evolve extension: https://www.mercurial-scm.org/doc/evolution/

Re: Mercurial 4.0 Sprint Notes

#63

Post by alblue »

avar wrote: post #49
kyrra wrote: post #16

Earlier quoted context omitted.

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more compl…

The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.

There is no ".git" file. It's a directory with a lot of files. Some of the packing has been storage optimisations but the logical model (objects identified by hash) has remained the same throughout.

The nice thing about this is you can present the same logical model while being flexible about the way that model is persisted, unlike Mercurial which has a fixed file format upon which operations are based.

Re: Mercurial 4.0 Sprint Notes

#64

Post by rjbwork »

warbiscuit wrote: post #55
agentgt wrote: post #19

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…

Aside from all the other technical bits, one killer feature for my company is TortoiseHG ( http://tortoisehg.bitbucket.org/ ). Unlike a number of the other Tortoise-* projects (which don't seem related actually), TortoiseHG is a really great cross-platform gui, written in python & qt -- runs just about everywhere, and makes working with mercurial uniformly easy. The fact that instead of "hg ci" I can type "thg ci" an…

Yeah, THg is the absolute best DVCS GUI client I've had the pleasure of using. Everything else is awful and confusing in comparison IMO.

I even use it for Git with hggit sometimes.

Re: Mercurial 4.0 Sprint Notes

#65

Post by rjbwork »

pjmlp wrote: post #21
the_duke wrote: post #6

I had no idea Google and FB were dabbling with Mercurial. I checked it out years ago, but pretty much settled on Git. What are the advantages?

A sane distributed source control system implemented in Python. I am still disappointed that Git won.

Depends on your definition of won, I guess...fourth job in a row using Hg. I've never used git professionally, just for OSS stuff.

Re: Mercurial 4.0 Sprint Notes

#66

Post by smegel »

agentgt wrote: post #19

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…

Maybe Docker is the solution.

Your "working state" is now in an image (maybe a Docker file that checks out particular revisions of different repos), so putting everything into one giant VC repo is not necessary.

A versioned Dockerfile that says "this is how we built SystemX at version 1.5" is much better than doing it in Git, as it also covers how the underlying server was built, while a giant git repo might have every application you need at the correct version, but won't say anything about the server it is deployed to.

Re: Mercurial 4.0 Sprint Notes

#67

Post by glandium »

tux1968 wrote: post #58
hinkley wrote: post #48

Earlier quoted context omitted.

The big thing I miss about Subversion is that you could check out one subtree. On the biggest SVN project I worked on, we built 5 binaries from the same code tree, but only the leads and a couple of senior devs that worked on crosscutting concerns (ie, the people who would do the mass edits you mention) had the entire tree checked out. Everyone else had just the one or two modules they were working on. The second big…

This post is about Mercurial with which i'm not familiar, but in Git you can checkout a subtree since version 1.7[1]. It's commonly called "sparse checkout". [1] http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s...

But you still need to clone the whole thing. Sparse clones are theoretically possible, but aren't implemented AFAIK.

Re: Mercurial 4.0 Sprint Notes

#68

Post by jjnoakes »

cyphar wrote: post #40
pjmlp wrote: post #35

Earlier quoted context omitted.

Well, on Windows we also have COM, but I get your point. Going off topic, maybe someone will eventually do a SQLLite re-write as well and other critical projects to our modern stacks that still rely on C.

> Going off topic, maybe someone will eventually do a SQLLite re-write as well and other critical projects to our modern stacks that still rely on C. SQLite does not need to be rewritten. It has the best and most comprehensive test suite in the history of software development -- I would go so far as to say that there are no implementation bugs in SQLite (every single branch in the code has been extensively tested and…

I'm not advocating one way or the other, but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent.

Now it probably isn't worth the effort for a very well tested project like sqlite, but that doesn't validate the premise.

Re: Mercurial 4.0 Sprint Notes

#69

Post by jjnoakes »

lucideer wrote: post #8
the_duke wrote: post #6

I had no idea Google and FB were dabbling with Mercurial. I checked it out years ago, but pretty much settled on Git. What are the advantages?

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?

Re: Mercurial 4.0 Sprint Notes

#70

Post by glandium »

steveklabnik wrote: post #2

Relevant quote: > Facebook is writing a Mercurial server in Rust. It will be distributed and > will support pluggable key-value stores for storage (meaning that we could > move hg.mozilla.org to be backed by Amazon S3 or some such). The primary > author also has aspirations for supporting the Git wire protocol on the > server and enabling sub-directories to be git cloned independently of a > large repo. This means yo…

It's interesting they're doing this in Rust. I would have expected them to do it in D.
Post reply on HN