[12:21] <mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 1 hour
[12:42] <lifeless> vila: hi
[12:42] <lifeless> vila: two things, firstly you can only delete the line if its the last line
[12:42] <lifeless> vila: if its not the last line you break dictionary references
[12:43] <lifeless> vila: secondly, please keep NEWS in alphabetical order as per the list thread a few weeks back.
[01:21] <Peng> Yay!
[01:22] <Peng> 10 points to Launchpad for using a "503 Service Temporarily Unavailable" for the maintenance page.
[02:30] <ubotu> New bug: #141629 in bzr ""bzr reconfigure" with no arguments throws an exception" [Undecided,Fix committed]  https://launchpad.net/bugs/141629
[03:43] <mthaddon> LP going down for maintenance in 15 minutes for 1 hour
[03:44] <Peng> Am I experiencing deja vu?
[03:44] <Peng> :P
[03:44] <Peng> What's up with LP?
[03:46] <elmo> 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] <elmo> Peng: sorry for any inconvenience
[03:51] <Peng> Ah.
[03:51] <Peng> No problem or anything. I was just curious.
[07:14] <vila> 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] <vila> 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] <vila> 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] <ubotu> New bug: #141555 in bzr-svn "Breakage with invalid SSL certificates (dup-of: 82086)" [Undecided,New]  https://launchpad.net/bugs/141555
[09:08] <vila> bbib
[10:27] <kgoetz> win 20
[12:45] <vila> lifeless: no, was waiting for a confirmation, trying to reproduce it in clean env, etc
[12:46] <vila> can't reproduce it so far :-/
[01:12] <vila> lifeless: http://paste.ubuntu-nl.org/38243/   describes the corrupted revision
[01:13] <vila> all zeroes, scary
[01:13] <vila> Could your last tuned_gzip.bytes_to_gzip be related ?
[01:14] <vila> My suspects so far: hardware problem (but find nothing else to confirm this),
[01:15] <vila> NFS, the repo is on HFS+ on OSX, mounted as NFS, but the commit itself was from OSX
[01:16] <vila> 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] <vila> 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] <vila> 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] <vila> 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] <vila> 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] <vila> All are available for diagnosis
[01:23] <vila> 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] <fullermd> See what happens when you step away from the computer for a couple weeks??
[01:25] <vila> 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] <vila> fullermd: hehe, did you know about tar wart above ?
[01:27] <fullermd> 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] <vila> 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] <vila> these blocks contain a mtime field, which is useless for them so they put 0
[01:30] <vila> ... and somwhow this 0 is converted to current date... boom
[01:30] <vila> fullermd: and the 'file change while we read it' rings a bell ?
[01:31] <vila> 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] <vila> 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] <vila> Never figured tar knew about that....
[01:42] <vila> 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 :)
[01:44] <vila> lifeless: I'm ready to loose the two branches involved, osx.pass.test.suite and bzr.integration
[02:32] <tuXXX> When I bzr push on a sftp, files and directory aren't created, only .bzr, it this the correct behaviour?
[02:32] <Peng> tuXXX: Yes.
[02:33] <Peng> tuXXX: .bzr is all that's necessary to run bzr branch on it.
[02:33] <tuXXX> Then I need a web front-end to display those files on my web server
[02:33] <Peng> tuXXX: You can run "bzr checkout", then run "bzr update" in a cronjob or something.
[02:34] <Peng> tuXXX: Or using bzr+ssh might do it, I dunno.
[02:34] <Peng> 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.
[02:35] <tuXXX> sftp is useful because it doesn't need bzr to be installed on the server
[02:35] <Peng> Yeah.
[02:39] <GaryvdM> tuXXX - There is a plugin that does that. I'm just going to find it...
[02:41] <GaryvdM> There is https://launchpad.net/bzr-push-and-update/
[02:42] <tuXXX> ok
[02:43] <tuXXX> bzr still needs to be installed server-side
[02:43] <GaryvdM> Yhea :-(
[03:04] <tuXXX> ok so I have to do a "bzr checkout ." on the server
[03:04] <tuXXX> and it's work
[03:04] <tuXXX> *and it works
[03:26] <lapthrick> hrmm
[03:26] <lapthrick> so Gutsy's bzr can't cope with https://
[03:28] <vila> lapthrick: what do you mean ?
[03:28] <lapthrick> vila: https://bugs.launchpad.net/bzr/+bug/141105
[03:28] <ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [Undecided,New] 
[03:29] <lapthrick> 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] <vila> how so ? Can you try with https+urllib:// too ?
[03:30] <lapthrick> sure
[03:30] <AnMaster> gutsy? what is that
[03:30] <lapthrick> newest ubuntu, not released yet
[03:30] <AnMaster> ah
[03:31] <AnMaster> <-- Gentoo user
[03:31] <AnMaster> and FreeBSD
[03:31] <lapthrick> vila: works with urllib, yeah
[03:32] <lapthrick> I actually suspected it might be libcurl-gnutls's fault
[03:33] <vila> I should definitely look at that new version, that error code 77 may indicate some API break somewhere
[03:33] <lapthrick> ah, of course, you commented on that bug :)
[03:34] <vila> lapthrick: you're using a stock gutsy is it ?
[03:34] <lapthrick> aye
[03:34] <vila> lapthrick: yeah, didn't recognize you as mathrick either :)
[03:34] <lapthrick> :)
[03:35] <lapthrick> I need to setup an irc proxy
[03:36] <vila> 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] <ubotu> 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] <lapthrick> vila: I see. That's strange though, as the original svn repo from that bug I have authenticated permanently with plain svn client
[03:40] <vila> nothing strange in that :) svn should do proper certificate verification :)
[03:40] <lapthrick> given the exceedingly brief help it has
[03:40] <james_w> lapthrick: I think if you use svn+https:// for bzr-svn on that repo you will havee more success.
[03:40] <lapthrick> vila: but isn't it supposed to re-use svn cache?
[03:40] <lapthrick> james_w: yes, I needed a newer bzr-svn though
[03:40] <lapthrick> I just got it, lesse if it works now
[03:41] <vila> lapthrick: 1) I don't know what bzr-svn does, 2) we are not talking about credentials, we are talking about certificates
[03:42] <vila> the server send a client saying: That's who I am (my certificate), this certificate have been validated by vendor$$$
[03:42] <lapthrick> vila: yes, using svn client I accepted that certificate permanently
[03:42] <vila> Ok, so it means bzr-svn doesn't use that
[03:43] <james_w> 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] <lapthrick> ah
[03:44] <lapthrick> james_w: that makes sense
[03:44] <vila> ah
[03:44] <lapthrick> mathrick@hatsumi:/tmp$ bzr cl svn+https://beta.aimido.de/svn/src2/trunk
[03:44] <lapthrick> Segmentation fault (core dumped)
[03:44] <lapthrick> :(
[03:45] <lapthrick> it fetches the revisions info properly
[03:45] <lapthrick> then dies
[03:45] <lapthrick> cl == checkout --lightweight
[03:45] <james_w> lapthrick: you should report that against bzr-svn, jelmer will want to know.
[03:45] <james_w> a backtrace might be appreciated.
[03:46] <lapthrick> mhm, if I can get a sensible trace
[03:47] <james_w> I believe there are python debug packages, and maybe libsvn ones as well.
[03:47] <lapthrick> yeah, I'll just check if it happens with branch as well
[03:59] <lapthrick> seems to work just fine with branch
[04:10] <lapthrick> hmm, isn't bzr status in an svn checkout supposed to work?
[04:10] <lapthrick> it doesn't for me
[04:11] <james_w> yeah it should I think.
[04:11] <lapthrick> oh wait, wrong dir
[04:11] <lapthrick> I forgot trunk/
[04:12] <abentley> If you're getting a segfault, you should try running it under gdb.  That's a bug on the C side.
[04:12] <lapthrick> abentley: I know :)
[04:28] <lapthrick> h, what was the command to see the difference between branches?
[04:30] <dato> in terms of revisions, `bzr missing`
[04:30] <dato> (for diff, obviously `bzr diff`)
[04:33] <lapthrick> yeah, I just saw missing
[04:33] <lapthrick> thanks though
[04:47] <lapthrick> hey jelmer_
[04:48] <jelmer_> hi lapthrick
[04:50] <lapthrick> jelmer_: seen my latest bugreport?
[04:51] <lapthrick> I don't seem to be able to get a sensible trace, btw
[04:51] <jelmer_> yep
[04:51] <lapthrick> is python-dbg `which bzr` ... the correct way to get a backtrace from bzr?
[04:52] <jelmer_> `bzr co --lightweight`is just an alias for 'svn co ...' btw
[04:52] <lapthrick> jelmer_: oh
[04:53] <lapthrick> mathrick@hatsumi:/tmp$ svn co svn+https://beta.aimido.de/svn/src2/trunk
[04:53] <lapthrick> svn: Undefined tunnel scheme 'https'
[04:53] <jelmer_> without the svn+ :-)
[04:53] <jelmer_> ah, that's the problem
[04:54] <lapthrick> jelmer_: hmm? So the svn client underneath dies and it crashes because of that?
[04:54] <GaryvdM> bzr gdiff
[04:54] <GaryvdM> err wrong window
[04:54] <jelmer_> lapthrick: Yes, that's what I suspect
[04:54] <jelmer_> GaryvdM: :-)
[04:54] <lapthrick> it's noticeably faster
[04:55] <GaryvdM> lapthrick: I gave up trying to set it up on windows
[04:55] <jelmer_> lapthrick, can you try running that checkout command in gdb?
[04:55] <lapthrick> jelmer_: and bzr-svn is , especially now I got it to check out my work repo
[04:55] <lapthrick> jelmer_: I guess so
[04:57] <lapthrick> jelmer_: ah, yes, that's much more sensible
[04:57] <lapthrick> 0x080a215c in PyString_FromFormatV (
[04:57] <lapthrick>     format=0x816de98 "'%.50s' object has no attribute '%.400s'",
[04:57] <lapthrick>     vargs=0xbfb19f38 "\001") at ../Objects/stringobject.c:202
[04:57] <lapthrick> 202     ../Objects/stringobject.c: No such file or directory.
[04:57] <lapthrick>         in ../Objects/stringobject.c
[04:59] <lapthrick> jelmer_: http://pastebin.com/m33018646
[05:00] <jelmer_> thanks
[05:01] <jelmer_> looks like another python-subversion bug
[05:01] <lapthrick> I see
[05:01] <lapthrick> jelmer_: why is there a difference between what schemes svn and bzr-svn handle anyway?
[05:03] <jelmer_> lapthrick: bzr-svn supports everything that svn supports
[05:03] <jelmer_> lapthrick: and it also supports 'svn+https' to work around that problem with SSL certificates
[05:03] <lapthrick> jelmer_: yeah, but it was bailing out with the same error earlier, before I upgraded to 0.4.3
[05:04] <Qhestion> hi. can i put my bzr installation (from the windows installer) on my usb stick?
[05:04] <lapthrick> and isn't svn supposed to understand svn+https://? It's not uncommon to see urls like that on the net
[05:04] <jelmer_> lapthrick: it supports svn+ssh://, svn://, http:// and https://
[05:05] <jelmer_> lapthrick: which error did it bail out with earlier as well?
[05:05] <jelmer_> Qhestion: you mean the files that it installed or the setup file?
[05:05] <lapthrick> "Undefined tunnel scheme 'https'"
[05:06] <Qhestion> the files it installed
[05:06] <Qhestion> i just dont want to run the installer on the target machine
[05:06] <Qhestion> (read: can't)
[05:07] <jelmer_> Qhestion: should work ok as long as all the dependencies are installed
[05:07] <Qhestion> dependencies?
[05:07] <GaryvdM> Qhestion: I've never tried it, but I can't see why not.
[05:07] <jelmer_> Qhestion: python, paramiko if you would like to use sftp, etc
[05:07] <Qhestion> this is the "standalone installer"
[05:07] <Qhestion> there shouldnt be dependencies
[05:08] <Qhestion> and no sftp needed, only local (usb stick) repos
[05:08] <jelmer_> Qhestion, not sure in that case, I don't know where that installs its python binary
[05:08] <GaryvdM> Most of the dependencies are built into the installer, except the ssh stuff
[05:08] <Qhestion> well, in C:\Programs\Bazaar there is a Python25.dll
[05:08] <Qhestion> guess that is python ;)
[05:08] <jelmer_> 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] <jelmer_> there was a bug where that wasn't happening in bzr-svn 0.4.1 I believe
[05:09] <lapthrick> ah
[05:09] <lapthrick> jelmer_: I thought svn+whatever was a general syntax
[05:09] <GaryvdM> Qhestion: I'm sure it will work - give it a go
[05:10] <Qhestion> i only have one try
[05:10] <Qhestion> ;)
[05:11] <lapthrick> Qhestion: can't you ask a random friend if you can test if it works?
[05:11] <lapthrick> most probably they won't have bzr installed, so it's a good way to find out
[05:12] <Qhestion> lapthrick: all my friends already got python ;)
[05:12] <Qhestion> and bzr
[05:12] <Qhestion> ya know, i need some people to test my software ;)
[05:13] <Qhestion> i stopped programming in python, but i use Bazaar as version control system, and also to publish my sources
[05:13] <Qhestion> hmm, i remember i should go back to the bazaar bugtracker
[05:13] <Qhestion> filed a feature request there
[05:13] <GaryvdM> Qhestion: I can do a test on my sisters machine when she gets home - probably in about 15 min.
[05:13] <Qhestion> k
[05:14] <Qhestion> thank you
[05:14] <Qhestion> shall i send you a zip ?
[05:14] <GaryvdM> ok
[05:14] <GaryvdM> garyvdm@gmail.com
[05:16] <Qhestion> woo 11 MB
[05:16] <Qhestion> this will ake a bit
[05:16] <jelmer_> lapthrick: you can add custom tunnel mechanisms to svn for the native svn protocol
[05:16] <jelmer_> the http protocol is different though
[05:16] <jelmer_> lapthrick, Thanks for the backtrace, I have to head out now, will have a look at it later today.
[05:16] <GaryvdM> don't worry - I'll download the installer
[05:16] <Qhestion> ok
[05:44] <GaryvdM> Qhestion: It works
[05:45] <GaryvdM> And my sister dose not have admin rights on her machine
[05:45] <GaryvdM> s/dose/does
[05:46] <Qhestion> Garyvd: thank you
[05:47] <Qhestion> Garyvd: she does not have admin on her own machine? lol. good job ;)
[05:48] <GaryvdM> It's a work machine from a big corporate...
[05:48] <Qhestion> oh
[05:50] <schierbeck> phanatic: hey
[05:50] <phanatic> schierbeck: hi :)
[05:50] <schierbeck> phanatic: i was thinking
[05:51] <schierbeck> do you really need a date column in the viz treeview?
[05:51] <schierbeck> it happens quite often with big projects that the window becomes too wide
[05:52] <phanatic> 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] <schierbeck> phanatic: but i'd rather have a nice, easy-to-comprehend graph than a timestamp...
[05:54] <schierbeck> i mean, it's not often you actually *need* to know the exact time of a commit, or do you?
[05:54] <schierbeck> it may just be me...
[05:54] <phanatic> yeah, you're probably right
[05:55] <schierbeck> i think i'll create a branch and toy around with it
[05:55] <GaryvdM> schierbeck, phanatic: I've hacked up a possible solution to reduce the with of the graph. I was just emailing phanatic about it.
[05:55] <GaryvdM> s/with/width
[05:55] <phanatic> 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] <GaryvdM> https://code.launchpad.net/~garyvdm/bzr-gtk/brokenlines
[05:56] <schierbeck> GaryvdM: cool, as long as the graph is still easy to read
[05:56] <schierbeck> phanatic: i like the commit message being there, and sometimes the author
[05:56] <schierbeck> but there's no need for both the author name and email
[05:57] <GaryvdM> Thats a good point...
[05:57] <phanatic> indeed
[06:03] <schierbeck> GaryvdM: i'm not sure about the new graphs, i took a look, and it's a bit curvy (?)
[06:03] <schierbeck> of course, i'm no authority on the subject
[06:03] <phanatic> GaryvdM: this brokenlines stuff is pretty interesing
[06:03] <phanatic> schierbeck: imho they look better this way
[06:05] <schierbeck> phanatic: okay, it seems i'm outnumbered in my favor of straightness :P
[06:05] <phanatic> :D
[06:05] <schierbeck> i really like the way broken lines are handled
[06:05] <schierbeck> in the new branch, that is
[06:06] <phanatic> yep, me too
[06:06] <phanatic> does it load faster as well, or it's just me who feels it? :)
[06:08] <GaryvdM> I hope so :-)
[06:09] <GaryvdM> I should only be loading the revision data after the first screen is shown
[06:10] <GaryvdM> I'm hoping I can get it to only load the revision data for a rivision when it is scrolled into view.
[06:11] <GaryvdM> s/I/It
[06:11] <phanatic> 2.625s on bzr.dev, that's quite impressive
[06:11] <schierbeck> GaryvdM: do you think you could get the merge and branch-off lines to join at a different angle?
[06:12] <GaryvdM> Yes - play with the curve controll points
[06:13] <schierbeck> 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] <schierbeck> GaryvdM: ok, i'll look into it
[06:13] <phanatic> huh, with current bzr-gtk trunk it takes 25.085s
[06:13] <GaryvdM> viv/graphcell.py line 181-187
[06:13] <phanatic> oops, 15.085s that is :)
[06:13] <phanatic> but still 7 times more than with brokenlines
[06:16] <ubotu> New bug: #144071 in bzr "dirstate-tags format is expensive for network operations?" [Undecided,New]  https://launchpad.net/bugs/144071
[06:16] <phanatic> schierbeck: thanks, i will :)
[06:16] <schierbeck> phanatic: i'm also looking into cutting off the email portion of the committer id
[06:16] <phanatic> great
[06:17] <phanatic> GaryvdM: what do you think: is brokenlines stable enough to get in into 0.91?
[06:18] <GaryvdM> I don't know - I would love to have testing done on it.
[06:18] <GaryvdM> Lots of new code.
[06:19] <GaryvdM> s/more testing
[06:20] <phanatic> fine, i won't merge it then before the release :)
[06:20] <GaryvdM> Yhea - lets merge it just after the release.
[06:21] <schierbeck> phanatic: the new version should have been pushed to lp now, got a little ahead of myself before
[06:21] <schierbeck> i also tried making the graph column non-resizable
[06:21] <schierbeck> i think it is actually better -- when do you *not* want to see the branch graph?
[06:24] <phanatic> schierbeck: if it gets too wide, maybe?
[06:25] <schierbeck> phanatic: perhaps, but i think the graph is the main feature of the viz -- without it, it's really hard to navigate
[06:25] <phanatic> yes, you're right
[06:25] <schierbeck> i think it's better to make sure the graph will almost never be too wide
[06:25] <schierbeck> :)
[06:26] <phanatic> that's where brokenlines comes into the scene ;)
[06:31] <schierbeck> phanatic: i've pushed the changes to lp; the email part is now hidden in the treeview
[06:32] <schierbeck> my implementation is not perfect; i guess the separation of name and email should go in bzrlib, not in bzr-gtk
[06:33] <phanatic> i get a traceback here
[06:33] <phanatic> Traceback (most recent call last):
[06:33] <phanatic>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/viz/branchwin.py", line 190, in populate_model
[06:33] <phanatic>     committer = revision.committer.split('<')[0] .strip()
[06:33] <phanatic> AttributeError: 'NoneType' object has no attribute 'split'
[06:35] <phanatic> (i ran bzr viz on bzr.dev tree)
[06:38] <schierbeck> phanatic: ok, committer can apparently be None...
[06:39] <phanatic> yeah, it seems :/
[06:40] <schierbeck> heh, there was a check for revision.committer is None one line above... doh!
[06:40] <lapthrick> 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] <lapthrick> is that possible?
[06:41] <lapthrick> both branches are created by bzr-svn btw
[06:41] <lapthrick> *further changes in B
[06:42] <schierbeck> phanatic: pushed a fix
[06:42] <phanatic> wow, lp syncs pretty fast finally
[06:43] <schierbeck> yup
[06:44] <phanatic> schierbeck: looks fine to me :)
[06:44] <schierbeck> phanatic: can it get merged into trunk, or is it too big a change of the ui?
[06:45] <phanatic> i think it's sane change. and we don't have things like ui freeze :)
[06:46] <schierbeck> lovely :)
[06:46] <phanatic> schierbeck: you know the drill: add a NEWS entry, and i'll be all happy :P
[06:46] <schierbeck> great
[06:49] <Odd_Bloke> 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] <Odd_Bloke> lapthrick: If so, is branch A related to branch B at all?
[06:49] <schierbeck> phanatic: added NEWS entry and pushed to lp
[06:50] <lapthrick> 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] <GaryvdM> Do you want the rivision history from B in A?
[06:53] <GaryvdM> If not, you can just use a nested directory
[06:55] <GaryvdM> If yes - I think you need to use graft?
[06:55] <lapthrick> GaryvdM: no, I don't really need the history of B past the point it got imported into A
[06:55] <GaryvdM> http://spacepants.org/src/bzrgraft/
[06:56] <lapthrick> 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] <GaryvdM> Are you talking about a nested branch?
[06:57] <lapthrick> I think graft is not compatible with recent bzr's
[06:57] <lapthrick> GaryvdM: I guess I am
[06:58] <lapthrick> if I use a nested branch, will the branches understand their mutual relationship?
[06:58] <GaryvdM> 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] <GaryvdM> Once you have imported B into A, will you need to merge changes from B's trunk into B
[07:02] <lapthrick> 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] <lapthrick> 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] <GaryvdM> 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] <GaryvdM> But it would be easy to merge you changes to B with the vendors changes.
[07:08] <lapthrick> GaryvdM: okay, so when someone branches off A, will they also get a copy of B?
[07:08] <GaryvdM> no
[07:09] <lapthrick> so that's not really a solution for me, I need A to actually have all of B in it
[07:17] <lapthrick> so basically I need 'bzr steal' functionality
[07:18] <lapthrick> GaryvdM_: how hard would it be to add such 'bzr steal' function?
[07:19] <lapthrick> hmm, I wonder if multiparent does anything of what I want
[07:20] <GaryvdM> lapthrick: I don't know - I have only been hacking on bzr-gtk for about a month.
[07:21] <lapthrick> I see
[07:21] <schierbeck> GaryvdM: do you think revision id deserves its own column in the viz window? i tend to prefer a tooltip instead
[07:22] <GaryvdM> No - it's very long
[07:22] <lapthrick> https://launchpad.net/bzr-merge-into/
[07:22] <lapthrick> oho!
[07:22] <GaryvdM> I supect that you are talking about the revision number column though
[07:23] <schierbeck> GaryvdM: sorry, i meant revision number
[07:24] <GaryvdM> Well  - Someone loged it as a feature request: https://bugs.launchpad.net/bzr-gtk/+bug/64167
[07:24] <ubotu> Launchpad bug 64167 in bzr-gtk "bzr viz don't show revno for main revisions" [Wishlist,Fix committed] 
[07:25] <schierbeck> hmm, it says "fix committed" -- where's the fix?
[07:25] <schierbeck> (using trunk)
[07:25] <GaryvdM> Viz is being used for 2 things - a GUI for Log - and a graph renderer
[07:26] <GaryvdM> I't commited to https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges, but not to trunk yet
[07:26] <schierbeck> GaryvdM: ok
[07:26] <schierbeck> as a column or a tooltip?
[07:27] <GaryvdM> May be we need a interface to select what columns the user wants
[07:27] <phanatic> GaryvdM: btw we assume that "Fix committed" means it was committed to trunk (just a sidenote)
[07:27] <GaryvdM> Oh
[07:28] <GaryvdM> Changed
[07:32] <abadger1999> abentley: around?
[07:55] <lapthrick> does John Arbash Meinel IRC? And if so, what nick does he use?
[07:56] <phanatic> lapthrick: jam
[07:57] <lapthrick> doesn't really seem to be here
[07:57] <phanatic> lapthrick: 1. it's weekend 2. he's on us time
[07:57] <lapthrick> true
[08:32] <james_w> 3. he's got a new son.
[08:32] <james_w> lapthrick: I can't spot your question, would you mind repeating it?
[08:33] <lapthrick> 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] <lapthrick> at least if I understand merge-into's scope correctly it's supposed to do that
[08:35] <james_w> and merge-into isn't what you want?
[08:35] <lapthrick> james_w: it is, but doesn't work
[08:36] <lapthrick> https://bugs.launchpad.net/bzr-merge-into/+bug/144108
[08:36] <lapthrick> just finished writing
[08:36] <ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] 
[08:37] <lapthrick> if I can get this fixed, I no longer will have to put up with stupid subversion crap
[08:38] <james_w> lapthrick: thanks, caught up now.
[08:39] <james_w> so, I believe merge into is now superceded by by-value nested trees, so I think that should solve your problem.
[08:39] <james_w> however I don't really know how they work, and they are still experimental.
[08:40] <james_w> and by-reference nested trees are currently completely broken, so maybe by-value are too.
[08:41] <lapthrick> ouch, I don't really understand what you just said
[08:41] <james_w> do you understand nested trees?
[08:42] <james_w> as in you have one tree (branch) tracked as part of another.
[08:44] <lapthrick> 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] <james_w> yeah, it sounds like you want a by-value nested tree.
[08:45] <lapthrick> what's the difference?
[08:45] <james_w> by-value means that the contents are tracked, by-reference means that just a pointer is tracked.
[08:45] <lapthrick> I see
[08:45] <lapthrick> so yeah, by-value
[08:46] <james_w> by-value is just breaking up a branch so that you can branch from a sub-directory of it.
[08:46] <ubotu> 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] <james_w> but also allows you to merge as you want I hope.
[08:46] <james_w> merge-into was jam's plugin to do by-value before nested trees were started.
[08:47] <lapthrick> james_w: excellent, bzr + bzr-svn == all bzr , no stupid svn 
[08:47] <lapthrick> as long as it works, that is :)
[08:48] <james_w> yeah, you shouldn't have to touch svn
[08:51] <james_w> lapthrick: I have an idea for fixing merge-into, wnat to try it?
[08:52] <james_w> edit merge_into.py, and on the line (near the end) before conflicts = merger.do_merge() insert merger.find_base()
[08:52] <lapthrick> james_w: sure
[08:53] <james_w> that should set the missing attribute, but whether it will work is another question.
[08:53] <lapthrick> okay, lemme try
[08:55] <lapthrick> "Branches have no common ancestor, and no merge base revision was specified."
[08:56] <lapthrick> james_w: success was not full it seems
[08:56] <james_w> indeed.
[08:57] <james_w> perhaps try in __init__ just set self.base_is_other_ancestor = False and remove the other change.
[08:57] <james_w> I'm not sure what the effect will be, but it sounds like that will never be true in this case.
[08:57] <lapthrick> yeah
[08:59] <james_w> or I have another suggestion.
[09:00] <james_w> where you put find_base before put set_base_revision
[09:02] <james_w> merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
[09:02] <james_w> you will need to do from bzrlib import revision before
[09:03] <james_w> after that I'm a bit stuck for ideas.
[09:26] <lapthrick> james_w: okay, lemme try that
[09:26] <lapthrick> james_w: are those two separate ideas, or a single change?
[09:27] <james_w> two separate, I would try the second one first, it seems like less of a hacky change.
[09:27] <james_w> even if it is unlikely to work/
 merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
