[00:05] <poolie> spiv, igc, i'm having some skype issues...
[00:05] <poolie> are you here?
[00:11] <rick_h__> lifeless: ping
[00:35] <MatthewWilkes> Right 4 hours is enough. I may try again tomorrow
[02:17] <gdoubleu> Is there anything special you need to do when pushing a loomified branch?  I pushed a loomified branch to launchpad from my laptop and then branched that onto another machine, but it didn't seem to have the threads.
[02:17] <gdoubleu> I have the bzr-loom plugin on both machines
[02:20] <Odd_Bloke> gdoubleu: Did you 'bzr record' first?
[02:20] <gdoubleu> i did not
[02:20] <Odd_Bloke> I think you need to.
[02:20] <Odd_Bloke> Though I don't really use looms, so am not sure.
[02:21] <gdoubleu> I'll try that and attempt to push again
[03:24] <mwhudson> how do i make a branch7 branch?
[03:26] <mwhudson> poolie, spiv?
[03:27] <mwhudson> oh, done
[03:40] <igc> hi all
[03:41] <igc> fyi, I'll be working on porting/testing fastimport to use the new Repository API today
[03:41] <igc> but I'll be offline for a few hours first - lunch & my daily hospital visit first
[04:31] <mwhudson> hey, can bzrlib.repofmt.pack_repo.RepositoryFormatPackDevelopment1 get a new name in bzr.dev really fast?
[04:35] <Odd_Bloke> mwhudson: Why?
[04:35] <mwhudson> well, because it's a terrible name
[04:36] <Odd_Bloke> What would you suggest instead?
[04:36] <thumper> SuperDuperFormat?
[04:36] <thumper> RockinFormat
[04:36] <mwhudson> not sure what the conventions are
[04:36] <Odd_Bloke> It'll be renamed to SuperDuperFormat or somesuch once it's actually that.
[04:37] <Odd_Bloke> But, ATM, it's a development format.
[04:37] <spiv> Something without "Development" would be nice, once it's no longer in Development.
[04:38] <mwhudson> well, i'm kinda hoping 1.6 is actually going to get released soon
[04:38] <Odd_Bloke> mwhudson: I think this format will be in development during the 1.6 cycle.
[04:38] <Odd_Bloke> s/1.6/1.7/
[04:38] <Odd_Bloke> So will be renamed before 1.7 is released.
[04:40] <Odd_Bloke> So before then, users will only see it if they've opted-in to the use of a development format.
[04:45] <mwhudson> speaking as a launchpad developer, i really hope not :)
[04:45] <mwhudson> there's a difference between a development format and a non-default format, surely
[04:48] <Odd_Bloke> In what sense?
[04:49] <mwhudson> well, in the 'option name' sense
[04:49] <spiv> rich-root-pack is a non-default format that isn't a development format, for example.
[04:49] <Odd_Bloke> Well, it'll be hidden, I think.
[04:49] <Odd_Bloke> It certainly should be hidden...
[04:50] <spiv> i.e. the option for it is relatively non-scary, it isn't hidden, etc.  Whereas I think the --stacked option on a branch isn't going to be hidden?
[04:50] <spiv> ISTR some discussion about it on the list.
[05:06] <poolie> mwhudson: i have a patch that makes it a stable format
[05:07] <mwhudson> poolie: excellent
[05:11] <mwhudson> how can i see things that are note()d or mutter()ed when prodding bzrlib interactively?
[05:11]  * mwhudson has vague memories of trace.enable_default_loggin()...
[05:11] <poolie> like from a python interpreter
[05:11] <poolie> yes that should do it
[07:04] <gdoubleu> Odd_Bloke: about the pushing looms, it looks like it's not possible yet: https://bugs.launchpad.net/bzr-loom/+bug/201613
[07:09] <mwhudson> i think that bug is actually mostly fixed
[07:09] <mwhudson> apart from the 'when do i need to record' confusion
[07:10]  * mwhudson wanders off
[09:03] <stub> How do I turn off the bzr prompt thing that seems to have installed itself into /etc/bash_completion.d ?
[09:08] <tacone> boys, my bzr got locked, what to do ? --> Unable to obtain lock lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock
[09:08] <tacone> break-lock doesn't seem to work
[09:09] <tacone> bzr: ERROR: Unsupported protocol for url "lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock"
[09:09] <stub> Is it a bug that bzr has installed /etc/bash_completion.d/bzrbashprompt.sh (breaking my prompt), or is there some way I need to turn it off?
[09:10] <AfC> tacone: is that long number supposed to be there in the protocol?
[09:10] <AfC> ﻿/msg tacone Oh, just FYI, there are women here, too.
[09:10] <bob2> stub: just have to rm it for now
[09:11] <tacone> girls, my bzr got locked :(. http://pastebin.com/m4a069b45 what to do ?
[09:11] <AfC> :)
[09:12] <spiv> stub: there is a bug report about that
[09:12] <AfC> tacone: maybe try `bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/`
[09:12]  * tacone is about to switch in scared-newbie-mode-on
[09:12] <spiv> tacone: "bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/"
[09:12] <spiv> AfC: beat me :)
[09:12] <tacone> lol
[09:12] <AfC> spiv: Hooray!
[09:13] <stub> And then file a bug about the message that tells you to do different
[09:13] <spiv> stub: I'm just doing exactly that
[09:14] <tacone> worked
[09:14] <AfC> Terrific
[09:14] <tacone> I'll file a bug for that, thanks.
[09:16] <spiv> tacone: I just filed one
[09:17] <spiv> tacone: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/250451
[09:18] <kiorky> why does bzr-svn not want to store my creds :S
[09:20] <tacone> spiv: oh god. I was about to click submit :-)
[09:21] <tacone> ok, trashed :-D
[09:22] <tacone> thanks you all. goodbye
[09:43] <jelmer> kiorky, it's not bzr-svn that doesn't store them
[09:44] <jelmer> kiorky, it's bzr itself
[09:44] <jelmer> kiorky, any chance you can file a bug about this?
[09:45] <lifeless> Jc2k: is the conduit guy around at the moment ?
[09:46] <Jc2k> lifeless: he is
[09:46] <lifeless> Jc2k: I have a few minutes before leaving for the train
[09:46] <lifeless> rick_h__: hi
[09:46] <Jc2k> lifeless: *tries to lure him on to gnome-bzr*
[09:47] <jelmer> 'morning lifeless
[09:49] <lifeless> ohi jelmer
[09:59] <kiorky> jelmer: yep, but i am at work, but sue i can when i l have time
[10:00] <kiorky> jelmer: maybe around 12:30, so 11:30 for u
[10:00] <jelmer> Thanks
[10:00] <kiorky> jelmer: describe me what u want as backtrace or tests and etc
[10:02] <jelmer> kiorky, just the fact that passwords aren't saved should be sufficient
[10:06] <blaudden> Hi, I'm running the "merge3-per-file" version of bzr and it just pops into "pdb" all the time. Can't see that it has any breakpoint set ot anything. Typing "cont" will run for a while and then stop at the same line again. Any advice?
[10:07] <jelmer> blaudden, Is that John Meinel's branch?
[10:08] <jelmer> You'd probably want to talk to him - he's around here as "jam" but it's probably too early for him right now
[10:08] <blaudden> yes, it looks like that from "bzr log"
[10:08] <blaudden> ok, i'll hang around. Thanks!
[10:14] <spiv> blaudden: presumably there's a "pdb.set_trace()" either in your branch of bzr, or perhaps in a plugin
[10:14] <spiv> blaudden: I'd try grepping for pdb in your branch of bzr and also in ~/.bazaar/plugins
[10:14] <spiv> If you do "bt" at the (pdb) prompt it should give an indication of where the pdb.set_trace() line is
[10:15] <blaudden> spiv: i'll try that.
[10:18] <blaudden> 850  	            import pdb; pdb.set_trace();
[10:18] <blaudden> thanks!
[10:20] <spiv> blaudden: ta-da :)
[10:25] <poolie> hello
[10:26] <jelmer> spiv,poolie: Hallo!
[10:50] <rick_h__> lifeless: still around?
[10:53] <lifeless> rick_h__: yes, going v soon though to start travelling home
[10:54] <rick_h__> lifeless: cool, have a good trip then
[10:54] <rick_h__> just wanted to try to get this repo/branch thing right in my head
[10:54] <lifeless> ok
[10:54] <rick_h__> check that "commiting to the repo" "add files to the repo" were good
[10:54] <rick_h__> and that creating a branch, and serving out the branch were right
[10:55] <rick_h__> the docs with the shared repository for multiple branches seemed to make some sense
[10:56] <rick_h__> I've just never set it up that way so repo == branch for appearance
[10:56] <lifeless> yeah
[10:56] <lifeless> branch is the user abstraction people work with
[10:57] <lifeless> there is always a repository for  abranch, its implicitly created if no explicit one was made by the user
[10:57] <rick_h__> so should I also commit your changes to the branch then?
[10:57] <rick_h__> and the only time really refer to the repository is if setting up a shared one?
[10:57] <lifeless> yup
[10:58] <spiv> jelmer: hey
[10:58] <rick_h__> ok, sounds like a plan then
[10:58] <lifeless> the tip of a branch is the latest revision
[10:58] <lifeless> a branch has a tip, tags, and configuration details
[10:58] <rick_h__> yea, that comment in that article threw me a bit, but I found some of the docs that seemed to clear it up more
[10:58] <spiv> jelmer: how soon will bzr-svn be faster (the "find_tags is slow" bug)? :)
[10:59] <rick_h__> well have a nice trip lifeless and hopefully this article will be life in Oct and then I can bug you on some more advanced stuff :)
[11:00] <lifeless> sure thing
[11:25] <jelmer> spiv: couple of days hopefully
[11:44] <Peng_> With one slow and large svn repository, bzr-svn spends a massive amount of time crawling the whole thing for tags even when I do a no-op "pull", and even though the branch I actually have checked out is quite tiny.
[11:44] <jelmer> Peng, there's an open bug about this
[11:46] <Peng_> Okay. Well, if you want an example branch, http://software.inl.fr/svn/mirror/tools/ipy/trunk (but I didn't try to reproduce it; I don't feel good about abusing random svn servers to test things).
[11:46] <jelmer> Peng_, Thanks for reporting this. It'll hopefully be fixed in a couple of days
[11:47] <jelmer> (see also spivs comments a couple of lines back)
[11:47] <Peng_> Yeah, since the subject had been brought up, I just wanted to mention it.
[13:05] <kiorky> jelmer: uhm i have another problem, i have a bzr+qsvn branch, then i rebranch locally, but it trys to acces the foreign repo. Why ?
[13:06] <kiorky> jelmer: the work connection is pretty bad, soi like to work offline :)
[13:09] <trepca> hey
[13:49] <jelmer> kiorky, hi
[13:50] <jelmer> kiorky, I suspect you don't have an actual local branch but just a local working tree
[13:50] <jelmer> kiorky: E.g. "svn co" will not create a local branch
[14:07] <kiorky> jelmer: i used bzr branch svn+http://svncred:pass@foo
[14:07] <kiorky> jelmer: then bzr branch ../path
[14:08] <jelmer> kiorky: Where ../path was created with "bzr branch" ?
[14:08] <kiorky> the first yes : "bzr branch svn+http://svncred:pass@foo"
[14:08] <jelmer> not "bzr co" ?
[14:08] <kiorky> nope
[14:09] <jelmer> if that created "foo" then "bzr branch foo bla" should not access the network
[14:09] <kiorky> i can redo it to double check
[14:09] <kiorky> let me a minute
[14:11] <kiorky> jelmer: ~>bzr branch foo bar
 Login LDAP Makina Corpus mpa password:
