[10:31]  * LeoNerd is somewhat surprised that 'bzr shelve' in a git checkout /mostly/ works
[12:03] <jelmer> LeoNerd: with bzr-git, presumably?
[12:10] <LeoNerd> Yeah.. admittedly it did crash, but it seems to have crashed after storing the shelf and unpatching it from the workdir.. so it's quite servicable
[12:11] <LeoNerd> I'm currently developing a server using python in git, a client using perl in bzr, and an integration-test script between the two using perl in git. So it's a bit of a mixup in my head sometimes :)
[12:14] <jelmer> LeoNerd: that sounds.. suboptimal?
[13:10] <thrustcore> bzr has been updating for 2 hours, should I break the lock and start again or should I wait for it to finish?
[15:44] <mark06> anyone experimenting with bzr-hg or fastimport?
[15:45] <mark06> I managed to make bzr-hg proceeed after a path to the mercurial lib, but then it takes hours processing the "manifests", up to failing due to some memory error
[15:47] <mark06> as for fastimport, none of the mentioned commands for exporting an hg repo exists
[23:12] <mark06> is there some way to merge a branch with no common ancestor?
[23:13] <mark06> surprisingly it seems to be a common case: http://zakalwe.fi/~shd/articles/why_not_bazaar.html
[23:13] <mark06> "Having a common ancestor is a strong "hint" that a merge is possible, but it should not be a technical requirement for merging. Git and hg both allow merging arbitrary trees together."
[23:22] <mark06> any progress after this? http://fourword.fourkitchens.com/article/creating-common-branch-ancestry-hard-problem
[23:24] <fullermd> I merge unrelated branches all the time.
[23:24] <jelmer> mark06: that article is very ignorant
[23:24] <jelmer> mark06: "bzr merge -r0..-1 <branch-to-merge>"
[23:40] <mark06> fullermd: how do you do?
[23:41] <mark06> full of conflicts, jelmer: http://vpaste.net/IY9Ku
[23:41] <jelmer> mark06: sure, if there are paths that exist in both you'll probably get conflicts
[23:42] <mark06> better formatted, http://vpaste.net/XXdgs
[23:42] <mark06> jelmer: which is exactly what the article says
[23:42] <jelmer> mark06: no, the article says that a merge is not possible
[23:42] <mark06> no it doesn't say that
[23:43] <mark06> let's put the vcs wars aside, I don't care about it, really
[23:43] <jelmer> mark06: " Bazaar version control tool demands that two trees that are merged must have at least one common ancestor, or cherry-picking must be used."
[23:43] <mark06> I just want to merge :)
[23:44] <mark06> jelmer: you mean the first post? ok
[23:44] <jelmer> mark06: merging two branches with different file ids for the same paths is problematic in bzr; you need to pick the file ids of either side
[23:45] <jelmer> mark06: yes, the first post is wrong. The second post gives a reasonable explanation, at a quick glance
[23:45] <jelmer> (and yes, this is an unsolved problem.. it's a fundamental issue with file ids)
[23:45] <mark06> I wish they worked on "I’m currently looking at writing a custom merge handler (subclassed from  the standard merge3 in Bazaar) that would intelligently handle merges  where file paths do represent the same files"
[23:46] <jelmer> mark06: who are you referring to with "they" ?
[23:46] <mark06> I managed to resolve all the conflicts with lost of "just resolve" but then I get no merge at all but a plain commit
[23:47] <mark06> they = whoever was planning to write such custom merger
[23:48]  * mark06 curious how fullermd handles it
[23:49] <mark06> my real case is that if I ever get bzr-hg working, then I could work better with upstream repo for pidgin... currently I have committed 2.10.9 to a new branch supposed to get only upstream changes....
[23:50] <jelmer> mark06: ah, you're taking up bzr-hg development?
[23:50] <jelmer> mark06: there are lots of use cases for merging unrelated branches
[23:51] <jelmer> mark06: one is merging unrelated branches with non-overlapping files; file ids are not an issue there
[23:52] <mark06> not really, I made some progress with a small patch to mercurial's python module but then the manifests step takes too long and eventually fails with memory error (this is windows, the idea was trying it on my ubuntu server)
[23:52] <mark06> yeah my case is definitely overlaping files
[23:53] <jelmer> mark06: yeah, there is no good way of handling those (the name for this problem is "parallel imports")
[23:53] <mark06> since I have an upstream branch with one single commit for 2.10.9, and from which I based all of my work for pidgin++
[23:54] <jelmer> mark06: cool, bzr-hg is in need of some attention :)
[23:54] <fullermd> I merge really-unrelated branches, so there's minimal overlap in file names (and when there is, they usually really are different files, so resolution is renaming)
[23:55] <mark06> so instead of committing next version to the upstream branch (or breaking this into manual commits according to how often I update it)... I would like to merge the mercurial branch on top of that (all changesets after 2.10.9 I mean)
[23:57] <mark06> hopefully these many conflicts would be only for the first time...
[23:57] <mark06> I just don't understand because in my test, after solving all conflicts I got no merge at all, the commit was plain
[23:59] <jelmer> mark06: resolving conflicts should not remove pending merge parents