=== dewd [n=dewd@201009147182.user.veloxzone.com.br] has joined #bzr [12:21] Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 1 hour === radix [n=radix@70.91.133.157] has joined #bzr === niemeyer [n=niemeyer@200.140.230.150] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] [12:42] vila: hi === radix [n=radix@70.91.133.157] has joined #bzr [12:42] vila: two things, firstly you can only delete the line if its the last line [12:42] vila: if its not the last line you break dictionary references === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr [12:43] vila: secondly, please keep NEWS in alphabetical order as per the list thread a few weeks back. === radix [n=radix@70.91.133.157] has joined #bzr === asabil [n=asabil@ti0035a340-0469.bb.online.no] has joined #bzr === radix [n=radix@70.91.133.157] has joined #bzr === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr [01:21] Yay! [01:22] 10 points to Launchpad for using a "503 Service Temporarily Unavailable" for the maintenance page. === duckx [n=Duck@tox.dyndns.org] has joined #bzr === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === besonen_mobile2 [n=besonen_@71-220-234-148.eugn.qwest.net] has joined #bzr === igc [n=igc@ppp121-45-206-141.lns1.bne1.internode.on.net] has joined #bzr === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr [02:30] New bug: #141629 in bzr ""bzr reconfigure" with no arguments throws an exception" [Undecided,Fix committed] https://launchpad.net/bugs/141629 === J-Unit [n=jdong@SIMMONS-THREE-SIXTY-FIVE.MIT.EDU] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1177770446.dsl.bell.ca] has joined #bzr === J-Unit is now known as j-dizzle === BasicOSX [n=BasicOSX@216.70.10.130] has joined #bzr [03:43] LP going down for maintenance in 15 minutes for 1 hour [03:44] Am I experiencing deja vu? [03:44] :P [03:44] What's up with LP? [03:46] Peng: we ran into some problems during the previous maintenance window, so it had to be rolled back. we've resovled them and trying again to rollout the new code [03:46] Peng: sorry for any inconvenience [03:51] Ah. [03:51] No problem or anything. I was just curious. === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === mw is now known as mw|out === jelmer_ [n=jelmer@h66-201-205-140.gtconnect.net] has joined #bzr [07:14] lifeless: soooo, I broke my repo dictionary reference because I didn't respect alphabetical order in NEWS... Naah, I can't believe that... Will drink another coffee first [07:27] lifeless: ok, so, the corrupted revision is the fourth from the end, you're saying I should delete the four to recover my repo. Should I track those revisions in the repository/knits hierarchy too ? [07:29] lifeless: About NEWS, I saw your first notice, I had read the thread but haven't realized the decision have been taken, I will comply. As soon as I can :) [07:40] New bug: #141555 in bzr-svn "Breakage with invalid SSL certificates (dup-of: 82086)" [Undecided,New] https://launchpad.net/bugs/141555 === liw [n=liw@a91-154-119-10.elisa-laajakaista.fi] has joined #bzr === CardinalFang [n=c@217.194.71.122] has joined #bzr === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [09:08] bbib === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === eugene [n=eugene@redhat/eugene] has joined #bzr === eugene [n=eugene@redhat/eugene] has left #bzr [] === rml [n=Skippy@78.32.35.169] has joined #bzr === Starting logfile irclogs/bzr.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by poolie at Wed Sep 12 03:35:03 2007 [10:27] win 20 === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by poolie at Wed Sep 12 03:35:03 2007 [12:45] lifeless: no, was waiting for a confirmation, trying to reproduce it in clean env, etc === duckx [n=Duck@tox.dyndns.org] has joined #bzr [12:46] can't reproduce it so far :-/ === Vernius [n=tomger@p508AC622.dip.t-dialin.net] has left #bzr [] === phanatic [n=phanatic@dsl54028230.pool.t-online.hu] has joined #bzr [01:12] lifeless: http://paste.ubuntu-nl.org/38243/ describes the corrupted revision [01:13] all zeroes, scary [01:13] Could your last tuned_gzip.bytes_to_gzip be related ? [01:14] My suspects so far: hardware problem (but find nothing else to confirm this), [01:15] NFS, the repo is on HFS+ on OSX, mounted as NFS, but the commit itself was from OSX [01:16] your last modification to tuned_gzip.bytes_to_gzip, but only because it modifies a code that may be related, I found nothing especially suspect in your modification, I just try to enumerate possible causes [01:17] this is mainly an annoyance because the repo holds everythin bzr related (including plugins) and it seems many commands try to read that revision even from branches that have nothing to do with it [01:18] for safety, I think I will reorganize this whole hierachy in several repos, just because I wanted to do that for quite some time [01:19] I lack time to hack as much as I want on this bug, but I may need to at least fix the .kndx (or several ? That's the point I want confirmation on) just to extract the right info (I still have several long lived branches in this repo) [01:21] I've made a backup of the whole hierarchy (888MB) and of the repo itself (93MO) and also from the .bzr.log of the two machines that may be involved [01:21] All are available for diagnosis [01:23] I lose some time doing that because tar suddenly told me 'file change while we read it' that scared me and made me think a little bit longer that I had an hardware problem (doing two consecutive tar and comparing them with cmp yielded ~3000 differences) [01:24] See what happens when you step away from the computer for a couple weeks?? [01:25] After searching for the tar format and looking at the tar sources, it appears that some long file names triggers additional blocks containing the *current* date and time (sic), so false alert, I just learned that you can't compare two tar files :-/ [01:26] fullermd: hehe, did you know about tar wart above ? [01:27] Not specifically what it was, but I did know that two tars of the same source aren't necessarily equal, even if they are equivalent. [01:29] fullermd: what a shame... apparently this is triggered by block checksums being different (so far so good), the blocks in question are special blocks preceding file header blocks for long file names [01:29] these blocks contain a mtime field, which is useless for them so they put 0 [01:30] ... and somwhow this 0 is converted to current date... boom [01:30] fullermd: and the 'file change while we read it' rings a bell ? [01:31] I triggered it by asking OSX the size of the folder I was tar'ing, silly me, lost a couple more minutes for that :-/ [01:33] the hard part was confirming that, indeed, OLDGNU_FORMAT (described in tar.h as 'obsolete RSN') was still the current format on OSX (and surely elsewhere) and that, yes, it includes an 'atime' field [01:33] Never figured tar knew about that.... [01:42] lifeless: http://paste.ubuntu-nl.org/38244/ contains the .kndx files identified, thanks for confirming that deleting the lines (last of each file) will fix my repo (to the best of your knowledge :) === rml [n=Skippy@78.32.35.169] has joined #bzr [01:44] lifeless: I'm ready to loose the two branches involved, osx.pass.test.suite and bzr.integration === tuXXX [n=damien@ARennes-258-1-127-138.w90-25.abo.wanadoo.fr] has joined #bzr === CardinalFang [n=c@217.194.71.122] has joined #bzr === GaryvdM [n=chatzill@mtngprs5.mtn.co.za] has joined #bzr [02:32] When I bzr push on a sftp, files and directory aren't created, only .bzr, it this the correct behaviour? [02:32] tuXXX: Yes. [02:33] tuXXX: .bzr is all that's necessary to run bzr branch on it. [02:33] Then I need a web front-end to display those files on my web server [02:33] tuXXX: You can run "bzr checkout", then run "bzr update" in a cronjob or something. [02:34] tuXXX: Or using bzr+ssh might do it, I dunno. [02:34] tuXXX: Loggerhead is an advanced web front-end. I dunno about anything simple. There's bzr-webserve, but I'm not sure if it's maintained. === Peng wanders off. [02:35] sftp is useful because it doesn't need bzr to be installed on the server [02:35] Yeah. === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr [02:39] tuXXX - There is a plugin that does that. I'm just going to find it... [02:41] There is https://launchpad.net/bzr-push-and-update/ [02:42] ok [02:43] bzr still needs to be installed server-side [02:43] Yhea :-( === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr === xOjka [n=wyller@141.80-202-66.nextgentel.com] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr [03:04] ok so I have to do a "bzr checkout ." on the server [03:04] and it's work [03:04] *and it works [03:26] hrmm [03:26] so Gutsy's bzr can't cope with https:// [03:28] lapthrick: what do you mean ? [03:28] vila: https://bugs.launchpad.net/bzr/+bug/141105 [03:28] Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [Undecided,New] [03:29] first I thought it was bzr-svn that was failing, but it turns out to die for plain bzr https:// uris as well [03:29] how so ? Can you try with https+urllib:// too ? [03:30] sure [03:30] gutsy? what is that [03:30] newest ubuntu, not released yet [03:30] ah [03:31] <-- Gentoo user [03:31] and FreeBSD [03:31] vila: works with urllib, yeah [03:32] I actually suspected it might be libcurl-gnutls's fault [03:33] I should definitely look at that new version, that error code 77 may indicate some API break somewhere [03:33] ah, of course, you commented on that bug :) [03:34] lapthrick: you're using a stock gutsy is it ? [03:34] aye [03:34] lapthrick: yeah, didn't recognize you as mathrick either :) [03:34] :) [03:35] I need to setup an irc proxy [03:36] lapthrick: if urllib is fine with you, keep using it, be aware that it makes *no* certificate verification though, track bug #82086 if you want to be kept informed on progress [03:36] Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] https://launchpad.net/bugs/82086 [03:38] vila: I see. That's strange though, as the original svn repo from that bug I have authenticated permanently with plain svn client === lapthrick guesses "multiparent" plugin is not intended for end-user consumption yet [03:40] nothing strange in that :) svn should do proper certificate verification :) [03:40] given the exceedingly brief help it has [03:40] lapthrick: I think if you use svn+https:// for bzr-svn on that repo you will havee more success. [03:40] vila: but isn't it supposed to re-use svn cache? [03:40] james_w: yes, I needed a newer bzr-svn though [03:40] I just got it, lesse if it works now [03:41] lapthrick: 1) I don't know what bzr-svn does, 2) we are not talking about credentials, we are talking about certificates [03:42] the server send a client saying: That's who I am (my certificate), this certificate have been validated by vendor$$$ [03:42] vila: yes, using svn client I accepted that certificate permanently [03:42] Ok, so it means bzr-svn doesn't use that [03:43] I think jelmer says that bzr-svn works fine, it is just that bzr is probing for a bzr branch first, and so fails, adding svn+ bypasses this and goes straight to using the svn client, and so uses the stored information. [03:44] ah [03:44] james_w: that makes sense [03:44] ah [03:44] mathrick@hatsumi:/tmp$ bzr cl svn+https://beta.aimido.de/svn/src2/trunk [03:44] Segmentation fault (core dumped) [03:44] :( [03:45] it fetches the revisions info properly [03:45] then dies [03:45] cl == checkout --lightweight [03:45] lapthrick: you should report that against bzr-svn, jelmer will want to know. [03:45] a backtrace might be appreciated. [03:46] mhm, if I can get a sensible trace [03:47] I believe there are python debug packages, and maybe libsvn ones as well. [03:47] yeah, I'll just check if it happens with branch as well [03:59] seems to work just fine with branch === fog [n=fog@debian/developer/fog] has joined #bzr [04:10] hmm, isn't bzr status in an svn checkout supposed to work? [04:10] it doesn't for me [04:11] yeah it should I think. [04:11] oh wait, wrong dir [04:11] I forgot trunk/ [04:12] If you're getting a segfault, you should try running it under gdb. That's a bug on the C side. [04:12] abentley: I know :) === CardinalFang [n=c@217.194.71.122] has joined #bzr [04:28] h, what was the command to see the difference between branches? [04:30] in terms of revisions, `bzr missing` [04:30] (for diff, obviously `bzr diff`) [04:33] yeah, I just saw missing [04:33] thanks though === jelmer_ [n=jelmer@h66-201-205-140.gtconnect.net] has joined #bzr === jelmer is now known as jelmer_ [04:47] hey jelmer_ [04:48] hi lapthrick === asabil [n=asabil@ti0035a340-0469.bb.online.no] has joined #bzr [04:50] jelmer_: seen my latest bugreport? [04:51] I don't seem to be able to get a sensible trace, btw [04:51] yep [04:51] is python-dbg `which bzr` ... the correct way to get a backtrace from bzr? [04:52] `bzr co --lightweight`is just an alias for 'svn co ...' btw [04:52] jelmer_: oh [04:53] mathrick@hatsumi:/tmp$ svn co svn+https://beta.aimido.de/svn/src2/trunk [04:53] svn: Undefined tunnel scheme 'https' [04:53] without the svn+ :-) [04:53] ah, that's the problem [04:54] jelmer_: hmm? So the svn client underneath dies and it crashes because of that? [04:54] bzr gdiff [04:54] err wrong window [04:54] lapthrick: Yes, that's what I suspect [04:54] GaryvdM: :-) === lapthrick runs bzr shell [04:54] it's noticeably faster [04:55] lapthrick: I gave up trying to set it up on windows [04:55] lapthrick, can you try running that checkout command in gdb? [04:55] jelmer_: and bzr-svn is , especially now I got it to check out my work repo [04:55] jelmer_: I guess so [04:57] jelmer_: ah, yes, that's much more sensible === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr [04:57] 0x080a215c in PyString_FromFormatV ( [04:57] format=0x816de98 "'%.50s' object has no attribute '%.400s'", [04:57] vargs=0xbfb19f38 "\001") at ../Objects/stringobject.c:202 [04:57] 202 ../Objects/stringobject.c: No such file or directory. [04:57] in ../Objects/stringobject.c [04:59] jelmer_: http://pastebin.com/m33018646 [05:00] thanks [05:01] looks like another python-subversion bug [05:01] I see [05:01] jelmer_: why is there a difference between what schemes svn and bzr-svn handle anyway? === Qhestion [n=Linrev@Z7bb5.z.pppool.de] has joined #bzr [05:03] lapthrick: bzr-svn supports everything that svn supports [05:03] lapthrick: and it also supports 'svn+https' to work around that problem with SSL certificates [05:03] jelmer_: yeah, but it was bailing out with the same error earlier, before I upgraded to 0.4.3 [05:04] hi. can i put my bzr installation (from the windows installer) on my usb stick? [05:04] and isn't svn supposed to understand svn+https://? It's not uncommon to see urls like that on the net [05:04] lapthrick: it supports svn+ssh://, svn://, http:// and https:// [05:05] lapthrick: which error did it bail out with earlier as well? [05:05] Qhestion: you mean the files that it installed or the setup file? [05:05] "Undefined tunnel scheme 'https'" [05:06] the files it installed [05:06] i just dont want to run the installer on the target machine [05:06] (read: can't) [05:07] Qhestion: should work ok as long as all the dependencies are installed [05:07] dependencies? [05:07] Qhestion: I've never tried it, but I can't see why not. [05:07] Qhestion: python, paramiko if you would like to use sftp, etc [05:07] this is the "standalone installer" [05:07] there shouldnt be dependencies [05:08] and no sftp needed, only local (usb stick) repos [05:08] Qhestion, not sure in that case, I don't know where that installs its python binary [05:08] Most of the dependencies are built into the installer, except the ssh stuff [05:08] well, in C:\Programs\Bazaar there is a Python25.dll [05:08] guess that is python ;) [05:08] lapthrick: bzr-svn has to strip the svn+ bit for svn+http and svn+https before it passes urls to the svn libraries [05:09] there was a bug where that wasn't happening in bzr-svn 0.4.1 I believe [05:09] ah [05:09] jelmer_: I thought svn+whatever was a general syntax [05:09] Qhestion: I'm sure it will work - give it a go [05:10] i only have one try [05:10] ;) [05:11] Qhestion: can't you ask a random friend if you can test if it works? [05:11] most probably they won't have bzr installed, so it's a good way to find out [05:12] lapthrick: all my friends already got python ;) [05:12] and bzr [05:12] ya know, i need some people to test my software ;) [05:13] i stopped programming in python, but i use Bazaar as version control system, and also to publish my sources [05:13] hmm, i remember i should go back to the bazaar bugtracker [05:13] filed a feature request there [05:13] Qhestion: I can do a test on my sisters machine when she gets home - probably in about 15 min. [05:13] k [05:14] thank you [05:14] shall i send you a zip ? [05:14] ok [05:14] garyvdm@gmail.com [05:16] woo 11 MB [05:16] this will ake a bit [05:16] lapthrick: you can add custom tunnel mechanisms to svn for the native svn protocol [05:16] the http protocol is different though [05:16] lapthrick, Thanks for the backtrace, I have to head out now, will have a look at it later today. [05:16] don't worry - I'll download the installer [05:16] ok === jelmer_ is now known as jelmer === asak [n=alexis@201-1-42-33.dsl.telesp.net.br] has joined #bzr [05:44] Qhestion: It works [05:45] And my sister dose not have admin rights on her machine [05:45] s/dose/does === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr [05:46] Garyvd: thank you [05:47] Garyvd: she does not have admin on her own machine? lol. good job ;) [05:48] It's a work machine from a big corporate... [05:48] oh [05:50] phanatic: hey [05:50] schierbeck: hi :) [05:50] phanatic: i was thinking [05:51] do you really need a date column in the viz treeview? [05:51] it happens quite often with big projects that the window becomes too wide [05:52] good question, it's nice to see the date right away, not just in the details. but it often runs off the screen because of the graph being too wide [05:53] phanatic: but i'd rather have a nice, easy-to-comprehend graph than a timestamp... [05:54] i mean, it's not often you actually *need* to know the exact time of a commit, or do you? [05:54] it may just be me... [05:54] yeah, you're probably right [05:55] i think i'll create a branch and toy around with it [05:55] schierbeck, phanatic: I've hacked up a possible solution to reduce the with of the graph. I was just emailing phanatic about it. === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr [05:55] s/with/width [05:55] actually i was thinking about redesigning the full thing. e.g. display only the graphs, and the details only when you move your mouse on a node. what do you think? [05:56] https://code.launchpad.net/~garyvdm/bzr-gtk/brokenlines [05:56] GaryvdM: cool, as long as the graph is still easy to read [05:56] phanatic: i like the commit message being there, and sometimes the author [05:56] but there's no need for both the author name and email [05:57] Thats a good point... [05:57] indeed === Qhestion [n=Linrev@Z7bb5.z.pppool.de] has left #bzr [] [06:03] GaryvdM: i'm not sure about the new graphs, i took a look, and it's a bit curvy (?) [06:03] of course, i'm no authority on the subject [06:03] GaryvdM: this brokenlines stuff is pretty interesing [06:03] schierbeck: imho they look better this way [06:05] phanatic: okay, it seems i'm outnumbered in my favor of straightness :P [06:05] :D [06:05] i really like the way broken lines are handled [06:05] in the new branch, that is [06:06] yep, me too [06:06] does it load faster as well, or it's just me who feels it? :) [06:08] I hope so :-) [06:09] I should only be loading the revision data after the first screen is shown [06:10] I'm hoping I can get it to only load the revision data for a rivision when it is scrolled into view. [06:11] s/I/It [06:11] 2.625s on bzr.dev, that's quite impressive [06:11] GaryvdM: do you think you could get the merge and branch-off lines to join at a different angle? [06:12] Yes - play with the curve controll points [06:13] phanatic: i've made a version of viz without the date column, have a look: https://code.launchpad.net/~dasch/bzr-gtk/viz-remove-timestamp-column [06:13] GaryvdM: ok, i'll look into it [06:13] huh, with current bzr-gtk trunk it takes 25.085s [06:13] viv/graphcell.py line 181-187 [06:13] oops, 15.085s that is :) [06:13] but still 7 times more than with brokenlines [06:16] New bug: #144071 in bzr "dirstate-tags format is expensive for network operations?" [Undecided,New] https://launchpad.net/bugs/144071 [06:16] schierbeck: thanks, i will :) [06:16] phanatic: i'm also looking into cutting off the email portion of the committer id [06:16] great [06:17] GaryvdM: what do you think: is brokenlines stable enough to get in into 0.91? [06:18] I don't know - I would love to have testing done on it. [06:18] Lots of new code. [06:19] s/more testing [06:20] fine, i won't merge it then before the release :) [06:20] Yhea - lets merge it just after the release. [06:21] phanatic: the new version should have been pushed to lp now, got a little ahead of myself before [06:21] i also tried making the graph column non-resizable [06:21] i think it is actually better -- when do you *not* want to see the branch graph? [06:24] schierbeck: if it gets too wide, maybe? [06:25] phanatic: perhaps, but i think the graph is the main feature of the viz -- without it, it's really hard to navigate [06:25] yes, you're right [06:25] i think it's better to make sure the graph will almost never be too wide [06:25] :) [06:26] that's where brokenlines comes into the scene ;) [06:31] phanatic: i've pushed the changes to lp; the email part is now hidden in the treeview [06:32] my implementation is not perfect; i guess the separation of name and email should go in bzrlib, not in bzr-gtk [06:33] i get a traceback here [06:33] Traceback (most recent call last): [06:33] File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/viz/branchwin.py", line 190, in populate_model [06:33] committer = revision.committer.split('<')[0] .strip() [06:33] AttributeError: 'NoneType' object has no attribute 'split' [06:35] (i ran bzr viz on bzr.dev tree) === mneptok [n=mneptok@canonical/support/mneptok] has joined #bzr [06:38] phanatic: ok, committer can apparently be None... [06:39] yeah, it seems :/ [06:40] heh, there was a check for revision.committer is None one line above... doh! [06:40] so, I have one branch A (which is mine), and now I want to incorporate another branch B (upstream, not mine) as a part of A, but in a way that would still let me merge further changes in A [06:41] is that possible? === sverrej [n=sverrej@cm-84.208.117.164.chello.no] has joined #bzr [06:41] both branches are created by bzr-svn btw [06:41] *further changes in B [06:42] phanatic: pushed a fix [06:42] wow, lp syncs pretty fast finally [06:43] yup [06:44] schierbeck: looks fine to me :) [06:44] phanatic: can it get merged into trunk, or is it too big a change of the ui? [06:45] i think it's sane change. and we don't have things like ui freeze :) [06:46] lovely :) [06:46] schierbeck: you know the drill: add a NEWS entry, and i'll be all happy :P [06:46] great [06:49] lapthrick: Are you asking if you can incorporate branch B into branch A but later be able to merge further changes from B into A? [06:49] lapthrick: If so, is branch A related to branch B at all? [06:49] phanatic: added NEWS entry and pushed to lp [06:50] Odd_Bloke: no, not at all related. I want to incorporate it as in I want all the files from B in A (in a subdirectory, too) [06:52] Do you want the rivision history from B in A? [06:53] If not, you can just use a nested directory [06:55] If yes - I think you need to use graft? [06:55] GaryvdM: no, I don't really need the history of B past the point it got imported into A [06:55] http://spacepants.org/src/bzrgraft/ [06:56] GaryvdM: so I just copy it and that's all? What happens if at one point I decide to move a file outside B? Also, will A see B as a part of it (as in, I will commit and it will notice all those files that appeared)? [06:57] Are you talking about a nested branch? [06:57] I think graft is not compatible with recent bzr's [06:57] GaryvdM: I guess I am [06:58] if I use a nested branch, will the branches understand their mutual relationship? [06:58] For a nested branch - you have two seperate branches with seperate rivision histories, but one is inside the other on the file system [06:59] Once you have imported B into A, will you need to merge changes from B's trunk into B [07:02] GaryvdM: but I need them integrated. Basically I have a big repo A, and I have some outside vendor's source B I want to import. So I want A to contain all the files from B, but I want them also to retain their identity, so that when the vendor commits changes to their repo, I can just pull them and it'd do the right thing [07:03] yet I also need to be able to manipulate the imported files myself, as the B sources are not usable for me pristine [07:06] I think a nested branches would be the best solution, but not perfect. Lets say you make a change to A and a change to B that go together, you would have commit seperatly to A and B. [07:07] But it would be easy to merge you changes to B with the vendors changes. [07:08] GaryvdM: okay, so when someone branches off A, will they also get a copy of B? [07:08] no [07:09] so that's not really a solution for me, I need A to actually have all of B in it [07:17] so basically I need 'bzr steal' functionality === GaryvdM_ [n=chatzill@mtngprs5.mtn.co.za] has joined #bzr [07:18] GaryvdM_: how hard would it be to add such 'bzr steal' function? [07:19] hmm, I wonder if multiparent does anything of what I want === GaryvdM_ is now known as GaryvdM [07:20] lapthrick: I don't know - I have only been hacking on bzr-gtk for about a month. [07:21] I see [07:21] GaryvdM: do you think revision id deserves its own column in the viz window? i tend to prefer a tooltip instead === lapthrick pokes people he suspects have a clue, like lifeless, abentley and james_w [07:22] No - it's very long [07:22] https://launchpad.net/bzr-merge-into/ [07:22] oho! [07:22] I supect that you are talking about the revision number column though [07:23] GaryvdM: sorry, i meant revision number [07:24] Well - Someone loged it as a feature request: https://bugs.launchpad.net/bzr-gtk/+bug/64167 [07:24] Launchpad bug 64167 in bzr-gtk "bzr viz don't show revno for main revisions" [Wishlist,Fix committed] [07:25] hmm, it says "fix committed" -- where's the fix? [07:25] (using trunk) [07:25] Viz is being used for 2 things - a GUI for Log - and a graph renderer [07:26] I't commited to https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges, but not to trunk yet [07:26] GaryvdM: ok [07:26] as a column or a tooltip? [07:27] May be we need a interface to select what columns the user wants [07:27] GaryvdM: btw we assume that "Fix committed" means it was committed to trunk (just a sidenote) [07:27] Oh [07:28] Changed [07:32] abentley: around? [07:55] does John Arbash Meinel IRC? And if so, what nick does he use? [07:56] lapthrick: jam [07:57] doesn't really seem to be here [07:57] lapthrick: 1. it's weekend 2. he's on us time [07:57] true === sverrej [n=sverrej@cm-84.208.117.164.chello.no] has joined #bzr === sverrej [n=sverrej@cm-84.208.117.164.chello.no] has joined #bzr [08:32] 3. he's got a new son. [08:32] lapthrick: I can't spot your question, would you mind repeating it? [08:33] james_w: yes, I basically want to do what merge-into provides: merge in outside code into my own branch, whilst still retaining the ability to pull in later changes in upstream [08:34] at least if I understand merge-into's scope correctly it's supposed to do that [08:35] and merge-into isn't what you want? [08:35] james_w: it is, but doesn't work [08:36] https://bugs.launchpad.net/bzr-merge-into/+bug/144108 [08:36] just finished writing [08:36] Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 -- no attribute 'base_is_other_ancestor'" [Undecided,New] [08:37] if I can get this fixed, I no longer will have to put up with stupid subversion crap [08:38] lapthrick: thanks, caught up now. [08:39] so, I believe merge into is now superceded by by-value nested trees, so I think that should solve your problem. [08:39] however I don't really know how they work, and they are still experimental. [08:40] and by-reference nested trees are currently completely broken, so maybe by-value are too. [08:41] ouch, I don't really understand what you just said [08:41] do you understand nested trees? [08:42] as in you have one tree (branch) tracked as part of another. [08:44] james_w: yes, the concept is pretty clear and incidentally exactly what I want (as long as I am still able to move parts of the inner tree to the outside one) [08:45] yeah, it sounds like you want a by-value nested tree. [08:45] what's the difference? [08:45] by-value means that the contents are tracked, by-reference means that just a pointer is tracked. [08:45] I see [08:45] so yeah, by-value [08:46] by-value is just breaking up a branch so that you can branch from a sub-directory of it. [08:46] New bug: #144108 in bzr-merge-into "Doesn't work with 0.90 -- no attribute 'base_is_other_ancestor'" [Undecided,New] https://launchpad.net/bugs/144108 [08:46] but also allows you to merge as you want I hope. [08:46] merge-into was jam's plugin to do by-value before nested trees were started. [08:47] james_w: excellent, bzr + bzr-svn == all bzr , no stupid svn [08:47] as long as it works, that is :) [08:48] yeah, you shouldn't have to touch svn [08:51] lapthrick: I have an idea for fixing merge-into, wnat to try it? [08:52] edit merge_into.py, and on the line (near the end) before conflicts = merger.do_merge() insert merger.find_base() [08:52] james_w: sure [08:53] that should set the missing attribute, but whether it will work is another question. [08:53] okay, lemme try === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr [08:55] "Branches have no common ancestor, and no merge base revision was specified." [08:56] james_w: success was not full it seems [08:56] indeed. [08:57] perhaps try in __init__ just set self.base_is_other_ancestor = False and remove the other change. [08:57] I'm not sure what the effect will be, but it sounds like that will never be true in this case. [08:57] yeah [08:59] or I have another suggestion. [09:00]