[14:11] <kiorky> jelmer: :)
[14:12] <kiorky> which a fresh bzr branch svn+...
[14:12] <kiorky> (in foo)
[15:50] <nevans> bug in bzr-svn relating to checkouts: https://bugs.launchpad.net/bugs/248289
[15:50] <nevans> It seems that bzr will try to lock the checked-out branch during a bound branch's commit...
[15:51] <nevans> but it can't lock an svn "branch", so it winds up rewinding history on the svn repo.  :-(
[15:53] <nevans> I didn't even notice this had happened until recently... apparently I've done it four times in the last six months...
[15:53] <nevans> s/done it/triggered this bug/
[16:28] <pickscrape> Is there something in bzrlib that I can use to list files in a remote directory? I'm specifically talking about a non-branch directory (e.g. a directory that might contain branches)
[16:30]  * pickscrape looks at bzrlib.transport
[16:34] <james_w> pickscrape: there is listdir(), but it doesn't work over http
[16:36] <pickscrape> james_w: I've got transport's list_dir working very nicely over bzr+ssh, thanks!
[16:46] <bpeterson> Bazaar can use a variety of different libraries for http, correct?
[16:47] <luks> where 'variety' == two
[16:47] <bpeterson> urllib and pycurl?
[16:47] <luks> but I think plain urllib2 is now the prefered one
[16:47] <luks> yes
[16:48] <bpeterson> is one faster than the other?
[16:48] <luks> faster in what way?
[16:48] <luks> even if one is faster than the other, it won't be noticable
[16:49] <luks> network will be limiting them, not CPU
[16:49] <bpeterson> it's just that bzr over http seems quite slow to me
[16:49] <luks> bzr is slow over http
[16:49] <luks> or generally, bzr is slow :)
[16:49] <bpeterson> especially with networking
[16:49] <james_w> bpeterson: slower than what?
[16:49] <bpeterson> hg
[16:50] <bpeterson> I still use Bazaar because st, diffing, and committing are pretty snappy, but not networking...
[16:50] <luks> what format are you using?
[16:50] <luks> (bzr info)
[16:51] <bpeterson> rich-root-pack
[16:51] <luks> ah, not much you can do, I'm afraid
[16:52] <bpeterson> is rich-root-pack a comprise for space over something else?
[16:53] <radix> bpeterson: I think what he means is that the pack-based formats are the most efficient formats right now, so there's nothing better for you to upgrade to for better performance over HTTP
[16:53] <james_w> bpeterson: static-http for hg?
[16:53] <bpeterson> yep
[16:55] <nevans> how does sftp compare to http for performance?
[16:55] <nevans> still the same bottleneck?
[16:56] <bpeterson> actually I'm more concerned with performance over bzr+ssh
[16:56] <fullermd> No, I think sftp has all different bottlenecks   :)
[16:57] <fullermd> I'm pretty sure sftp eats more round trips, so it's probably a bit more latency sensitive.
[16:57] <bpeterson> it's over ssh, so shouldn't have state?
[16:57] <fullermd> Well, bzr+ssh is a totally different beast from either, so...
[16:58] <bpeterson> mm
[16:59] <nevans> I think it must depend a lot on various factors (e.g. size of your repo).  I just did some tests on a very small branch of mine... and bzr+ssh actually went slower than http.
[17:00] <nevans> probably because it has additional overhead of ssh connection and starting up bzr on the remote end
[17:00] <bpeterson> I'm working with the Python core bzr repo; ~200 MB
[17:34] <LeoNerd> 'bzr st' still claims a pending merge, even though I've shelved it away for now... How might I clear that?
[17:35] <LeoNerd> In actual fact I probably want to just revert it, but I'm keeping it shelved for now
[17:35] <bpeterson> LeoNerd: bzr resolve
[17:35] <luks> bzr revert --forget-merges
[17:35] <LeoNerd> Ah yes; the latter did it
[17:35] <LeoNerd> bpeterson: isn't that for conflicts?
[17:35] <bpeterson> yes, never mind
[17:40] <bialix> luks: hi
[17:40] <luks> hey
[17:40] <bialix> good evening
[17:41] <bialix> luks, Garyvdm was very helpful in fixing regressions
[17:41] <bialix> I think we are ready to release 0.9.2
[17:41] <luks> I haven't followed the latest fixes
[17:41] <bialix> I'm planing to prepare some screenshots with new features
[17:41] <luks> but the current state is usable for me
[17:42] <bialix> me and Gary have fixed all known (for me) regressions so far
[17:43] <pickscrape> Does anyone know what happened to the bzr gentoo overlay?
[17:43] <bialix> luks: so I'm about to starting release process tonight or tomorrow
[17:43] <luks> cool, thanks a lot
[17:44] <luks> I've uploaded translations to launchpad, still waiting for review :(
[17:44] <bialix> I saw.
[17:44] <bialix> I'm confused because I could cange status of some translations
[17:44] <bialix> I'm confused because I could change status of some translations
[17:45] <bialix> I won't wait for translations and don't want to delay release
[17:45] <bialix> but if you wanna to update sk.po I'll wait
[17:45] <bialix> pickscrape: what's up with Gentoo?
[17:47] <pickscrape> Well, I added the overlay a while back to layman, which set it up as a bzr branch that it would pull
[17:47] <pickscrape> But lately it seems that the branch it pointed at has gone away.
[17:47] <pickscrape> Wondering if it has died or just been moved somewhere else.
[17:47] <bialix> luks, I can't create deb for linux. But it will be nice to have it for 0.9.2. This release will be a bomb
[17:48] <luks> bialix: umm, I might do it
[17:48] <luks> but I actually wanted to get rid of the PPA
[17:48] <luks> it's easy to install it on linux
[17:48] <bialix> well, I'm fine either way
[17:49] <bialix> if you will close PPA, then I'll just need to update our wiki page properly
[17:49] <luks> I did :)
[17:49] <luks> or do you mean more than removing it from there?
[17:49] <pickscrape> Is bzr-gtk no longer going to be in the bzr PPA then?
[17:50] <luks> this is about qbzr
[17:50] <pickscrape> oic
[17:50] <bialix> pickscrape: I'm actually using Windows, but I saw this: https://launchpad.net/bzr-gentoo-overlay May be it helps you
[17:51] <pickscrape> bialix: thanks, I just found that myself. I think they might have moved it, so I'm setting it up again to find out...
[17:51] <bialix> luks: I mean this: https://launchpad.net/~luks/+archive
[17:51] <bialix> I don't know PPA well, so maybe presence of 0.9.0 confused me a bit
[17:52] <luks> let me see if I can remove 0.9.0 from there
[17:52] <bialix> ok. I'm just wanted to check this with you
[17:53] <luks> I'll probably build 0.9.2 after the release
[17:53] <luks> but in a ~qbzr-dev PPA
[17:53] <bialix> ah, ok. make sense
[17:56] <chadmiller> Hi.  I work in a project that makes a lot of tags.  |wc -l  says "320".  This brings into relief that tagging in bzr is kind of weird.
[17:57] <LeoNerd> A tag is just a human-readable "friendly" name for a revision... same as a hostname is just a friendly name for an IP address
[18:00] <jam> chadmiller: How are you using tags, and how is it a bit weird in bzr?
[18:00] <jam> (eg, care to elaborate?)
[18:00] <jam> You might be using branches for tags, which is an older way that is certainly clumsier
[18:01] <chadmiller> Consider this morning:  Tim noticed that some tag was on the wrong revision.  He used "bzr tag --delete", "bzr tag", "bzr push" to change it.  Paul comes along and, on pull, gets "Conflicting tags:\n\tblah-blah".  This concerns Paul.  He's questions whether his tree is valid, completed "pull" correctly, et c.
[18:02] <jam> chadmiller: well, tim could have used "bzr tag --force" but sure
[18:02] <chadmiller> He can't tell very much with "missing" or "log".
[18:03] <jam> The problem is that tags aren't versioned
[18:03] <jam> so when they disagree
[18:03] <jam> we don't know which one is "more correct"
[18:03] <chadmiller> Right.
[18:03] <jam> we've had some long discussions about it
[18:03] <jam> it is hard to do better without introducing a whole lot of "meta" overhead
[18:04] <jam> chadmiller: is there some ui polish we could apply to make it a bit more understandable?
[18:06] <chadmiller> I think my biggest problem with it is informational.  Maybe the "Conflicting tags" message should also have "Don't Panic" in warm, friendly letters.
[18:08] <jam> Conflicting tags: <3 <3
[18:08] <jam> Something like that?
[18:08] <Jc2k> now it sounds like bzr is enjoying your suffering
[18:09] <bpeterson> perhaps provide a bzr tag --rename command?
[18:09] <bpeterson> or document that you should use bzr tag --force if you want to rename
[18:10] <bpeterson> here, I'll send you a bundle
[18:11] <jam> bpeterson: "bzr help tag"
[18:11] <jam> --force               Replace existing tags.
[18:11] <jam> But if it is missing in other documentation, feel free :)
[18:12] <jam> also, '--rename' sounds like it would change the name of the tag (but point to the same revision)
[18:12] <jam> which isn't the same as pointing the same name to a different revision
[18:12] <chadmiller> :)  "Your $(verb)s completed, but upstream disagrees about which revisions these tags should appear on.  Your tags were not updated.  Conflicts:\n"
[18:12] <bpeterson> isnt' that what chadmiller wanted?
[18:12] <chadmiller> "%", not "$", grr.
[18:12] <jam> chadmiller: well, probably 'not all tags were updated"
[18:12] <jam> but I understand
[18:13] <chadmiller> Something in the "tag{,s} --help" about resolving those would be good too.
[18:15] <chadmiller> And "bzr pull --clobber-local-tags" ?
[18:15] <bpeterson> so if you want to rename a tag (change the name, but keep it on the same revision), you should bzr tag --delete name and bzr tag --force name
[18:15] <bpeterson> ?
[18:15] <pickscrape> We actually encountered exactly this this mornin g
[18:15] <jam> bpeterson: I would do "bzr tag new-name -r tag:oldname"
[18:15] <jam> and then "bzr tag --delete oldname" if you prefer
[18:15] <pickscrape> A colleague changed a tag, and when I tried to pull I got the 'conflicting' message
[18:15] <jam> but deleting tags doesn't propagate at the moment..
[18:16] <pickscrape> The solution was for me to redefine the tag at my end, after that pull worked.
[18:17] <pickscrape> The problem is, I didn't know (other than talking to him myself) what revision he had changed it to
[18:17] <jam> pickscrape: I *think* you can also "pull --overwrite" but I'm not 100% sure.
[18:17] <jam> pickscrape: bzr log -r tag:NAME path/to/his/branch
[18:18] <pickscrape> jam: I was worried about --overwrite clobbering my local changes
[18:18] <jam> or 'bzr tags -d /path/to/his/branch"
[18:18] <pickscrape> It would have been good if the message had told me which revision the tag was defined as upstream
[18:24] <bpeterson> uhh. that new launchpad ui sure gets me
[18:52] <trepca> is there anyway to save my password for HTTP auth
[18:52] <trepca> it's a pain typing it every time
[18:52] <trepca> even worse ... it asks me several time
[19:04] <chadmiller> Uhm, is the ppa "bzr-beta-ppa" a likely candidate for the real release?
[19:05] <chadmiller> There's some serious evil in there.
[19:05] <jam> Care to list specific evil?
[19:05] <jam> I know poolie plans a couple changes before an rc1
[19:06] <chadmiller> etc/bash_completion.d/bzrbashprompt.sh .   1) clobbering $PS1.  2a) running a python interpreter twice for every shell prompt.  2b) running /bzr/ twice for every shell prompt.
[19:07] <jam> chadmiller: ah, that is planned to be fixed
[19:07] <jam> we weren't meant to install that file
[19:07] <jam> it is a packaging issue
[19:07] <chadmiller> Whew!  Okay, good.
[19:07] <jam> in the short term you can just rm that one
[19:08] <radix> that reminds me of when I installed git-core and it installed a bash completion file which ran git twice
[19:08] <radix> unfortunately, there's another program I have installed in ~/bin called "git", which is an interactive fiction interpreter for Glulx games
[19:09] <radix> so every time I started a new terminal two GUI windows would pop up and give an error message
[19:11] <jam> radix: at least it wasn't on every \t :)
[19:11] <radix> heh, yeah
[19:34] <pickscrape> I'm writing a plugin for internal use that provides a main command with subcommands (shelf-style)
[19:35] <pickscrape> it's been going well, but I'm now having a problem adding options to the subcommands
[19:35] <pickscrape> It seems that bzrlib is trying to parse them as part of the main command, and complaining that it doesn't have the option
[19:36] <pickscrape> I suppose this is because subcommands are a bit of a hack, bit I'm wondering if anyone knows of a workaround
[19:37] <LarstiQ> pickscrape: ah, you're overloading short options that already exist in bzr?
[19:37] <LarstiQ> pickscrape: oh no, I see now.
[19:38] <LarstiQ> pickscrape: well, as a hacky workaround, combine the main command's options from the subcommand options?
[19:38] <pickscrape> LarstiQ: I was just going to try that. It might work, the only problem being the options would show up againt the main command in the help output. I will give it a try though
[19:43] <LarstiQ> pickscrape: yeah
[19:46] <james_w> pickscrape: you may be able to write a subclass of Command that works better with subcommands
[19:47] <pickscrape> james_w: I thought I'd find that when I originally looked at the shelf code, but didn't. Now that I've hit this obstacle I think I might revisit that idea again :)
[19:47] <james_w> it would be a useful thing to have in the core for other plugins to make use of, e.g. shelve
[19:48] <pickscrape> Yes, I was thinking that too. If I get one working I'll see about making it available to bzr. Thing is, nothing in bzrlib would actually need it right now.
[19:49] <LarstiQ> pickscrape: but because it isn't there, no one feels invited to use it :)
[19:49] <pickscrape> chicken/egg :)
[19:49] <pickscrape> My concern is more related to testing/bitrot: if it gets added but not used etc...
[19:49] <LarstiQ> pickscrape: right, I see.
[19:50] <pickscrape> I suppose shelf could keep it happy though if it was migrated to use it.
[19:50] <LarstiQ> pickscrape: if there are two plugins using it though, I think the use part is reasonably covered. For it to be accepted into core it needs to be fully covered with tests anyhow.
[19:50]  * LarstiQ nods
[19:51] <pickscrape> Hmm, on that idea, perhaps it would be better added to bzrtools initially, and then to core once stable etc?
[20:04] <Gilgad13> if i want to move an entire directory that is versioned, how would i do so?  i've tried "bzr mv oldDir path\to\newDir" but i get an error that newDir is not versioned.  Do I have to create and add newDir first?  Is it possible to move whole directories?
[20:04] <Gilgad13> i'm using windows, if it matters
[20:05] <pickscrape> Is newdir inside the same branch as the directory you're moving?
[20:06] <Gilgad13> yes, its executed exactly like that, ie. both paths are relative
[20:06] <LarstiQ> Gilgad13: is path\to\ versioned?
[20:06] <pickscrape> Does path\to already exist and versioned?
[20:06] <Gilgad13> no, should it be?
[20:06] <pickscrape> Gilgad13: yes
[20:06] <LarstiQ> Gilgad13: I'd think so.
[20:07] <Gilgad13> hang on...
[20:07] <james_w> is there a typo in oldDir
[20:07] <james_w> I think if that is the case it complains about the wrong thing
[20:07] <Gilgad13> no, versioning path\to worked
[20:09] <Gilgad13> and an obvious next question.  can I undo a specific move, without reverting to last commit?
[20:18] <Gilgad13> no handy undo-last?
[20:19] <pickscrape> bzr uncommit will undo your last commit, but it will cause problems if the commit has been published elsewhere
[20:20] <Gilgad13> i'm talking about operations between commits, like complex reorg's with multiple moves.  Right now i either bzr revert or move the moved file
[20:20] <pickscrape> Oh. I think revert should do what you need it to
[20:20] <Gilgad13> but it would be nice to have the safety net
[20:21] <Gilgad13> well, if i'm like 4 move's in, it would suck to redo them because of a typo
[20:21] <LarstiQ> Gilgad13: if it's really complex there is no silver bullet.
[20:21] <pickscrape> revert won't undo only the last move I don't think
[20:21] <Gilgad13> damn, i like silver bullets
[20:21] <pickscrape> AFAIK it just looks at the WC picture as a whole.
[20:21] <Gilgad13> pickscrape: exactly
[20:21] <Gilgad13> so i'd have to start over
[20:22] <LarstiQ> starting over doesn't seem like the way to go?
[20:22] <pickscrape> Could you just bzr mv the file back again?
[20:22] <LarstiQ> Gilgad13: but I don't have a clear enough picture of your situation to really give advice.
[20:22] <Gilgad13> pickscrape: its what i've been doing
[20:22] <james_w> you can "bzr mv" back, and "revert path" would probably do it, but obviously would do the wrong thing if the files were modified as well
[20:22] <Gilgad13> LarstiQ: its mostly hypethetical, so no worries
[20:23] <LarstiQ> Gilgad13: are you looking for a revert that only undoes treeshape changes, not content changes?
[20:23] <Gilgad13> LarstiQ: yes, and if possible lets me select specific changes
[20:23] <LarstiQ> problem with that being creating a tree state that never existed in history, but yes.
[20:24] <LarstiQ> Gilgad13: what do you mean exactly? 'bzr revert -r a..b path/' wouldn't be enough?
[20:26] <Gilgad13> having experimented more, i think its a mental problem with how i thought bzr recorded moves
[20:26] <Gilgad13> as in, i thought the recorded a log of actions, but i now see that only the beginning (ie, last commit) and end(now) state matter, not how many moves were applied inbetween
[20:27] <Gilgad13> s/the/bzr in first line
[20:27] <LarstiQ> Gilgad13: ah, indeed.
[20:42] <pickscrape> LarstiQ: I may be jumping the gun a bit here, but it looks like the only change needed to get subcommands working properly is to call parser.disable_interspersed_args() in _parse_args after retrieving it
[20:43] <pickscrape> Sorry, parse_args
[20:43] <pickscrape> (I moved it into a local subclass and called it _parse_args.)
[20:43] <pickscrape> So if that was moved into the Command class itself, a simple switch could potentially allow subcommands with options to function.
[20:44] <pickscrape> Hopefully I didn't make any other changes that I forgot to take into account here...
[21:06] <pickscrape> In fact, simply adding that right into bzrlib appears to make everything work, and doesn't appear to break anything else.
[21:06]  * pickscrape goes off to run the bzr unit tests for the first time ever :)
[21:15] <pickscrape> Yeah, it does break some things. :) This is what tests are for.,..
[21:36] <lifeless> Gilgad13: you can 'bzr revert FILENAME'
[21:36] <Gilgad13> aye, but what would that do with regards to moves?  unmove them?
[21:37] <Gilgad13> revert content changes?
[21:38] <meatballhat> are transparent checkouts from svn supposed to 'just work'?
[21:48] <lifeless> Gilgad13: it would put the path back and revert content changes; I think there i sroom for a --path-only flag or something
[21:48] <lifeless> meatballhat: yes, though you can't pull or merge into a an actual svn tree
[21:49] <lifeless> meatballhat: ((ecause svn can't add revisions without doing a commit to a branch)
[21:56] <meatballhat> lifeless: so there is nothing akin to the 'git-svn' interface, or do I misunderstand? :)
[21:57] <lifeless> meatballhat: you misunderstand
[21:57] <lifeless> meatballhat: 'svn co svn://... foo && cd foo && bzr merge bzr://...' -> FAIL (the .svn directory is not capable of representing a pending merge)
[21:58] <lifeless> meatballhat: 'bzr branch svn://... foo && cd foo && bzr merge bzr://... && bzr commit && bzr push svn://...' -> WIN
[21:59] <meatballhat> lifeless: so I use bzr <command> with 'svn://' urls? or are you only explaining the workflow?
[22:00] <meatballhat> rather, is the use case documented for "I'm at work and my company uses Subversion, but I'd like to interface with it using Bzr" ?  :)
[22:03] <lifeless> meatballhat: I think its documented on the FAQ
[22:03] <lifeless> meatballhat: and yes, you use svn urls with bzr
[22:04] <meatballhat> lifeless: thanks much!
[22:17] <wingo--tp> what's robert collins' nick? any idea why he hasn't definitively commented on https://bugs.launchpad.net/bzr/+bug/239499 ?
[22:19] <lifeless> wingo--tp: that would be me
[22:19] <wingo--tp> ah hello good sir!
[22:19] <lifeless> wingo--tp: I've been travelling for the last two weeks; kind of fragments things
[22:19] <wingo--tp> ah ok
[22:19] <wingo--tp> i'll wait then :)
[22:19]  * wingo--tp just got back to a normal rhythm, post-guadec
[22:20] <lifeless> yah, I had a distro sprint post guadec, then LRL
[22:20] <lifeless> currently in an airport
[22:20] <wingo--tp> yowsers
[22:23] <thumper> lifeless: what is LRL?
[22:23] <lifeless> thumper: lug radio live
[22:23] <thumper> ah
[22:42] <jam> lifeless: I thought it might be something like "Living Real Life", but I was pretty sure you don't do that :)
[22:42]  * lifeless gestures
[22:45] <lifeless> jam: what do you think of the marks rfc?
[23:01] <jam> lifeless: I think it could be really neat, as long as it doesn't get too complex for the user
[23:01] <jam> the hunk-level support is interesting
[23:02] <jam> I'm not sure how we would layer it in for stuff like 'commit', though I'm sure it is possible
[23:02] <jam> I guess it could just be a MarksTree(WorkingTree)
[23:03] <jam> lifeless: I was just looking over your testresources code, aren't you being naughty and iterating over a dictionary you are mutating?
[23:03] <jam> Or is that strictly allowed with your priorityDictionary
[23:04] <poolie> jam, hello
[23:04] <jam> hi poolie, ready for a call?
[23:05] <poolie> yes, does skype suit you
[23:05] <lifeless> jam: I don't recall; its nearly entirely paged out
[23:05] <jam> lifeless: no problem, looking closer it seems to be the way it is designed
[23:05] <jam> poolie: skype is fine
[23:06] <jam> lifeless: sorry to hear about your flight being delayed, are you on your way back to AU?
[23:06] <lifeless> yes
[23:06] <lifeless> jam: I think marks should be core
[23:06] <lifeless> poolie has said hes concerned by that :)
[23:07] <lifeless> I just think its likely to need to be pretty fundamental to work well and consistently
[23:07] <jam> lifeless: I think marks is hooking into a lot of places, so it would end up decorating a lot of commands
[23:07] <jam> status/diff at a minimum
[23:07] <lifeless> jam: yah
[23:07] <jam> commit
[23:07] <poolie> i was imagining a decorator type object too
[23:07] <jam> I'm not sure about update
[23:07] <lifeless> so I'm thinking a WT5 tree; with methods to get a flavour view
[23:08] <jam> poolie: yeah, even if it was "WT.get_view('xxx') which returned ViewTree(self)
[23:08] <poolie> i don't really necessarily mind it being in the core as long
[23:08] <lifeless> or even just change the view on the main object
[23:08] <poolie> something about that mail worried me on first reading
[23:08] <poolie> i would hope that we can work out a way to eg make a ViewTree rather than patching things all over the place
[23:09] <lifeless> lets not use the term view here
[23:09] <lifeless> views are Ian's partial-files-on-disk project
[23:09] <lifeless> which has some overlap but is different
[23:09] <jam> lifeless: well, MarksTree is a bit clumsy, but something like that
[23:09] <jam> sure
[23:09] <lifeless> (I realise I used the term view above; naughty robert :))
[23:10] <poolie> it would also be nice to support
[23:10] <poolie> commit --interactive
[23:10] <poolie> which would ask which files or hunks to commit
[23:10] <lifeless> jam: one way is to decorate a WT; another is to alter the behaviour of the WT itself
[23:10] <lifeless> poolie: yes, bzr-interactive does this already
[23:10] <poolie> and this might want to create a transient in-memory view just for that one command
[23:10] <poolie> oh, nice
[23:10] <lifeless> poolie: and I think I proposed a way to do that in the thread using marks
[23:10] <jam> lifeless: sure, though I think doing it with a decorator is a bit better separation of concern
[23:10] <jam> but as long as it is tasteful, either way is fine
[23:11] <lifeless> merge needs to preserve marks for instance
[23:11] <lifeless> indeed tree transform needs to know
[23:14] <lifeless> though perhaps a lookaside structure will work
[23:14] <bud3030_> Hi Bzr I have a 2nd pc with hardy on it I wen to change passwd under preference  now the new and old want auth.
[23:16] <bud3030_> If there is not a fix that mean a clean install
[23:17] <lifeless> what protocol are you using with bzr?
[23:18] <jam> lifeless: do we have any way of creating branching/merging history without creating a real tree on disk?
[23:18] <jam> BranchBuilder and MemoryTree don't really seem to offer that functionality
[23:20] <lifeless> jam: they both do, but at quite a low level, not by calling merge()
[23:20] <jam> lifeless: how do you create the second branch?
[23:21] <jam> BranchBuilder only has 'build_commit'
[23:21] <jam> and never exposes its tree
[23:21] <lifeless> oh hmm; remember tired :) I'm sure MemoryTree supports set_parent_ids
[23:21] <lifeless> BranchBBuilder though I dunno
[23:21] <jam> ah, I guess
[23:22] <jam> I guess I could do the 1 MemoryTree and use uncommit, etc to move it around
[23:22] <jam> I'll try it
[23:22] <jam> Though I guess I also need to create files in the tree
[23:22] <jam> which is difficult with MemoryTree ... :(
[23:22] <jam> oh, I guess you have put_file_bytes...
[23:23] <lifeless> right
[23:23] <lifeless> its why it exists :P
[23:23] <jam> but it requires a file_id
[23:23] <jam> which is a bit odd for creating a new file
[23:23] <lifeless> yes, which add gives you
[23:23] <lifeless> add([foo], [fooid], [file])
[23:23] <jam> so you just "add(['foo']" even though foo doesn't actual exist?
[23:23] <lifeless> put_file_bytes(fooid, content)
[23:23] <jam> _add you mean?
[23:23] <lifeless> public add
[23:24] <jam> ah, and by passing the kinds it shortcuts '_gather_kinds'
[23:24] <jam> ok
[23:25] <lifeless> could you eyeball https://bugs.launchpad.net/bugs/250514 please
[23:29] <jam> lifeless: I thought we already had a proper patch for that a while ago
[23:29] <jam> maybe it just didn't make it into trunk?
[23:30] <lifeless> ><
[23:30] <jam> jamesh: ^^ Didn't you work up a proper "resend ehlo after starting tls" ?
[23:31] <jam> lifeless: ah, it is the one in bzrlib which is fixed
[23:31] <jam> And for some reason the 'email' plugin doesn't use the one in bzrlib
[23:31] <lifeless> I thought it had been patched to do so :(
[23:32] <jam> lifeless: well, it is parameterized
[23:32] <jam> so it looks easy to do so
[23:32] <jam> but for some reason, I don't see a "from bzrlib import XXX"
[23:33] <lifeless> weird
[23:34] <jam> lifeless: I uploaded a simple patch on it
[23:38] <lifeless> jam: thanks