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

51–60 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#51

Post by kyrra »

pierrebai wrote: post #37
cmrdporcupine wrote: post #28

Earlier quoted context omitted.

Been at Google for coming up 5 years and I don't think I'm giving away any secrets when I say don't recall there being any performance issues with the mono repository. And coupling is what is explicitly being sought, not rejected. The whole point is to build everything off head, keep head sane at all times, and avoid version dependency hell.

Then maybe you can answer a few questions: - Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? - What about release branches? If you need to intergrate a bug-fix in a sub-system, the magic mono-repo now means merging a fix is harder as it may…

From the ACM link someone else provided:

> An area of the repository is reserved for storing open source code (developed at Google or externally). To prevent dependency conflicts, as outlined earlier, it is important that only one version of an open source project be available at any given time. Teams that use open source software are expected to occasionally spend time upgrading their codebase to work with newer versions of open source libraries when library upgrades are performed.

So if an external library has to be updated, the entire codebase must be migrated all at once. Then Rosie is used to split the change into a lot of smaller changes (to be reviewed by all affected teams). Once all the smaller changes are LGTM'ed, it's submitted all at once.

Re: Mercurial 4.0 Sprint Notes

#52

Post by shoover »

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 work for ages, but I suspect we will be held to 3.x for a while.

[1]: https://www.mercurial-scm.org/wiki/4.0sprint

Re: Mercurial 4.0 Sprint Notes

#53

Post by marcinkuzminski »

shoover wrote: post #52

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's you best KILN feature ? I wonder if we can adopt it at RhodeCode

Re: Mercurial 4.0 Sprint Notes

#54

Post by DannyBee »

pierrebai wrote: post #37
cmrdporcupine wrote: post #28

Earlier quoted context omitted.

Been at Google for coming up 5 years and I don't think I'm giving away any secrets when I say don't recall there being any performance issues with the mono repository. And coupling is what is explicitly being sought, not rejected. The whole point is to build everything off head, keep head sane at all times, and avoid version dependency hell.

Then maybe you can answer a few questions: - Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? - What about release branches? If you need to intergrate a bug-fix in a sub-system, the magic mono-repo now means merging a fix is harder as it may…

"- Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? "

I own third party policy, so i can answer this. I'll stick to public info.

There are thousands of 3rd party libraries. The rules of the shared codebase is "third party libraries are not free headcount". You choose whether you use them or not (implicitly or explicitly). If you add a third party library, you get to maintain it, and stay within the support horizon of upstream. If you choose to use one, you get to stay up to date with the upgrades others make. If you need features not in the current version, you get to upgrade the library (and work with teams, who are not allowed to block you).

This is pretty much the only way to make it all work in practice (i'm aware of how it sounds. In practice, even upgrading stuff literally every google target depensd on takes a week. It's only stuff where folks let it go for 6 years [we now have better detection of out-of-date code] that become a problem to upgrade).

If you don't like it, don't use third party code.

Note that these rules make it just like any other code, because your problem is not specific to third party code.

Note that binary versioning, etc, is pretty much always a complete disaster in practice on a large scale

"the magic mono-repo now means merging a fix is harder as it may depend on other unrelated changes all over teh repo?"

This is rarely true in practice, because usually fixes are targeted.

Re: Mercurial 4.0 Sprint Notes

#55

Post by warbiscuit »

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" and get a commit window with cherry-picking and meld integration right off the bat is really powerful. I've not seen any good git guis that come close to it's featureset.

Re: Mercurial 4.0 Sprint Notes

#56

Post by ngoldbaum »

shoover wrote: post #52

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…

Mercurial doesn't use semantic versioning. If tooling that depends on mercurial breaks in a mercurial update, this is often considered a mercurial regression, so long as the tooling isn't using mercurial's internal APIs which have no backward compatibility guarantees.

I do know that the person primarily behind kiln harmony left a while ago and now works at Khan Academy.

Re: Mercurial 4.0 Sprint Notes

#57

Post by shoover »

marcinkuzminski wrote: post #53
shoover wrote: post #52

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's you best KILN feature ? I wonder if we can adopt it at RhodeCode

Hmm. I haven't looked at RhodeCode. For me Kiln has provided a good UI and workflow and just worked ever since their v2.4 or so. I'm not sure there is a particular best feature, but roughly these features are what come to mind:

- Code review UI including comment pane with one level of sub-threading and easy click and drag linking to lines of code, small changeset selection pane, and large scrolling code pane are simple and work well. By contrast, I'm less sure about github and bitbucket pull requests UI.

- largefiles

- Single sign-on and linking with FogBugz (if we reference a FogBugz case in a commit message, then the commits show up in the case notes)

Re: Mercurial 4.0 Sprint Notes

#58

Post by tux1968 »

hinkley wrote: post #48
avar wrote: post #31

Earlier quoted context omitted.

As someone who works at another company with a big monorepo, briefly: * Ability to change an API and all its users at the same time. * Circular dependencies become a non-issue in a lot of cases where the would be if you vendor your dependencies. * Even if you vendor your dependencies hunting for bugs is a lot easier, your bisect of a bug in a library will just come down the commit that upgraded it from 1.0 to 2.0 wit…

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...

Re: Mercurial 4.0 Sprint Notes

#59

Post by Bjartr »

marcinkuzminski wrote: post #14
lucideer wrote: post #8

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…

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.

Re: Mercurial 4.0 Sprint Notes

#60

Post by marcinkuzminski »

shoover wrote: post #57
marcinkuzminski wrote: post #53

Earlier quoted context omitted.

What's you best KILN feature ? I wonder if we can adopt it at RhodeCode

Hmm. I haven't looked at RhodeCode. For me Kiln has provided a good UI and workflow and just worked ever since their v2.4 or so. I'm not sure there is a particular best feature, but roughly these features are what come to mind: - Code review UI including comment pane with one level of sub-threading and easy click and drag linking to lines of code, small changeset selection pane, and large scrolling code pane are simp…

Thanks for sharing, actually those two first ones was our main focus from beginning.

We worked back in the days with Unity which was using kiln to make the code-review workflows similar.

If you miss kiln, you should check RhodeCode out, and our community edition is even open-sourced.

Post reply on HN