=== Chex changed the topic of #bzr to: Bazaar version control | Launchpad will be down/in read-only from 23:00 UTC up to 02:00 UTC for a code update | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers! [00:53] Hi, I just installed bzr-builddeb and got a debconf dialog about postfix [00:53] I know I can basically ignore it, but is there some way to set it up to work with gmail? [00:54] bzr's email stuff can [00:54] but I don't think thats what installed postfix [00:54] it will be debuild's dependencies bringing it in [00:55] right [01:04] is it a known bug that bzr branch lp: isn't working in lucid? [01:04] oh, maybe this is because lp is read-only right now [01:06] lamalex: lp is down right now, for code hosting. [01:12] lifeless, thanks === Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers! [02:12] hi all [02:51] hello. I was wonder if "Bazaar Developers" received a review request for bzr-grep for https://code.launchpad.net/~parthm/bzr-grep/bzr-grep-first-review/+merge/20613 [02:52] I get an oops looking at that page [02:52] thumper: ^ [02:52] lifeless: yep [02:52] lifeless: we kknow [02:52] works on prod [02:52] edge has a misconfiguration [02:53] parthm: I haven't received an email about it, so I guess not [02:54] spiv: weird. the maintainer is bzr devs so i assume it should have worked. [02:54] for bzr-grep [02:56] spiv: i did 'request another review' with reviewer as 'bazaar developers'. i though the maintainer would be the default reviewer. [03:00] parthm: FWIW, it's listed at https://code.edge.launchpad.net/~bzr/+activereviews [03:00] Although bzr's reviews actually go to ~bzr-core, not ~bzr [03:00] spiv: they do ? [03:00] Oh, I might be wrong? [03:00] they go to subscribed teams [03:01] anyhow, ~bzr is in ~bzr-core [03:01] so there is issue if ~bzr-core is the one subscribed to lp:bzr [03:01] s/is/is no/ [03:02] My mail archives suggest that review requests for bzr go to bzr-core [03:05] spiv, lifeless: ok. as long as its in activereviews :-) next time on i can add bzr-core. [03:05] parthm: please don't === samurai is now known as samiam [03:05] the folk in bzr-core *explicitly do not want* to know about bugs or code in plugins. [03:06] ~bzr is the right team, always, for working with stuff in plugins. [03:06] parthm: what lifeless said [03:06] lifeless: sounds fine. [03:06] parthm: but unfortunately I haven't actually received a mail about your review request, so I wouldn't have known it was there without you saying on IRC :( [03:07] spiv: thats what i was confused about. its probably listed only because i added ~bzr explicitly. shouldn't maintainer (~bzr) be the default reviewer? lp bug? [03:08] parthm: I'm as confused as you are. [03:08] parthm: who owns the branch === samiam is now known as samurai [03:09] lifeless: ~parthm owns the branch, ~bzr is the maintainer for bzr-grep. [03:09] maintainer doesn't mean anything [03:09] branch owner does [03:10] if you want - and its up to you - bzr-grep to be team maintained (which your desire for code review suggests), then change the owner of lp:bzr-grep (the target branch), to be ~bzr [03:11] lifeless: that was it. fixed. https://code.launchpad.net/~bzr/bzr-grep/trunk [03:11] lifeless: thanks. [04:29] * igc lunch [04:34] lifeless: btw, regarding bug 531667, see http://jcalderone.livejournal.com/54911.html [04:34] Launchpad bug 531667 in subunit "There is no version attribute anywhere in subunit" [Undecided,New] https://launchpad.net/bugs/531667 [04:36] spiv: patches appreciate [04:37] lifeless: Good to hear they appreciate rather than depreciate in value :) [04:38] I was reading through the man page and I don't see any way to do the equivalent of "svn up -rxxx [file]", i.e. switch a file or the tree to some previous revision [04:38] so, seriously. I'd love a patch [04:38] spiv: what happened to the "p"? [04:38] marv: in bzr 2.1 both update and switch take a -r option [04:39] ah. i seem to have 2.0.2, which is apparently what ubuntu 9.10 makes available to me [04:39] marv: for individual files, perhaps you just want "bzr revert -r NNN some/file", though? [04:40] spiv: that was my next question, i read about the "revert" command, but the man page didn't make it clear if it just changed the working copy, or actually uncommitted the files. all the stuff about it making backups makes me think the latter [04:40] marv: note that bzr commits entire trees, not just individual files, so there isn't really any concept of "fileA at rev 99, but rest of tree at rev 101" [04:40] marv: revert just changes your working tree [04:42] ok, thanks [04:42] marv: if you want to try 2.1 for ubuntu 9.10, you can try the bzr PPA: https://launchpad.net/~bzr/+archive [04:42] marv: revert doesn't actually change the meta data from "r101" to "r99", though. It's "r101 + the files have been modified and coincidentally happen to look like r99". That's often perfectly fine, though. [04:44] Peng: yeah, i could just revert them again to be back at head. and that behavior actually matching what svn users want half the time when using -r with update, at least in my experience [04:44] :) [04:54] Anyone got a moment to enlighten me on bzrlib's export function? [04:54] I thought this would be the most lightweight way of getting the contents of the current revision of a branch. [04:55] But when I use it from within my Launchpad branch, it seems to ignore the URL I pass it and always retrieve a Launchpad branch instead. [04:55] Is this the wrong function to use when I just want to get the current contents of a branch given by URL? [04:57] jtv: there isn't a really lightweight way to get a remote branches tip revision content. [04:57] jtv: export is 'ok', as is using the tree functions. But tell me what you want to do - gimme a full lifecycle use case. [04:58] lifeless: I want to get the current contents of a given branch, do stuff with them, take the results of the stuff away, and forget all about whatever I did with bzr [04:58] (in other words, delete the directory where I got the branch contents) [04:58] jtv: more detail [04:59] will you be querying the revision graph [04:59] will you be diffing files [04:59] will you be doing other things [04:59] I'll be running intltool. [04:59] Which afaik doesn't care one hoot about bzr and even if it wanted any of its features, doesn't know how to. [04:59] thaats it ? [05:00] That's it. [05:00] will it be over the internet [05:00] or a LAN ? [05:00] Read the branch contents as a bit of filesystem. [05:00] This is LP build slaves talking to the codehosting server, so pretty much LAN. [05:01] No private branches now, and for this way of obtaining the branch, probably ever. [05:01] ok [05:01] The preferred protocol is http. [05:01] export should be alright for your use case [05:02] so whats happening [05:02] My code: [05:02] branch, subdir = Branch.open_containing(branch_url) [05:02] rev_tree = branch.basis_tree() [05:02] export(rev_tree, branch_dir) [05:02] . [05:03] This creates branch_dir as it should, but in there, gives me the contents of a Launchpad branch. [05:03] Regardless of what URL I pass. [05:03] what is branch_url? [05:03] what do you mean 'Launchpad branch.'? [05:03] mwhudson: http URL where the branch can be found. [05:04] jtv: do you mean it gives you the entire contents of the branch, not just a subdir that you are identifying in the url? [05:04] lifeless: a branch of the Launchpad source. [05:04] ! [05:04] spiv: no, I'm asking for a completely different, non-LP-related branch and am still getting the LP source tree instead. [05:04] jtv: you are running this command while your cwd is a launchpad checkout? [05:04] that sounds a little strange [05:04] spiv: exactly [05:04] jtv: provide a failing url [05:04] jtv: please [05:04] Now, it may just be an unintended consequence of the way I'm running this. [05:05] lifeless: lp:unpaste [05:05] jtv: oooh [05:05] ok, /not/ an http url. [05:05] jtv: in future, please don't be vague :) [05:05] jtv: make sure bzr plugins are loaded [05:05] jtv: you need to load bzr plugins - the launchpad one specifically [05:05] import bzrlib.plugin [05:05] bzrlib.plugin.load_plugins [05:05] - or - [05:05] jtv: but yeah, best to use http:// urls [05:05] shouldn't that just FAIL if the plugins are missing ? [05:05] import bzrlib.plugins.launchpad [05:06] I did try with an http URL at one point, but don't remember how it failed [05:06] SamB_XP: no, because open_containing is a heuristic - it walks up [05:06] jtv: because lp: name resolution is done by talking to the appservers, which buildds won't be able to do [05:06] SamB_XP: and finds '.', 'lp:unpaaste' [05:06] lifeless: ah [05:06] jtv: I suggest that you don't want open_containing either [05:06] jtv: for what you're doing, 'open'. [05:07] * jtv experiments [05:08] open_containing is for dealing with user input [05:08] 'there is abranch around here somewhere' [05:09] and 'I want the relative path to something in that branch' [05:09] like "bzr diff", yeah? [05:09] neither of which apply to your case AFAICT [05:09] SamB_XP: right [05:09] and bzr merge [05:09] bzr log [05:09] bzr cat [05:10] bzr dog [05:10] bzr moo [05:11] Okay, it works when I try it with open_containing on an http URL. Obviously I'm still doing something wrong with the URL though, because I get "BzrBranch7 object is not iterable" when I use open. [05:11] jtv: open returns the branch [05:11] jtv: no subdir [05:11] jtv: see pydoc bzrlib.branch.Branch.open [05:11] SamB_XP: $ bzr dog [05:11] Command 'dog' not found, perhaps you meant 'log'? [y/n]: [05:12] $ bzr moo [05:12] Command 'moo' not found, perhaps you meant 'move'? [y/n]: [05:12] oh. "this bzr does *not* have super-cow powers." [05:12] open_containing returns (branch, left_over_url_portion) because it has to perform guesswork. open either finds the branch or fails, no ambiguity, so no need for left_over_url_portion. [05:12] oops [05:12] SamB_XP: install bzr-guess :P [05:13] ...and that works! [05:13] Thanks for your patience with my screwups. [05:37] lifeless: tsk tsk: $ bzr love ==> bzr: ERROR: unknown command "love" ;; leaving me to ask, where's the love!!! [05:37] ~$ bzr love [05:37] Command 'love' not found, perhaps you meant 'move'? [y/n]: [05:37] spm: install bzr-guess, you can find the love :> [05:38] I find that a bit creepy that bzr love === bzr move. [05:38] I've been meaning to ask. We can delete thelove@canonical.com now, surely. [05:38] spm: there ain't no love without movement. [05:38] probably; RT requests accepted. [05:39] that's the creepy part.... [05:39] lifeless: somewhat less seriously; managed to briefly grab lamont; he is reaching new levels of bafflement and bewilderment on the subunit stuff. the build for intrepid; drop in hardy question remains open. [05:40] spm: I'm happy with a manual install: I just want it done [05:41] yeah... trouble is we've been down that path before and pain awaits in the fairy garden at the end. But he is aware of it, so I remain hopeful of a solution soon. [05:41] thanks! [05:43] goodbye, thelove! [05:44] alas poor love, I knew him/her/it well.... [05:46] spm: we're being very Shakespearian this week, aren't we? [05:47] Or Hamletic really, since it's all from the same monologue [05:47] one (badly mis)quote and I'm labelled?!!?!? :-) [05:47] to commit or not to commit, that is the question [05:48] (Hmm... "monologue"—that's a good word for a dialogue-that-just-holds-everything-up-until-you-click-OK) [05:48] spm: I did most of the bad quoting as I recall [05:48] "whether 'tis nobler in the channel" [05:48] "to suffer the guns and roses of outrageous fortune" [05:48] jtv: ahh my bad, you said "we're". apologies for the excess of self-ego issues [05:49] * jtv is going dyslexic and read that as self-lego issues [05:49] Must be also why I typed "bzr sty" just now, but in my defense, that _should_ be a valid command [05:49] jtv: I didn't know Self came with Legos! [05:49] or is that the issue ? [05:49] jtv: so what I'm getting there is that a monologue is a language exclusive lock? or perhaps I've spent too much time earlier today staring at postgres logs.... [05:50] SamB_XP: I'll completely ignore the reference and answer, "it depends on who self is" [05:50] spm: hey, it beats sniffing glue. What's a _language_ exclusive lock though? [05:50] jtv: and technically, it could be argued, I do have self-lego issues. seeing as I started stock piling lego for a boy when he was ~ 2-3 months old. which now he's 6 works *really* well :-D [05:50] you know, that language-whose-implementation-does-not-wish-to-build-on-x86/with-modern-G++? [05:51] s/a boy/our boy/ [05:51] spm: that pretty much meets my definition of being one of the very few people _without_ lego issues [05:51] hahahah [05:51] Two, if you count the boy [05:51] SamB_XP: I _said_ I'll completely ignore the reference. :-P [05:52] * SamB_XP gives jtv a morphic drip to correct the problem [05:52] a whu'!? [05:53] Morphic is the name of Self's UI framework [05:55] ah [05:56] and the drip? [05:56] (damn this trait of curiosity!) [05:56] you know, an IV [05:56] like a morphine drip, only morphic ;-P [05:57] YKYBPTLW you miss a reference to morphine because morphic seems such a normal word [05:58] normal word? what the? [05:58] Well, if YBPTL, it might seem to be ;) [05:58] have you been on Squeak or something ? [05:58] (I'm guessing P == Pratchetting) [05:59] also, YRU using all these crazy things starting with Y? [06:03] the what's new in 2.1 page linked me to http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html which seems to 404 [06:03] Y? Y! [06:03] hi all [06:04] thanks for pointing that out, marv [06:05] Hi poolie [06:08] hi spiv, how are you? [06:10] i wish http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion would have linked to http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html the latter seems much more useful but I had a harder time finding it [06:10] marv, it's a wiki so please feel free to add a link [06:15] poolie: pretty good, although I just got a surprising and hopefully unreproducible test failure... [06:24] igc: ping [06:24] hi bialix [06:24] hi igc [06:24] qbzr 0.18.3 is ready for you [06:24] bialix: thank-you [06:25] :-) [06:25] marv: that 404 is a bug in the plugin guide. I need to generate a new one [06:26] igc: anything else needed? [06:26] bialix: not that I know of. hopefully .3 fixes most of the treewidget issues in explorer [06:27] okay, I'll be online again later [06:29] * bialix disappears [06:34] igc, marv, i'll just run an update on escudero [06:34] it may just be out of date? [06:46] no, that's not it, so i'll leave it with you igc [06:57] Hello [06:58] hello [07:00] biab, rebooting [07:01] I have a bazaar repository made with 1.13.1 that I'd like to clone to be able to use with Bazaar 1.6.1. [07:02] Can I use the newer Bazaar to clone it in a way compatible with the older Bazaar? [07:03] sttng359: This depends on what format the repository is in. If I remember correctly, the default format of 1.13.1 should be compatible with 1.6.1, so you should be good to go. [07:03] If you used a non-default format, then you may have problems. [07:03] It was created using the bzr-svn plugin. [07:03] I get Unknown repository format: 'Bazaar RepositoryFormatKnitPack6RichRoot (bzr 1.9)\ [07:04] sttng359: you are _much_ better off installing a new bzr. [07:04] with the older Bazaar. [07:04] sttng359: is that not possible? [07:04] sttng359: I think you could get around that by serving the repository over the smart-server, but newer bzrs are cooler. :) [07:04] My work is using an Ubuntu 8.10 server with has 1.6.1. [07:04] RAOF: Probably not -- bzr still does a lot of VFS access. [07:05] sttng359: So use the PPA to install a newer one. https://launchpad.net/~bzr/+archive [07:05] Then you can upgrade to a newer, smaller, faster repo format too. :D [07:06] The options like 1.6.1-rich-root don't seem to affect branch. [07:06] sttng359: Downgrading is certainly possible, but...why would you want to use an older, suckier format in an older, suckiet bzr? [07:06] I don't have root on my work server. [07:06] sttng359: Ooh. Well, do you have the sysadmin's phone number? :D [07:06] sttng359: you can do 'bzr upgrade --1.6.1-rich-root' [07:06] You _could_ still run bzr from source. [07:06] They are planning on upgrading to Ubuntu 10.04, I think, but it's currently 8.10. [07:07] sttng359: (i.e. the upgrade command can also downgrade) [07:07] ok [07:07] spiv: It can? [07:07] Yes. [07:07] Hey, it can. [07:07] I'd have to get fellow devs to share work with me, so I prefer the server installed version of tools [07:08] but I could probably get them to use my custom installed version. [07:08] 1.6 is not going to be reliable on rich root [07:08] _really_ don't use it with the bzr-svn import [07:09] does --1.9-rich-root represent the format used by newer Bazaar? That option doesn't exist in 1.6.1. [07:09] no [07:09] "bzr init --2a foo && cd foo && bzr upgrade --1.6.1-rich-root" seems to go into an infinite loop. :D [07:09] hi all ! [07:09] the 1.9 formats are about a 15 months old, maybe more. [07:10] Peng: the branch objects don't have a downgrader written for them. [07:10] Peng: there is a bug open. [07:10] lifeless: Ah, fun. [07:10] sttng359: you can use sftp:// rather than bzr+ssh://, then the version of bzr on the server won't matter. [07:14] do I need rich-root support on clones if they won't be directly commiting to subversion? [07:14] yes [07:14] 2.0 has rich root by default [07:14] is much faster and uses less memory ;) [07:16] maybe I can convince my sysadmin to install a newer package, but even my home computer with 9.04 only has 1.13.1. [07:17] You can use the PPA on your home computer too. :> [07:20] Are http transports for Bazaar repository agnostic? [07:21] I don't know what you mean by that question. [07:23] I'm just curious how much trouble open source developers have since it seems like the Bazaar repository format keeps changing. [07:23] It hasn't changed so far this year! [07:23] * Peng ducks [07:24] People use older formats, or upgrade bzr. [07:25] vila, thanks for all the reviews [07:25] sttng359: as Peng says, people stick with the older formats if they can't upgrade bzr [07:25] If I can't clone an open source projects repository because it's the new 2.0 format for example. [07:25] and for replying to the meta patch pilot thing, that saved me feeling i was totally wasting my time [07:25] sttng359: the main problem we had was that bzr-svn required a non-default format until 2.0 [07:25] sttng359: are you having trouble yourself or is it just a general comment? [07:26] poolie: hehe, you're welcome, there are still some left but the queue size is already more reasonable [07:27] fwiw i probably would have finished henninge's branch rather than pushing it back [07:27] bu, obviously, i can still actually do that myself [07:27] no, I am just an assumption that Bazaar 2.0 would create a 2.0 rep by defaultd on my difficulkty using repositories created with bzr-svn (yes, using pre-2.0 bazaar. [07:28] I have had enough issues with subversion automatically updating the format of working copies the moment a newer client even does a status on an older format. I was very glad to at least find out that Bazaar does not automatically upgrade. [07:29] But I assumed Bazaar would use the newest format available for new repos. [07:30] so standard 1.x Bazaar does not use rich-root for standard (non svn-based) repos? [07:30] Usually they wait a couple releases before making a new format the default. The 2.0 format has been supported since 1.18 or so. [07:30] sttng359: Bazaar only started defaulting to a rich-root format in 2.0. [07:31] poolie: well, for henninge's branch, I left the door open, had he say: "Sorry I won't", I would have finished it, but I'd like to make some progress on the conflict stuff too... [07:31] <_habnabit> Can you have a subdirectory in a branch be linked to some other branch, like you can in svn? [07:33] sttng359: There's nothing bzr-svn-specific about rich-root formats, it's just that bzr-svn is pretty much the only thing that requires rich-roots. [07:34] On a seperate note, I am having issues with Bazaar 1.13.1 and bzr-svn checking out a secured HTTPS subversion repository with unexpect 401 response (expect 200 or 404). [07:34] Oh god, _that_ bug. [07:34] so I *really* need to upgrade? [07:35] Wait. Maybe not _that_ bug. [07:35] Still auth makes my head hurt, and I meant to go AFK like an hour ago. Bye! [07:35] s/auth/HTTP auth/ [07:35] k [07:35] thkx for your help [08:33] Hi [08:34] Is there a known memory leak in "bzr svn-import"? [08:34] If not, how can I obtain additional information for the bug report? [08:34] * igc dinner [08:44] vila: i am going through your review comments https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691 [08:45] vila: for the comment on "def parent_dir(path):" are your suggesting i move the code into copy_ownership? [08:47] parthm: copy_ownership says: "If own_src is None, the containing directory is used as source" but this refers to the *usage* of the function instead of implementing it, [08:48] and even there ISTM that you *don't* call chown() if ownership_src is None in higer levels [08:48] So I would rather special case None and '' in copy_ownership and get rid of parent_dir [08:49] but I as said in the end, I'm not sure the whole approach is really sound... [08:49] vila: sounds fine. i think the change might have got lost in one of my edits. [08:49] vila: the approach is discussed a bit on bug #376388 [08:49] Launchpad bug 376388 in bzr "~/.bazaar created owned by root (when run under sudo)" [Medium,In progress] https://launchpad.net/bugs/376388 [08:50] parent_dir is weird in itself and doesn't realy match the way we work in bzrlib [08:50] parthm: yeah, I've read that, I don't agree with everything said there :) [08:50] vila: ok. [08:51] so should we just keep the behavior as is for now? [08:51] but if you address my other concerns, I'll nudge poolie for a review and we'll discuss on a clean patch [08:51] vila: sounds fine. [08:51] regarding the test. [08:52] parthm: that's what I'm unsure about, ISTM that etckeeper already addressed the bug and that we may leave that as is. On the other hand, if we can address the sudo problem for the root user case, maybe we should [08:52] i use _dummy_chown to set instance variables and see if these are changed. does that seem inadequate to you. [08:53] parthm: partly yes, because you then execute code that doesn't do what it's supposed to do and that's... weird [08:53] vila: the assumption is that os.chown works correctly. [08:53] i couldn't think of another way. [08:54] i.e. this is cheating a bit too much and will be brittle in the long run (say if someone make a change, you may still have tests passing without detecting a potential bug) [08:55] vila: thats the lowest level. so unless the os.chown behavior changes it should catch things. the only other way istm is to actually copy ownership from/to another user. [08:56] What I'd do there is making sure chown *change* uid gid [08:56] yes, that would be better [08:56] but i am not sure how portable/reliable that is. [08:57] as long as chown is available and the user running the test owns the containing directory, I'm pretty sure you're allowed to change uid/gid and still be able to delete the file [08:57] or dir [08:57] vila: but do we have access to another user for a test system? we could assign root, but how does that play out with the test infra. [08:57] I'll avoid root but using anything else should be fine [08:57] vila: ok. i was concerned about the delete part. i can try that out. [08:58] making the test explicitly delete the chowned file is a good way to ensure that it fails if something goes wrong [08:58] vila: what other user do you suggest? [08:58] uid+1, gid+1 [08:58] anything that isn't the current user nor root [08:59] vila: +1 may not always work. for e.g. on my laptop i am the only user. [08:59] ro [08:59] I'm pretty sure you may use uids and gids that don't exist [08:59] s/may/can/ [09:00] vila: oh. ok. so just change the uid/gid. sounds reasonable as long as we can delete it. i will give that a try. [09:01] parthm: also recording the calls to chown allows to use a single assertEquals(('path', 12, 12), call_args) [09:01] instead of 3 [09:01] vila: or maybe we can go with some user like 'backup' but i am not sure if that exists on osx. [09:02] vila: i am not sure i understand the part about recording the calls. [09:02] you need to use uids anyway so no need to translate that from usernames, and I don't know of any username guaranteed to exist anyway [09:02] let me find an example in the code base [09:02] vila: sounds ok. i can pick some reasonably large uid/gid [09:03] parthm: arbitrary large is not guaranteed to be different of the current one, that's the key [09:04] vila: yes. +1 should be ok i suppose. if +1 has too many rights we are in trouble anyway :-) [09:04] Probabilistic tests are more fun anyway :p [09:04] fillermd: :) [09:04] fullermd: yeah and funny hostnames too :) [09:05] * fullermd slinks back into his corner [case] :p [09:05] parthm: bzrlib/tests/test_selftest.py search for SkippedTest [09:06] parthm: the methods record the calls *and* call the real methods [09:07] overrideAttr returns the original value (the real chown) that you'll need to use [09:08] vila: sounds good. [09:09] a somewhat related question. is there a shortcut to see work-in-progress mps. right now i go through my branch list for this but its difficult to remember. [09:10] https://code.edge.launchpad.net/$project/+activereviews [09:10] vila: so assertEquals actually makes the call? [09:10] Peng: it seems work-in-progress doesn't show up there. [09:10] Oh. [09:11] Peng: i was just wondering if there was something like +wip [09:11] parthm: wow, no, assertEqual just checks that things are equal :) [09:11] parthm: The branch's +activereviews page shows work-in-progress ones, e.g. https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/+activereviews [09:11] vila: :-) so i make the call myself. [09:11] parthm: there is https://code.edge.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1 [09:12] parthm: you want a recording_chown that append to self._calls and *then* you can check : [09:12] vila, Peng: thanks. loggerhead definitely has a nicer url :-) [09:12] Good afternoon. I was wondering if anyone knew if bzr+svn can use authentication.conf (trying to work on a Google Code svn+https repository that asks for passwords every operation) [09:13] vila: yes. thanks for the help on the review. i think i am good to take another stab at it. [09:13] vila: What pages link to +merges? [09:13] assertLength(1, self._calls) and assertEquals(('path', 12, 12), self._calls[0]) [09:13] vila: good idea. [09:14] Peng: I don't know, I just have this one in my history so I type 'workinp' in firefox and select it :-P [09:14] vila: Heh, okay. [09:15] Peng: sorry, I lied, I just type ''wor' :D [09:15] oh my, I should go through that list as Patch Pilot... [09:16] vila: thats a long list :-) [09:16] Peng: I lied again, see: http://wiki.bazaar.canonical.com/PatchPilot [09:17] Peng: it's mentioned there from 'You can also keep an eye on work in progress merges ...' [09:20] Ah. [09:20] * parthm goes back to actually closing review comments and not talking about them. [09:47] hello, I got a question regarding checkout of subfolders: I have a project where I have a main "root" folder and subfolders e.g. "A" and "B". Currently I have "root" setup as a branch. Is it possible to just checkout/branch one of the subfolders and at the same time get the full history of that subfolder (i.e. no exporting), and also push only this subfolder back? [09:47] Or would I have to setup each subdir as a branch? [09:49] Also, if I did that, is it possible to have changes to the subfolders propagated to the root? [09:49] So if some user just needs folder "A" he can checkout/checkin that, but if someone wants the whole project he can checkout "root", and both are synchronized? [09:50] I'm not afraid to do a bit of python hacking to make the sync work ;) [09:59] vila: lol (re-patch crew mail) [09:59] Kohlrabi: A and B should be 2 branches [10:00] then you can use bzr-externals plugin or scmproj plugin to work on root+A+B as the whole [10:01] bialix: Always Happy to make you laugh (TM) :D [10:01] vila: many thanks! [10:04] vila: I'm writing plugin as universal hooks launcher [10:04]