# /srv/irclogs.ubuntu.com/2008/07/21/#bzr.txt

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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!