[00:00] <AfC> lifeless: (I accept your guidance to only delete contents from now on, but "sure it's fine to delete obsolete packs sure sounds like it's ok to delete obsolete_packs" is all)
[00:39] <lbieber> I've tried to run "bzr branch lp:drizzle/staging" from several machines but keep getting these errors - http://pastebin.com/stUsEjNC
[00:40] <spiv> lbieber: hmm :(
[00:41]  * spiv looks
[00:41] <lbieber> I can run bzr branch lp:drizzle with no problem  and also "bzr branch lp:drizzle/build"  which are our main branches that we work with
[00:43] <spiv> Hmm, it doesn't seem to be bug 354036.  Which is good news, although it makes this error a bit mysterious...
[00:49] <lbieber> spiv:  any work arounds for now?
[00:51] <spiv> lbieber: hmm, it just worked for me...
[00:51] <spiv> lbieber: I'm guessing you have a local shared repository
[00:52] <spiv> lbieber: if you could, please tar up that .bzr/repository right now, before anything changes
[00:52]  * spiv digs up the likely bug number
[00:52] <lbieber> I'm not aware of any shared repository that we are using
[00:53] <spiv> You haven't done 'bzr init-repo' at all?
[00:53] <spiv> Hmm.
[00:53] <lbieber> no, didn't do init-repo, let me try that
[00:54] <spiv> lbieber: strange
[00:55] <spiv> lbieber: so, two comments:
[00:55] <spiv> 1) you probably should be using a shared repository if you have multiple branches of drizzle locally, it'll save space and be faster
[00:55] <spiv> 2) I have no idea why you're getting that error
[00:56] <spiv> Hmm, I guess try again, add -Dhpss to the command line, and paste the .bzr.log if it fails again.
[00:56] <spiv> But that exact command worked for me (branching into my /tmp, so no shared repository either)
[00:57] <lbieber> I've tried it now on 3 different machines and always get the same result
[00:57] <spiv> What's your lp username?
[00:57] <spiv> Are you a member of ~drizzle-developers?
[00:57] <lbieber> yes
[00:58] <lbieber> lp username is kalebral
[00:58] <spiv> Hmm, and I'm not.  That might be the key difference.
[00:59] <spiv> mwhudson: ping?  'bzr branch lp:drizzle/staging' works for me, but gives a server-side 'absent factory' error for a user in ~drizzle-developers (which owns that branch)
[01:00] <spiv> lbieber: you might be able to workaround it by using nosmart+lp:drizzle/staging as the URL
[01:00] <spiv> mwhudson: it's not a stacked branch perhaps you could grab a tarball of it for me?
[01:01] <lbieber> just had another drizzle engineer try it and they got the same error, also a member of drizzle-developers
[01:06] <spiv> lbieber: great, that does suggest that's a key ingredient then
[01:07] <spiv> lbieber: some background: lp's codehosting serves you a different copy of the branch depending on whether you have write access to it or not
[01:07] <lbieber> spiv:  ahhhh, ok
[01:07] <spiv> lbieber: so you get direct read access to the version that you (and the rest of ~drizzle-developers) can write to
[01:08] <spiv> lbieber: and I (and everyone else) read from the read-only mirror that lp makes automatically
[01:09] <spiv> It seems there's some sort of glitch in the writeable copy that has been fixed in the read-only copy, presumably the act of mirroring has fixed it up somehow.
[01:10] <mtaylor> spiv: fwiw - branching lp;drizzle/staging works for me - and I should be accessing the read-write version ...
[01:10] <jelmer> poolie: are you landing those two approved branches for lp:bzr ?
[01:10] <lbieber> spiv:  what does "nosmart" do, that appears to be working for me although hasn't finished yet
[01:10] <spiv> mtaylor: perhaps you already have the affected revs in a local shared repo, though?
[01:10] <poolie> i'm going to land ajeans and mine
[01:11] <poolie> hello spiv, jelmer
[01:11] <mtaylor> spiv: that is certainly possible
[01:11] <jelmer> poolie: ok
[01:11]  * mtaylor never operates without a local shared repo
[01:11] <jelmer> moin poolie
[01:11] <poolie> yes, those are the two
[01:11] <spiv> lbieber: it basically disables any efficient streaming of the repo by the smart server
[01:12] <lbieber> spiv:  ok, it does seems very slow
[01:12] <spiv> lbieber: i.e. it's like using sftp, the client does all the work and the server is just sending files, not interpreting them
[01:13] <spiv> I *suspect* that if someone grabs an exact copy of the read-write version from lp, and runs 'bzr check' on it, it will report that it is damaged.
[01:13] <spiv> The mystery is how it got damaged.
[01:14] <spiv> I don't know of any bugs in 2.0 or any later release that would cause that.
[01:15] <poolie> lifeless: could you have a think about bug 551332, a subunit-related thing, or try to reproduce it
[01:15] <lifeless> poolie: I thought your speculation was on target
[01:15] <lifeless> poolie: so I didn't say anything
[01:15] <lbieber> spiv:  so how do we repair it?
[01:17] <spiv> lbieber: Perhaps 'bzr reconcile lp:drizzle/staging', although I'd expect that to be abominally slow
[01:17] <spiv> If 'bzr reconcile' can fix it, we could ask an lp admin to run it server-side for you
[01:18] <spiv> Or maybe we should just ask an lp admin to replace the read-write copy with the contents of the read-only copy?
[01:18] <lbieber> spiv:  either way, which ever you think is more efficient
[01:18] <lifeless> spiv: why  do you think the ro copy is ok ?
[01:20] <bj0> there a workaround for https://bugs.launchpad.net/bzr/+bug/522637 ?
[01:20] <spiv> lifeless: because I can branch it just fine, but lbieber (who is in the owning team) can't from three different machines, no shared repo, and at least one colleague in that team has the same problem
[01:21] <lifeless> ok
[01:21] <spiv> lifeless: mtaylor can branch it... but into a shared repo that may well already have the relevant records
[01:21] <spiv> lifeless: alternative theories welcome :)
[01:21] <lifeless> I can suggest a test
[01:21] <lifeless> mv the .bzr dir there to backup.bzr
[01:21] <lifeless> and have mtaylor push to the dir using '--use-existing-dir'
[01:22] <lifeless> if that fixes it, we can analyse the backup async
[01:23] <lifeless> if it doesn't fix it, then it may be a stacking interaction with whatever it stacks on
[01:24] <thumper> poolie: bug 551525
[01:24] <lifeless> and a genuine bug
[01:24] <thumper> moring bzr people
[01:24] <thumper> well, afternoon for me now
[01:25] <poolie> hullo thumper
[01:26] <lbieber> lifeless:  what is the command line you want mtaylor to try?
[01:27] <lifeless> mtaylor: ping
[01:28] <lifeless> lbieber: if he has a local copy of staging, pushing it up fresh to the existing branch location
[01:28] <lifeless> which requires sftping in to move the current data out of the way
[01:28] <lbieber> lifeless:  ok
[01:28] <lifeless> and if we can distract him from his shiny new machine, I'll step him through it
[01:29] <poolie> jelmer: actually considering john's point in https://code.edge.launchpad.net/~mbp/bzr/484558-merge-directory/+merge/22430 i'm not going to merge that now
[01:29] <poolie> why do you ask
[01:30] <spiv> lifeless: it doesn't seem to be stacked, btw
[01:30] <lifeless> spiv: interestinger and interestinger
[01:30] <lifeless> spiv: what do you think of my suggested test?
[01:30] <spiv> lifeless: sounds good
[01:31] <spiv> lifeless: well,
[01:31] <lbieber> lifeless:  :)   ok, I have to run for now but  will try to grab him to work this out
[01:31] <lbieber> thanks for all the help on this issue
[01:31] <spiv> it's possible that mtaylor's copy is also damaged, just that for some reason he isn't encountering the damage
[01:31] <jelmer> poolie: I'm patch pilot this week, so wanted to make sure ajeans patch was going to make it in
[01:31] <spiv> So if the problem still occurs after the test, the result is going to be ambiguous
[01:31] <jelmer> poolie: so far, you've been making it very for me though :-)
[01:32] <spiv> but if it works, and there's a good chance it will, then great :)
[01:32] <poolie> heh
[01:32] <poolie> there are still lots of branches
[01:33] <mtaylor> lifeless: pong
[01:33] <lifeless> mtaylor: see above
[01:33] <lifeless> your staging branch is bust
[01:34] <lifeless> we should see if your local copy is ok
[01:34] <mtaylor> how do I test if my local copy is ok?
[01:34] <lifeless> and if it is replace the server copy, preserving the current .zbr for analysis
[01:34] <lifeless> cd /tmp
[01:34] <mtaylor> yup
[01:34] <lifeless> bzr branch bzr+ssh://localhost/home/path/to/your/staging/branch
[01:34] <mtaylor> gotcha
[01:39] <mtaylor> lifeless: worked
[01:39] <mtaylor> lifeless: shall I push --overwrite to lp:drizzle/staging?
[01:39] <mtaylor> lifeless: or does someone need to save something to debug later?
[01:40] <spiv> mtaylor: --overwrite won't have any effect, and yes we do want to save something to debug
[01:40] <spiv> mtaylor: so sftp in, move .bzr to .backup.bzr, and then push --use-existing-dir
[01:41] <spiv> Actually, I think "backup.bzr" is the preferred name now.
[01:41] <AfC> The corporate network I'm on blocks bzr:// :(
[01:43] <mtaylor> AfC: whatabout http and/or ssh?
[01:44] <mtaylor> bzrlib.errors.PermissionDenied: Permission denied: "/~drizzle-developers/drizzle/staging/.bzr"
[01:44] <mtaylor> I tried using hitchhiker... lemme try with sftp itself
[01:45] <mtaylor> Couldn't rename file "/~drizzle-developers/drizzle/staging/.bzr" to "/~drizzle-developers/drizzle/staging/backup.bzr.20100330": Permission denied
[01:45] <spiv> mtaylor: just "backup.bzr"
[01:45] <mtaylor> spiv: there is already one of those :)
[01:45] <spiv> ah
[01:45] <spiv> launchpad restricts the filenames you can have in that dir
[01:45] <AfC> mtaylor: yes, in this case I have http:// set up at a parallel URL, but for the duration of the day it's going to be annoying to have to manually express every single branch in terms of a different URL from the ones stored by Bazaar
[01:46] <mtaylor> AfC: find a different corporate network? :)
[01:46] <mtaylor> WOW. Lucid is really f-ing borked at the moment
[01:46] <AfC> mtaylor: I'm not going to bother to try and explain Bazaar to the network admins here. They're as useless as is usually the case with that lot.
[01:46] <mtaylor> AfC: I usually use bzr via ssh myself...
[01:48] <spiv> mtaylor: ALLOWED_DIRECTORIES = ('.bzr', '.bzr.backup', 'backup.bzr')
[01:48] <mtaylor> spiv: nice
[01:49] <spiv> mtaylor: if neither of those is free, you could probably cheat and move it to backup.bzr/backup.bzr.20100330...
[01:49] <lifeless> you could move it to backup.bzr/broken.backup.bazaar
[01:49] <lifeless> jinx
[01:49] <mtaylor> spiv: I moved it to .bzr.backup
[01:49] <spiv> mtaylor: just be sure to tell us :)
[01:49] <spiv> Ok, thanks :)
[01:50] <mtaylor> done
[01:56] <lifeless> ok
[02:02] <cody-somerville> bzr: ERROR: Can't export tree to non-empty directory.
[02:02] <cody-somerville> The directory doesn't exist!
[02:06] <cody-somerville> oh, weird.
[02:06] <cody-somerville> The destination is the first argument.
[02:17] <poolie> sorry, that is a bit weird
[02:17] <poolie> we should change the second to be -d
[02:18] <lifeless> poolie: try stopping apparmour and restartnig it
[02:19] <poolie> heh, apparm_o_r
[02:19] <AfC> bastards
[02:20] <lifeless> poolie: if that fixes it, there is a bug either open or needing filing about this
[02:39]  * igc out for a few hours
[02:52] <mwhudson> hazmat: hello
[02:56] <mwhudson> nm, i'll email
[03:35] <hazmat> hi mwhudson
[03:37] <hazmat> mwhudson, thanks, i missed that in my conversion attempt, that should do the trick
[05:30] <lifeless> EOD; ciao
[05:34] <poolie> ciao, thanks for the bug & review comments
[05:34] <poolie> and lh feedback
[05:34] <lifeless> np :)
[05:53] <poolie> hello spiv
[05:53] <poolie> nice to see you back
[05:55] <spiv> poolie: thanks
[05:55] <spiv> poolie: so nice that you'll review https://code.edge.launchpad.net/~spiv/bzr/smarter-index-search/+merge/21615? :)
[05:55] <poolie> i did read it actually
[05:55] <poolie> should i go through and try to check if you did everything john wanted
[05:55] <poolie> or should i just review it myself?
[05:56] <poolie> if you're confident on the former i can do the latter more qucikly
[05:56] <spiv> Either would satisfy our process, and me, I think.
[05:57] <poolie> :) ok
[05:57] <spiv> I am pretty confident that I've done everything John suggested, but it's been almost two weeks so my memory for the details is fading.  The biggest thing by far though was that it needed tests, and I've added some.
[07:47]  * vila @dentist, bbs
[08:28] <phexter> when trying to branch somthing like lp:xyz i get the following error message: "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.", while http connection work fine. can someone explain me how to solve that? gooogling turned out to be rather frustrating and fruitless... though i think i know that it has to do something with the key verification.
[08:34] <fullermd> You could try connecting to LP with sftp/ssh directly and check the keys that way.
[08:36] <phexter> problem solved
[08:36] <phexter> i didn't had openssh-server installed and the lp ssh key i registered was wrong as well
[08:44] <spiv> phexter: you don't need openssh-server, you do need openssh-client (or an alternative client like paramiko) instead
[08:44] <spiv> phexter: but I'm glad it's working for you now :)
[08:45] <phexter> well i had the whole ssh packet not rightfully installed, and i needed the ssh server package so seahorse could create and setup a new ssh key which i then could update to lp
[08:46] <phexter> i probably could have created just the key, but it worked and therefore i don't worry too much about it ;)
[10:18] <d1b> question on windows is pycurl still used ? (for ssl stuff)
[10:19] <vila> d1b: .bzr.log should already contains the answer. If it doesn't try adding -Dhhtp and use an https url
[10:19] <d1b> vila: im not on windows
[10:20] <vila> d1b: well, me meither :)
[10:20] <d1b> vila: ...
[10:25] <vila> d1b: it used to be included for https certificate verification, if you don't need that, you shouldn't care, is that the case ?
[10:26] <d1b> vila: im trying to work out how to solve bundling pycurl on windows
[10:26] <d1b>  / ssl checking on windows
[10:27] <vila> d1b: meh, how do you do that without being on windows ?
[10:27] <hansinge> What is the best way to upload/update a website? The  bzr-upload plugin? Is it better to install bzr on the server?
[10:27] <d1b> vila: do it on windows in a vm
[10:28] <vila> d1b: so my first remark applies, check .bzr.log on windows
[10:34] <vila> bialix: do you know the status of pycurl on windows ? And its history if it's not included anymore ?
[10:34] <bialix> vila: last time you said me that pycurl is not needed
[10:34] <bialix> vila: I think it's no more bundled into windows installer
[10:34] <bialix> but I don;t know is there any explicit disbale for pycurl
[10:34] <vila> bialix: it's needed if you want certificate verification
[10:35] <bialix> yes, if you want verification. but even without it everything is works, no?
[10:36] <vila> bialix: if you don't need the verification, yes, the urllib based transport works
[10:36] <bialix> I don't know is I need verification
[10:38] <vila> bialix: *you* may not need it, but d1b seems to be needing it :)
[10:38] <bialix> yeah, I'm trying to joke
[10:47] <vila> d1b: so all that is needed is to check if pycurl is still bundled and if not file a bug on lp asking for it
[10:47] <vila> d1b: all the code is already in bzr to use pycurl if it's installed
[10:49] <bialix> vila, d1b: there is no pycurl library in 2.1.0
[10:49]  * vila finds that amazing...
[10:49] <awilkins> I found PyCurl caused more problems than it solved when I was running earlier versions so I uninstalled it
[10:49] <bialix> I mean in the official bzr.exe Windows installer
[10:49] <awilkins> (on Windows)
[10:50]  * bialix remember to have some "nice" days to attempt adding support for certificates
[10:50] <bialix> d1b: pycurl itself is not enough, you have to add bundle with CA certificates
[10:51] <bialix> I've used the ones from Mozilla
[10:57] <bialix> also there was problem with self-signed certificates
[11:31] <d1b> bialix: yes
[11:31] <d1b> i saw thah too
[11:50] <lifeless> anyone know how big a task it was to glue the bzr http server layer into loggerhead?
[12:26] <spiv> lifeless: I don't think it was too large
[12:27] <spiv> lifeless: bzr's http server stuff is WSGI, after all
[12:29] <spiv> lifeless: there's a fairly small "if relpath == '/.bzr/smart':" check in loggerhead/apps/transport.py
[12:29] <spiv> lifeless: I'm not sure how much other code had to be rearranged to keep that so simple, but the end result seems fairly straightforward :)
[12:56] <u-foka> Hy!
[12:56] <u-foka> What is the best practice to set up a shared remote repository?
[12:57] <u-foka> I have 3 system users who have to access the repository but noone else
[12:58] <u-foka> I tryed troughsftp:// but the first push seems to remove my group write permissions :S
[12:58] <u-foka> is bzr+ssh works better in that situation?
[12:58] <u-foka> or where I should look around?
[13:02] <naoki^_> u-foka: May sticky bit help you?
[13:02] <naoki^_> http://www.profarius.com/content/creating-your-own-bazaar-server
[13:03] <u-foka> thanks, will read :)
[13:15] <fullermd> Sticky bit won't affect anything.
[13:15] <fullermd> Presumably you mean the setgid bit.  That affects the group ownership, but wouldn't touch the group write.
[13:16] <fullermd> That gets set based on <some directory>.  Generally just setting g+w on every dir under .bzr/ is the simplest way.
[13:20] <u-foka> yeah, you both right, now I checked again, and really the files created with group write by bazaar, but under my users's name+group, and this what sticky bit can solve right?
[13:21] <fullermd> setgid.  Yes.
[13:22] <fullermd> I dunno who started the fad of calling it 'sticky', but it's totally wrong.  Sticky bit is 01000.  Setgid is 02000.
[13:22] <vila> fullermd: it may have to do that both are displayed 's' in ls -l ?
[13:23] <fullermd> Well, all the 0x000 bits show as s's.
[13:23] <vila> Or that both carry the idea that they "stick" to whatever they are applied to
[13:24] <fullermd> My cynical side says it's because somebody heard "sticky bit" once, and it stuck floating in their head looking for something to hitch onto.
[13:24] <spiv> fullermd: ...for something to *stick* to ;)
[13:24] <fullermd> But then, I'm a grumpy old misanthrope.  And git offa my lawn!
[13:25] <spiv> fullermd: or to put it another way... your theory is that "sticky bit" is a sticky bit of terminology ;)
[13:25] <vila> fullermd: the thing is.... I mixed them for a long time... until I read the Fine manual :)
[13:25] <spiv> fullermd: and you wonder why people are confused? :)
[13:26] <fullermd> Oh, I don't assume people are confused.  Never attribute to incompetence what can be adequately explained by malice   :)
[13:26] <spiv> So the "Referer" header was misspelled as part of an evil plan, rather than by accident?  Hmm.
[13:27] <fullermd> Right.  The conspiracy becomes totally obvious when you link it with the creat() syscall, see.
[13:28]  * vila feels warm inside about all those people making typos too...
[13:32]  * bialix using bzr log to look at his own timezone
[13:42] <u-foka> thanks again! now it works great :) But this setgid (or whatever) thing shouldn't be part of the user-guide's server page?
[14:52] <Tak> when I do a lightweight checkout from a svn repo, is bzr supposed to go through the "analyzing repository" stuff for all the revisions?
[14:55] <LeoNerd> It moreorless has to, doesn't it?
[14:57] <Tak> I don't know; does it? :-P
[14:58] <Tak> I would expect a lightweight checkout to just need the tip
[14:59] <fullermd> How can it know what the tip is?
[15:00] <fullermd> Light co of svn sounds like pain incarnate.  A regular light co has to talk to the other side any time it needs any rev info.  With svn, it would have to re-derive it every time it needed something.
[15:06] <Tak> hmm
[15:06] <Tak> I guess I was hoping to get more or less a svn co, but with ability to do things like shelve
[15:07] <fullermd> You may be able to do that in an actual svn co.
[15:28] <ibboT> hi I'm trying to pull from a branch on a USB stick (I originally created the repository by branching from the USB stick) but I get: bzr: ERROR: [Errno 17] File exists
[15:29] <ibboT> this is using bzr in cygwin on windows
[15:39] <awilkins> Tak, what you want are stacked-branches-on-svn-repo   . I don't think bzr-svn supports that yet.
[15:40] <awilkins> Tak, I just take a local bazaar branch of the svn branch and make a lightweight checkout of that (or a topic branch of it)
[16:24] <Tak> awilkins: thanks - I was hoping to avoid that in this case
[16:30] <awilkins> Tak, big repo? Know the feeling.
[16:31] <awilkins> Branching things out of the Apache SVN is a PITA, it has about 900,000 revisions or something stupid
[16:31] <Tak> big repo, often big changes in big binaries between commits
[16:31] <awilkins> Yuck
[16:32] <awilkins> Jelmer might be able to answer, if he wasn't Guest91560
[16:32] <Boingo> Hello everyone.  I am still a bit new to bzr and trying to get my head wrapped around how I should best use it.  In my case, I have a distributed team work on a base project (PHP website).  Most of the work goes into the base product.  But, from time to time, we need to branch and create specific version for a client.  Most of the changes are cosmetic, CSS, images, etc.  Some are code changes.  Either way, we would like to be able to track the changes in th
[16:32] <Tak> oh, and my connection is through a vpn to a different continent ;-)
[16:33] <awilkins> Tak, One way I deal with this is having a machine close to the repository on which I can take the Bazaar branch and then I pull that using bzr+ssh
[16:33] <awilkins> Tak, but not always an option of robvious reasons
[16:33]  * Tak nod
[18:12] <Hillshum> Can I put repos inside other repos?
[18:16] <fullermd> Do you really mean that, or do you mean branches inside other branches?
[18:16] <fullermd> Either way, the answer is "yes, but", but the buts are different.
[18:18] <Hillshum> fullermd: Maintain subprojects within one main repo
[18:20] <fullermd> See, I think you really mean 'branches' there.  Anything you work on is a branch, not a repo.
[18:21] <fullermd> In any event, you can certainly put one branch inside another in your workspace, but that doesn't establish any connection between them, just impositioning.
[18:22] <fullermd> Establishing a logical connection would be the realm of "nested trees", which isn't an implemented capability.  There are some plugins that approximate it (scmproj and externals being the two primary ones now, I believe)
[18:24] <maxb> oh dear, is it the qt changes in lucid that have broken qbzr? :-(
[18:26] <maxb> Hillshum: A question you might like to consider is: Should these subprojects really share a single common history? Will they really always be branched, merged, tagged as one complete unit?
[18:27] <Hillshum> maxb: No
[18:28] <maxb> In that case, they definitely should be a separate branch per subproject, and if you need a tool to compose a certain filesystem layout from a set of branches, scmproj or externals may be relevant to you
[18:30] <Hillshum> Okay
[20:57] <masklinn> excuse me, I'm trying to list the branches contained in a shared repository, my googling lead me to believe there would be a "bzr branches" command that would do that, but upon trying it this results in bzr: ERROR: unknown command "branches" using bzr 2.1.0 in OSX
[20:59] <IslandUsurper> masklinn, it's in the bzrtools plugin/package
[21:00] <masklinn> IslandUsurper: oh damn, I thought I'd reinstalled it along with bazaar yesterday, but you're right I forgot about it and it indeed isn't installed
[21:01] <masklinn> thanks
[21:01] <IslandUsurper> np
[22:44] <TresEquis> Is this the channel for 'bzr explore' hacking?
[22:46] <GaryvdM> TresEquis: Hi, yes
[22:48] <TresEquis> I'd like to work on getting 'make' to run from inside a project (to build Sphinx docs, actually)
[22:48] <TresEquis> any pointers on where to start?
[22:48] <TresEquis> I'd like to stay mostly "naive" about the code, if I can help it, although I read and write Python for a liviing
[22:49] <the_angry_angel> hi guys, stupid question, but i've hunted through the docs and tried what I'd consider to be the obvious - how can I get bzr forced to use a username and password when checking out from a svn repo? theres anonymous read access, but no matter wht I've tried bzr 2.1.0 on OSX will not allow me to commit. I've tried including the username and password in the URL, I've looked for arguments and failed. any sugestions, or does it need to be shoved i
[22:51] <beuno> the_angry_angel, including them in the URL is the way to go, AFAIK
[22:51] <the_angry_angel> beuno: thats what I figured from some old, old posts on the mailing lists
[22:52] <GaryvdM> the_angry_angel: You can also try authentication.conf
[22:53] <GaryvdM> TresEquis: Confused. How does make/spdinx docs relate to bzr explore?
[22:53] <the_angry_angel> GaryvdM: will do. I've just confirmed that it works as expected under Windows and Linux, so I'm guessing that its an OSX specific bug - cheers for the assistance guys
[22:59] <DebbieWork> Hiya.  I just got told to 'use bzr' for our project's VCS.  I've been reading up, and get a little lost in the diffs bet shared, stacked & nested branches.  If I init-repo my own repo @ "/project", and pull in two branches, /proj/brA & /proj/brB, from 2 different sources, I think I have a 'shared' repo, right?
[22:59] <GaryvdM> DebbieWork: Yes
[23:00] <GaryvdM>  repo @ "/proj/" not  repo @ "/project/"
[23:01] <DebbieWork> GaryvdM: Oops type :-) Thanks.  Ok, so what if I instead create /proj/, pull in /proj/brA, then pullin /proj/brA/brB.  Is that 'nested' or 'stacked'?
[23:01] <DebbieWork> Ugh. typO.
[23:01] <thumper> DebbieWork: you can pretty much ignore stacked and nested branches (you shouldn
[23:01] <thumper> DebbieWork: shouldn't need them
[23:02] <GaryvdM> DebbieWork: shared,
[23:02] <DebbieWork> GaryvdM was it something i said? ;-)
[23:02] <GaryvdM> No press ctrl q by mistake
[23:02] <DebbieWork> thumper Then what's the best way to 'do' /proj/brA/brB?
[23:03] <DebbieWork> GaryvdM: :-)
[23:03] <thumper> DebbieWork: what are you trying to do?
[23:03] <GaryvdM> DebbieWork: You can safely ignore stacked and nested branches when you are starting out. However shared repos are important.
[23:07] <DebbieWork> thumper: Well, first - LEARN! :-)  But, eventually, the proj is a CivicSpace rollout.  Basically, Drupal layout.  Which has the site files buried in a folder in the install.  So, I wanna check out the install from the CivicSpace site (into /proj/brA), then checkout the site files from somewhere else (into /proj/brA/brB), and "end up" with a dir structure that I can publish to the web.
[23:07] <thumper> DebbieWork: I'd ask emmajane
[23:07] <thumper> DebbieWork: I'm sure emmajane has worked with bzr and drupal
[23:07] <DebbieWork> GaryvdM: I'm missing the "important" part of shard repos.  I get the "convenient" biz -- less disk space.
[23:08] <thumper> DebbieWork: shared repos are really helpful for speed of creating other branches (as it isn't copying revisions)
[23:08] <DebbieWork> thumper: Thanks!  emmajane ping?
[23:08] <GaryvdM> DebbieWork: Disk space, and time to branch.
[23:09] <DebbieWork> GaryvdM: Time to branch inside the same shared repo, you mean?
[23:09] <lifeless> moin
[23:11] <GaryvdM> DebbieWork: Yes
[23:11] <DebbieWork> Ooh, is that *this* EmmaJane? http://www.amazon.com/gp/product/0137136692/
[23:12] <GaryvdM> Yes
[23:13] <DebbieWork> GaryvdM: Huh.   Didn't think that that'd be 'important'.  But, I havan't done a gazillion branches yet.  Probably adds up!
[23:13] <DebbieWork> GaryvdM: Great!  I ordered her book yesterday :-D
[23:14] <DebbieWork> thumper: "as it isn't copying revisions".  Just the latest changes, then?  That's the 'sharing' part, right?
[23:15] <idnar> if you're branching within the shared repo, then by necessity all of the revisions involved must already be in the repo, so none will need to be copied
[23:15] <idnar> if you branch from somewhere else, then any revisions not already present in the repo will need to be copied, but those that you already have don't need to be
[23:16] <orbarron> hello all.. need some help :) I want to do the following:  lp: project-rootstock however I am getting the following error --> bzr: ERROR: Connection error: Could not resolve 'edge.launchpad.net' [Errno -2] Name or service not known
[23:16] <orbarron> has anyone seen this?
[23:17] <orbarron> opps.. let me correct that I am running the following command --> bzr branch lp:project-rootstock
[23:19] <DebbieWork> idnar: "any revisions not already present in the repo will need to be copied".  Ok, I see the various .bzr folders -- at the 'top' dir for the init-repo, and in each of the branches.  The shared, and need-to-be-copied, repos' revisions *all* go in to the top-level .bzr? Or each bracnh gets its revisions, but meta-data about it all in the top level?
[23:24] <idnar> DebbieWork: as I understand it, the branch is a record of which revisions make up that particular branch
[23:25] <idnar> DebbieWork: but the actual data about those revisions (file contents etc.) are stored in the repository
[23:27] <idnar> DebbieWork: so the shared repository resides in the top-level .bzr, while the branch data sits in the lower .bzr dirs, as you said
[23:28] <GaryvdM> orbarron: can you access launchpad.net in a web browser?
[23:28] <GaryvdM> orbarron: do you use a proxy server?
[23:29] <DebbieWork> idnar: Poking around with 'du -h', that seems to make sense. Of course the actual DATA files stay in each branch.
[23:30] <GaryvdM> DebbieWork: FYI "Data files" are refered to as Working Tree
[23:30] <GaryvdM> If I understand you correctly.
[23:31] <poolie> hello gary, all
[23:32] <GaryvdM> Hi  poolie
[23:32] <GaryvdM> bla #qt is so rude.
[23:33] <GaryvdM> unhelpfull
[23:33] <GaryvdM>  /rant
[23:33] <DebbieWork> GaryvdM: Hum.  Well, I created 'init-repo --no-trees', then pulled some branches of external projects into the top-level repo.  Those barnches have all the project code in them -- my "data files" -- but there are not Trees involved yet.  Iiuc, I only get a Working Tree if I now checkout (rather than branch again) a branch somewhere.
[23:33] <DebbieWork> This all makes a girl's head spin 8-}
[23:34] <DebbieWork> GaryvdM: They're even worse if you're a paying customer!  ;-p
[23:36] <GaryvdM> DebbieWork: if you do bzr checkout in an existing, that branch will then have a working tree. Run bzr remove-tree to remove the working tree.
[23:37] <GaryvdM> *existing branch
[23:40] <DebbieWork> GaryvdM: Ooh, didn't know that.  So a branch minus its WorkingTree is ... Empty? (except for the .bzr)
[23:40] <GaryvdM> a branch without a working tree
[23:41] <idnar> yeah, there'll just be a .bzr
[23:42] <DebbieWork> Hum.  I guess I need to re-read the checkout vs branch stuff (still thinking about how to layout the CivicSpace project code -- for Production, Staging & Development using bzr).  So many options!   CVS is *much* simpler.  Of course you can't DO much with it :-)
[23:44] <DebbieWork> Well, DUH!  This page snuck past me http://wiki.bazaar-vcs.org/CheckoutTutorial.
[23:47] <TresEquis> GaryvdM: I want to add a tool to my explorer which can kick off a 'make html' inside the project's 'docs' directory
[23:47] <TresEquis> Typical IDE task
[23:48] <TresEquis> This page mentions it as a future feature: http://doc.bazaar.canonical.com/explorer/en/tutorials/customization.html
[23:48] <TresEquis> Note
[23:48] <TresEquis> It would be nice to support make, ant, etc. here. That may work via launching a shell each time. Patches welcome.
[23:48] <TresEquis> (end of quote)
[23:48] <orbarron> GaryvdM: I can access it in a web browser
[23:49]  * orbarron believes this is a proxy issues... :(
[23:49] <GaryvdM> TresEquis: I see. I'm not sure myself. Look out for igc. He is in Australia, so he will be awake soon.
[23:50] <orbarron> just not sure how to set up for bzr
[23:53] <DebbieWork> Ok. So if I have a local branch in a shared repo, /proj/brA, and want to hack on brA *on the same machine*, I can either (1) just hack diretcly on brA, (2) checkout brA brAdev, hack on brAdev, with @commit auto pushed to brA, or (3) branch brA brAdev, hack on brAdev, commit, then update ?
[23:59] <GaryvdM> poolie: I'm not sure if I have missed mail or not. What is the status of 2.2b1?