[00:00] <jelmer> thumper: I'm not sure why it isn't there for the working tree, it's strange indeed. I could imagine it being None for files that have changed (since their current state is not in any revision yet) but not for unchanged files.
[00:03] <thumper> I guess I could file a bug, it can always be marked invalid :)
[00:13] <poolie> thumper: it's not a bug
[00:13] <poolie> files in the wt don't have a revision
[00:13] <thumper> poolie: even when they are versioned?
[00:13] <thumper> poolie: it has a parent_id
[00:14] <thumper> poolie: hence my confusion
[00:15] <spiv> thumper: a working tree is a revision-under-construction, conceptually.
[00:16] <thumper> spiv: it'd make sense to me then to not have a parent_id for the InventoryFile from a working tree
[00:16] <spiv> Well, it knows the parent.
[00:16] <thumper> at least then it would be internally consistent from my point of view
[00:16] <poolie> thumper: nb the parent is the parent directory
[00:16] <thumper> spiv: so why doesn't it know the revision?
[00:16] <poolie> thumper:  what revision do you want it to be?
[00:16] <poolie> the one where it was last modified?
[00:16] <thumper> poolie: that is what I would expect, yes
[00:16] <poolie> but then what if it's been modified on disk?
[00:16] <spiv> Or the one it is about to be when you type "bzr ci" ;)
[00:17] <poolie> if we leave it the same, there is a big risk of bugs
[00:17] <poolie> if we perhaps set it to None in that case, that requires reading the whole file to determine this property
[00:17] <poolie> which would tend to make things slow
[00:17] <thumper> I'm not sure, I'm just starting to play with bzrlib internals
[00:18] <poolie> so
[00:18] <poolie> if you want to find out "for the unmodified files, tell me which revision they came from"
[00:18] <poolie> this necessitates doing a diff type operation
[00:18] <poolie> so you have to do iter_changes
[00:18] <thumper> poolie: so what is the parent_id of an InventoryFile?
[00:18] <thumper> poolie: all I want to find out is the last revision a particular file was modified in
[00:18] <spiv> thumper: the file_id of its containing directory
[00:19] <thumper> poolie: which I get from wt.basis_tree().inventory[file_id].revision
[00:19] <thumper> poolie: which is what jelmer said
[00:19] <poolie> or something equivalent to that
[00:19] <poolie> we should document that more
[00:19] <poolie> thumper: yes that's the best way to get it
[00:19] <thumper> cool
[00:19] <poolie> assuming you don't care about uncommitted changes
[00:20] <thumper> poolie: for what I'm doing, there aren't any uncommitted changes
[00:20] <poolie> k
[00:20] <poolie> you don't even have to use a wt if you don't need one
[00:20] <thumper> poolie: it makes for fast file access
[00:20] <thumper> poolie: for the tip revision
[00:21] <thumper> that is my current reasoning
[00:21] <thumper> I may change later to just using in memory trees
[00:21] <thumper> but getting something working first
[00:22] <poolie> please file bugs tagged 'doc api' if something is not sufficiently explained, or perhaps just send one email describing everything
[00:22] <poolie> and i will try to make it better
[00:22] <thumper> poolie: where are the existing docs on the api?
[00:22] <thumper> poolie: I'm just working from mwhudson's pydoctor files right now
[00:22] <thumper> poolie: if there are some conceptual overviews that'd probably help
[00:23] <spiv> thumper: In addition to the pydoctor docs there is http://doc.bazaar.canonical.com/bzr.dev/developers/
[00:23] <thumper> spiv: thanks, I'll take a look
[00:24] <spiv> Primarily the "Developing using bzrlib" section, I guess.
[00:24] <spiv> But there might be some relevant info in the other sections, e.g. if you want to use bzrlib's testing facilities in your test suite.
[00:25] <thumper> yeah, I'm using TestCaseWithTransport
[00:25] <thumper> I'm actually quite keen to learn more of the bzr internals
[00:25] <thumper> I may even submit some patches :)
[00:26] <poolie> cool
[00:26] <thumper> one day...
[00:26] <poolie> this really is a good chance to improve the api docs
[00:26] <thumper> I'll try to make notes of my pain points
[00:26] <poolie> lucid needs to reboot now, biab
[00:26] <mwhudson> i guess i could try to put my editable version   of the apidocs online again
[00:27] <poolie> mm
[00:27] <poolie> you're welcome too, but i think it will become a dead end
[00:28] <poolie> i think what we need is not a gloss written onto the api docs, but rather people asking questions that actually drive improvements in the docs instead
[00:28] <mwhudson> probably
[00:28] <poolie> like a footer on all of them saying "if this is unclear ask in #bzr and we will improve it"
[00:31] <dvheumen> hi poolie. about the contributor agreement. I forwarded your reply to me with the agreement and my text, but maybe that's what killed the process?!?
[00:31] <dvheumen> :P
[00:31] <dvheumen> In that case, I could send a clean version again
[00:32] <dvheumen> ... and I didn't CC you, only sent it to contributor-agreement@canonical.com
[00:33] <poolie> would you please forward that mail to me?
[00:33] <dvheumen> ah, whoops, I missed the second part of that sentence saying I should CC you :P
[00:33] <dvheumen> forwarding ...
[00:34] <spiv> dvheumen: ah good, I'm looking forward to your patch landing :)
[00:35] <dvheumen> spiv, well, it's not that spectacular :), but thanks for saying that ;)
[00:35] <dvheumen> poolie, mail should arrive shortly
=== BasicPRO is now known as BasicOSX
[00:41] <poolie> k thanks
[00:42] <dvheumen> okay, since you've got the Agreement, everything should be alright. I'm gonna call it a night.
[00:51] <igc> morning
[00:58] <moldy> hi
[00:59] <moldy> can i easily merge a single directory of another branch into my branch while keeping history?
[01:00] <bob2> no
[01:00] <moldy> hm, ok :-/
[01:00] <moldy> bob2: how would you approach this?
[01:02] <spiv> moldy: the two basic options are "lose the history" and "merge the whole other branch in but then undo the changes from outside the directory you want."
[01:02] <moldy> spiv: hm, ok, thanks.
[01:11] <moldy> if i deleted a directory, how can i view the log for that directory? "Path unknown at end or start of revision range"
[01:14] <Peng> moldy: If you can remember when you deleted it, 'bzr log -r <some rev where it existed>'
[01:15] <moldy> Peng: hm, ok, thx
[01:23] <poolie> hi igc
=== gnomefreak76 is now known as gnomefreak
[02:19] <thumper> poolie: any way to tag an individual file?
[02:19] <poolie> thumper: i just answered the question about it
[02:19] <poolie> no
[02:20] <thumper> poolie: thanks
[07:19] <vila>  hi all
[07:20] <gour> hello
[07:20] <gour> jelmer is the author of bzr-svn?
[07:20] <vila> gour: yes he is
[07:21] <gour> vila: i had some crash in bzr explorer while fetching from svn repo, but would like to send paste before opening ticket (http://dpaste.com/173190/) - maybe it's just network problem
[07:23] <vila> gour: well, 'could not connect' indicates either a network problem or an authentication problem
[07:24] <vila> gour: try connecting with the svn client itself and, except if the problem is transient) file a bug
[07:24] <gour> vila: thanks. it may be network problem then...it fetched quite a lot from the repo before crashing
[07:24] <gour> ok
[07:28] <gour> vila: svn did the job
[07:29] <vila> gour: bug filing time it is then
[07:29] <gour> vila: ok
[08:06] <igc> bbiab
[08:11] <echo-area> spiv: ping
[09:03] <knielsen> bzr has per-file changeset comments (implemented for MySQL I think). They can be added with `bzr gcommit`. But is there any way to view them? I couldn't find any ...
[09:08] <vila> oh boy, how I hate linux when it starts thrashing...
[09:13] <GaryvdM> knielsen: I believe with bzr glog
[09:14] <vila> knielsen: bzr viz (GaryvdM you insensitive clod !)
[09:15] <knielsen> ok, thanks! (glog is a plugin I guess?)
[09:15] <vila> GaryvdM: may be we should just add glog as an alias for viz in bzr-gtk ;-)
[09:15] <vila> knielsen: it's part of bzr-gtk
[09:16] <GaryvdM> vila: Oh. I thought that was allready the case.
[09:16] <knielsen> vila: hm, strange, I have bzr-gtk but don't seem to have glog ... anyway, I'll check it out
[09:17] <GaryvdM> knielsen: I thought it was glog, but it is bzr viz
[09:17] <vila> knielsen: GaryvdM thought about qlog in qbzr plugin but it's called viz in the bzr-gtk plugin
[09:17] <knielsen> hehe, ok :)
[09:17] <vila> knielsen: sorry for the confusion
[09:18] <spiv> echo-area: pong
[09:18] <spiv> echo-area: I'm only half around...
[09:21] <vila> knielsen, GaryvdM, jelmer : I've just pushed to lp:bzr-gtk the alias addition, so there
[09:21] <GaryvdM> :-)
[09:22] <knielsen> ok, I see, that works, thanks! I guess there is no command-line way to see the comments?
[09:22] <vila> GaryvdM: Wow, just tried 'bzr qlog' in a directory (below a shared repo) without branchs in it (but still branches in sub dirs)
[09:23] <vila> GaryvdM: I got a message on the console but a blank (well grey) screen....
[09:23] <knielsen> (probably `bzr log --verbose` should show them, if anyone cared enough to add that)
[09:25] <knielsen> I guess MySQL is probably the only project to use per-file comments anyway ...
[09:28] <vila> knielsen: it's implemented as a revision property, which are quite arbitrary (and in that case encoded in a non-trivial way), so bzr itself can't just display it properly
[09:28] <vila> knielsen: a specific log formatter can, you may want to file a bug asking for one
[09:28] <knielsen> vila: ok, I see, thanks for info
[09:29] <echo-area> spiv: Okay, so let's talk tomorrow.  I just checked our last dialogue, and you are off the day by now :)
[09:30] <GaryvdM> vila: my 3g went wonkey, so I may have missed messages. The last thing I saw was: "GaryvdM: I got a message on the console but a blank (well grey) screen..."
[09:30] <vila> GaryvdM: that was it
[09:31] <GaryvdM> vila: what was the message?
[09:31] <vila> GaryvdM: not a branch
[09:32] <GaryvdM> Vila: ok. I'll log a bug. It should be able to handel that.
[09:33] <vila> GaryvdM: sure, that's the first time I encounter it and I was a bit surprised that I needed to *kill* the window, clicking the close button seemed unresponsive
[09:34] <GaryvdM> vila: Can you reproduce the hang?
[09:34] <vila> just a sec
[09:35] <vila> WOW
[09:35] <vila> I can't
[09:36] <vila> I just get the error message and the qlog just quit
[09:36] <balor> So I've merged something onto my mainline.  I've now got a BASE OTHER and THIS file for one file.  What's the best way to merge all this?  Do I meld OTHER and THIS onto BASE or some other permutation?
[09:36] <vila> amazing, ok, forget it, I can't reproduce
[09:38] <vila> balor: 'file' itself already contains all the merged stuff and the conflicted regions enclosed with markers
[09:38] <balor> vila: I can see that.  But is there a tool that lets me choose between chunks, rather than simply editing the file in emacs?
[09:39] <vila> balor: man, if you use emacs try smerge !
[09:39]  * vila checks how smerge is configured here
[09:40] <vila> balor: hmm, just opending a conflicted file is enough to trigger smerge here
[09:40] <balor> And if I wasn't an emacs user, is there another tool?
[09:40] <vila> Ha, that maybe because I use dvc
[09:40] <vila> yes meld certainly, but I don't use it (I've just installed it, gimme a sec)
[09:42]  * vila thought meld could be triggered automatically frombzr
[09:42] <balor> ah! bzr-gconflicts
[09:42] <balor> It'll set up meld correctly to do the merge
[09:42] <vila> balor: starts meld automatically ?
[09:42] <vila> good
[09:43] <vila> balor: try pinging GaryvdM when he come back, I'm pretty sure qconflicts (from qbzr) can do that too
[09:51] <balor> Hmm....I still have to copy foo.c.BASE over foo.c after the merge
[10:49] <vila> balor: you still need to to 'bzr resolve file'
[10:54] <vila> s/to to/to do/
[11:45] <alf_> Hi all, I have been using bzr explorer to read the history/logs of specific files and directories.
[11:46] <alf_> Due to the depth of the history (>40000) this takes a while. Is there a way to speed things up? Would indexing using "bzr index" help here?
[11:50] <jelmer> alf_: Hi
[11:50] <jelmer> alf_: No, bzr index is just used by "bzr search" - it won't speed anything up
[11:50] <jelmer> alf_: Do you have the Bazaar C extensions compiled?
[11:51] <jelmer> alf_: And are you using a recent version of Bazaar?
[11:51] <alf_> jelmer: I am using bzr 2.1.0 from debian testing
[11:55] <alf_> jelmer: The good thing is that bzr explorer incrementally displays the matching commits as it finds them. It still takes a lot of time to process them all, however.
[11:57] <alf_> I am guessing it is just searching all commits and just displays ones that match?
[12:03] <jelmer> alf_: You're just browsing aren't you?
[12:04] <jelmer> alf_: Or are you doing something more complex than that?
[12:05] <igc> night all
[12:05] <alf_> jelmer: in the file browser I am selecting a file/directory and clicking show log in the context menu
[12:07] <jelmer> g'night Ian!
[12:35] <dcoles> jelmer: Would you believe I'm having trouble with bazaar and urlsplit again...
[12:36] <dcoles> This time with bzr-git...
[12:36] <jelmer> dcoles: You're running Lucid I bet?
[12:37] <dcoles> Yes. Someone changed the behaviour of urlsplit?
[12:37] <jelmer> dcoles, Yep, upstream python did
[12:37] <jelmer> there's a fix for it in bzr-git trunk
[12:37] <dcoles> (Since I can no longer reproduce the behavour that was breaking bzr-svn)
[12:38] <jelmer> the behaviour in bzr-svn was unrelated to Python
[12:39] <dcoles> Ah. Cool. I had just started to monkey-patch and then noticed that bzr-git already "did the right thing"
[12:56] <bialix> jelmer: hi
[12:57] <bialix> jelmer: can we chat about Bug 540363
[12:57] <ubottu> Launchpad bug 540363 in qbzr "SVN Commit throws 'SvnBranch' object has no attribute 'control_files'" [High,Fix released] https://launchpad.net/bugs/540363
[12:58] <jelmer> bialix, hi
[12:58] <jelmer> bialix, sure
[12:58] <bialix> in qcommit we're trying to store some data in branch.conf
[12:58] <bialix> IIUC SvnBranch has no branch.conf?
[12:59] <bialix> so my fix to use Branch.get_physical_status instead of bzranch.control_files might be incorrect at all?
[12:59] <jelmer> bialix: To access branch.conf you should use Branch.get_config()
[13:00] <bialix> jelmer: maybe I should skip work with branch.conf at all for SvnBranch? Or even for all non-BzrBranches?
[13:01] <bialix> jelmer: we're using Branch.get_config()
[13:01] <jelmer> bialix: bzr-svn will return a config object if you call get_config() on a SvnBranch
[13:02] <jelmer> bialix: but will store/retrieve in branch.conf but elsewhere
[13:02] <bialix> jelmer: here is the code: http://pastebin.com/kTCkCkic
[13:03] <bialix> self._get_branch_config() == Branch.get_branch_config()
[13:03] <jelmer> Branch.get_config() you mean?
[13:03] <jelmer> Anyway, that should work
[13:03] <bialix> yes, get_config, sorry
[13:04]  * jelmer gets dragged to lunch
[13:04] <bialix> bon appetit
[13:04] <bialix> thanks, jelmer
[14:35] <smoser> Hey all, I know this isn't bzr specific, but expect someone would know an answer here.
[14:36] <smoser> I'm looking at http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/files/head%3A/user-data/ , and want to include a download link to the 'head' version of one of the files there
[14:36] <smoser> include-compressed-script-01.txt.gz specifically
[14:37] <smoser> the 'download file' link seems to be a premenant link to the head at the time i grab it.
[14:39] <james_w> smoser: you can probably mangle the link
[14:40] <smoser> i would have thought so. but it seems to have some data in it.
[14:40] <smoser> http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/download/head%3A/includecompressedscr-20100318141221-ewki6l3sasp5rmny-1/include-compressed-script-01.txt.gz
[14:40] <smoser> and its missing the path (user-data/), so i wasn't sure
[14:40] <james_w> interesting
[14:41] <james_w> beuno: around? ^
[14:41] <james_w> smoser: it still seems to be pointing to head: though, so should work
[14:42] <james_w> it will break if you bzr rm and then bzr add that file
[14:42] <smoser> well, it doesn't. i upated the file and the old link didn't work.
[14:42] <smoser> well, it worked, but got the old version
[14:46] <james_w> very odd
[14:49] <smoser> yeah, i suspect user error.
[14:49] <smoser> maybe i checked before new version had updated
[14:52] <james_w> ah, there is probably a lag of a minute or two after you push
[14:53] <beuno> james_w, hi
[14:53] <beuno> yeah
[14:53] <beuno> so loggerhead is on the public area
[14:53] <james_w> hi beuno
[14:53] <beuno> which has to wait for the puller to bring it in
[14:53] <beuno> so there is a delay
=== salgado is now known as salgado-lunch
=== IslandUsurper is now known as IslandUsurperAFK
[16:25] <NfNitLoop> Hrmm.  I'm helping a coworker learn/use bzr and bzr-svn.  He's used git before, and I think he's familiar with hg as well.  But he seems to be having a hard time with some of the concepts.  I may not be the best teacher. :/
[16:26] <NfNitLoop> Like, it's confusing to him that each branch is a separate directory since in bzr & hg that's handled in SCM metadata w/o the need for another directory.
[16:28] <NfNitLoop> and he's not quite understanding the difference between a "parent" branch and a "bound" branch.
[16:28] <NfNitLoop> OTOH, the problem could just be that he hasn't read any bzr docs and is relying on me to tell him everything. heh.
[16:28] <fullermd> I'm of the belief the former is easier to grasp by thinking strictly about the 3 components, and which are present in a given location.
[16:29] <fullermd> For the latter, _I_ like solving it by killing "bound".  With fire.    :)
[16:29] <NfNitLoop> hehe.
[16:29] <fullermd> But that's more like a troll than a solution...
[16:29] <NfNitLoop> Well, we have a rather large tree, so it's handy to bind it to branches, do some work, bind to a different branch, do some other work...
[16:30] <NfNitLoop> instead of creating N working copies, or doing 'bzr checkout .' 'bzr remove-tree' all the time.
[16:30] <NfNitLoop> but yeah, he tried to rebase in a bound branch and... things did not go well. :p
[16:30] <fullermd> What's the advantage of bounding, rather than using a light checkout and switch?
[16:33] <NfNitLoop> eh, it's in a shared repo, bind and switch,  light checkout and switch.   Not much difference in that case, right?
[16:33] <fullermd> Clarity about what's going on.
[16:34] <fullermd> It would be better modelling it as a heavy checkout and switch, than as a bound branch.  But with it all being local, light checkout is conceptually a step closer.
[16:35] <NfNitLoop> does the behavior differ?
[16:35]  * fullermd covertly looks around for anybody who'll call him on trolling like this...
[16:35] <NfNitLoop> I thought the only difference is that a lightweight checkout doesn't have local history.
[16:36] <NfNitLoop> but otherwise all operations between a light/heavy checkout should be the same?
[16:36] <NfNitLoop> (and a bound branch == a heavy checkout.)
[16:36] <fullermd> Well, see, that's the thing...
[16:36] <fullermd> In implementation, they are, which is the root of confusions.  In concept, they're not.
[16:37] <fullermd> And in concept, what you're using here is a checkout, because what you want is just a working tree on a branch (in a serial-monogamy sort of sense).
[16:38] <fullermd> And (IMAO) that's a lot easier to explain and grasp if explained as a checkout (working tree) moved among branches via 'switch', than as another branch with a special bound property that causes certain automatic interations with this other branch.
[16:39] <NfNitLoop> Oh.  Yeah.
[16:39] <NfNitLoop> Only at this point, changing his workflow more would be counterproductive.
[16:39] <fullermd> Oh, just reboot 'im.  The POST will wipe out the old habits.
[16:39] <NfNitLoop> heh.
[16:40] <NfNitLoop> I think he'd be a lot less confused if he'd started with the bzr tutorial and learned the concepts first.
[16:40] <NfNitLoop> instead, he looked at a wiki page I wrote about the workflow I use to interact with our SVN repo.
[16:40] <NfNitLoop> thought "Git's close enough" and started using my workflow.
[16:40]  * fullermd really should write up his model docs sometime   :|
[16:40] <NfNitLoop> without quite understanding it.
[16:42] <fullermd> Well, look at the bright side; if the version control usage doesn't pan out, he's still got a good future in politics   8-}
=== salgado-lunch is now known as salgado
=== IslandUsurperAFK is now known as IslandUsurper
=== radoe_ is now known as radoe
=== salgado is now known as salgado-brb
[20:50] <MTecknology> What would cause this? bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-drupal-devs/ubuntu-drupal-theme/6.x-orange/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[20:52] <fullermd> Trying to write across http.
[20:54] <MTecknology> fullermd: that happened when I just rant bzr commit -m "..."
[20:54] <fullermd> Which suggest that somewhere prior to that you did "bzr checkout http://...."
[20:54] <MTecknology> I grabbed it with bzr branch lp:..
[20:55] <MTecknology> I even tried on a fresh branch
[20:55] <fullermd> If you're not logged in (bzr lp-login), lp: resolves to a read-only http:// URL.
[20:55] <MTecknology> oh..
=== salgado-brb is now known as salgado
[20:56] <fullermd> If you lp-login, it'll resolve to a writable (assuming you're in the right group anyway) bzr+ssh:// url, so you could lp-login, and then "bzr switch lp:..." to swap over to the writable protocol.
[20:56] <MTecknology> why does it need to use the web if I'm only doing a commit on a branch grabbed using bzr branch? I thought that usually meant everything happens local until a push
[20:57] <fullermd> It doesn't, if you made a _branch_ with "bzr branch".  But in this case, you made a _checkout_ with "bzr co" (or possibly altered the branch later with 'reconfig' or 'bind')
[20:58] <fullermd> Check "info".
[20:58] <MTecknology> oh.... i get it now
[20:58] <fullermd> (if you expect and _want_ a separate branch, definitely check before you switch and commit and maybe push it upstream before you intend to)
[20:59] <MTecknology> I ran bzr branch lp:.. but because I didn't do lp-login, that's why it did http
[21:00] <MTecknology> I thought you meant that had to do with the commit
[21:00] <MTecknology> fullermd: thanks
[21:00] <fullermd> Well, commit wouldn't try to write to the upstream if it were just an indepdendent branch.
[21:01] <fullermd> It would only do that if you somehow ended up with a checkout/bound branch.
=== salgado is now known as salgado-afk
[21:58] <poolie> hi igc, lifeless, spiv, jelmer,
[22:12] <lifeless> poolie: the robert has landed
[22:17] <poolie> ah, you're in the other Commonwealth?
[22:27] <lifeless> poolie: yup
[22:27] <lifeless> about to go to the pre conf dinner I think
[22:29] <poolie> enjoy
[22:31] <lifeless> I got some good stuff done on the plane; I took lynnes new eeepc - huge battery life
[22:34] <fullermd> Wait...   if there's an "other", they're no longer common wealths anymore.
[23:06] <igc> morning
[23:06] <igc> hi poolie
=== Meths_ is now known as Meths