[09:27] <lapthrick> this one, set in place where I previously did find_base?
[09:27] <james_w> yes.
[09:28] <james_w> adding the import statment just above.
[09:28] <lapthrick> should I also add find_base call?
[09:28] <james_w> or add revision to the list of imports at the top.
[09:28] <james_w> no, the find base is the wrong one, it should be deleted, as I see it will never work here.
[09:28] <lapthrick> okay
[09:33] <lapthrick> james_w: awesome, that worked
[09:33] <lapthrick> I will post a patch for that bug then
[09:33] <james_w> wow.
[09:33] <james_w> did you try it on your branches as well?
[09:33] <lapthrick> james_w: yes, bzr missing --other ../other shows nothing
[09:34] <lapthrick> which is exactly what I expected :)
[09:34] <james_w> horsesome.
[09:34] <lapthrick> I'm gonna try pulling some changes from upstream now
[09:36] <lapthrick> hmm
[09:36] <lapthrick> james_w: http://pastebin.com/m1a097d9d
[09:38] <james_w> lapthrick: so is that file named foo.html or pokersource/foo.html in ../../pokersource?
[09:39] <lapthrick> james_w: foo.html, if I wanted to access it, I'd say ../../pokersource/foo.html
[09:40] <james_w> and when you did the merge-into you made it put the contents of the ../../pokersource branch in pokersource/ ?
[09:41] <lapthrick> james_w: yes
[09:41] <james_w> that's a good sign I think then.
[09:41] <lapthrick> how so?
[09:41] <james_w> it knows how to resolve that file in to the subdir.
[09:41] <lapthrick> do you mean it can be fixed, or that it's not broken?
[09:42] <james_w> so I think a path conflict comes when you add a file of the same name in two branches independently
[09:42] <james_w> which would suggest that the merge-into messed up the file-ids.
[09:43] <james_w> but the fact that it knows that ../.../foo.html corresponds to pokersource/foo.html means that it got something right.
[09:43] <lapthrick> ah
[09:43] <james_w> lapthrick: it's definately broken, I was just commenting that it seemed to be at least partially right.
[09:43] <lapthrick> james_w: can I get it to tell me file-ids?
[09:43] <james_w> It may be fixable.
[09:44] <james_w> lapthrick: I'm not sure about command line. I can do it with bzrlib easily if you want to.
[09:44] <james_w> python
[09:44] <james_w> >>> import bzrlib
[09:44] <james_w> >>> from bzrlib.workingtree import WorkingTree
[09:44] <james_w> >>> t = WorkingTree.open_containing('.')
[09:45] <james_w> >>> t.path2id(path)
[09:45] <james_w> however I'm not sure which id you will get it the conflicting case.
[09:46] <james_w> if you revert, and then check pokersource/foo.html in this branch, and then foo.html in the other they should be the same.
[09:46] <lapthrick> >>> t.path2id("pokersource/foo.html")
[09:46] <lapthrick> Traceback (most recent call last):
[09:46] <lapthrick>   File "<stdin>", line 1, in <module>
[09:46] <lapthrick> AttributeError: 'tuple' object has no attribute 'path2id'
[09:46] <james_w> t = t[0] 
[09:46] <james_w> I always forget that one.
[09:47] <lapthrick> james_w: and how do I retrieve the id now? It didn't return any value
[09:47] <james_w> I'm also not sure whether it's the fact that you are doing a delete that is causing the issue.
[09:47] <james_w> >>> t.path2id should work now.
[09:47] <lapthrick> yes, but it doesn't return anything
[09:47] <lapthrick> well, returns None
[09:48] <james_w> that means the file is not versioned.
[09:48] <james_w> did you revert first?
[09:48] <lapthrick> no
[09:48] <james_w> try the reverted case first, and also uncommit + revert in the other branch to test that one.
[09:49] <james_w> let's check that it thinks the two files are the same first, then work out what causes the conflict.
[09:50] <lapthrick> >>> t.path2id("pokersource/foo.html")
[09:50] <lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
[09:50] <lapthrick> >>> t.path2id("foo.html")
[09:50] <lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
[09:50] <lapthrick> so they got the same ID
[09:52] <james_w> that's good. bzr will equate the two.
[09:52] <lapthrick> james_w: indeed, non-rm change works just fine
[09:52] <james_w> you may get the conflict as you are doing a delete. Can you instead try an edit in the upstream branch and then merge that.
[09:53] <james_w> ah, that's good then.
[09:53] <lapthrick> yeah, I just did :)
[09:53] <james_w> I wonder where that conflict comes from then.
[09:53] <james_w> you could look at the conflicts documentation.
[09:53] <lapthrick> what do you mean?
[09:55] <james_w> http://pastebin.com/d4818a9e7
[09:55] <james_w> there is a conflicts section of the user guide.
[09:56] <james_w> I guess this is the parent directory case.
[09:57] <james_w> so bzr sees 'rm foo' in one branch and 'mv foo ...' in the other and doesn't know who to listen to.
[09:58] <james_w> lapthrick: it appears to be working, so you could resolve the conflicts as a workaround, and then ask on Monday for any ideas for a fix.
[09:58] <lapthrick> james_w: hmm, but why does it see mv?
[09:59] <lapthrick> james_w: yep, it's already much much awesomely better than trying to do the same with subversion :)
[09:59] <lapthrick> I love how bzr is the best available svn client
[09:59] <james_w> well, one tree has / as the parent, the other has /pokersource/ and so it considers it a move I guess.
[10:00] <lapthrick> james_w: oh, I see. So we need to muck the path in there to make it see pokersource/ as the parent where needed
[10:00] <lapthrick> as / I mean
[10:01] <james_w> bzr doesn't actually record moves, it just preserves file ids, and then sees name and parent directory changes as moves later I believe.
[10:01] <lapthrick> james_w: in any case, huge thanks for the help
[10:01] <james_w> lapthrick: no problem. This fix is probably a bit in depth for me.
[10:02] <lapthrick> maybe jam will come around on monday
[10:02] <lapthrick> right now I have it working, I don't need to pull in any actual change yet, so it's really not a big issue
[10:02] <james_w> that would be one fix, but I'm not sure that you could enforce that without massive changes (aka nested trees I guess).
[10:02] <lapthrick> yeah
[10:02] <james_w> and the conflicts should be easy to solve, and perhaps rare.
[10:03] <lapthrick> otherwise it'd try to move to /.., and that just doesn't make sense
[10:03] <james_w> I guess the nested tree support there is may provide a way to fix this.
[10:03] <lapthrick> yeah, I'm more than happy to move to that once it's not broken
[10:03] <james_w> I guess jam maybe knew this was a limitation, but it was 'good enough'.
[10:04] <james_w> it needs someone to pick it up, and most of the core devs are on performance at the moment.
[10:04] <james_w> lapthrick: could you mail a bundle to the bug report with your fix please?
[10:06] <james_w> I'm off out now, so I can't commit it tonight, but if it's in my inbox it will remind me to do it tomorrow.
[10:06] <lapthrick> james_w: sure
[10:06] <james_w> thanks.