=== et_ [n=et@ip111.215.dsl-acs2.sea.iinet.com] has joined #bzr [12:21] Running 0.18.0. Have checkout. Tried to commit. Got "ERROR: parent_id ... not in inventory". Have no clue what caused this happen, or how to correct it. [12:27] Looks like if you bzr moved a file, and try to commit another file without first commiting the move, you get this error message. The work around is to commit the move first. === et_ [n=et@ip111.215.dsl-acs2.sea.iinet.com] has left #bzr ["Leaving"] === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr [02:29] 4. he's got a *first* baby :) === BasicOSX [n=BasicOSX@216.70.10.130] has joined #bzr [03:50] can you uncommit a revision from the middle of the history? [03:51] like, if the current revision is, say, 3000, can I uncommit rev 2900 only? === rml [n=Skippy@78.32.35.169] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1177770446.dsl.bell.ca] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === keir [n=keir@bas15-toronto12-1168010434.dsl.bell.ca] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === NamNguyen [n=namnt@203.162.163.50] has joined #bzr === Theq629 [n=mwhitney@207.6.214.198] has joined #bzr [06:45] lapthrick: no, uncommit just pops the top off the branch, recursively === NamNguyen [n=namnt@cm103.delta195.maxonline.com.sg] has joined #bzr === NamNguyen_ [n=namnt@cm103.delta195.maxonline.com.sg] has joined #bzr === NamNguyen [n=NamNguye@cm103.delta195.maxonline.com.sg] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === n2diy [n=darryl@wlk-barre-208-103-147-226.dynamic-dialup.coretel.net] has joined #bzr === herzel88 [i=herzel@gateway/tor/x-84232ec7bb0c10f4] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === asabil [n=asabil@ti0035a340-0469.bb.online.no] has joined #bzr === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === phanatic [n=phanatic@160.114.21.241] has joined #bzr === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr [02:32] I'm confused that adding identical files is a conflict. [02:34] cory: when you `bzr add` the same file in two different branches, each of them gets assigned a different file-id, which is the id bzr uses to know if they're the same file or not === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr [02:49] I understand. I guess my gut expectation though is that it clobber files with the same name so that I can do a bzr status to see if they've actually changed, myself. [02:52] Also, if, say, I accidentally reverted that part of a merge and kept the files different, I have no idea how to cause them to merge again. [02:54] It's unfortunately guaranteed to happen the way I'm trying to round-trip changes with p4. :P === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has left #bzr [] === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === jrydberg [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === mw|out [n=mw@189.146.13.202] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === phanatic [n=phanatic@160.114.21.241] has joined #bzr === clsk [n=clsk@unaffiliated/clsk] has joined #bzr === dpm [n=dpm@p54A13579.dip0.t-ipconnect.de] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [08:34] jelmer: poke? [08:51] moin [08:51] cory: ping === asak [n=alexis@201-0-38-48.dsl.telesp.net.br] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [09:29] lifeless: Hiya. [09:29] hi [09:30] you're working on a p4 round-tripper ? [09:30] pong? [09:32] I just have some sketchy scripts I threw together. One to automate bringing changes from p4 to bzr, and one that just opens files for edit / add / whatever by comparing the current working tree and p4 branch in bzr. [09:33] ok [09:33] The first should really just be tailor, but fixing that was more daunting than making something that would work for now. [09:33] so a couple of notes about the guts that may help you [09:33] tailor is, IMO, broken by design [09:33] because its a lowest common denominator approach [09:34] Sure. [09:34] I prefer high fidelity myself [09:34] anyhow, bzr has an inode concept [09:34] files are accessible by path, but identified by 'inode', which we call 'file-id' [09:36] How would I take advantage of that? [09:36] we have some sketches for recording copying and merging of file-ids. When we have that it will be possible, and occasionally sensible, for merges that end up with a file with mostly the same content, at the same place, to be merged rather than placed alongside each other [09:36] Ah, neat. [09:36] but until those sketches are turned into reality you have a bit of a problem :) [09:37] there are a few ways around the issue [09:37] bzr-svn, which has the same issue, tackles it by assigning deterministically unique file-ids [09:38] which gives e.g. README in all branches of the same project on the same svn server the same fileid [09:38] http://pastebin.com/m63022805 <-- more bzr-svn fun [09:38] but unique across all other svn servers [09:38] Hrrrrm. [09:38] apparently you can't merge-into from an SVN repo, it goes wrong at some point [09:39] lapthrick: merge-into is a plugin command, it possibly uses the bzrlib api in ways that the bzr-svn author hasn't accomodatd. [09:39] How do files get added to a branch from the bzr side when you're working with bzr-svn? [09:39] lapthrick: I would file a question on bzr-svn about that [09:39] cory: bzr add :) [09:40] lifeless: you mean a question and not a bug now? [09:40] Does bzr-svn get involved and make sure the file has a proper file-id? [09:40] lapthrick: I suggest you work with 'bzr checkout svn:// && bzr merge && bzr commit' because that will preserve the history the same as merge-into, with the advantage of working. [09:40] lapthrick: yes, its not clear where the bug is. [09:40] lapthrick: so ask for help :) [09:41] cory: perhaps I misunderstood your question. I thought you meant 'bzr branch svn:/// foo && cd foo && touch BAR && bzr add BAR && bzr commit && bzr svn-push svn:////' [09:41] Oh, or is the original file-id stored in an svn property? [09:41] cory: yes, bzr svn-push (it will be integrated with bzr push sometime) annotates the svn repository [09:42] lifeless: but plain merge won't result in having a branch in a subdir, I do have it working with a branch made out of SVN, I just wanted to reduce the number of intermediate steps between upstream SVN and my branch-in-subdir [09:42] lapthrick: I don't understand what you mean [09:42] lifeless: well, I don't understand what I'm supposed to merge [09:43] lapthrick: what are you trying to do then? [09:44] cory: so if you don't want to annotate p4, you can just do a one-way solution, as long as the ids in different branches for the same file are the same bzr will be happy [09:44] cory: when you add a file on the bzr side, you will have a history disconnect after you get it coming back at you from p4, just take the p4 version always [09:45] lifeless: the same as I was doing yesterday (have a branch of an upstream SVN repo inside a subdir of my own repo), but pulled directly from SVN, instead from my-branch-of-upstream-SVN that serves no other purpose than to mediate between upstream SVN and my branch-in-a-subdir [09:45] lifeless: Yeah, that sounds sensible. [09:45] cory: and do a manual merge (patch foo < diff foo.ORIG foo.THIS) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [09:45] lapthrick: do you mean 'repo' or 'tree' ? [09:46] lifeless: tree [09:46] lapthrick: the terms are not interchangable for bzr. [09:46] yeah, I guess [09:46] lapthrick: so, you have tree-root/upstream [09:46] where tree-root is a bzr tree === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr [09:46] and upstream is a svn checkout ?, or a bzr-svn branch from svn ? [09:49] lifeless: http://pastebin.com/m1a7e323 [09:49] is it more clear? [09:51] Random thought...or there could be something like patch queue manager performing the actual p4 submits. :) [09:52] what's p4? === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [09:54] lapthrick: I don't have a browser here [09:54] lapthrick: perforce [09:54] lapthrick: perforce, a vcs [09:54] lifeless: sec, I'll paste it in private [09:54] k' [09:54] cory: so you're writing p4 integration? [09:55] adhoc version I think [09:55] rather than e.g. bzr-p4 [09:55] Just hacking enough together to get by. :P [09:55] ah, so just a single project that's somehow dependent on p4? [09:56] lapthrick: I'm still confused; what is the relationship between mytree and myupstream; did you bzr join? or are you using the alpha-quality nested trees support? [09:57] lapthrick: its hard for me to understand what you mean, as your commands used paths that did not exist (you branch to myupstream, then cd to mytree; I can't tell what mytree is meant to be there) [09:58] lifeless: mytree is a pre-existing tree I want to have upstream as a part of. I want to get the same effect as bzr join would have, but I'm using merge-into for that [09:58] not nested trees [09:58] I don't understand why you use merge-into, rather than cd + bzr pull [09:59] merge-into is for doing *merges*, and if you are not changing the upstream, and its just a separate tree that happens to be positioned one dir down, then pull should work fine [09:59] lifeless: because I want to have upstream/ be seen as a part of mytree. Mytree is actually backed by an SVN repo, so when I push into it, I want upstream/ be uploaded as well [10:00] I'm essentially using bzr to manage SVN for me [10:00] ok [10:00] so if you want the content to be added and managed, you need to combine the trees. [10:00] that means 'bzr join myupstream' [10:00] but that's really experimental, right? [10:01] merge-into does the same, except without real nested trees support [10:01] (and with slight caveats because of that) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr [10:03] lifeless: will I get burnt badly if I use bzr join? [10:04] merge-into does an implicit join [10:04] you've already joined [10:04] after that you should just use regular merge [10:04] yes, I know [10:05] lifeless: it works, as long as I don't try to merge-into directly from svn:// [10:05] if I have that intermediate bzr-svn branch, it works like a charm [10:05] lapthrick: but why are you running merge-into more than once [10:05] lapthrick: I don't see why the intermediate branch is a problem as you only need it once [10:05] lifeless: I'm not, those were two different cases. First is what I did (and what worked), second was what I'd like to do [10:06] so, I'd definately record this somewhere [10:06] lifeless: oh, so I can merge with svn:// later on? [10:06] if so, it's even better [10:06] so that jelmer/john can look at the error [10:06] but merge-into is used to perform the join [10:06] yah, will do [10:06] you should not keep using merge-into [10:06] I'm not, I used it only once [10:07] righto. So now you use bzr merge svn:// and that should work [10:09] apparently it does, missing --other reports nothing [10:09] lifeless: thanks, I didn't realise I could do that [10:10] thats something John should add to the plugin docs [10:11] now I just need to figure out how to prod bzr-svn into making an actual SVN branch (ie. one that will result in a branch being created in the SVN repo) [10:11] bzr svn-push ? [10:11] hmm, or I can do it by hand and then rebind [10:12] lifeless: will it have the same effect as doing cd svncheckout && svn cp trunk branches/mybranch && svn commit ? [10:13] I don't know [10:13] ah, right, that's what it should do I guess [10:13] Anyone knows whether jelmer works freelance? [10:13] let's test it on something that's not my job repo though :) [10:14] Lo-lan-do: he's at uni still AFAIK === keir [n=keir@206-248-159-109.dsl.teksavvy.com] has joined #bzr [10:14] hi keir [10:14] Hmm. [10:15] lifeless, hey [10:15] lifeless, RL has been giving me the smackdown lately [10:15] I know the feeling [10:15] lifeless, so i haven't touched the indexing backend in awhile [10:15] I only made incremental partial commit 40% faster last week :() [10:16] that's sweeeet! [10:16] index reading is 14% of the remaining overhead ! [10:16] lifeless, cool [10:18] lifeless, is that because it has to read the entire index? [10:19] yes [10:20] awesome, it works [10:22] lifeless, when do you expect to merge packs? [10:24] keir: I'm hoping this week to have the code in bzr.dev [10:24] is there a way to retroactively change the committer on revisions? I have some revisions committed with the wrong name and would like to avoid mucking around with shelve if possible [10:24] lifeless, neat! [10:24] format freeze will be once the index read issue is fixed [10:25] lifeless, have you looked at all at my code? [10:25] keir: at some yes [10:25] not at all [10:25] lifeless, i won't be able to touch it until tuesday [10:26] thats fine [10:26] lifeless, i feel like the code has become too complicated, and i'd like a second opinion [10:32] so what about changing the committer? Is that possible? [10:34] lapthrick, uncommit and re-commit? [10:34] lapthrick: bzr does not support altering or annotating existing revisions [10:34] keir: I wanted to avoid doing that [10:34] hmm, okay [10:34] lapthrick: we currently feel that this is too much complexity for too little return [10:34] lifeless, what about the 'nuclear launch codes' problem? [10:34] keir: uncommit and garbage collect [10:34] lifeless, i've personally run into that and had to hex edit a svn repo [10:35] there are plugins that can create new revisions from existing, preserving the deltas etc [10:35] lifeless, aah, ok. in my case it was several revs behind [10:35] but the *meaning* of the revision changes when you remove a file from it [10:35] or change its content [10:35] its hash changes [10:36] okay, so what will be the easiest change to pop a series of commits, then recommit them, just with a different name? If I could avoid typing in commits messages anew, it'd be helpful [10:36] s/easiest change/easiest way/ [10:36] lapthrick: check the rebase plugin out; AIUI it will do what you want [10:36] of course, it may not ;) [10:37] ah, right [10:37] I wonder how experimental it is === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [10:47] bzr bzr-pokerolymp:2085/> log -r ancestor:svn+https://beta.aimido.de/svn/src2/trunk [10:47] Unhandled error: [10:47] 'NoneType' object has no attribute 'base' [10:47] interesting [10:49] bug filin' time :) [10:49] bzr bzr-pokerolymp:2085/> log -r branch:svn+https://beta.aimido.de/svn/src2/trunk [10:49] A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mathrick/Dev/rails/bzr-pokerolymp/.bzr/repository/) [10:49] man, I'm good :) [10:51] intereseteing [10:51] log should be read only [10:52] I'm better bzr-svn is the culprit === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1177770446.dsl.bell.ca] has joined #bzr === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #bzr === igc [n=igc@ppp121-45-227-231.lns1.bne4.internode.on.net] has joined #bzr [11:55] morning all [11:55] hola [11:55] you're up early :)