[00:00] <poolie> Odd_Bloke: i'll look for your mail and reply then
[00:01] <Odd_Bloke> poolie: Sure, just grabbing your key to encrypt it now.
[00:01] <Odd_Bloke> GPG - fun for all the family.
[00:02] <GaryvdM> Hi - How can I revert changes made by a revision in my wt?
[00:02] <GaryvdM> Not revert to a revision
[00:02] <poolie> undo just some of the changes?
[00:03] <GaryvdM> Undo the changes by a revisions, but the the changes by subsequent revisions
[00:03] <GaryvdM> *Undo the changes by a revision
[00:03] <poolie> try something like 'bzr merge -r 10..9'
[00:03] <GaryvdM> ok
[00:05] <GaryvdM> Thanks poolie - That worked.
[00:05] <Odd_Bloke> poolie: Sent.
[00:09] <bpierre_> well, that little conversation about switch was a real eye opener, I can't beleive I skipped this section in the manual... thanks for your answers
[00:09] <bpierre_> bye
[00:25] <markh> jam: any hope still of getting the plugin localizations included with 1.7?
[00:30] <poolie> abentley, bb seems to be down...
[00:30] <abentley> poolie: restarted
[00:30] <poolie> thanks very much
[00:31] <GaryvdM> ping lifeless
[00:32] <jam> markh: I suppose I could force it. Though it would be nice if we could get poolie or spiv to review it and also approve.
[00:32] <jam> It is small enough that I would be okay with bringing it in post rc2
[00:35] <GaryvdM> jam: could you give me any pointers to try figure out why get_parent_map is slower when passing all revisions in one go?
[00:36] <lifeless> GaryvdM: hmm?
[00:36] <lifeless> call to all devs: please give my readdir branch a spin
[00:37] <GaryvdM> lifeless: same question as jam :-)
[00:37] <lifeless> GaryvdM: lsprof
[00:37] <GaryvdM> ok
[00:38] <lifeless> also try a btree based repo and see if that handles it more gracefully
[00:38] <poolie> jam, i'll try to look
[00:39] <GaryvdM> ok
[00:51] <GaryvdM> lifeless: Sorry - how do I create a btree based repo?  None of the formats in "bzr help init" mention btree?
[00:59] <markh> lifeless: recall how you suggested I set sys.platform to "win32" so linux can run the same tests?  The problem is that osutils, and probably others, do win32 specific things at *import* time - eg, osutils.abspath is set to a linux or windows specific version as osutils is imported.  Thus, as Ian noticed, the tests fail on Linux.  What do you suggest?
[01:07] <lifeless> markh: oh
[01:07] <lifeless> markh: bummer :P, I guess, disable it then
[01:08] <markh> ok cool
[01:08] <lifeless> GaryvdM: the index2 plugin has the code, though its a little bitrotted;
[01:08] <jelmer> markh: hi!
[01:08] <markh> jelmer: hi!
[01:08] <markh> jelmer: you get a build related patch from me?  I *think* I remembered to send one...
[01:09] <jelmer> markh: No, what was it about?
[01:09] <jelmer> markh: bzr-svn on Windows? (-:
[01:09] <markh> bummer.  libsasl.dll needs to be included for 1.5
[01:09] <markh> svn 1.5
[01:09]  * markh looks
[01:09] <jelmer> markh: what address did you send it to?
[01:10] <markh> jelmer at samba.org, sent tuesday
[01:10] <markh> try again to that addy?
[01:11] <igc> hi all
[01:11] <markh> g'day ian!
[01:11] <igc> markh: hi
[01:11] <igc> markh: re your win32utils patch, it needs a tweak too
[01:11] <markh> igc: thanks for the review of that patch - but that lifeless character led me astray ;)
[01:11] <beuno> hi igc!
[01:11] <igc> hi beuno
[01:12] <markh> igc: you referring to the transport abspath patch?
[01:12] <lifeless> markh: well the altered code path should be testable; its a nuisance that its not
[01:12] <markh> lifeless: yeah, I understand and agree with your motivations
[01:12] <igc> so markh, TestlocationCtypes needs some more protection as it runs (and fails) on Linux
[01:12] <igc> the os.environ["APPDATA"] bit causes a KeyError
[01:13] <jelmer> markh: let me just check whether I didn't accidently skip over it
[01:13] <jelmer> markh: nope - please resend
[01:13] <igc> markh: get_local_appdata_location() patch
[01:14] <jelmer> 'morning Ian!
[01:14] <igc> hi jelmer. How are you?
[01:14] <markh> igc: right, bummer.  I must remember that my test ubuntu installation is only a couple of clicks away...
[01:14] <igc> :-)
[01:14] <markh> I'll quickly fix the transport abspath to simply disable the tests on windows first
[01:15] <markh> jelmer: sent
[01:16] <jelmer> markh: also, I was wondering if you could run the testsuite against my IPv6 patch on windows.
[01:16] <markh> jelmer: why not :)  where is it?
[01:16] <jelmer> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080830185330.GA22976%40vernstok.nl%3E
[01:17] <jelmer> igc: Good, thanks!
[01:17] <jelmer> igc: How are you? It's good to see you around here again.
[01:17] <markh> jelmer: is there a nice subset of tests I can run to reduce the noise caused by the full suite?
[01:18] <jelmer> markh: Just the smart server tests should be sufficient
[01:19] <igc> jelmer: I'm better thanks.
[01:21] <markh> jelmer: socket module has no attribute AI_ADDRCONFIG on windows :(
[01:22] <jelmer> markh: does it work ok if you exclude AI_ADDRCONFIG?
[01:24] <markh> jelmer: "smart.*server" runs 27 tests and they all pass now.  How to remove that flag from server.py and medium.py
[01:24] <markh> s/How/Had/
[01:25] <jelmer> markh: Cool, thanks.
[01:26] <markh> just "selftest server" runs 42 and they all pass too :)
[01:37] <markh> igc: I resubmitted the transport_abspath patch which skips the test on non-windows.
[01:38] <igc> markh: thanks
[01:42] <GaryvdM> Hi lifeless. I unfortunately get the following error: http://pastebin.com/d78fe14ad
[01:42] <GaryvdM> I attached a debugger, and format_registry.register_metadir is being called twice
[01:43] <lifeless> interesting
[01:43] <lifeless> is the plugin loading correctly?
[01:43] <GaryvdM> no
[01:44] <lifeless> well, thats probably the cause of the double-registration
[01:44] <GaryvdM> It seems that that error is being thrown when the plugin is loading
[01:44] <lifeless> I'll see if I can peek later today, but trying with bzr 1.6 might let it load properly
[01:44] <GaryvdM> ok
[01:45] <lifeless> no, that error is during arg processing
[01:47] <lifeless> oh cool - http://www.datadictionary.nhs.uk/  uses bzr
[01:47] <lifeless> awilkins: do you know more about them ?
[01:48] <mwhudson> blink
[01:48] <GaryvdM> lifeless: It's because I don't have pybloom installed :-)
[01:49] <lifeless> if you hack the plugin up a bit
[01:49] <lifeless> you can use the btree implementation in bzr.dev
[01:50] <lifeless> (rather than the one in the plugins btree_index module
[01:52] <jelmer> lifeless: from what I understand, awilkins works for NHS :-)
[01:52] <lifeless> jelmer: ah
[01:54] <markh> igc: thanks for the review, and I should try to proof-read better :(  I'm still confused by the 'tweak' thing though - who will/should fix that typo in the comments?
[01:55] <igc> markh: I will when I merge it to pqm
[01:55] <lifeless> markh: tweak technically means 'ok to merge with no more review but the changes done'
[01:56] <markh> lifeless: yeah - but sometimes I'm not sure if I'm being asked to make the tweak and resubmit, or someone else will...
[01:56] <lifeless> markh: if you don't have merge access, then I'd say you still should make the changes yourself, but you could just ping someone on IRC to land it (or send it in again with a note saying 'all reviewed this is the tweaks')
[01:56] <markh> especially as the person saying 'tweak' might not be the person submitting it to PQM IIUC
[01:56] <lifeless> right
[01:57] <igc> markh: we do overload tweak to mean two things ...
[01:57] <markh> lifeless: yeah, I don't have merge access, so I think I'll assume I should resubmit with the tweaks unless I can convince a sucker to tweak and land for me :)
[01:57] <igc> 1) another review not required
[01:57] <igc> 2) small changes needed before merging
[01:58] <lifeless> igc: I don't see that as overloading :). We have could represent it as multiple bits in a bitfield, but symbolic names are easier :P
[01:59] <igc> markh: if I ever vote tweak but ask you to do the tweaks, it's my polite way of saying you can probably tweak it better than I can
[02:00] <igc> markh: in the case of fixing a comment, I'm sure I have the intellect to manage that myself :-)
[02:01] <igc> lifeless: if you're ok with markh's resubmitted patch, I'll tweak and land it
[02:02] <mwhudson> jam: yay for figuring out https://bugs.edge.launchpad.net/bzr/+bug/242510
[02:03] <markh> so now all we need is a story for the LockContention failure noise on Windows and the test suite there will be looking good!
[02:03] <lifeless> igc: poolie has acked I think
[02:03] <lifeless> markh: if I vote tweak, I expect the author to tweak
[02:03] <markh> igc: good to see you back again :)  How are things?
[02:04] <lifeless> markh: which FWIW is the safe default for you to assume :P
[02:04] <markh> lifeless: so I hope you understand my slight confusion ;)
[02:04] <lifeless> markh: I think its due to igc being helpful
[02:04] <igc> markh: I'm better today. Still some pain but nothing like before
[02:04] <markh> damn helpful people!
[02:05] <markh> igc: good.  the treatment getting easier?
[02:05] <igc> markh: treatment stopped for now; surgery in early Oct is next; recovery before then
[02:07] <poolie> hello igc
[02:07] <igc> hi poolie!
[02:09] <markh> jelmer: that mail arrive?
[02:17] <jelmer> yep, thanks
[02:17] <jelmer> markh: I've merged it
[02:28] <markh> jam: that patch for the plugin l10n files has actually got 2 approve votes already.
[03:15] <markh> 1.7rc2 binaries for windows are now up on launchpad
[03:18] <markh> Also FYI, http://bazaar-vcs.org/TortoiseBzr has some recent Tortoise screen-shots from Vista and is looking quite pretty :)
[03:26] <thumper> markh: OMG, the UI refers to creating a stacked branch
[03:27] <thumper> markh: I do question the (possible) default of making a checkout
[03:27] <markh> thumper: is the stacked branch thing good or bad? :)
[03:27] <thumper> markh: is the revno really 0.0.1dev?
[03:27] <thumper> markh: surely we could have a bigger number :)
[03:27] <markh> yep :)  Probably should be 0.0.2.dev now ;)
[03:27] <thumper> markh: kinda good
[03:28] <thumper> markh: but more to explain to the users :)
[03:28] <thumper> markh: looks very pretty though
[03:28] <thumper> markh: good work
[03:28] <markh> thanks!
[03:28] <thumper> blog now please :)
[03:28] <markh> lots of the prettiness is qbzr
[03:29]  * markh needs to get one of those new-fangled blog thingies...
[03:29] <GaryvdM> Nice markh!
[03:31] <markh> I just recently landed a nice change so we can easily have those 'links' on the form display a popup help window with any bzr topic formatted as reasonable html, which is nice.  All 'revision number' boxes can have a link that explain the revision number formats, for example.
[03:33] <markh> ack - but I just noticed the binaries don't have docutils so things aren't as pretty as they could be :(
[03:34] <GaryvdM> markh - just want to nudge you to Bug #271983
[03:36] <markh> GaryvdM: ack - I must have missed that.  Do you have any idea what it does mean?  I'm guessing localizations?
[03:36] <markh> WFM obviously
[03:37] <GaryvdM> I was hoping it was something you missed. I'll debug.
[03:37]  * markh just twigges GaryvdM is qbzr's Gary - hi!
[03:37] <markh> twigged
[03:37] <GaryvdM> Hi!
[03:38] <markh> GaryvdM: what do you think in principle of those large changed I recently mailed about?
[03:39] <GaryvdM> I haven't got my head around them yet :-(
[03:40] <GaryvdM> I did pull the branch and gave it a test run - And I could not see any problems :-)
[03:40] <markh> fair enough :)  I think being able to use the signal/slot editor is a nice feature, as is the abaility to have the form at runtime look much more likje it does in qtdesigner.  I'm happy to negotiate the actual impl obviously though :)
[03:41] <markh> its very nice to have a checkbox connected to a radio button, so magically the checkbox is only enabled when the radio is - all with zero code :)
[03:41] <GaryvdM> Oh - Thats cool
[03:42] <markh> similarly with links - you could add a new help link to any of our forms with zero code.
[03:42] <markh> just connect the signal with the slot in the editor
[03:42] <markh> I'm quite impressed with qt
[03:43] <GaryvdM> That bug is weird. I get it when I run from the command line, but not when I run from Komodo
[03:45] <markh> the code I copied from blindly indexed via 'foo[0][1]' - ie, had no regard for the fact there might be more than 1.  So that's probably a good option :)  I'll have a look after I eat...
[03:52] <GaryvdM> It's get 2 help topics because I have the bzrtools plugin installed, which has a command called branches.
[04:06] <markh> hrm - I have bzrtools 1.7.0 installed too
[04:07] <GaryvdM> I think we can safely just display the first topic.
[04:07] <markh> sounds fine to me
[04:07] <GaryvdM> Ok I'm pushing a fix now.
[04:08] <markh> thanks
[04:20]  * igc unch
[05:52] <stefanlsd> I am playing around with bzr and the merging, and when i merge it gives me a file.moved. How do i get the launchpad / ubuntu functionality where it generated the conflict markers in the same file?
[05:53] <RAOF> stefanlsd: It's my understanding that what you're seeing happens when you've independently added the same file in different branches, and so bzr doesn't know that they're the same file.
[05:56] <stefanlsd> RAOF: yeah, i did that.  let me try and modify the contents of the same file after i've merged then...
[05:56] <spiv> stefanlsd: RAOF is right.  You get foo.moved files when it's a conflict of two different files at the same path.  You get conflict markers within a file when there's a conflict of the contents of one file.
[05:58] <stefanlsd> RAOF, spiv:  thanks, yeah. i see that now.
[07:02] <vila> hi all
[08:24]  * vila off to renew passport
[08:46] <ngnp> ﻿hi ... is there document about combining cvs and bazaar ... my project is in cvs ... doing a cvs 'switch-branch' my .bzr was deleted
[08:46] <ngnp> do I need a shared repo to prevent this or are there other ways.
[08:53]  * vila 's back
[09:04] <matkor> Hi ! I upgraded bzr 1.5 -> 1.6.1, during bzr update bzr suggested doing upgrade I did , now I during bzr update I get: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. ?
[09:06] <matkor> ah
[09:06] <matkor> sorry
[09:06] <matkor> upgrade vs update confusion :)
[09:20] <bignose> if I don't see a command in the 'bzrlib' package, but I know it's provided by core Bazaar (not a plug-in), how do I find out how to run it programmatically?
[09:20] <bignose> e.g. 'version-info'
[09:21] <LarstiQ> bignose: I always start by `vim bzrlib/builtins.py`
[09:22] <LarstiQ> bignose: version-info specifically is in bzrlib/cmd_version_info.py
[09:23] <bignose> hmm. so I should 'import bzrlib.cmd_version_info' to get it?
[09:24] <LarstiQ> bignose: well, it is possible to rund the cmd objects, but often that is not exactly what you want
[09:24] <bignose> indeed.
[09:25] <LarstiQ> bignose: depends on what you're doing ofcourse
[09:25] <bignose> I'm hoping there's a better API to get the output of the command, and specify its inputs
[09:25] <bignose> (so now I guess my question is specifically about the 'version-info' command)
[09:25] <bignose> that module exports only the Command class
[09:26] <bignose> s/class/subclass/
[09:26] <LarstiQ> bignose: I'd forego the cmd object and directly do builder=format...
[09:27] <LarstiQ> bignose: are you thinking of specifying a tempate in a file instead of as an argument?
[09:27] <LarstiQ> template, even
[09:28] <bignose> yes, potentially
[09:29] <LarstiQ> bignose: then I request you submit a patch, because I want that too ;)
[09:30] <LarstiQ> bignose: are these enough pointers for now? If so, I'm going afk for the day
[09:30] <bignose> LarstiQ: thanks very much, yes
[09:34] <LarstiQ> cool
[09:34] <LarstiQ> *runs*
[09:46] <lifeless> bignose: you _can_ do cmd_class().run_argv(argv), but thats a pretty crude way to reuse code
[10:28] <bignose> bzrlib.export.export(workingtree.branch, export_dir_path, format="dir")
[10:29] <bignose> File "/usr/lib/python2.5/site-packages/bzrlib/export/dir_exporter.py", line 38, in dir_exporter inv = tree.inventory
[10:29] <bignose> AttributeError: 'BzrBranch6' object has no attribute 'inventory'
[10:30] <bignose> what API should I be using for export? the above doesn't seem to work on a branch as referenced by 'bzrlib.workingtree.WorkingTree.branch'
[10:31] <james_w> branch.repository.revision_tree(branch.last_revision())
[10:31] <james_w> that will get you the last committed revision on the branch as a revision tree, and export works on trees
[10:32] <bignose> hmm. so I know how to get from "arbitrary path somewhere in the working tree" to a WorkingTree instance
[10:32] <bignose> how do I get a repository?
[10:32] <jelmer> bignose: WorkingTree.open_containing(path)
[10:32] <bignose> jelmer: yes, that's the part I know.
[10:32] <jelmer> that'll return a workingtree instance and path relative to the path in the working tree
[10:33] <jelmer> bignose: workingtree.branch.repository
[10:34] <bignose> so I need to do 'branch = workingtree.branch', then 'tree = branch.repository.revision_tree(branch.last_revision())', then 'bzrlib.export.export(tree)'
[10:34] <bignose> yes?
[10:35] <jelmer> bignose: yep
[10:35] <jelmer> bignose: branch.basis_tree() is a shortcut for branch.repository.revision_tree(branch.last_revision()) btw
[10:36] <bignose> jelmer: excellent, thanks
[10:42] <bignose> from a branch instance, how can I get the branch root?
[10:43] <jelmer> bignose: the URL of the branch you mean? branch.base IIRC
[10:43] <bignose> no, the filesystem path as output by 'bzr root'
[10:44] <spiv> That's the .basedir of the workingtree.
[10:44] <bignose> spiv: thanks
[10:45] <spiv> (Which may be the same as the osutils.local_path_from_url(branch.base) a lot of the time)
[10:48] <lifeless> or
[10:48] <lifeless> tree.basis_tree()
[10:48] <lifeless> if you want the wt's parent rather than the branch tip, which could be different
[12:47] <awilkins> markh: Ping?
[12:49] <matkor> Hmmm I upgraded to bzr 1.6.1, done bzr upgrade now, when starting olive (bzr-gtk) bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/users/matkor/.bzr/repository/') has no revision ('matkor@laptop-hp-20080918151249-q38r0dgg95jsnhqi',) .. any suggestions ?
[13:05] <matkor> Hm I had to get back to old (Knit) version of repo ... should I fill bug somehow ?
[13:06] <matkor> by repo has 119 MB and contains data I do not want make public ...
[13:10] <gnomefreak> ok something is really wrong with bzr bd :( on first build using -S -sa everything goes into build-area (that is good) now without doing anything to build-area i build without -S -sa and everything gets pulled from build-area and goes into work/ except for source.changes file
[13:12] <james_w> gnomefreak: -sa isn't a valid option to bd, could you be more specific in what you are doing please?
[13:16] <gnomefreak> james_w: first build (source or binaries) everything goes into build-area   2nd build (source or bins) everything gets removed from build-area except sources.changes and put into work
[13:16] <gnomefreak> dir
[13:16] <gnomefreak> james_w: that is what is causing the cheksum mismatch i showed you earlier
[13:17] <james_w> gnomefreak: yes, I understand
[13:17] <james_w> I'm trying to find out where the bug is, are you now saying that it doesn't matter whether the second is without "-S -sa", everything still gets moved?
[13:18] <gnomefreak> james_w: right that is why ~jjv worked and other one failed
[13:18] <gnomefreak> failed -- errored on lintian
[13:18] <james_w> can you give me the transcripts of this happening then please?
[13:21] <gnomefreak> james_w: i got rid of the build clutter http://pastebin.mozilla.org/539840
[13:22] <james_w> thanks
[13:22] <gnomefreak> james_w: np
[13:23] <james_w> ->mozillateam
[13:23] <gnomefreak> ok
[13:23] <gnomefreak> you mean try that command?
[16:09] <jelmer> join #samba-technical
[16:09] <jelmer> argh
[16:10] <beuno> tsk tsk, look at jelmer trying to get people to join his channel...
[16:11] <james_w> hey jelmer
[16:11] <james_w> hey beuno
[16:11] <jelmer> :-)
[16:11] <beuno> hey james_w!
[16:11] <james_w> how you guys doing?
[16:11] <jelmer> Hey beuno, james_w
[16:11] <beuno> howdy jelmer
[16:11]  * Jc2k resists jelmers demands
[16:11]  * beuno is getting ready to go to NZ for a week
[16:12] <jelmer> beuno, lucky bastard.
[16:12] <beuno> well, it's 24h flight plus 16h timezone shift
[16:13] <beuno> I'm not sure how that's going to pan out
[16:13] <jelmer> a week is not a very long time though  - where are you going there?
[16:13] <beuno> Dunedin, to visit thumper
[16:14] <jelmer> ah, Dunedin is nice
[16:14] <beuno> you've been there?
[16:14] <jelmer> yeah, a couple of years ago
[16:15] <jelmer> a friend of mine lives near Dunedin at the coast
[16:15]  * beuno is impressed
[16:17] <beuno> brb
[17:52] <Leonidas> is there a way to create ghost revisions on purpose via the command line?
[17:55] <jelmer> Leonidas, nope, API only afaik
[17:55] <Leonidas> jelmer: ok, thanks, so I'll write myself a small helper which does that.
[18:02] <bialix> jam: hi
[18:03] <jam> hi bialix
[18:38] <abentley> bialix: I'm closing down the server you have a unix account on.  If you need anything off it, it's at old.aaronbentley.com.
[18:39] <bialix> abentley: thank you, but I don;t have there anything. If there still my files, you can delete it
[18:39] <abentley> bialix: Cool.
[18:39] <bialix> thanks for the fish
[18:40] <abentley> bialix: I tried to let you know by email, but your server dropped the message: http://pastebin.ubuntu.com/48368/
[18:41] <bialix> ukr.net is a free mail server
[18:44] <abentley> bialix: Okay.  Just letting you know.
[18:44] <bialix> thx
[19:53] <abeaumont> hi, i've a svn repo mirror as explained in user guide's 8.2.3 section, which are the commands to have the bazaar mirror synchronized with subversion repo?
[20:01] <tvainika> Do you know about gnome's bzr mirror (bzr-playground.gnome.org), does it sync changes bi directionally? Can I commit with bzr to bzr-playground, or should I commit my changes with bzr-svn to normal svn.gnome.org?
[20:02] <beuno> jelmer, do you know?  ^
[20:03] <jdobrien> i need some assistance resolving a simple conflict with bzr merge
[20:03] <jdobrien> it's a one line conflict and i know what i want in my new branch
[20:04] <beuno> jdobrien, so what's the problem?
[20:04] <jdobrien> the new branch as the proper line it it
[20:05] <jdobrien> but when ever i remove the <<< >>> and try to commit, it says Conflicts detected ...
[20:05] <beuno> jdobrien, so, you removed all the >>>, <<<<, and  [20:05] <beuno> run "bzr resolve"
[20:05] <jdobrien> ahh!
[20:06] <jdobrien> bueno: thanks
[20:06] <beuno> welcome'
[20:07] <beuno> my turn!
[20:07] <beuno> anyone know how I can push a branch to a remote server, and create the working tree automatically?
[20:14] <jdobrien> beuno: can't you just scp the whole folder?
[20:14] <LarstiQ> jdobrien: bad idea
[20:15] <jelmer> tvainika, afaik it's one way - pushing to svn.gnome.org should work
[20:15] <LarstiQ> beuno: push-and-update is not sufficient I presume?
[20:16] <beuno> LarstiQ, it would, but I'm not sure it creates the working tree the first time?
[20:18] <LarstiQ> beuno: good question
[20:19] <beuno> my feeling is no, since the plugin just does the push and updates
[20:19] <beuno> which will error
[20:27] <jdobrien> LarstiQ: thanks, i didn't realize all the capabilities of bzr push
[20:30] <beuno> ok, so next question
[20:31] <beuno> which I've seen answered a billion times, but can never remember
[20:31] <beuno> how do I create a working tree from the pushed branch?
[20:32] <Peng_> beuno: "bzr co"?
[20:33] <LarstiQ> beuno: what Peng_ said
[20:33] <beuno> marianom, what Peng_ and LarstiQ said  :)
[20:33] <beuno> thanks guys
[20:33] <beuno> that's why I never remember
[20:33] <beuno> it doesn't make sense to me
[20:35] <tvainika> beuno: co = checkout just like in svn, cvs or any other "old fashion" vcs, why it doesn't make sense?
[20:36] <beuno> because I'm within a branch, and I'm checking it out into itself
[20:36] <beuno> blows my mind for some reason
[20:37] <fullermd> Sure; you're making a working tree for a branch.  That's what checkout does   :)
[20:37] <LarstiQ> beuno: this is the other sense
[20:37] <Peng_> hg uses "hg update" both to change the working tree to an arbitrary revision and to delete the working tree ("hg up null", since it treats no tree and a tree set to the null revision identically). More intuitive, IMO.
[20:37] <Peng_> Also one command vs. three.
[20:37] <fullermd> Wow, that sounds utterly insanely bizarre.
[20:38] <Peng_> Haha.
[20:38] <Peng_> Both are slightly odd, with "hg up null" and "bzr co", so whatever.
[20:38]  * Peng_ shrugs.
[20:38] <LarstiQ> bzr co corresponds to .bzr/checkout/, which is the metadata for the working tree
[20:38] <fullermd> bzr co never seems odd in the slightest to me.  In CVS, you use 'cvs co' to create a working tree.  In SVN, you use 'svn co' to create a working tree.  In bzr, you use 'bzr co' to create a working tree.
[20:38] <fullermd> Heck, in RCS you use 'co' to create a working file...
[20:39] <fullermd> In SCCS, you just kill yourself.
[20:39] <LarstiQ> :)
[20:39] <beuno> ah, that makes more sense
[20:39] <jdobrien> In VSS you kill everyone else...and then yourself
[20:39] <beuno> "bzr co corresponds to .bzr/checkout/, which is the metadata for the working tree" is what I was looking for
[20:39] <beuno> thanks LarstiQ
[20:39] <fullermd> But you fail at killing yourself, because your weapon corrupted itself from being used too many times.
[20:40] <Peng_> That does make sense, but it still bothers me.
[20:40]  * fullermd still thinks it bothers you because you had the misfortune to hear the phrase 'bound branch'.
[20:40] <Peng_> fullermd: Right.
[20:40] <fullermd> Knowing too much about the underpinings of lightweight and heavyweight and whatnot muddles the issue severely.
[20:41]  * LarstiQ nods
[20:41] <fullermd> If you just stick with 'checkout creates a working tree for a branch', and ignore the lower level stuff as trivial implementation issues that don't affect anything else, it's much easier to work with.
[20:42] <fullermd> I'm a firm believer that overcommunication of that causes a LOT of unnecessary trouble in the user-base.
[20:42] <fullermd> Doubled and tripled the moment somebody mentions 'commit --local'.
[20:43] <jdobrien> fullermd: probably better than complete ignorance, such as mine
[20:44] <fullermd> I'm not sure of that, really.  You don't _need_ to know any of the difference, until you reach below the covers with something like ci --local and unmask it.
[20:44] <jdobrien> you must have missed my suggestion :-)
[20:47] <GaryvdM> Hi - We sometimes see a problem in qlog, where the following error is written to the console:
[20:47] <GaryvdM> UserWarning: LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/Documents%20and%20Settings/Gary/My%20Documents/bzr/.bzr/repository/>) was gc'd while locked
[20:47] <GaryvdM>   warnings.warn("%r was gc'd while locked" % self)
[20:47] <GaryvdM> What can I do to debug this
[20:48] <GaryvdM> I've checked that all our lock_read()'s have try: finally: unlock()
[20:49] <LarstiQ> hmm, no bpierre
[20:50] <LarstiQ> GaryvdM: all I know is to direct you to spiv ;)
[20:50] <GaryvdM> Ok
[20:51] <beuno> and, it's saturday for spiv, so he probably won't be here for a couple of days  :)
[20:52] <LarstiQ> GaryvdM: only qlog has that?
[20:52] <GaryvdM> yes
[20:52] <LarstiQ> GaryvdM: it also happens in bzr selftest runs btw
[20:53] <LarstiQ> GaryvdM: based on that summier knowledge, I'd say it's either something tests and qlog do the same, or it is a bzrlib problem.
[20:53] <LarstiQ> GaryvdM: can you reproduce it reliably?
[20:53] <GaryvdM> Currently
[20:54] <GaryvdM> In fact I've just realised that it happens when you click Refresh\
[20:54] <GaryvdM> Which reopens the branch.
[20:55] <GaryvdM> Now that I realized that - it should be easy to fix :-)
[20:58] <LarstiQ> GaryvdM: aah :)
[21:02] <LarstiQ> does anyknow how I can reach bpierre_ other than waiting till he shows up here again?
[21:06] <jelmer> join #ctrlproxy
[21:06] <jelmer> argh
[21:06] <jelmer> not my best day
[21:08] <beuno> twice, you're borderline spamming!  :p
[21:09] <emmajane> beuno: You're around. :) I have a question for you...
[21:09] <emmajane> How did you tag your web site files in terms of release information.
[21:10] <emmajane> for example: I have just uploaded a series of files for a client to look at. I should probably take a snapshot now so that I can roll back to this point. I don't think I want a branch... but I'm not sure what I want.
[21:10] <Odd_Bloke> kick jelmer Spamming.
[21:11] <LarstiQ> Odd_Bloke: I haven't had time to look at testing bisect yet
[21:11] <jelmer> Odd_Bloke, :-)
[21:12]  * jelmer waves at beuno, emmajane, Odd_Bloke and LarstiQ 
[21:12]  * emmajane waves
[21:12]  * LarstiQ waves at jelmer 
[21:13] <emmajane> (and that was an open question if anyone else has suggestions :) )
[21:13]  * fullermd waggles.
[21:13] <beuno> emmajane, you want to tag the uploaded set of files?
[21:13] <beuno> the revid is uploaded to a hidden file
[21:13] <fullermd> I dunno.  Tags are easy and cheap.
[21:13] <beuno> if you add a tag to the branch
[21:13] <beuno> you can easily map those two later on if needed
[21:14] <LarstiQ> emmajane: a tag sounds reasonable
[21:14] <fullermd> And after all, you can always create a branch from that rev later if you turn out to need a branch.
[21:14] <beuno> and/or push that specific revision
[21:14] <emmajane> beuno: I'm just "manually" uploading files at this point because I'm lazy (at least I remembered to bzr init though *grin*). I think it makes sense to have some kind of history that I can roll back to. Normally I rely on my memory and my commit messages. But there must be something more efficient...
[21:14]  * emmajane nods.
[21:14] <emmajane> tags are like flags, right?
[21:14] <emmajane> just sort of a "hello!! over here!" note?
[21:14] <beuno> emmajane, you mean you didn't use bzr-upload?
[21:14] <LarstiQ> emmajane: "manual" sounds like more work than I'm willing to do ;)
[21:15] <emmajane> beuno: I know, I know. :/
[21:15] <beuno> heh
[21:15] <beuno> well
[21:15] <beuno> if you *do* use bzr-upload, the plugin uploads a file with the revid
[21:15] <emmajane> beuno: I'm already a day late on delivering the specs so I'm amazed I remembered to even think about revision control. It's a start. :)
[21:15] <beuno> so you know what revision was uploaded
[21:15] <Odd_Bloke> beuno: Presumably that's overwritten next time the upload happens?
[21:15]  * Odd_Bloke hasn't even looked at bzr-upload.
[21:15] <LarstiQ> GaryvdM: you're not going to be in .nl somewhere this year perchance?
[21:16] <beuno> Odd_Bloke, yeap
[21:16]  * fullermd has lost count of how many days late he'd be for things if he WEREN'T thinking about revision control   :p
[21:16] <beuno> there's no history of uploads
[21:16] <beuno> we'd need to develop a revision control system on top of a plugin for revision control
[21:16] <emmajane> fullermd: heh
[21:17] <beuno> (or, just keep on adding the uploaded revs to the current file, which is very cheap and easy, but no fun at all)
[21:17] <beuno> emmajane, anyway, if you've just uploaded manually
[21:17] <LarstiQ> beuno: ah, but think about the scalability!
[21:17] <emmajane> at this point I've uploaded it to /client_name/v1-layout/files.html so that they know they're looking only at the "general layout" .. once they've approved that I'll give them sub-nav.
[21:17] <beuno> just do:  bzr tag something_to_rmemeber_it_by
[21:17] <Odd_Bloke> We should write it in C, and really obfuscate the UI.
[21:17] <Odd_Bloke> Then it'll be _fast_.
[21:17]  * emmajane nods.
[21:17] <beuno> and you can come back to that later on
[21:17] <beuno> bzr tags
[21:17] <emmajane> Yeah. I think that's what I want.
[21:17] <beuno> will show you all the tags
[21:18] <emmajane> for example: bzr tag v1_upload
[21:18] <fullermd> Odd_Bloke: Obfuscated UI is nice and all, but C is a pain, and fast is overrated.  If you just wrote it in Haskell...
[21:18]  * LarstiQ cringes at the nested-trees/bzr.dev diff
[21:18] <emmajane> PS I hate IE...
[21:18]  * jelmer cheers on LarstiQ 
[21:18] <beuno> emmajane, we all do  :)
[21:19] <emmajane> Just thought I'd throw that in there.
[21:19]  * emmajane grins.
[21:19] <Odd_Bloke> fullermd: :D
[21:19] <emmajane> thanks for the suggestions, everyone. :)
[21:19] <beuno> welcome'
[21:20] <beuno> and, hurray for LarstiQ finishing nested tree support!
[21:22] <LarstiQ> hah, that's a bit premature :)
[21:23] <beuno> :)
[21:24] <NfNitLoop> ooh, nested tree support.
[21:24] <emmajane> a tag applies to all files, not just the files in that sub-directory, right?
[21:24] <NfNitLoop> What sort of support is that?  :)
[21:24] <LarstiQ> NfNitLoop: lp:~larstiq/bzr/nested-trees
[21:24] <jelmer> emmajane, yep
[21:25] <LarstiQ> emmajane: it applies to a revision, so the versions of all files in the tree at that point
[21:25]  * emmajane nods
[21:25] <emmajane> and I assume I have to commit after adding a tag?
[21:26] <beuno> nope
[21:26] <emmajane> interesting.
[21:26] <beuno> that's one way of putting it, yes  :)
[21:26] <emmajane> what happens if there are changed files ... does the tag apply itself to the last commit?
[21:26] <LarstiQ> beuno: it's a 97k diff, so this will take a while. And then there is fixing the outstanding problems off course. But if you want to help stress test whay I do, please!
[21:27] <fullermd> The tag points at whatever revision you tell it to point at (which is the last commit if you don't say something else)
[21:27]  * emmajane nods
[21:27] <emmajane> again.. "interesting"
[21:27] <emmajane> tags == flags == bookmarks.
[21:28] <beuno> LarstiQ, ah, 97k sounds like fun. Another reason to finish the implementation ASAP  :)
[21:28] <beuno> I'll branch and start poking at it
[21:28] <beuno> what repo format do I need to use it?
[21:29] <LarstiQ> beuno: --development-subtree
[21:29] <beuno> LarstiQ, Format <RepositoryFormatKnit1> for lp-140342092:///~larstiq/bzr/nested-trees/.bzr is deprecated - please use 'bzr upgrade' to get better performance
[21:30] <LarstiQ> beuno: bpierre was trying it out yesterday, and didn't get it to work. I got the same thing. But today I tried afresh, and it works. Difference: using a repository or entirely standalone (the latter works)
[21:30] <LarstiQ> beuno: so be warned of that
[21:30] <LarstiQ> beuno: yeah, I know :)
[21:30] <LarstiQ> beuno: and nested-trees is probably one of the trees with funky revisions, so I'll need to reconcile it.
[21:31] <GaryvdM> LarstiQ: No - I live in South Africa
[21:31]  * LarstiQ nods at GaryvdM 
[21:31] <LarstiQ> GaryvdM: but that in itself doesn't prevent you from visiting :)
[21:31] <GaryvdM> Yes
[21:31] <GaryvdM> I don't think so.
[21:32] <GaryvdM> I'm not working in IT atm.
[21:32] <LarstiQ> GaryvdM: ah, ok.
[21:32] <GaryvdM> Do you know me?
[21:32] <beuno> LarstiQ, note, need a standalone
[21:32] <LarstiQ> GaryvdM: nope!
[21:33] <LarstiQ> GaryvdM: other than from qbzr
[21:34] <GaryvdM> Ok - was just wondering - cause I worked in Maastricht for a while.
[21:35] <LarstiQ> GaryvdM: most people from South Africa I know live/work in the Delft area. And the StoneThree people.
[21:36] <GaryvdM> That is interesting.
[22:20] <danielfolsom> whenever i try to do bzr launchpad-login Danielfolsom, an error comes up: " https://launchpad.net/%7EDanielfolsom/%2Bsshkeys is permanently redirected to https://launchpad.net/~danielfolsom/+sshkeys "
[22:20] <danielfolsom> any ideas?
[22:21] <LarstiQ> danielfolsom: try with daniefolsom instead of Danielfolsom?
[22:21] <LarstiQ> modulo the l
[22:21] <LarstiQ> danielfolsom: the point being upper -> lower case
[22:21] <danielfolsom> omg that did it
[22:21] <danielfolsom> i'm so sorry
[22:21] <LarstiQ> danielfolsom: that's ok :)
[22:21] <danielfolsom> thanks very much!
[22:28] <LaserJock> I've got a perhaps stupid bzr repo question
[22:29] <LaserJock> if I've got a repo, and then two branches that are similar, but different depths, will they still share history?
[22:29] <danielfolsom> does anyone who uses bzr on a mac know if there's a way to update it? And also, would anyone know why bzr would keep freezing up (very consistently)?
[22:29] <LaserJock> my use case is using bzr svn to get different depths of a SVN repo
[22:29] <LarstiQ> LaserJock: yes
[22:30] <LarstiQ> LaserJock: what do you mean with 'different depths' of an SVN repo?
[22:30] <LarstiQ> danielfolsom: get a newer version of bzr? I'm not a mac user, but doesn't bazaar-vcs.org carry .dmgs?
[22:30] <LaserJock> what I mean is, the svn repo has a trunk/<project>/ structure
[22:30] <LarstiQ> danielfolsom: and could you describe the freezing in more detail?
[22:31] <LaserJock> if I branch both trunk/ and trunk/project/ will the repo know that they share history?
[22:31] <LarstiQ> LaserJock: bzr init-repo repo; cd repo; bzr branch foo; mkdir deeper; cd deeper; bzr branch bar;
[22:31] <danielfolsom> LarstiQ: oh ok - and then just another random question - is there any way to uninstall? (just so i know for future reference)
[22:31] <LarstiQ> LaserJock: foo and bar share history
[22:31] <danielfolsom> LarstiQ: it just stops about 1/4 of the way through
[22:31] <LarstiQ> LaserJock: specifically in the case of svn though, they might not have any revisions in common, possibly
[22:32] <LarstiQ> danielfolsom: on mac? No clue. For me it would be apt-get remove bzr.
[22:32] <LarstiQ> danielfolsom: I think it's not freezing, but rather taking a long time.
[22:33] <danielfolsom> LarstiQ: possibly - i'll get back to you after i update - it does say it has to redirect
[22:37] <danielfolsom> BasicOSX: i assume you use bzr with a mac
[22:38] <BasicOSX> danielfolsom:  hourly
[22:38] <danielfolsom> do you know how to uninstall (I'd like to know for the future)
[22:38] <BasicOSX> I pull from bzr.dev repo
[22:38] <BasicOSX> I don't use a package or anything like that
[22:38] <danielfolsom> ahh ok - thanks
[22:39] <danielfolsom> so just bzr pull bzr.dev repo - and that's it?
[22:39] <BasicOSX> Look at appzapper, it will do what you want
[22:39] <BasicOSX> in ~/projects/bzr.dev
[22:39] <LarstiQ> going out on a limb here, but don't .dmgs have their own uninstall facilities?
[22:39] <BasicOSX> then I symlink ~/bin/bzr to ~/projects/bzr.dev/bzr
[22:39] <BasicOSX> and make sure ~/bin/ is first in my path
[22:40] <BasicOSX> just drag the app into trash that does what you want
[22:40] <BasicOSX> appzapper will kill all conf files and whatnot
[22:40] <danielfolsom> haha - that's all a bit over my head
[22:40] <BasicOSX> osx != windows
[22:41] <danielfolsom> and i can't actually find the bzr app, so i don't think appzapper will work
[22:41] <BasicOSX> if installed via dmg should be in /Applications
[22:41] <danielfolsom> yeah - i can't seem to find it
[22:41] <danielfolsom> so i guess that means i didn't install via dmg
[22:42] <LarstiQ> danielfolsom: darwin ports or similar?
[22:42] <danielfolsom> side question: the way you know that bzr is frozen is if the line stops spinning, right?
[22:43] <danielfolsom> LarstiQ: idk, sorry - i've never used darwin before i don't think though
[22:43] <danielfolsom> possibly via svn ... for some reason i just can't find anything
[22:43] <LarstiQ> danielfolsom: no, the line can spin so slowly that you don't see it moving
[22:43] <danielfolsom> o ok
[22:43] <BasicOSX> there is a darwin port, but I haven't used it
[22:44] <danielfolsom> when i put bzr in the search box i get README.txt, bzr.rb, bzlib.h, and bzlib.h - i don't know why there are two
[22:44] <LarstiQ> bzlib.h is bz2 compression, nor bzr
[22:48] <danielfolsom> that's weird - it's still saying i need to update the server to bazaar 1.2, but usng bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev - i thought i just upgraded to 1.5
[22:48] <Peng_> danielfolsom: Known issue. An RPC was removed in 1.6, so older clients assume the server is older than 1.2.
[22:49]  * Peng_ just walked in on this conversation.
[22:49] <danielfolsom> haha no worries
[22:50] <danielfolsom> actually my real problem is  bzr isn't downloading successfully - it did what i said correctly, but when i do bzr branch lp:getting-down-with - it stops 1/4 of the way through
[22:50] <danielfolsom> and i don't think that it's that huge of a file
[22:51] <LarstiQ> /home/larstiq/bin/bzr get lp:getting-down-with  2.39s user 0.40s system 10% cpu 26.783 total
[22:51] <LarstiQ> it isn't that huge
[22:52] <LarstiQ> danielfolsom: do you have strace or somesuch?
[22:52] <danielfolsom> strace? no
[22:53] <danielfolsom> oh wait! Wow, well it took 10 minutes (13 minutes to be exact), but it finally got it
[22:53] <danielfolsom> thanks for all your help!
[22:54] <LarstiQ> danielfolsom: np.
[23:01] <LaserJock> huh, fascinating
[23:01] <LaserJock> bzr is really smart
[23:01] <LaserJock> or maybe I'm just a tad slow ;-)
[23:02] <LaserJock> but it amazes me that I could create a shared repo, bzr branch trunk/ from an LP code import, and then bzr branch trunk/<project/ from the SVN repo directly
[23:03] <danielfolsom> ok i have one more question (sorry to keep coming back): is there a way to see what someone did in a specific diff?
[23:04] <LaserJock> and I lose nothing, each branch only costs me 40KB
[23:07] <danielfolsom> anyone know?
[23:07] <fullermd> danielfolsom: What, you mean just from bzr diff?
[23:08] <danielfolsom> can you use diff to see what someone did in a certain revision? Say revision 177?
[23:08] <fullermd> bzr diff -c177
[23:08] <danielfolsom> o sweet - i never knew about that
[23:09] <danielfolsom> thank you!
[23:09] <LaserJock> bzr help diff has lots of neat things you can do :-)
[23:10] <LarstiQ> danielfolsom: you're welcome to stay around, no need to quit :)
[23:11] <danielfolsom> sweet :)
[23:12] <LaserJock> LarstiQ: do you know if either possible or done already to have bzr remove unneeded revisions from a shared repo
[23:14] <LarstiQ> LaserJock: one way is branching to a new repository
[23:14] <LarstiQ> LaserJock: sorry, I'm falling asleep right now
[23:15] <LarstiQ> LaserJock: also look at the plugins page
[23:15] <jfroy|work> w00t
[23:15] <jfroy|work> I completed Brian de Alwis's work and did the small bit of work left in bzr-svn's ra.c file to enable keychain authentication on Mac OS X
[23:16] <LarstiQ> jfroy|work: cool!
[23:16]  * LarstiQ detaches, be back tomorrow