Kiln Harmony

[Max Horn]

Hi there,

I just came upon this blog post:
http://www.joelonsoftware.com/items/2013/03/11.html

and then (with much detailed information)
http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/

They are *very* boastful and claim

"Everything maps. Everything round-trips."

I am (naturally) somewhat sceptical, but it certainly might be interesting to learn more. One thing we should look into is that they claim they are
"repeatable, lossless, and idempotent"

That is, if converting the same commit twice, in different contexts, this should still yield identical commit ids in the converted result. So if I convert a hg repository to git today; and then convert it again, independently, on another machine, perhaps on a latter date (with more commits accumulated in the hg repository), then still: The commit with id 12345 on the hg side should be mapped to the same git commit in each cases (with the same commit hash).

I believe this is not currently the case for us, at least it wasn't when I tried this a few weeks ago. I am not sure whether that was due to changes in gitifyhg (I was comparing a repository converted using an older version to the then most recent version). In any case: I really think that would be an important feature, and we should log an issue for it.


Also interesting is how they handle multiple heads on a single hg branch, etc. They offer a live Q&A next week for a limited set of participants: If any of you has time March 19th, 2013, 2 PM EST, perhaps consider joining that, and asking some questions:
http://www.fogcreek.com/nocompromise/index.html?fccmp=bannounce


Cheers,
Max

[Max Horn]

On 13.03.2013, at 09:23, Max Horn wrote:

> Hi there,
>
> I just came upon this blog post:
> http://www.joelonsoftware.com/items/2013/03/11.html
>
> and then (with much detailed information)
> http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/

PS: I should mention two more things:
1) They will "be running a series of articles in the coming days on how Kiln Harmony works", so watch that place ;-).

2) It is possible to get a free 45-day trial of Kiln, might be worth looking at that one day ;-).

Cheers,
Max

[Jed Brown]

On Wed, Mar 13, 2013 at 3:23 AM, Max Horn <m...@quendi.de> wrote:

They are *very* boastful and claim

 "Everything maps. Everything round-trips."

I am (naturally) somewhat sceptical, but it certainly might be interesting to learn more. One thing we should look into is that they claim they are
  "repeatable, lossless, and idempotent"

That is, if converting the same commit twice, in different contexts, this should still yield identical commit ids in the converted result. So if I convert a hg repository to git today; and then convert it again, independently, on another machine, perhaps on a latter date (with more commits accumulated in the hg repository), then still: The commit with id 12345 on the hg side should be mapped to the same git commit in each cases (with the same commit hash).

I believe this is not currently the case for us, at least it wasn't when I tried this a few weeks ago. I am not sure whether that was due to changes in gitifyhg (I was comparing a repository converted using an older version to the then most recent version). In any case: I really think that would be an important feature, and we should log an issue for it.

I would like to know where in the git repository they encode the sort order of a file listing for a commit made by Hg. Old versions of Hg used Python dict order instead of lexicographic order.

http://selenic.com/pipermail/mercurial/2011-June/038850.html

Notice how casual they are here about the inability of their own tools to round-trip. This would be like 'git fast-export | git fast-import' not reproducing.

[Dusty Phillips]

On 13/03/13 02:23 AM, Max Horn wrote:
> Hi there,
>
> I just came upon this blog post:
> http://www.joelonsoftware.com/items/2013/03/11.html
>
> and then (with much detailed information)
> http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/
>
> They are *very* boastful and claim

Coincidentally, my company has been thinking of switching to Kiln for
its other features. I'll be seeing a presentation on the topic today.

Dusty

[Max Horn]

They put out the first technical article, and I am impressed:

http://blog.fogcreek.com/kiln-harmony-internals-the-basics/

However, it also is clear to me now that they solve a somewhat different problem: They provide a "repository server" that can serve both hg and git clients seamlessly. That is a bit different than what gitifyhg attempts to do. In particular, they can afford to intentionally produce "corrupt" data in these repositories (which may sound insane at first, but they explain quite well how and why they do it. And it makes sense if you think about the "non-canonical Mercurial commits" issue we discussed earlier (were "equivalent" hg commits with essentially identical content can end up with different ids).

On the git side, they also add lots of custom commit headers, which is greatly frowned upon by the git.git community (see e.g. http://thread.gmane.org/gmane.comp.version-control.git/138848). And those extra headers will be dropped by e.g. an --amend or rebase -i, so it is not suitable for use in a working tree. But server side, sure.


Cheers,
Max