#bzr 2007-10-22
<lifeless> ok, this makes performance tolerable, just fixing this depth-of-query bug
<lifeless> abentley: a thought, isn't 'is_ancestor()' just 'return self.heads([ancestor, descendant]) == set([descendant])'
<abentley> Could be.  Haven't thought of it that way.
<lifeless> AFAICT it should be equally efficient
<abentley> That seems right to me.
<lifeless> yah it is
<lifeless> and it exposes the bug in heads, because making it the same errors on the test that is_ancestor does not access all history
<lifeless> :)
<jauricchio> hi all! i have a couple very very basic questions about bzr.
<jauricchio> (trying to decide between bzr, darcs, and mercurial)
<jauricchio> First of all... does bzr have any support for forests like Mercurial's Forest Extension?
<jelmer> work is in progress to add support for nested trees (equivalent of forests as I understand it)
<lifeless> superset of forests, because nested trees recurse indefinately, forests are a single construct
<lifeless> where is LarstiQ anyhow ? :)
<jauricchio> Second question... how well does bzr handle binary files?
<jauricchio> (pdfs, icky-word-processor documents, images... up to about 5mb)
<jelmer> lifeless: he had problems with his internet connection after his holidays
<jelmer> lifeless: haven't spoken to him in a couple of weeks
<igc> bbiab
<lifeless> jauricchio: binaries are fine
<lifeless> jauricchio: they can be a bit slow to diff; but other than that we just preserve them as-is.
<jauricchio> lifeless: Does bzr diff magically avoid unchanged files?
<jelmer> lifeless, did you see my discussion with aaron on dirstate-with-subtree? do you think now be a good moment to encourage packs-with-subtree over packs-without-subtree?
<lifeless> jelmer: no, I didn't.
<lifeless> jauricchio: what do you mean? If you mean, do unchanged binaries make 'bzr st' and 'bzr diff' slow - no they don't
<jauricchio> Yeah that was the question.
<jauricchio> So slowness is only incurred when the file is actually changed
<jauricchio> that's good :)
<lifeless> if you touch the file we sha it
<lifeless> if the sha is different we will diff it
<lifeless> (roughly). There are some tweaks in different circumstances.
<jauricchio> makes sense.
<Vantage13> Workflow question.  Let's say I'm a developer working on multiple features for a release of a projects.  So I make a branch of our most recent version to record my changes that will go into the next release.  Now let's say I've got 5 features I'm adding.  I get them done, commit them all locally, but then let's say a feature gets pulled.  Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b
<lifeless> Vantage13: your sentence is being truncated
<lifeless> Vantage13: 'without creating a b
<lifeless> 10:32 < l
<lifeless> '
<Vantage13> without creating a branch for every feature?
<Vantage13> or how do people usually handle this scenario?
<jauricchio> I think you wanted to create a branch for every feature. Branches are cheap. :)
<Vantage13> jauricchio: branches are, but working trees are not.  Currently our code base is about 2GB, so 5 working trees would be 10GB of space per developer...
<jauricchio> Hm... fair enough. (That's a *lot* of code, man...)
<jauricchio> Darcs would call this a "spontaneous branch". Prefix your commit messages with something, and you can work with 'all patches prefixed with (matching) some text'
<lifeless> Vantage13: there is a 'switch' command in bzrtools
<Vantage13> the one thing I thought might deal with this would be using a shared repo and doing a bzr switch for each feature.  So switch to main version, branch feature1, commit, switch back to main version, branch feature2, commit, switch back, etc.  Then merge them all later...
<lifeless> Vantage13: this lets you transform a working tree from branch A to branch B quite cheaply
<Vantage13> lifeless: exactly what I was thinking
<Vantage13> lifeless: does what I described sound right?
<lifeless> yup
<Vantage13> lifeless: Is there a way to 'switch' and create a branch at the same time?  e.g. switch back to main after feature1, then create a branch for feature2 in the same working tree, then switch to it? (to avoid having to create a second working tree at all)
<lifeless> Vantage13: why would you create a second working tree?
<Vantage13> lifeless: I wouldn't want to.  I'd just want to create a branch and switch to it from my current working tree (which would be on the main branch)
<Vantage13> lifeless: I'm wondering if I can do that without creating another working tree
<lifeless> Vantage13: 'bzr branch main new-branch && bzr switch new-branch'
<lifeless> won't create a working tree unless your repository is configured to make a working tree
<lifeless> so just disable creating working trees
<Vantage13> lifeless: ah...
<jauricchio> So, another question. Suppose I have a directory within a repo. I'd like to pull it out of the repo with all changes applicable to it, and make a new repo containing only it. With leading pathnames removed.
<jauricchio> That is, projects is my repo. I want to take projects/foo/baz and make a new repo containing the contents of baz with all history.
<jauricchio> With baz as the top level of the new repo
<Peng> jauricchio: I think "hg transplant" could do that (or at least do the reverse, moving baz into project/foo), but I'm not sure if it preserves cset IDs.
<Peng> jauricchio: I don't know of a way for bzr.
<jauricchio> It's okay if cset IDs are lost
<jauricchio> My use case is, I've been working on this little baby project that didn't deserve its own repo. Then I decide it does and I want to share it with the world.
<lifeless> Peng: answering questions here with 'hg can do X' isn't exactly helpful.
<lifeless> jauricchio: 'bzr split' can do that
<jauricchio> lifeless: /me checks docs
<Peng> lifeless: Heh, sorry. :P
<lifeless> Peng: You're more than welcome to say things like 'packs at 10% faster for me, but you're still 40% slower'. Thats extremely useful to know.
<jauricchio> lifeless: 'split' not found in the user reference at doc.bazaar-vcs.org
<lifeless> jauricchio: 'bzr help split'.
<jauricchio> not installed currently :\
<lifeless> ah. Well then. We have the feature.
<jauricchio> :) cool
<lifeless> and naturally we're expanding on it and improving it as time goes by.
<jauricchio> of course
<jauricchio> ok, thanks for your help lifeless, Peng, and jelmer. bzr looks to be what i need!
<jauricchio> bye
<Peng> Cool.
<lifeless> Peng: speaking of which, are you still dogfooding packs from time to time ?
<lifeless> jelmer: so do you mean bug 131667 ?
<ubotu> Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667
<jelmer> yes
<lifeless> I would love someone to sit down and take on the patch
<lifeless> larstiq was working on it but hes disappeared
<lifeless> the patch to make nested-by-reference trees robust
<poolie> lifeless, hi, so to check that plan:
<lifeless> this is what is needed to make -subtrees a default format and trigger the format bump
<poolie> - make new knit repo containing bzr.dev
<poolie> - reconcile that.
<poolie> - make a new pack repo
<poolie> - pull bzr.dev from the first repo
<poolie> - pull packs branch
<lifeless> (or bzr upgrade --experimental in the reconciled repo)
<lifeless> but yes, thats the right list
<Peng> lifeless: I keep a copy of bzr.dev and repository in pack format and pull and diff frequently, but that's the extent of my dogfooding.
<lifeless> ok
<Peng> FWIW, I never reconciled it.
<lifeless> did you try the C sequence matcher thing ?
<lifeless> which speeds up diff, and would AIUI make your home dir versioning tolerable or even pleasant
<Peng> lifeless: I switched it over to hg before I found out about that, and I've never gotten around to trying it.
<Peng> Hmm. I could right now, but Firefox is hogging so much RAM it wouldn't be remotely accurate.
<lifeless> thats fine, don't worry about it
<Peng> Mozilla should pay me for all the RAM upgrades I have to do for Firefox.
<lifeless> less tabs++ :)
<Peng> Yeah.
<Peng> Less Flash++ too.
<Peng> That's what's really killing it.
<lifeless> poolie: how is it going ?
<poolie> reconciling again
<poolie> i may skip that as i'm pretty sure i did that in the same repo on friday
 * Peng sighs.
<poolie> switching terminals
<Peng> Firefox froze right before I was going to shut it down.
<lifeless> :(
<Peng> Hmm. I should probably just cp instead of using "bzr branch".
<lifeless> abentley: you're bouncing
<abentley> Yes.  Sorry.
<abentley> Updated to gutsy, and it's giving me probs.
<lifeless> :(
<Peng> Uh-ohs.
<Peng> Branching the pack version of my homedir crashed with a KnitCorrupt error.
<Peng> But I think that branch might be older than the most recent pack format.
<lifeless> yes, you probably have annotated knit data in it
<Peng> Yeah.
<Peng> Yeah, I think it might be like the very first revision it's saying is corrupt.
<Peng> Or, the first file.
 * Peng watches the progress bar.
<Peng> A 700 MB .pack file. That scares me.
<Peng> It was 743 MB with annotations, now it's 712.
<lifeless> thats cause you have a lot of data with lots of changes
<Peng> Well yeah. But I'm afraid of it.
<ubotu> New bug: #155629 in bzr "newly-created dirstate file appears blank on curlftpfs filesystem" [Undecided,New] https://launchpad.net/bugs/155629
<Peng> One little bit out of 6 billion could be wrong.
<lifeless> no different to have many 10M files
<Peng> lifeless: With 0.91 with Pyrex and dirstate, real time is 3m9.784s, user is 2m56.132s, sys is 0m10.781s. That might be like a 20 or 30 second improvement.
<lifeless> Peng: how many files are there there ?
<Peng> lifeless: Uhh. A lot.
<lifeless> Peng: and are you committing a merge, or just a regular commit ?
<lifeless> Peng: and finally, had you just added new files before the commit ?
<Peng> lifeless: What command tells me the total number of files?
<lifeless> bzr inventory | wc -l
<Peng> lifeless: 4695.
<Peng> lifeless: In that commit, 39 files changed. Not a merge, and no new files.
<lifeless> had you run bzr add?
<lifeless> (bzr add in 0.91 destroys the stat cache)
<Peng> lifeless: Nope.
<Peng> lifeless: uncommit, maybe a status or two, then commit.
<lifeless> thanks
<lifeless> thats very slow compared to my current results with packs, which is encouraging
<Peng> I'm testing packs right now.
<Peng> BTW, hg is like 30 seconds. ;P
<lifeless> yah
<Peng> Also, I caught it at up to ~355 MB of RAM, and I bet it was bigger at other times.
<Peng> Wow.
<Peng> real    1m44.768s
<Peng> user    1m37.652s
<Peng> sys     0m5.437s
<Peng> Packs *are* faster.
<Peng> The new .pack file is 726 KB.
<lifeless> hmmm, not that much faster
<lifeless> I'd love it if you could repeat that
<Peng> Just run it again?
<lifeless> with --lsprof-file foo.callgrind
<lifeless> then gzip the callgrind file and mail it to me
<Peng> Gack.
<lifeless> this won't give me anything private
<lifeless> just the callgraph and timings
<lifeless> so I can see where the slowness is coming from
<Peng> I know.
<Peng> I said "Gack." because I had just started running it again.
<lifeless> ;)
<lifeless> just ctrl-C it
<Peng> I did.
<Peng> It'll be done shortly.
<lifeless> thanks!
<Peng> real    2m0.958s
<Peng> user    1m38.290s
<Peng> sys     0m22.328s
<Peng> Huh.
<Peng> I would've expected user time to be higher due to lsprof.
 * Peng sighs.
<ubotu> New bug: #155632 in bzr "KeyError: 77 in pycurl_errors.errorcode" [Undecided,New] https://launchpad.net/bugs/155632
<lifeless> poolie: how goes it ?
<Peng> lifeless: What's your email address?
<lifeless> robert at ubuntu
<Peng> Blaah, you have more email addresses than I do.
<Peng> ubuntu.com?
<lifeless> yah
<poolie> lifeless, i think that's the same error i saw on friday
<poolie> so
<Peng> Wasn't it @canonical.com two months ago?
<lifeless> yes
<lifeless> its there too
<lifeless> you coulda use the prior address :)
<Peng> I'll send it in a second.
<Peng> Sent.
<lifeless> Peng: thanks
<lifeless> Peng: 67% is in get_content_maps
<lifeless> Peng: which is building up the copy of the the text to diff against
<lifeless> 10% in IO
<lifeless> we can't reduce that much
<lifeless> actually, 5%
<lifeless> 5% parsing the deltas from disk
<lifeless> ohfuckme
<lifeless> Peng: I can see an easy 17% win
<lifeless> we're memory copying stuff we don't need to, because of a general 'get many versions' function
<lifeless> Peng: if you look at bzrlib/knit.py
<lifeless> Peng: the function get_content_maps
<ubotu> New bug: #155637 in bzr "patch confict should be an internal error" [Low,Confirmed] https://launchpad.net/bugs/155637
<lifeless> see the coyp() calls in there - there are two I think. Guard them with e.g. 'if multiple_versions:'
<lifeless> and at the top of the function do
<lifeless> multiple_versions = 1 != len(version_ids)
<lifeless> this should save 17% trivially.
<Peng> lifeless: Cool.
<Peng> Hold on.
<Peng> lifeless: _get_content_maps?
<lifeless> yah
<lifeless> line 1000 in my knit.py
<Peng> Exactly 1000?
<Peng> Anyway, done.
<Peng> lifeless: Want a new callgrind file?
<lifeless> nah, just run it without callgrind and see if it helps
<Peng> Well, I ran it with callgrind and it helped.
<Peng> Uhm.
<Peng> 56 seconds vs. 1m38s.
<lifeless> great
<Peng> Yeah.
<lifeless> theres another win of the same size in _apply_delta
<lifeless> in the same file
<lifeless> will be a little more tricky to fix that without leading to bugs
<lifeless> I'll do both today though
<Peng> I helped make Bazaar faster. Cool.
<lifeless> yup
<Peng> Well, I'd be happy to re-run it in the future if you ever want me to.
<lifeless> tomorrow probably ;)
<lifeless> and thanks
<Peng> Heh, okay.
 * ig1 food
<poolie> lifeless, ping?
<lifeless> hi
<ig1> so lifeless, 3 patches today (so far) - what order do you want them reviewed in if any?
<lifeless> don't care about order
<lifeless> just about completeness
<lifeless> FIFO is fine
<lifeless> and probably best
<ig1> ok - I'll start with the tests one now
<lifeless> oh that one can be ignored
<lifeless> leave it till later
<ig1> that's why I asked :-)
<ig1> graph.heads then
<poolie> i've turned my check-knits branch into a plugin
<poolie> it's faster than a full check (because it does less)
<poolie> it may be useful
<lifeless> ig1: how is the review going ?
<ig1> getting there ...
<ig1> haven't looked at the graph code before
<ig1> you have an import pdb but onothing else stands out so far
<ig1> s/onothing/nothing/
<lifeless> do I? oh foo
<ig1> in test_graph.py
<ig1> also 2 lines immediately before run_heads_break_deeper ...
<ig1> otherwise tests look good
<lifeless> is that 'merge it'
<lifeless> or 'I'm still thinking' ? :)
<ig1> I'm still thinking - need another 20-30 minutes I think
<lifeless> ig1: well, next patch is up
<ig1> ok - not thru yet to me - will check again soon
<lifeless> there it goes
<lifeless> Peng: 2851
<lifeless> Peng: thats the revno in repository with a bugfix to remove all three list-copies.
<lifeless> Peng: it will also, incidentally, reduce memory pressure, but probably not much
<poolie_> bug 154283
<ubotu> Launchpad bug 154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283
<poolie_> join-branches.txt-20050309044946-f635037a889c0388^@robertc@robertcollins.net-20050919060519-f582f62146b0b458^@^@1747020^M1746789^I1747020^@ 42658896 124$
<fullermd> Took the words right outta my mouth.
<Lo-lan-do> You have strange things in your mouth.
<fullermd> It's like that thing with the old lady who swallowed a fly.
<ig1> lifeless: that review finally mailed - few tweaks only as best I can see
<Peng> lifeless: Holy crap. With callgrind, user time went from 56 seconds last time to 19. Real time was still at 56 seconds, but Firefox is open now so everything is probably laggier. Sys time went from 23s to 21s.
<Peng> lifeless: Trying again, real time is down 10s and the others are down 1 or 2.
<lifeless> ig1: yup, copacetic
<lifeless> ig1: will do tomorrow.
<lifeless> Peng: so is this good ?
<ig1> lifeless:quikc Q
<ig1> what's the idea behind the version_id param in the apply_delta API?
<lifeless> Peng: what is real time sitting at without callgrind ?
<lifeless> ig1: KnitContent objects have a version
<lifeless> ig1: Plain ones use this for all lines; Annotated ones carry it per-line
<lifeless> so the parameter is to totally transform the content object from state to state
<Peng> Hold on. I'm brushing my teeth.
<ig1> and self_version_id only gets set for one, not the other, is therefore by design?
<lifeless> yes
<ig1> s/self_/self._/
<ig1> ok - thanks
<mdke> I'm still playing with svn-import. Does anyone know why I'd get a "server certificate verification failed" on one gutsy computer and not on another, connecting to https://docteam.ubuntu.com/repos?
<lifeless> check for /etc/ssl/ca-certificates.crt
<lifeless> if its missing run update-ca-certificates
<Peng> real    0m22.511s
<Peng> user    0m17.378s
<Peng> sys     0m2.758s
<Peng> lifeless: ^
<lifeless> Peng: how does this compare to hg ?
<Peng> Umm.
<Peng> Very good.
<Peng> well?
<lifeless> thanks :)
<mdke> lifeless: it was present in /etc/ssl/certs/
<mdke> I ran the update anyway, no change
<Peng> Last hg one I did was:
<Peng> real    0m45.080s
<Peng> user    0m13.716s
<Peng> sys     0m2.316s
<lifeless> mdke: sorry yes thats the right place. Other than that I have no suggestions.
<mdke> ok, thanks anyway
<lifeless> Peng: hmm, still need to shave off lots of user time. But I knew that
<mdke> lifeless: one was executed over ssh, could that make a difference?
<Peng> Bzr and hg aren't committing exactly the same data.
<Peng> So it's not an entirely fair comparison.
<lifeless> Peng: bzr's committing less?
<Peng> I don't know.
<lifeless> ah
<lifeless> so its roughly the same but not identical ?
<Peng> Bzr is using two-month-old data. Since then, my IRC logs have grown larger, but I've also switched from Opera to Firefox.
<Peng> Hm.
<Peng> I think hg is about the same as it was two months ago. It used to take about 30 seconds, but I'm not sure if that was real or user time.
<Peng> If it was real time, the extra time is just due to Firefox hogging RAM.
<lifeless> gnight all.
<Peng> Good night.
<Peng> lifeless: BTW, bzr is probably committing more changes. Bzr is doing 12 hours of changes while hg is doing 1.
<GaryvdM> Is it possible to pull the bzr.dev branch over the bzr protocal
<GaryvdM> All the docs point to http urls
<poolie_> GaryvdM, you should be able to get it from
<poolie_> bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk
<poolie_> you need to have a launchpad account
<poolie_> we'll offer public bzr:// soon
<Peng> Not to be a troll, but is bzr any less slow than http?
<Lo-lan-do> I think there are fewer round-trips, so probably.
<Peng> It takes a very long time to pull changes to bzr.dev.
<Peng> Of course, the one time I time it, there aren't any new changes, and it takes 3 seconds.
 * Peng wanders off.
<poolie_> ok so it's
<poolie_> KnitVersionedFile(file:///home/mbp/newbzr/dest2/.bzr/repository/text%3ATestUtil.py-20050824080200-5f70140a2d938694)
<poolie_> bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8ef5e4c>".
<indraveni> hi all
<indraveni> i would like to know, whether there are any tools for viewing the bazaar content
<indraveni> like for subversion we have, trac, websvn etc
<Kinnison> Morning
<indraveni> i would like to know, whether there are any tools for viewing the bazaar content
<indraveni> like for subversion we have, trac, websvn etc
<poolie_> indraveni, yes, look at loggerhead
<Peng> indraveni: There's also a bzr plugin for Trac.
<GaryvdM> Peng: acording to http://weblogs.mozillazine.org/jst/archives/2007/02/bzr_and_different_network_prot.html bzr is faster than http
<GaryvdM> I'm going to test it now
<GaryvdM> I live in South Africa - We have slow internet connections.
<GaryvdM> bzr+ssh  = 12 sec
<ig1> night all
<GaryvdM> http = 8.9
<GaryvdM> no changes in the tree on either
<lifeless> Peng: bzr can be faster than http; packs help with this, on knits latency sucks arse.
<Peng> What I wonder is how efficient bzr's smart server is, espcially compared to hg. Hg only uses a smart server, so it must have had a lot of tweaking. With bzr, the smart server is only starting to catch on.
<Peng> There is that hpss stuff.
<ubotu> New bug: #155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Confirmed] https://launchpad.net/bugs/155730
<GaryvdM> On http://bazaar-vcs.org/BzrDevelopment , the Release revids have not been updated for a while
<GaryvdM> How can I find out what they are for newer releases?
<AfC> GaryvdM: I was going to guess `bzr tags`, but somewhat astonishingly there aren't tags for releases in their 'bzr.dev' branch
<fullermd> Sorry, those revids are only available to Members of the Brotherhood.
<GaryvdM> Who does the releases?
<fullermd> Well, the releases don't come from bzr.dev.  They have their own branches.
<fullermd> (and bzr.dev can't have tags anyway, in its current form)
<jsk> hi all: does anyone know a good method for doing "bzr pull" over an unreliable connection?
<jsk> all: my connection only lasts a maximum of 12 minutes at a time, but the pull operation takes longer (because it's a big tree).
<jsk> all: I'm using bzr+ssh://.......
<jsk> all: I'm open to using a workaround, such as downloading the tree via HTTP, in multiple chunks.
<fullermd> Well, pull saves what it gets, in some granularity.  So as long as it takes you less'n 12 minutes to get a single "hunk" (probably the changes or a subset of the changes to one file, with knits), each pull should move forward.
<fullermd> I tend to think "kill your network admin in his sleep" is a more satisfying solution, though.
<jsk> fullermd: I'd like to do that to my ISP.
<mwhudson> i think jsk would quite like to take that approach
<jsk> :)
 * jsk has been plotting revenge for some days now
<fullermd> Oh, ISP's even easier.  You know they're all in one office   ;)
<fullermd> Take off and nuke the site from orbit.  It's the only way to be sure.
<jsk> fullermd: :)
<AfC> fullermd: (bzr.dev is not tags compatible? You guys are weird)
<fullermd> AfC: bzr.dev is still branch5.  I think some Linux distros are still shipping 0.11, so if we updated it they couldn't access it.
<AfC> Oh
<fullermd> It's probably about time that it would be "OK" to make that switch these days.
<Peng> Well, the default format has changed to dirstate-tags.
 * AfC refrains from commenting on distros that have such lame upgrade policies, although he notes down a reminder to rant about it again when giving his next conference keynote.
<fullermd> Hasn't been any big pressure to, though.  I wouldn't be too surprised if it stayed as-is until there's been a couple releases with packs, then it gets moved there.
<mwhudson> like, uh, dapper ?
<jsk> fullermd: So you suggest the following steps:
<jsk> 1. run "bzr pull --remember bzr+ssh://..."
<jsk> 2. <connection drops>
<jsk> 3. <connection returns>
<jsk> 4. do a ^C to kill the "bzr pull"
<jsk> 5. rerun "bzr pull --remember bzr+ssh://..."
<jsk> 6. repeat 2 onwards...
<jsk> where "..." represents the full path
<fullermd> Well, you'd only need the --remember once.  But yeah, that's the best I've got.
<AfC> The subsequent commands won't need --remember
<jsk> fullermd: cool. I'll give it a try. thanks :)
 * jsk resumes his plotting...
<AfC> fullermd: you know, that's not the sort of environment that I would have thought about, but I am curious how the packs modality will work in the face of partial transfers.
<fullermd> Well, with a buttload fewer round trips, there's a good chance packs will get done sufficiently quicker that you wouldn't have to many mid-flight disconnects.
<fullermd> The individual hunks to download and save would probably be bigger, so I s'pose that with a sufficiently high disconnect rate and low bandwidth, you might get stuck never making any progress with packs, where knits would inch along.  But that's pretty pathological.
<jsk> (about to be disconnected)
<fullermd> In that case, the answer is probably "keep trying to pull until the smart server gets sufficiently smart and the server upgrades"   ;)
<fullermd> 'course, with sufficiently pathological conditions, that solution probably won't work either.
<fullermd> Your hunks would just be too large to move in the bandwidth/time available.
<VSpike> Hi guys ... just about to try and migrate from Perforce to bzr, and wanted to double check I'm doing the right thing, so may run some things by you all in the next few minutes
<VSpike> At the moment, I just need to share development between two of my machines, but eventually I may need to open this up to some of the company's clients, so the "Decentralized with human gatekeeper" model will come into play
<VSpike> To start, I'm going to pull my last stable version out of perforce and check it in as a head revision, and then the latest code in my two development branches, and check those in as branches to the head revision.  I don't need to pull across all the perforce history (which is good, because I probably can't)
<VSpike> I was just trying to figure out if I should have a shared repository with trees or without
<VSpike> I guess because the desktop machine is both my fileserver and workstation, with trees makes sense... does that seem reasonable?
<GaryvdM> Yes
<fullermd> Well, on the one hand, it doesn't matter.  You can change it around trivially later.
<VSpike> fullermd: thanks, that's useful to know
<fullermd> But yah, going with trees now would be the easy thing to do (unless the trees are so big it'll cause issues), since you can blow them away and disable them by default later.
<Peng> VSpike: You might be able to convert from p4 to bzr without losing history...
<VSpike> Peng: I quite like the idea of a clean start - then I can lay out the repository in a more logical way than the rather haphazard one I have in perforce
<GaryvdM> If I have a branch object, how do get the bzrdir object?
<GaryvdM> Ah - branch.base
<mwhudson> branch.bzrdir, isn't it?
<GaryvdM> mwhudson: yes
<GaryvdM> thanks
<jsk_> fullermd: thanks for your help earlier. I think I'll have to try a different method. My connection windows are 12 minutes long, and this doesn't seem sufficient for a "bzr pull" to get to the stage where it has committed anything to disk (the contents of .bzr do not change during this time, despite the network traffic and RAM usage increasing).
<jsk_> fullermd: after a full 11 minutes, the "bzr pull" is still at Pull Phase 0/2
<fullermd> Bleh.
<fullermd> Well, that part doesn't mean too much by itself.  I think 90% of pull's time is in phase 0 (that 0-based numbering still bugs me)
<jsk_> computer scientists...
<jsk_> :)
<fullermd> Well, it's inconsistent too, I think.  The /2 means there are 2 phases, and they're called 0 and 1.  So when it's doing its last byte, it's on phase 1/2.
<jsk_> fullermd: I do have ssh access to the server hosting the branch (at the other end of my connection). Perhaps I could create a tar of the branch, and download it in chunks.
<jsk_> fullermd: however, I'm not sure if this method will create a working local branch.
<jsk_> fullermd: +1 on your suggestion to revise the numbering...
<GaryvdM> After you have download the branch, you can do bzr checkout to create a working tree.
<jsk_> GaryvdM: that sounds like a good idea. However, I'm hoping to run a "bzr pull --remember" on the local branch, to tie it up with the remote one.
<jsk_> GaryvdM: I'm hoping that this operation will complete quickly.
<jsk_> GaryvdM: and not take as long as it would with an newly "bzr init"-ed directory.
<jsk_> GaryvdM: thanks for your help :)
<Edulix> hi
<Edulix> I get this
<Edulix> edulix@edulix-laptop:~/descargas/dark-extermination$ bzr push sftp://edulix@bazaar.launchpad.net/~edulix/dark-extermination/trunk
<Edulix> Permission denied (publickey).
<Edulix> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation
<fullermd> jsk_: Well, you could rsync too (as long as you're sure your destination doesn't have stuff that needs to be not be overwritten)
<AfC|dinner> fullermd: he's pulling
<AfC|dinner> jsk_: rsync would be ideal for this situation
<AfC|dinner> [I used to use rsync to *push* until the bzr server came along]
<vila> jsk_: have you tried bzr pull http+urllib:// ? It may be longer but urllib implementation should reconnect automatically on transient errors
<matkor> In checkouted tree I can see  parent branch: /home/users/arekdydo/src/abbon/abbon2 which is wrong, how can I change it to proper value ?
<fullermd> AfC|dinner: ?  I know, but what's that matter?
<AfC|dinner> fullermd: yeah, sorry, you're right.
<vila> Edulix: check that you published your ssh key on launchpad
<matkor> unbind / bind does not set parent branch it keeps on bugus value ...
<fullermd> Parent branch is set/used by pull/merge/missing...   maybe others I forget?
<fullermd> If you don't need those to default to anything in particular though, it doesn't really matter (except cosmetically) if the given value is nutty, though.
<matkor> fullermd: Ah ! I can set it  by bzr pull --remember
<matkor> Thanks
<VSpike> I know this is a bit OT, but how tightly wedded is Visual Studio to its \Projects, \Websites layout?  I'm wondering if I can make it play nicely with a head/project1, head/project2, etc.. layout... does anyone have experience?
<sabdfl> hey guys
<vila> jsk_: you're bouncing :) Did you succeed with your push-inside-a-network-shutting-down-every-12-minutes ?
<vila> pull even
<vila> sabdfl: hi, just passing around or heard about lifeless wonders ? :)
<sabdfl> vila: i hear there are wonders in the works, what's the latest news?
<vila> Peng: can you summarize your last experiments with the pack format to sabdfl ?
<sabdfl> oh, i saw that bit :-)
<vila> sabdfl: :)
<sabdfl> very cool indeed!
<vila> yup, very encouraging
<jsk_> vila: thanks! I did succeed in the end - but only by zipping up the remote branch and downloading it in small chunks. After reconstituting the branch locally, I was able to do a "bzr pull --remember..." followed by two successive "bzr pull" operations to get the branch synced with its parent.
<jsk_> vila: (two successive operations were necessary as the first "bzr pull --remember" got cut off by the network going AWOL).
<vila> jsk_: just for completeness, I'd be interested if you an try a bzr pull http+urllib:// in a temp directory to test the transient error handling
<vila> s/an/can/
<vila> jsk_: and you should write a nice letter to your isp too :)
<jelmer> mdke: any luck with svn-import?
<Vantage> hi, quick question.  How do I configure bzr to create a branch without a working tree (or create a remote branch in a shared repo w/o making a working tree)
<Peng> Well, you could use 'bzr init-repo --no-trees'.
<james_w> Vantage: there is also 'bzr remove-tree' to do it after the fact.
<james_w> and doing a push to a remote location will not create a working tree there.
<Peng> If you already have a shared repo and want new branches to stop creating working trees, touching .bzr/repository/no-working-trees should do it.
<Vantage> Peng: thanks.  Is that in a document somewhere?  I tried hunting for it on the site, but couldn't find it
 * Peng shrugs.
<Peng> Vantage: It's in 'bzr help' if you know where to look.
<lifeless> moin
<jam-laptop> morning lifeless, is my clock right in saying it is 5 am there?
<lifeless> yes
<fullermd> He's got pack repos.  They let him sleep faster.
 * lifeless flips the bird
<lifeless> ok, its cooked now ;)
<lifeless> jam-laptop: so, what do you have on your plate?
<jam-laptop> lifeless: right now I'm just going through the review queue and trying to squash all of the Critical bugs
<jam-laptop> At least the ones with relatively simple fixes
<lifeless> yah
<lifeless> the revisionspec one would be lovely if you could do
<jam-laptop> there is a surprising amount of stuff in: http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n
<jam-laptop> Which has been approved but not merged
<lifeless> I'm back stripping commit down to do only what it needs to do
<lifeless> dirstate lookup is problematic
<jam-laptop> sounds good
<lifeless> I'm considering a basic datatype to factor out - 'sorted dict'
<jam-laptop> Any way you can completely stream rather than doing the per-file lookup?
<lifeless> well, I wrote a patch that layers on iter changes
<jam-laptop> even if it was only for the non-merge case
<jam-laptop> that would be a pretty big win
<lifeless> but it still has to probe back in because iter changes hides too much
<lifeless> the core problem is that commit diffs against an arbitrary parent, not parent 0
<jam-laptop> well, that is why I said the "non-merge" case
<lifeless> well, I say 'problem'. The reason that iter_changes is not a good fit is that ..
<jam-laptop> Certainly I'm aware of the api divergence between multiple parents and _iter_changes
<lifeless> I really don't want two code paths here
<lifeless> I just feel it would be a recipe for bugs; and this is not a code area we want bugs in.
<jam-laptop> lifeless: I'd like to have 1 code path eventually, it is just an issue of crawling before we walk
<jam-laptop> I know we've gone around a few times of _iter_changes_for_commit
<lifeless> right, a native version of that may well help
<lifeless> but OTOH I think lsprof is lying
<jam-laptop> :)
<jam-laptop> lsprof does skew results a little bit
<lifeless> the cache I added shaves 1/2 second off
<lifeless> but if lookups really were what it though, it should be more, and it gets a solid hit rate
<lifeless> s/though/*t/
<lifeless> &t dammit :)
<jam-laptop> have you measured its hit rate?
<jam-laptop> I wonder if it is less than you think
<jam-laptop> (I don't see why it really would be, but it is something to consider)
<jam-laptop> For example, if you have an average of 4 files per directory
<jam-laptop> you can only have a 4/5 hit rate
<jam-laptop> Though that is still 80%
<lifeless> I'm testing on good ole moz
<jam-laptop> IIRC moz has < 10 files per dir average
<lifeless> interesting
<jam-laptop> At least, we have 5761 directories
<jam-laptop> and 49001 files
<Lo-lan-do> Is Moz still using CVS, by the way?
<jam-laptop> (49001 + 5761) / 5761 = 9.5
<jam-laptop> Lo-lan-do: primary development on Moz is still in CVS
<Lo-lan-do> Ouch
<jam-laptop> I think one of the "advanced branches" are trying hg
<jam-laptop> Either FF 3 or Seamonkey .next
<lifeless> jam-laptop: right
<jam-laptop> something like that
<Peng> Lo-lan-do: There's an hg mirror of the main CVS repo. I think a couple smaller Mozilla projects are primarily using hg.
<lifeless> so we could set last_entry_index to 0 when the last_block_index changes
<Peng> (Tamarin.)
<jam-laptop> lifeless: but don't you "last_entry_index + 1" ?
<jam-laptop> So really you want it -1
<jam-laptop> Though the code I saw fails
<jam-laptop> if you are the first entry
<jam-laptop> or the last entry
<jam-laptop> because of IndexError
<jam-laptop> Which could actually hurt performance
<jam-laptop> because you have an exception stack
<jam-laptop> that gets created
<lifeless> it only fails on first
<lifeless> not on last
<lifeless> because I didn't plan on seeding it this way
<jam-laptop> I thought I saw
<jam-laptop> entry_index = last_index + 1
<jam-laptop> ...
<lifeless> it is
<jam-laptop> And then later it does
<jam-laptop> if (key > block[entry-1] and key <= block[entry])
<jam-laptop> which should fail on the last
<jam-laptop> well, at least when it goes past the end of the block
<lifeless> which is the first entry on the next block
<lifeless> which is a miss anyway
<jam-laptop> sure
<jam-laptop> you might consider just adding a simple counter
<jam-laptop> to see how many queries hit there
<jam-laptop> rather than going to the next
<lifeless> I did in testing it
<lifeless> it was something I felt the cost of an if() to keep it there was not worth
<jam-laptop> sure, I wouldn't leave it in for production
<jam-laptop> just to get a feeling for what the hit rate was
<jam-laptop> lifeless:  but I fully agree that lsprof is not perfect
<lifeless> I've cover the start case
<lifeless> covered
<jam-laptop> Specifically: http://dpaste.com/23102/
<lifeless> I'll send a new patch if you would like to review
<jam-laptop> just doing "bzr test-prof"
<jam-laptop> shows the "two_functions" case taking 2x as long as the one function
<jam-laptop> under lsprof
<jam-laptop> I get 38ms versus 161ms
<jam-laptop> or 4x
<jam-laptop> though the wall clock time stays about 2x
<lifeless> new patch sent
<lifeless> yes, 50K function calls with 1 param is about 15ms
<lifeless> I find timeit is very good at this ;)
<jam-laptop> http://dpaste.com/23105/
<lifeless> hang on while I swtich to a machine with a browser
<jam-laptop> first paste is a plugin
<jam-laptop> second paste is the timing
<fullermd> jam-laptop: If you're looking at critical, 114615 isn't marked critical, but I kinda think it should be...
<jam-laptop> bug 114615
<ubotu> Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615
<dato> lifeless: (you can wget -qO- dpaste.com/123/text)
<jam-laptop> yeah, I wanted to follow up with that one and see if it should be critical
<lifeless> dato: yah
<dato> lifeless: (sorry, s/text/plain/)
<lifeless> dato: but its easier to move for a bit
<dato> what fits you best :)
<jam-laptop> fullermd: does your test case do something significantly different from mine?
<jam-laptop> (I can see that mine is still reproducible in bzr.dev, though, which might be enough to go on)
<fullermd> Not sure.  Back when you posted yours, the bug was just (or at least, seemed to just) weird out commit once, then work fine.
<fullermd> My later one was where it started marking files as deleted   :(
<fullermd> I dunno if that's just that we didn't hit that particular case before, or something in the code changed since we first looked at it.
<jam-laptop> fullermd: yeah, mine doesn't break "bzr status" like yours does
<fullermd> Yah.  Nobody else would be nutso enough to setup situations like that one   :p
<vila> hi all
<fullermd> (well, 'stat' isn't broken; it's showing exactly what it thinks is happening.  I found the bug by finding a couple revs later that the file had been deleted by commit)
<jam-laptop> fullermd: true
<fullermd> In a sense, it's not really data _loss_, since you can just revert the file and get it back.  But it's pretty freakin' scary to see happen to your tree...
<lifeless> jam-laptop: so, what do you think of my updated cache ? Good to go ?
<jam-laptop> I don't see how it is going to hit the first entry on the next pass
<jam-laptop> considering that you will have
<jam-laptop> entry = -1 + 1
<jam-laptop> block[entry -1]
<lifeless> which is 0
<jam-laptop> which will be an index error
<jam-laptop> or it will give you block[-1]
<jam-laptop> which is *really* not what you want
<lifeless> if (entry > 0 and block[entry - 1])
<lifeless> more precisely, this is the line
<lifeless> +                if ((entry_index > 0 and block[entry_index - 1][0] < key) and
<lifeless> which only looks at entry_index - 1 if entry_index is 1 or more
<jam-laptop> ok, I missed the nesting
<jam-laptop> lifeless: I would prefer: present = (block[entry_index][0] == key)
<jam-laptop> Though otherwise I think I approved the previous implementation
<jam-laptop> and you only changed 1 think
<jam-laptop> thing
<lifeless> yes you did
<lifeless> so I'm asking about the delta
<jam-laptop> well if the delta is just using -1 instead of none
<lifeless> but I'll add a () around present for you
<jam-laptop> bb:approve
<lifeless> its assign last_entry_index to -1 when we assign last_block_index
<lifeless> and change that one if block line
<jam-laptop> lifeless: maybe add a comment about why you are using -1?
<jam-laptop> Just a simple
<jam-laptop> # setting to -1 since we are likely to ask for the first record next
<jam-laptop> or something along those lines
<jam-laptop> since we just had the conversation
<jam-laptop> I understand what is going on
<jam-laptop> but I realize I'll probably forget in a couple months
<lifeless>         # Reset the entry index cache to the beginning of the block.
<lifeless> ok ?
<jam-laptop> sounds good
<jam-laptop> I don't know if we want a comment where they are defined
<jam-laptop> discussing the basic use case
<lifeless> I'll do that while we're here.
<jam-laptop> (going linearly through the data)
<jam-laptop> and that this is meant to speed up searching for the *next* entry
<lifeless>         # These two attributes provide a simple cache for lookups into the
<lifeless>         # dirstate in-memory vectors. By probing respectively for the last
<lifeless>         # block, and for the next entry, we save nearly 2 bisections per path
<lifeless>         # during commit.
<jam-laptop> lifeless: good enough
<jam-laptop> go for it
<lifeless> thanks
<vila> bzr revert --no-backup
<vila> wrong window :) err right keyboard but not redirected to the right PC to be exact :)
<fullermd> Could be worse.  You could be meaning to type that _here_, and do it in the wrong window...
<lifeless> heh
<jam-laptop> vila: I thought you were just trying to cover up a post you didn't mean to make
<vila> jam-laptop: check your mail :) I was just reverting the part I talk about :)
<jam-laptop> ah
<jam-laptop> yeah, I responded to you
<jam-laptop> Would it be possible to put a check like that in permanently?
<jam-laptop> vila: ^^
<vila> host empty ? I just have to diagnose the smart smoke test part, I fixed the other cases
<vila> but I didn't touch anything else
<lifeless> we really need to fix urlparse
<vila> lifeless: agree
<lifeless> nfs+trace+http+urlib://
<vila> a simple foo://user@host is enough to make it go nuts
<vila> for any foo that is not a known scheme :)
<jam-laptop> vila: for some reason urlparse feels that most protocols are not netloc style
<jam-laptop> while *we* feel that most *are*
<jam-laptop> and it would be more reasonable to register non-netloc protocols
<jam-laptop> I suppose it would be different
<jam-laptop> if we wanted to support
<jam-laptop> file:foo
<jam-laptop> or
<jam-laptop> file:/path
<jam-laptop> rather than file:///path
<jam-laptop> we are fairly strict on what type of url we support
<vila> jam-laptop: yes
<lifeless> jam-laptop: file:foo is not valid. phone: is :)
<jam-laptop> well, I *think* that FF and IE will let you type file:foo in the URL and do something with it
<jam-laptop> at the minimum
<jam-laptop> file:/foo
<jam-laptop> should work
<jam-laptop> which *we* do not support
<lifeless> file:/foo should not work according to std66
<vila> lifeless: what is std66, that the second time I run across that reference today ?
<vila> yeah, ok, google told me :)
<jam-laptop> lifeless: try typing file:/tmp into a browser
<jam-laptop> I'm pretty sure it will work just fine
<jam-laptop> (I just tested it. and it just renamed it to file:///tmp, but still worked)
<vila> I think you both agree :)
<lifeless> jam-laptop: crackheadedheuristicsforthewin
<jam-laptop> well, browser's have a long culture of DWIM
<jam-laptop> considering page reflows
<jam-laptop> and "gracefully" handling bad html
<vila> jam-laptop: your browser is telling you in a very subliminal way: "Thou Should Fix #123363"
<jam-laptop> bug #123363
<ubotu> Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363
<vila> ubotu, you obviously miss the joke...
<lifeless> anyhow
<lifeless> brb
<lifeless> back
<jam-laptop> vila: your last commit was "hhtp" again
<jam-laptop> "Make hhtp proxy aware of ..."
<vila> LOL
<vila> time to go to sleep then :P
<jam-laptop> vila: sleep well
<jam-laptop> need me to sing a lullaby?
<lifeless> nice vila
<jam-laptop> I'm getting pretty good at them
<lifeless> gnight
<lifeless> jam-laptop: :)
<vila> thanks for the heads up, I was about to resolve conflicts in smtp_connection, better to that with a fresh mind :)
<lifeless> jam-laptop: so, do you have time perhaps, to do the revspec bug I filed ?
<lifeless> its not inside the 'make commit fast' envelope, but its really annoying ;)
<jam-laptop> lifeless: well, not tonight :) I'm working hard against bug #114615
<ubotu> Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615
<lifeless> jam-laptop: ok
<jam-laptop> but I can look at bug #154204 tomorrow
<ubotu> Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
<lifeless> bah corruption
<jam-laptop> (that is the one you are talking about, right?)
<lifeless> yes, it
<lifeless> ...
<lifeless> is
<mdke> jelmer: thanks for asking. I didn't have any more opportunity to try it; I tried it on a faster machine but it gave me ca-cert errors... weird because the machine has the same configuration as this one
<jam-laptop> This is an odd case, where because of a conflict you can get some weird tree states
<jam-laptop> Like I just renamed a file back to its original location
<jam-laptop> and I get:
<jam-laptop> ('a', 'n.OTHER', ...), ('r', 'a/n', ...), ('a', ...), ('r', 'a/n', ...)
<jam-laptop> Or if your dirstate parser is rusty
<jam-laptop> it says that the file a/n.OTHER
<jam-laptop> is renamed to 'a/n' in THIS
<jam-laptop> and absent in the base
<jam-laptop> and renamed to 'a/n' in the other parent
<jam-laptop> (aka, it doesn't exist anywhere, but still has an entry.)
<lifeless> hmm
<lifeless> so rename is failing to change the 'a' back to 'f'
<jam-laptop> well, this is the "temporary" file that the merge conflict generates
<jam-laptop> (n.OTHER)
<lifeless> yah
<lifeless> so this suggests to me a general rename bug
<jam-laptop> so what it *should* do is just recognize it as an absent row
<jam-laptop> and nuke it
<lifeless> that renaming, when it is the last reference to a path, is remove it
<lifeless> right, we're agreed.
<jam-laptop> I don't know that it is the bug under question
<jam-laptop> but it is a weird one
<fullermd> Well, in Internet Years, dirstate is approaching the age where it starts "experimenting" with recreational chemicals, so...
<jam-laptop> lifeless: are you trying to get to the point that we don't need to build inventories during commit?
<jam-laptop> (or is that quite a way off?)
<lifeless> I'm going to see about getting rid of the wt inventory during commit
<lifeless> basis inventory removal is a tad further off
<nDuff> lifeless: bzr-packs has some impressive performance characteristics.
<nDuff> lifeless: considerably faster than mercurial in some scenarios, and only slightly slower in others.
<lifeless> nDuff: Thats excellent news.
<jam-laptop> lifeless: any idea how to detect the record_entry_contents API breakage?
<jam-laptop> (You now have an extra parameter)
<lifeless> nDuff: We found a serious performance bug in extracting texts yesterday, 30% win for large binaries, may help you there too.
<jam-laptop> I'm trying to update cvsps
<jam-laptop> cvsps-import
<jam-laptop> and I would like it to work with both pre 0.92
<jam-laptop> and 0.92
<lifeless> jam-laptop: Uhm, look at bzrlib.version_info is probably best.
<lifeless> commit is going to be in flux for at least one more release though
<jam-laptop> well, I would technically like to work with bzr.dev pre and post fix, too
<lifeless> nDuff: (the fix for that is in my repository branch)
<jam-laptop> oh, and that api break isn't mentioned in NEWS
<jam-laptop> you talk about a *different* api break
<jam-laptop> (requiring the root node)
<jam-laptop> but not that the number of parameters changed
<jam-laptop> lifeless: for the large files, didn't you get that merged?
<lifeless> heh, sorry
<lifeless> jam-laptop: it is merged, nDuff is testing packs though
<jam-laptop> ah, ok
<nDuff> lifeless: http://people.ubuntu.com/~robertc/baz2.0/repository/ ?
<lifeless> yup
<lifeless> it shows up when applying long delta chains
<lifeless> basically we did 3 list clones - newlist = oldlist[:]
<lifeless> which on files with many \n's leads to thousands of object reference-dereference pairs per delta in the delta chain
<lifeless> so a file that has been altered hundreds of times does millions of unneeded object reference pairs
<mdke> jelmer: ok, so now svn-import gives me "Invalid revision id {None} in SvnRepository"
<jelmer> mdke: what version of bzr-svn? afaik that was a bug fixed in 0.4.2 or 0.4.3
<mdke> jelmer: 0.4.1-1 (gutsy)
<lifeless> nDuff: I'd be interested in knowing where we were slow, so we can fix that too.
<jelmer> mdke: .debs of newer versions are available in debian, http://packages.debian.org/sid/bzr-svn
<mdke> jelmer: should I install a later version? is your repository the most reliable one?
<mdke> ah, ok
<mdke> jelmer: no idea about the ca-cert error I had on the other computer, I guess?
<jelmer> mdke: depends on the error
<jelmer> mdke: prefixing the url with "svn+" may help
<mdke> "server certificate verification failed"
<jelmer> does "svn ls <url>" work?
<lifeless> jelmer: do you have some debugging notes?
<jelmer> lifeless: for what specifically?
<mdke> yeah, svn ls works
<lifeless> for e.g. me to point e.g. mdke at
<lifeless> currently you're really the only person able to help users.
<jelmer> there's the FAQ that is going to be part of 0.4.4
<nDuff> lifeless: let me get all my results together. there are a few places where I was less rigorous about recording them than I should have been.
<jelmer> lifeless: that, and the list of known bugs
<lifeless> nDuff: sure, not meaning to put you on the spot in any way. Knowing the envelope you're working on and where it was slow is all. If you find particular ops slow please also feel free to mail me a callgrind for that run
<nDuff> lifeless: just threw an exception checking out your branch; see http://pastebin.com/m41646d13
<lifeless> nDuff: e.g. 'bzr --lsprof-file foo.callgrind command thing thing'
<jelmer> mdke: so, prefixing the url with "svn+" should fix the error then
<lifeless> nDuff: ok, thats the bad index in that repo; known issue - I have a fixed copy, one sec.
<lifeless> nDuff: http://people.ubuntu.com/~robertc/pack-repository.knits
<lifeless> nDuff: ^ that has all the code too, and is probably the one you pulled initially.
<jelmer> lifeless: btw, any news on pqm for bzr-gtk/my pqm merge requests?
<lifeless> sorry no
<lifeless> haven't forgotten, just had no cycles
<mdke> jelmer: right. I'm going to put another one on, leave it overnight and see what happens in the morning
<jelmer> lifeless: no hurries, just making sure it doesn't drop off your todo list :-)
<lifeless> kk
<jelmer> mdke: with a newer version ?
<mdke> yes
<mdke> jelmer: incidentally, since you're here, I'll just ask - if it all goes well, do I get separate bzr branches for trunk and each svn branch? or a single bzr branch? I don't understand the explanation in bzr help svn-import about what --all and --standalone do
<jelmer> mdke: yes, you will
<mdke> great
<mdke> ok, it seems to be getting on with the first branch already, splendid
<jelmer> mdke: --all is about importing revisions that were part of historic branches that have since been removed
<jelmer> mdke: --standalone is basically about not using a shared bzr repository
<mdke> ah, perhaps I wanted that
<jelmer> --standalone will blow up the amount of disk space required
<mdke> LP doesn't support shared bzr repositories, does it?
<jelmer> it doesn't, but you can push from a shared bzr repository to launchpad without problems
<mdke> so I can do the import now without --standalone and then create separate branches by pushing them to launchpad?
<jelmer> when using a shared repository you'll also have separate branches
<jelmer> but yes
<mdke> ok. sorry if I don't understand the concepts very well
<mdke> the aim is to have LP host branches centrally that the team can access, as long as I can achieve that, I'm happy
<lifeless> mdke: so branch is a line of development
<lifeless> mdke: repository is physical storage for historical data
<lifeless> mdke: every branch has to have a repository available to store its data; either one per branch, which we call standalone branches, or one shared across many branches, which we call a shared repository
<mdke> very clear
<mdke> and I can use my shared repository to push standalone branches to Launchpad?
<mdke> or not?
<lifeless> yes, because branch and repository are orthogonal cocepts
<lifeless> *concepts*
<lifeless> a branch is a branch
<lifeless> so you can push a branch from your shared repo to launchpad, and vice verca
<mdke> so when I upload a branch from the shared repo to LP, it will take the historical data relevant to it and store it in a standalone branch?
<lifeless> yes
<mdke> great.
<mdke> so essentially the history doesn't get lost either way, whether I import it with --standalone or not
<lifeless> right
<lifeless> its just much more efficient in terms of disk storage without --standalone
<mdke> thanks, and sorry for being a bit slow, but I wanted to make absolutely sure
<mdke> ok, we'll see where it gets to overnight. possibly I'll have to leave it to work for some time :D
<mdke> thanks for all the help, both
<nDuff> interesting.
<lifeless> jam-laptop: looks like we need a tree.iter_entries_by_dir
<lifeless> that supports file id filtering
<nDuff> lifeless: why would an uncommit+recommit take considerably less CPU time than the initial commit?
<lifeless> nDuff: the recommit step ?
<lifeless> or the two combined ?. Anyhow, no matter - it shouldn't. Unless the hash cache was empty on the first commit
<nDuff> lifeless: hmm. initial commit was ~15min of CPU time; the recommit was ~2m wall-clock. wrt the cache in question -- would it be populated by a "bzr status"?
<lifeless> yes
<lifeless> 15 mins of CPU to 2 is quite remarkable
<nDuff> hrm; even when it's needing to repopulate the cache, a bzr status isn't taking nearly 13 minutes.
<lifeless> thats really quite bizarre, no pun intended. If you find yourself able to reproduce, a callgraph of it would be wonderful
<igc> morning all
<lifeless> moin
<lifeless> I replied to your graph patch review
#bzr 2007-10-23
<igc> I saw that lifeless - thanks
<igc> I'm good with your reply
<lifeless> you've seen the new bundle ?
<igc> it's come thru but I'm yet to look at it
<igc> in email at the moment
<ubotu> New bug: #156003 in bazaar ""Tree transform is malformed" error with "bzr import-dsc"" [Undecided,New] https://launchpad.net/bugs/156003
<ubotu> New bug: #156015 in bzr "Typo in doc/en/user-guide/conflicts.txt" [Undecided,New] https://launchpad.net/bugs/156015
<spiv> Turns out gutsy's kernel doesn't like my firewall box.
<lifeless> ouch
<lifeless> seen that reconcile isn't ?
<lifeless> spiv: ^
<spiv> lifeless: no, I haven't.  I assume there's mail about it?
<lifeless> there's a bug
 * lifeless -> chemist
<lifeless> ring my mobile if you want to chat
 * spiv finds the bug
<spiv> poolie: ok, I understand the problem; the bug describes the situation pretty clearly.  I'll add a test scenario for it.
<poolie> spiv, ok
<poolie> do you need to narrow it down
<poolie> what i mean is, we want a narrower test than reconciling the whole branch
<poolie> do you know what narrower test is likely to fail?
<spiv> Well, I can write a narrower test than reconciling bzr.dev, I think.
<spiv> it seems likely that creating a simple repository with about three revisions should be enough to reproduce it.
<spiv> Is that what you meant?
<poolie> it is
<poolie> it's just that i would have thought that's what the existing tests do
<poolie> in other words, do you know what's untested and causing this problem?
<spiv> It appears the "file version X is actually removed from the repo (versions with X as a parent rewritten appropriately)" case is untested.
<spiv> I'm re-reading the existing scenarios to double-check that.
<poolie> but wasn't that the main point of the previous patch?
<poolie> igc, ping?
<igc> hi poolie
<spiv> Hmm, FileParentsNotReferencedByAnyInventoryScenario would seem to cover this case.
 * spiv digs further
<poolie> spiv, could it be to do with this being a no-op file merge (random guess)
<poolie> igc, quick call?
<igc> sure - I'll call now
<poolie> j
<kgoetz> ` bzr diff`'s help says "Shows the difference in the working tree versus the last commit". when i run the command i dont get any output. i'm running the version of bzr shipped in Debian 4.0
<kgoetz> am i doing something wrong?
<poolie> kgoetz, are there in fact any changes in the working tree?
<poolie> what does bzr status show?
<kgoetz> bzr status returns nothing, and yes i can confirm theres been changes made.
<poolie> what does bzr --version show?
<kgoetz> Bazaar (bzr) 0.11.0
<poolie> and bzr diff FILE on one modified file?
<kgoetz> returns nothing
<poolie> ok, this is pretty strange
<poolie> has this happened before?
<poolie> 0.11 is pretty old, is upgrading an option at all?
<kgoetz> no, but this is the first time i've tried using bzr diff
<kgoetz> yes it is, if theres decent debs
<poolie> would these work? http://backports.org/debian/pool/main/b/bzr/
<poolie> i don't recall any bug like this, but that release is over a year old...
<kgoetz> i'll check those out.
<kgoetz> 0.18 doesnt seem much newer then what i'm on though
<lifeless> kgoetz: if status shows nothing
<lifeless> kgoetz: are the changes actually in this tree, to files that have been added and are not ignored ?
<kgoetz> lifeless: i dont understand the 2nd bit
<lifeless> kgoetz: if you have ignored a file
<lifeless> then it can change, and bzr diff will not show it
<lifeless> whats the name of a file you have changed ?
<kgoetz> lifeless: bzr info says i have 0 ignored
<poolie> how many versioned files?
<kgoetz> http://pastebin.ca/746222 heres some of the info fromb zr
<kgoetz> 25+2 subdirs
<poolie> what does bzr ls show?
<poolie> did you just create this with bzr init. bzr add, or did you get the branch from somewhere else?
<kgoetz> i branched rev 39 from home a few hours ago, bzr merged rev 40 from my mate , tried to bzr diff and it didnt
<kgoetz> just instaleld the new bzr from backports
<kgoetz> and because it asked, i upgraded the 'working tree format'
<kgoetz> bzr info now has no info in it
<kgoetz> just 'location' and 'related branches'
<kgoetz> and 'bzr diff' and 'bzr diff file' still return nothing
<kgoetz> bzr --version
<kgoetz> Bazaar (bzr) 0.18.0
<lifeless> if bzr st shows nothing
<lifeless> then I bet that your friend has not pushed their changes
<lifeless> so the merge had nothing to merge
<lifeless> if you try merge now it will probably say that, our feedback has improved since 0.11.
<kgoetz> i can see a change i didnt make:
<kgoetz> ### THIS IS BAD COUPLING - SHOULD BE RUN FROM builderrvcore (andrew) ###
<lifeless> perhaps you committed the merge already? what does 'bzr log -r -1' show ?
<kgoetz> what part of it? revo: 40; commiter: andrew
<lifeless> I think perhaps you ran 'bzr pull' not 'bzr merge'
<kgoetz> not sure. what would that mean?
<lifeless> pull gives you a mirror of another branch
<lifeless> it would mean you have what andrew has done in front of you
<lifeless> assuming you are not andrew ;)
<kgoetz> then why dont i see uncommited files in bzr status?
<lifeless> because there are no changes
<lifeless> you have a copy of andrew's branch, not your branch with his changes merged and pending review
 * kgoetz is confused. perhaps looking at the documentation can be this arvos timespender
<poolie> a good way to check this would be
<poolie> bzr missing ANDREWS_BRANCH_URL|less
<kgoetz> says 'branches are up to date'
<poolie> then it looks like you did pull from him rather than merge
<poolie> in other words - he's already done the merge and there's nothing for you to do
<poolie> so, be happy :)
<kgoetz> so i have to bzr ci before i can see his stuff?
<poolie> you can modify a file yourself to check that diff works
<poolie> no
<poolie> his stuff is in your tree now
<poolie> lifeless, could it be that in 0.11 merge did --pull by default?
<lifeless> you're already looking at his stuff. If you want to see a diff of it, you can probably do 'bzr diff -r -2'
<lifeless> poolie: no
<kgoetz> is there some way i can see what changes he made then?
<lifeless> poolie: I'm pretty sure it never did that
<poolie> i didn't think so
<kgoetz> oh, with switches
<lifeless> kgoetz: you can use bzr log to see the commit messages; bzr log -v will show the files changed in each commit, and if you find your prior commit in log (which I bet is one commit back), bzr diff -r REVNO will show you the difference from that to whats on disk.
<kgoetz> lifeless: ok, thanks.
<kgoetz> so before i start hacking again: is it ok for bzr ifno to not contain any info past thelocation+parent branch (having just updated the format after installing 0.18)
<poolie> yes, we removed some bits that were expensive to calculate
<poolie> you can get them with info -v
<kgoetz> ah sweet. not sure how committers is calculated, but i'm guessing by system name
<poolie> yes, or you can set it with bzr whoami
<kgoetz> thanks.
<lifeless> I'm going to go for a walk;
<poolie> good, enjoy
<lifeless> I need to think through this apply delta logic
<poolie> can call if you want
<lifeless> thanks, but its not one of those problems, its one of these
<spiv> I think I have a failing test for the reconcile bug.
<lifeless> you/spiv can ring me if you want to talk about anything
<poolie> yay
<poolie> spiv, tell me more?
<spiv> Reconcile doesn't seem to actually remove unwanted file versions, although in all the tests so far it correctly updates other file versions to not use them as parents.
<spiv> Perhaps it's more accurate to say that I have a failing test that appears to be related to the reconcile bug, but maybe not the same issue.
<lifeless> so I got as far as a shave before I had my answer
<lifeless> igc: so why do you object to bugfixed ?
<igc> it's not a word :-)
<lifeless> 85000 examples of it on google
<igc> try answers.com
<lifeless> what about answers.com ?
<poolie> heh
<poolie> spiv, may i call?
<igc> it's neat - dictionary definitions, synonyms, etc.
<spiv> poolie: sure
<lifeless> still not getting the point :).
<lifeless> bugfixed appears to be more than uncommon
<igc> you asked why I objected - I told you
<lifeless> if not actually common
<igc> bugfixed doesn't add anything over just saying "fixed" but whatever :-)
<igc> it's not important right now
<lifeless> ok
<igc> lifeless: commit tweaks is now approved as well. Just the spelling errors raised by Rob Weir.
<lifeless> thanks
 * igc food
<lifeless> jam-laptop: ping
<jam-laptop> lifeless: hi, typing one handed, though
<lifeless> TMI
<kgoetz> lol
<lifeless> so, in dirstates memory representation
<lifeless> are fileids utf8 ?
<jam-laptop> yes
<lifeless> and have we made fileids utf8 outside that yet ?
<jam-laptop> IIRC, in memory everything is
<jam-laptop> file ids == utf8 in the core
<lifeless> greate
<jam-laptop> same with rev ids
<jam-laptop> kgoetz: this is why http://john.arbash-meinel.com/images/baby_face_01_small.jpg
<jam-laptop> lifeless: I'm probably heading off to bed
<jam-laptop> anything else you need?
<lifeless> sleep well
<kgoetz> jam-laptop: later mate. vcute
<lifeless> jam-laptop: actually there is something
<lifeless> jam-laptop: do you recall a function to iterate the entries within a given path:fileid pair in dirstate ?
<keir> abentley, ping
<keir> lifeless, did packs land?
<lifeless> keir: its in final review at the moment
<lifeless> poolie is sheparding it through, I'm hacking on a native dirstate tweak for commit
<keir> nice
<keir> i want to write that faster index but i have been super busy :(
<poolie> ok, my plan now is to make a patch to the pack code that makes it complain when copying a delta whose base is not copied
<lifeless> keir: no worries; at worst your work on taking my design goals and coming up with something concrete to meet them has been great.
<lifeless> keir: thats very nearly as valuable as code
<spiv> poolie: FWIW, the smart server fetch does a similar sanity check.
<lifeless> spiv: why isn't the test for insert_data_stream doing that check a per-implementation test ?
<lifeless> spiv: or in other words, why are some implementations allowed to not check that ?
<poolie> lifeless, is create_pack_from_packs active even when fetching from knits?
<spiv> lifeless: hmm, good question.  Probably an oversight :/
<lifeless> poolie: no, but copying from knits copies all the data.
<lifeless> spiv: rule of thumb: all tests should be interface tests unless they cannot apply to the interface in general.
<lifeless> poolie: its pack to pack thats a problem
<mrtuple> Hello all.
<mrtuple> I would like to create a new branch (from an existing branch), but only of a subtree.  Is this possible with BZR?  What is the recommended procedure?
<mrtuple> To be clear, I have a tree under source control:  ~/a
<mrtuple> And I'd like to create a branch from a subtree of it...  bzr branch ~/a/path/to/subtree
<mrtuple> Possible?
<poolie> lifeless, are you sure?  i think i'm seeing problems when branching from an existing knits repository into a new pack repository
<poolie> i'll check
<poolie> mrtuple, can you tell us more about what you want to do with the new branch after you've made it?
<poolie> will it eventually merge back into the whole tree?
<mrtuple> ooh. that would be cool...
<lifeless> poolie: yes; pulling from knits copies everything in the knit reachable by that knits index. Remember that in your source pack repo all the data was present.
<mrtuple> Yes, i'd like to place the branch in a http:// space so that I can commit to it and  a partner can branch from and merge from it.
<poolie> i thought i had tested that...
<lifeless> ring me if you need a reminder; though I thought you were doing the review changes first ?
<mrtuple> (And I would do the same with my partners branch -- I believe this workflow has a name in bzr docs, but I forget what it is).
<mrtuple> Then, finally, I'd like to remerge with the original ~/a
<mrtuple> (Once the project is complete).
<ubotu> New bug: #156091 in bzr "create_pack_from_packs should check that knit compression parents are present" [Undecided,New] https://launchpad.net/bugs/156091
<poolie> spivvo, how's it going?
<poolie> mrtuple, there's some partial support for this at the moment, but for production use you're probably better off using the whole tree fro now
<poolie> mrtuple, if you want to try it there is an experimental 'split' command
<effbiae> hi guys
<lifeless> hi
<lifeless> poolie:
<lifeless>         All the changes in the delta should be changes synchronising the basis
<lifeless>         tree with some or all of the working tree, with a change to a directory
<lifeless>         requiring that its contents have been recursively included. That is,
<lifeless>         this is not a general purpose tree modification routine, but a helper
<lifeless>         for commit which is not required to handle situations that do not arise
<lifeless>         outside of commit.
<lifeless> thats what I'm adding to the docstring, do you think it's clear enough?
<effbiae> i have the task of maintaining a patch and i need to forward port this to newer versions of the same code.  my problem is that i want to continue developing the code on  the old base, yet somehow update my forward ports when i do this.  making any sense?
<AfC> effbiae: just keep a branch for each one. Then you can merge from old to new whenever you want.
<lifeless> effbiae: if you have the patch in a branch
<lifeless> as AfC says :)
<poolie> lifeless, that sounds clear
<spiv> poolie: I've confirmed that reconcile isn't finding anything wrong with the join-branches.txt-... knit.  I think I have a change that may fix it, I'm testing now.
<poolie> is there any point keeping the more general version around, or yagni?
<poolie> "not finding anything wrong" even though it should
<effbiae> AfC: so i won't have to go through resolving conflicts again?
<spiv> poolie: right.
<AfC> effbiae: in theory
<AfC> effbiae: so long as you get the original state into Bazaar, then when you apply your patch on 'new' branch, it'll be a series of revisions that will diverge from the common base
<spiv> poolie: if a file version is never used by any inventory, then clearly no other file version should be using it as a parent.  But join-branches.txt-... has that problem.
<lifeless> poolie: yagni I think
<AfC> effbiae: meanwhile, changes to 'old' will likewise be change to that common base. You _should_ be able to then just merge from 'old' to 'new' periodically
<spiv> Hmm, while this runs I'm going to pop out for a quick lunch.
<AfC> effbiae: it's not foolproof, but you'll find that Bazaar is incredibly robust in its merge performance. You should be alright.
<effbiae> AfC, thanks for all your help.  i'll try that.
<effbiae> AfC, do i have to bind one branch to another?
<AfC> Huh? No
<AfC> poolie: (see what I mean about the bind command?)
<AfC> effbiae: just have each of 'old' and 'new' be a full power branch in its own directory.
<effbiae> AfC: i tried that, but i continue to have to resolve conflicts each time a do a merge...
<lifeless> effbiae: if thats the case, are you changing the same region of code a lot ? It may be that basically your patch needs to be updated lots.
<AfC> effbiae: as lifeless says :)
<spiv> poolie: so here's a funny thing.
<jelmer> lifeless: How much faster than knits are packs?
<spiv> poolie: the 'bad_revid' from your bug is one of unreferenced versions in that versioned file.
<lifeless> jelmer: depends on the use case. The most dramatic difference I'veheard of is 10 minutes or so down to 30 seconds for local operations
<jelmer> lifeless: And compared to rsync/
<spiv> poolie: so in some sense it shouldn't matter what the parent in the knit for it is, because it shouldn't be used.
<lifeless> jelmer: well, we already beat rsync, again depending on the scenario
<jelmer> lifeless: For initial push?
<lifeless> jelmer: in fact though, because you could teach rsync not to touch existing index and pack files, and only sync new ones and deletes, and pack-names, rsync should still be faster (if you don't want selected data copying)
<lifeless> jelmer: A month or so ago I benched it over my adsl to london as 80% of rsync speed
<lifeless> spiv: you sure? 20050919... ? Thats referenced
<lifeless> I thought. Dagnammit.
<spiv> lifeless: hmm, reconcile thinks not anyway.
<spiv> lifeless: (Pdb) pp revision_versions.get_text_version('join-branches.txt-20050309044946-f635037a889c0388', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')
<spiv> 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c'
<spiv> lifeless: and independently looking at the inventory agrees.
<spiv> Well, if that file version is referenced, it's not referenced by the revision with the same name ;)
<lifeless> spiv: indeed, it is.
<lifeless> erm
<lifeless> I mean, indeed, that revision does not itself point at it.
<lifeless> but clearly something does or it wouldn't be getting copied
<lifeless> >>> i = r.get_inventory('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
<lifeless> >>> i['join-branches.txt-20050309044946-f635037a889c0388']
<lifeless> InventoryFile('join-branches.txt-20050309044946-f635037a889c0388', 'join-branches.txt', parent_id='doc-20050309044934-a811c79dd26eef58', sha1='b8148e34e1546e83acf1ed32f4ec4bb4cc3502ae', len=3260)
<lifeless> >>> i['join-branches.txt-20050309044946-f635037a889c0388'].revision
<lifeless> 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c'
<lifeless> file_ids_altered....
<lifeless> is a good way to trap this
<lifeless> add a if fileid == thing and version == thing: pdb()
<jelmer> lifeless: is this all for a smart server using packs or just a dumb server?
<lifeless> dumb server
<lifeless> probably worse on the smart server today, at least until spiv gets push optimised too
<lifeless> because the file_stream method uses append() to write data incrementally
<lifeless> and that will bite. painfully.
<lifeless> down to 4 errors on the native update routine
<jelmer> lifeless, ah, ok - thanks
<lifeless> pull will be ok I think
<lifeless> just push will splatter chunky bits everywhere
<spiv> lifeless: ok, I see, there are 1290 revisions in bzr.dev with inventories referencing that file version.
<effbiae> [earlier talking about merging with AfC] but if i do a merge, how can i continue developing my patch on an old branch and retain the resolution i had to provide for the new branch (i think i'm confused)
<spiv> lifeless: and none referencing the "parent" that the knit claims it has.
<lifeless> spiv: but clearly, the inventory that *should* doesn't. Grah.
<spiv> lifeless: right.
<lifeless> effbiae: perhaps we're confused. :(
<spiv> lifeless: oh well, happily I think I can make a test case out of this.
<lifeless> spiv: so we need to rewrite that inventory too
<lifeless> spiv: or the inventories that point to it incorrectly. How can we tell which is which ?
<spiv> lifeless: Will that break signed testaments?
<lifeless> spiv: I don't recall if they refer to content purely or last-changed. content only I thought
<lifeless> woot
<lifeless> all tests passing, but the code is incomplete, so clearly so are the tests.
<lifeless> however, for testing, I'm uncommenting poolies comment
<lifeless> and we'll see how long it takes on moz
<spiv> lifeless: so, can we tell which inventories are wrong?
<spiv> lifeless: hmm, in this case it's easy
<lifeless> fuck me, 4 seconds faster on initial commit
<spiv> lifeless: oh, sorry, nm
<lifeless> 5 seconds faster on regular incremental commit
<poolie> that's pretty nice
<lifeless> real    0m19.527s
<lifeless> user    0m17.473s
<lifeless> sys     0m1.388s
<lifeless> real    0m12.243s
<lifeless> user    0m10.905s
<lifeless> sys     0m0.568s
<lifeless> hmm thats hard to read
<spiv> lifeless: neat
<lifeless> the first group of three is for 'bzr commit' with 5 new files
<Lo-lan-do> That's for a commit on Mozilla?
<lifeless> the second is 'bzr commit FILENAME'
<lifeless> with filename changed
<lifeless> Lo-lan-do: yes
<Lo-lan-do> Nice
<spiv> lifeless: so, here's a fun fact
<mdke> jelmer: no luck - "out of memory: killed process"
<lifeless> without this patch:
<lifeless> real    0m25.148s
<lifeless> user    0m22.729s
<lifeless> sys     0m1.368s
<lifeless> real    0m16.834s
<lifeless> user    0m15.537s
<spiv> lifeless: all 12 file versions of that file have the same sha1
<lifeless> sys     0m0.776s
<lifeless> spiv: ok
<lifeless> mdke: run it again, as-is
<lifeless> mdke: there is a memory leak :(, it will resume
<lifeless> poolie: I might finish this tomorrow, I need to write a new iterator for dirstate
<lifeless> to handle renames with children that are not altered
<mdke> lifeless: I will, but it looks like it didn't get very far
<lifeless> mdke: well, start it, and what does the progress bar look like
<spiv> lifeless: so presumably then the inventories that reference that version are mistaken, rather than the inventory in the revision corresponding to that version.
<effbiae> excuse me...
<effbiae> given this:
<effbiae>           A---B---C topic
<effbiae>          /
<effbiae>     D---E---F---G master
<effbiae> and between E and F, files were moved around
<effbiae> i have to produce patches E->C, F->C, G->C
<effbiae> but i will be continuing development on branch 'topic' and have to continue prov
<effbiae> iding combinations of patches
<poolie> lifeless, just one question if you're still here
<poolie> when you've replied to a review, have you either done or responded to everything in it
<lifeless> poolie: rofl.
<poolie> common sense says yes
<lifeless> I don't believe I have dropped items from the reviews silently.
<lifeless> if I have elided anything, I think it was either (a) in a review from someone else, or (b) actioned and clearly trivial.
<poolie> sure
<lifeless> I'm still staggered by the performance difference
<lifeless> I expected 25% as an upper bound based on lsprof
<lifeless> to get 33% is very pleasing
<AfC> That's great work
<mdke> lifeless: looks like it has started again. Anyway, when it was killed from the scrollback it looks like it only got to about five "=" signs, still 0/9 on the first branch
<lifeless> mdke: what is the status message ?
<mdke> lifeless: no "=" signs, 0/9 on the first branch
<mdke> lifeless: i guess the best way forward is for me to ask the vcs-import guys in Launchpad to do an import for me
<lifeless> mdke: it should have english at the right hand side
<lifeless> mdke: I'd really like to know what words are there.
<mdke> lemme see
<mdke> "branches/dapper:3442 0/9"
<mdke> that's all it has, aside from the progres bar [==              ]
<lifeless> jelmer: ^ does that mean its finished the mapping ?
<lifeless> mdke: there is a big mapping it does right at the start, which I think is completed for you
<mdke> lifeless: I think you are right, it has whizzed through "Finding branches"
<mdke> and it has obviously downloaded quite a lot of material, the directory is 191MB already
<lifeless> mmm, a 64Gb flash chip
<vila> hi guys
<vila> What is the official delay between deprecation declaration and deletion from the code base ?
<mdke> lifeless: you know, it says "branches/feisty" now, perhaps it is going a bit faster than I thought :)
<lifeless> spiv: the inventories
<lifeless> spiv: is the one 20050919 a merge/different exec bit/path/name/parent id ?
<lifeless> spiv: e.g. should it have recorded a new version in the per file graph ?
 * spiv looks
 * lifeless -> counterstrike source
<lifeless> if anyone needs my input tonight, ring my house
<lifeless> otherwise, chat tomorrow.
<spiv> lifeless: thanks for your help.
<spiv> lifeless: the answer to your question is "no", btw; there's no changes to the inventory entry for that fileid in that revision compared to the two parent revisions.
<spiv> lifeless: so AFAICT it should not have recorded a new version in the per file graph.
<lifeless> right, thats teh calculation you need to perform to decide whether its good or not.
<spiv> lifeless: I see.
<spiv> lifeless: there's an alternative to rewriting inventories...
<spiv> lifeless: I could (somewhat arbitrarily) make the parents in the versioned file be [version-referenced-by-corresponding-inventory].  It's not "correct", but I think it would solve poolie's problem.
<spiv> lifeless: I only mention it because it might be more expedient to do that than fix it properly.  I'll have a go at fixing it properly now though...
<spiv> lifeless: I'm a little surprised that a change to the executable bit and nothing else apparently means there should be a new version in the knit?
<spiv> lifeless: why shouldn't the inventory entry still point to the same old file version in that case?
<spiv> lifeless: oh, it's because the per-file graph is used for merge calculations, and is punned with the knit index?
 * igc food
<indraveni> hi all
<indraveni> i have downloaded loggerhead source for front end of bazaar
<indraveni> but there are no steps for installation or configurations in it
<indraveni> could some one please help me out in configuring the loggerhead for bazaar
<lifeless> spiv: the per file graph record all changes to that fileid, not just content changes.
<lifeless> spiv: content reconstruction is separated in pack repositories, in principle.
<mwhudson> indraveni: hi, still looking for help with loggerhead?
<indraveni> mwhudson, hi yes
<indraveni> mwhudson, i have installed  bzr
<indraveni> and then downloaded loggerhead
<indraveni> but there are no instauctions of how to install or configure loggerhead
<mwhudson> indraveni: there should be a loggerhead.conf.in file in the download
<mwhudson> copy that to loggerhead.conf and edit it as appropriate
<indraveni> mwhudson, yes its tehre
<mwhudson> then run ./start-loggerhead.py -f
<indraveni> where should i copy it to ?
<mwhudson> loggerhead.conf in the same directory
<mwhudson> i'm not sure what you mean by *installing* loggerhead
<mwhudson> tbh there's no real point
<indraveni> i  have saved the loggerhead source in my dekstop
<indraveni> and there is a loggerhead.conf under the Desktop/loggerhead/loggerhead.conf
<indraveni> i should copy and paste this where?
<mwhudson> oh, if it's called loggerhead.conf already
<mwhudson> then just edit it in place
<mwhudson> it has lots of comments in
<indraveni> mwhudson, what should i edit in this line
<indraveni> folder='/Users/robey/code/loggerhead'
<mwhudson> have you read the comment in the line above this line?
<indraveni> mwhudson, there is no comment above this line
<mwhudson> you want to put in the file path of the directory that contains the branch you want to browse
<mwhudson> hm
<indraveni> mwhudson, only a line like
<indraveni> [[loggerhead]]
<mwhudson> indraveni: where did you get the loggerhead source from?
<indraveni> from http://www.lag.net/loggerhead/
<mwhudson> ah
<mwhudson> https://code.edge.launchpad.net/~mwhudson/loggerhead/production <- this version of the code is better
<indraveni> ok
<indraveni> mwhudson, i downloaded, but it placesd all the source in a folder named production
<indraveni> can i change the folder name?
<mwhudson> yes
<indraveni> mwhudson, what should i spcify for cachepath
<indraveni> ?
<mwhudson> indraveni: for now i would just comment it out
<mwhudson> indraveni: how big are the branches that you want to browse (in terms of number of revisions, number of files)?
<indraveni> it may reach atleast for 10 revisions for each branch
<mwhudson> i'm not sure i understand
<mwhudson> 10 revisions is a tiny number
<indraveni> mwhudson, the project is in starting stage
<mwhudson> ok
<mwhudson> so don't worry about caching for now
<mwhudson> it's only needed for pretty huge projects these days (10000+ revisions or 5000+ files)
<indraveni> mwhudson, but if needed, how do i need to do ?
<mwhudson> indraveni: you would put a path to some directory there
<indraveni> mwhudson, ok, what does it do then ?
<mwhudson> indraveni: it caches some information about the branch
<indraveni> mwhudson, ok
<mwhudson> most importantly the list of files changed between revisions
<indraveni> mwhudson, next, the url value, is this needed now ?
<mwhudson> (which is expensive to compute in bazaar today, at least for large branches)
<indraveni>   url = 'http://bazaar-ng.org/bzr/bzr.dev'
<mwhudson> indraveni: the file you're reading now looks like this http://codebrowse.launchpad.net/~mwhudson/loggerhead/production/annotate/pqm%40pqm.ubuntu.com-20070910193149-jrabz72cwth1abup?file_id=loggerhead.conf-20061215091925-m5t3bxgioe500tx9-1 ?
<indraveni> mwhudson, exacly
<indraveni> mwhudson, exactly
<mwhudson> indraveni: then it has comments in
<mwhudson> indraveni: i suggest you read them
<jelmer> lifeless, still awake?
<lifeless> passing by from time to time
<lifeless> whats up?
<lifeless> jelmer: ^
<jelmer> lifeless: what's the timeframe on packs landing?
<lifeless> jelmer: couple of days
<lifeless> mwhudson: btw, the list copy reduction optimisation I landed for Peng, will help inventory extraction
<mwhudson> lifeless: for packs or generically?
<mwhudson> lifeless: cool, though
<lifeless> mwhudson: but only when the two inventories are asked for separately; so doing the further optimisation I put in as FUTURE there would help a lot
<jelmer> The discussion about VCS for Samba has come up again (git's UI is confusing people) and I'd like to show some impressive graphs (-:
<lifeless> generically.
<mwhudson> lifeless: will still help the revision view, i expect
<lifeless> jelmer: did you see my commit speed stuff? 10 seconds for a specific file commit in a mozilla tree in my current uncommitted code
<mwhudson> the changelog view gets a bunch of inventories all at once with getRevisionTrees, iirc
<lifeless> mwhudson: that will not benefit as yet then
<mwhudson> well, repository.revision_trees rather
<mwhudson> lifeless: okidoke
<jelmer> lifeless: no, I haven't
<lifeless> mwhudson: turns out applying 3 list copies to thousands of items long lists is expensive.
<lifeless> when you do that hundreds of times
<lifeless> 16:56 < lifeless> real    0m25.148s
<lifeless> 16:56 < lifeless> user    0m22.729s
<lifeless> 16:56 < lifeless> sys     0m1.368s
<lifeless> 16:56 < lifeless> real    0m16.834s
<lifeless> 16:56 < lifeless> user    0m15.537s
<lifeless> 16:56 < lifeless> sys     0m0.776s
<lifeless> thats packs in my branch today
<mwhudson> lifeless: who would have thought it
<lifeless> first is commit of 5 new files
<lifeless> second is commit of one changed file when we provide the file name
<lifeless> 16:55 < lifeless> real    0m19.527s
<lifeless> 16:55 < lifeless> user    0m17.473s
<lifeless> 16:55 < lifeless> sys     0m1.388s
<lifeless> 16:55 < lifeless> real    0m12.243s
<lifeless> 16:55 < lifeless> user    0m10.905s
<lifeless> 16:55 < lifeless> sys     0m0.568s
<mwhudson> lifeless: in the firefox tree?
<lifeless> thats with a patch that is not quite complete to update the dirstate from the delta that commit calculates
<lifeless> for the same twocases
<lifeless> you can see it saves 5 seconds consistently
<lifeless> mwhudson: moz tree, yes.
<lifeless> 55K files.
<lifeless> well, 55K paths
<mwhudson> lifeless: cool
<jelmer> lifeless: Should the weave_store for packs still work as it used to earlier or should I use some other interface to add revisions to it?
<lifeless> jelmer: as long as you take out a write group, it will still work, its just slower than the commit builder interface
<mwhudson> lifeless: well, it's still a bit slow really, but at least it's competitive with the competition :-)
<lifeless> mwhudson: pffft
<mwhudson> probably the right answer is not to have branches with 55k paths in
<lifeless> mwhudson: my laptop has slow disk, and its cryted
<lifeless> mwhudson: *crypted*
<mwhudson> lifeless: i know, i'm not being very realistic
<mwhudson> lifeless: it's a bit like "how do escape from this pit full of lions" -- the preferred solution involving not getting thrown into the pit full of lions in the first place
<lifeless> mwhudson: well. I think we can get down to 4-5 seconds for sure.
<lifeless> going lower will require...some more time
<lifeless> on thing I'm starting to seriously consider is a serialised euler tour variant for the revision graph
<lifeless> stored persistently and synthesised together on access
<lifeless> but I need a really clear head
<lifeless> and about three industrial whiteboards
<mwhudson> i guess there are probably higher priorities
<mwhudson> lifeless: is tree building any faster with packs?
<lifeless> its different
<lifeless> ;)
<lifeless> its not optimised yet
<lifeless> so over sftp it will be worse
<lifeless> but on local disk it appears a little worse, but branch is overall faster, so -for now- shrug.
<mwhudson> it's pretty slow with launchpad currently
<lifeless> well 5000 files
<lifeless> convert a branch to packs.
<lifeless> then you can see
<mwhudson> hm, maybe it's not as bad as i thought
<mwhudson> 20s the second time
<lifeless> thats knit disk latency
<lifeless> echo 1 to /proc/vm/drop_caches
<lifeless> or whatever it is
<lifeless> then it will be slow again.
<lifeless> $ cat ~/bin/drop-caches
<lifeless> #!/bin/sh
<lifeless> # get written data to disk (not that its guaranteed)
<lifeless> sync
<lifeless> # (drop the unmodified pages)
<lifeless> echo 1 | sudo tee /proc/sys/vm/drop_caches
<lifeless> ---
<mwhudson> right
<lifeless> packs suffer from that less
<mwhudson> cool
<jelmer> lifeless: is it correct that packs appear to be using a significant amount of memory less than knits?
<lifeless> likely
<lifeless> but much of the tweaks should apply to knits too
<lifeless> so if you are comparing between different versions of bzr as well as disk formats, your measurements will be suspect
<lifeless> there are really three interesting data points
<lifeless> knits in last release your team tested
<lifeless> knits in the packs branch
<lifeless> packs in the packs branch
<jelmer> ok, I'll keep that in mind
<lifeless> (if you want before and after graphs I mean)
<jelmer> I may actually do some unscientific benchmarking later, comparing to git and mercurial
<jelmer> so far, it does at least feel as fast as things like mercurial or git
<Lo-lan-do> If it turns out to be so, I guess a benchmark made on the kernel tree would be an interesting thing to brag about :-)
<Lo-lan-do> By the way: is 0.92 right around the corner, or should I try and install it from bzr?
<jelmer> Lo-lan-do: for packs? You'll need bzr.dev + the packs patch posted to the list or roberts packs branch
<Lo-lan-do> Not for packs, but I'd like to check a recent bzr-svn
<jelmer> I'm not sure what the plans for 0.92 are
<indraveni> mwhudson, hi again
<indraveni> mwhudson, i have configured all accordingly
<indraveni> mwhudson, now i ran the command ./start-loggerhead.py -f
<indraveni> mwhudson, but  the output is as follows,
<indraveni> http://pastebin.ca/746697
<indraveni> mwhudson, its saying distribution not found
<indraveni> mwhudson, there?
<indraveni> any one there who can solve my error in loggerhead
<hmeland> indraveni: I've never tried loggerhead, but have you got TurboGears installed?
<Lo-lan-do> jelmer: I see you haven't closed #145148... is it just because the fix hasn't been released, or is the bug still present in current code?
<jelmer> Lo-lan-do: it's not fixed for certain corner cases yet
<Lo-lan-do> Ah, but it might be fixed in my case?
<Lo-lan-do> I'm trying to decide whether I want to install a recent bzr and bzr-svn, based on whether it'll unblock the changes I need to push to the Gforge SVN
<jelmer> Lo-lan-do: yes, that should work now
<jelmer> Lo-lan-do: there may be some issues replaying still, but recommitting your patches should fix that
<Lo-lan-do> That's great :-)
<Lo-lan-do> Aehm, so how exactly do I recommit my patches?  Should I clean the SVN cache and the properties?
<Lo-lan-do> (I get the same old error message when I just do ~/bzr.dev/bzr push)
<jelmer> Lo-lan-do: create a separate copy of the svn branch using bzr-svn (in a different repository, or a standalone branch)
<jelmer> and then manually apply + commit your changes from the original branch
<jelmer> merging them from the original branch may also work, but I'm not sure
 * Lo-lan-do tries that
<Lo-lan-do> Merging would be best, since I have derived branches too.
<Lo-lan-do> Urgh, segfault
<Lo-lan-do> During the "get"
<Lo-lan-do> ~/bzr.dev/bzr get svn+https://svn.gforge.org/svn/gforge/trunk gforge-trunk-new
<Lo-lan-do> / [                                                                          ] copying revision    1/4883Erreur de segmentation
 * Lo-lan-do cries
<jelmer> :-/
<jelmer> what versions of bzr/bzr-svn?
<jelmer> the bzr.dev and 0.4 branches?
<Lo-lan-do> Up-to-date from bzr.dev andbzr-svn
<Lo-lan-do> Right
<jelmer> does "bzr selftest svn" pass or does that segfault too?
<Lo-lan-do> I'll check
 * jelmer meanwhile also tries to clone gforge trunk
<Lo-lan-do> Erm, re-trying a get seems to progress this time.
<Lo-lan-do> It's copying revisions (40/4883 so far)
<Lo-lan-do> And the selftests seem to work, too.  Currently at 46/691
<Lo-lan-do> I'll let both run for a while, as I need to go out for a few minutes.
<jelmer> k
<Lo-lan-do> [691/691 in 989s, 3 known failures, 9 skipped] bzrlib.plugins.svn.tests.test_blackbox.TestBranch.test_log_empty
<lifeless> sleep well all
<Rotund> Can I get a little help on how to use bzr to run a webpage?
<Lo-lan-do> The same as other SCM tools?
<Rotund> So I did a checkout, but the site needs to basically do a bzr update
<Rotund> but I don't have shell access on it.  what do I do?
<Rotund> do I do a push?
<mwhudson> Rotund: what access do you have?
<Rotund> sftp
<Rotund> no ssh though
<mwhudson> rsync, perhaps?
<mwhudson> push over sftp doesn't update the working tree
<Rotund> crap
<Rotund> what DOES update the working tree?
<Lo-lan-do> update, pull
<mwhudson> running 'bzr up' on the server :/
<Rotund> is there a secure rsync?
<mwhudson> i think you can rsync over sftp
<mwhudson> never tried it myself, mind
<LeoNerd> or ssh
<LeoNerd> RSYNC_RSH=ssh rsync ...
<Rotund> okay, well I don't have a shell
<Rotund> crap.  this stinks
<Rotund> may need to write an extension
<jam-laptop> effbiae: I think I saw that your questions got a little lost. If you are still around, I can try to help.
<jam-laptop> effbiae: A pretty darn good discussion of it is here: http://www.venge.net/mtn-wiki/DaggyFixes
<jelmer> Lo-lan-do, any luck?
<Lo-lan-do> The bzr get hasn't completed yet.
<Lo-lan-do> It grabs about one revision every 2s, and there are ~4900 revs to grab.
<jelmer> ouch
<jelmer> sorry you have to go through this :-/
<Lo-lan-do> Yeah.  800 revs to go...
<Lo-lan-do> I'll definitely save a local copy of the branch before attempting to merge and push :-)
<jelmer> (-:
<Lo-lan-do> (700 left)
<Lo-lan-do> I'll play a game or two while waiting
<Lo-lan-do> jelmer: Trying to push the first revision now (which I merged from my old branch)
<Lo-lan-do> It seems to take quite some time, and strace tells me bzr is opening and closing lots of sockets to the SVN server.
<Lo-lan-do> Well, just the one, but it opens and closes it quite a lot.
<jelmer> has it committed anything yet?
<Lo-lan-do> Not as far as I can tell.
<jelmer> (in SVN)
<Lo-lan-do> Nope.  svn update in a checkout brings no new revision.
<Lo-lan-do> Other strange thing: my bzr branch is now 225 MB large, while the previous one was only 55 MB, is that known?
<Lo-lan-do> Even the SVN checkout is "only" 139 MB
<Lo-lan-do> Oh, I know.  My fault actually.
<Lo-lan-do> The previous branch was actually a lightweight checkout.
<Lo-lan-do> Still running.  I'll go for dinner, and leave bzr running for now.
<Lo-lan-do> Pushed up to revision 4884.
<Lo-lan-do> real    16m18.448s
<Lo-lan-do> Yay!
<Lo-lan-do> Although, 16 minutes to commit three properties...
 * Lo-lan-do tries to push another merged change
<Lo-lan-do> Looks like it's going to take another quarter of an hour
<Lo-lan-do> Ah, no, 8 minutes this time.
<Lo-lan-do> Less than 2 minutes for the third change
<Lo-lan-do> jelmer: It looks like I'll stop bothering you for a while :-)
<jelmer> Lo-lan-do: It worked!? Nice :-)
<Lo-lan-do> It's not over, note, and I'll need your help to sync the new branch into the old one (so I can continue using the old one, whose URL has been made public)
<Lo-lan-do> But it seems to work, step by step.
<Lo-lan-do> l=$(bzr missing --line ../gforge-trunk+bzr | tail -1) ; r=$(echo $l | cut -d: -f1) ; m=$(echo $l | cut -c29-) ; echo $r -- $m ; bzr merge -r$r ../gforge-trunk+bzr ; bzr commit -m"$m" ; time bzr push
<Lo-lan-do> One commit at a time :-)
<gdoubleu> is there a way to temporarily disable a plugin temporarily without having to remove the package from /bzrlib/plugins/ ?
<james_w> gdoubleu: bzr --no-plugins might be too much for you.
<james_w> gdoubleu: otherwise no, you have to move the directory.
<jam-laptop> gdoubleu: you can put it in a subdirectory
<jam-laptop> I use ~/.bazaar/plugins/DEACTIVATED myself
<gdoubleu> ah, --no-plugins will work for me as I don't need any other plugins at the moment either
<gdoubleu> I didn't see that option as it doesn't appear in the output of bzr help commands
<gdoubleu> thanks, now back to coding
<james_w> bzr help global-options lists it.
<james_w> lets hope that bends the space time continuum to reach him before he actually logs off.
<Lo-lan-do> You have an STC bender?
<james_w> well, it's a work in progress, I wouldn't say it bends it yet, more strokes it gently.
<Lo-lan-do> jelmer: Okay, apparently it all went smoothly.  I did a pull from SVN in the old branch, and both branches seem identical now.
<Lo-lan-do> bzr missing doesn't list any differences, nor does diff -ruN
<jelmer> cool
<jelmer> If weigon_ can also no longer reproduce the bug, I'll close it
<weigon_> jelmer: at least I don't have the problem case anymore
<jelmer> weigon_: how do you mean?
<weigon_> I can merge and commit again after I uncomitted the change
<jelmer> weigon_: As a workaround you mean?
<weigon_> yes
<weigon_> I havn't really turned it into a real testcase
<jelmer> weigon_: but can you still reproduce the bug?
<weigon_> nope
<weigon_> I'm clean now
<VSpike> Here to ask some more really silly questions, if I may.. I'm used to the model of something like perforce, where the entire structure of the remote repository is mirrored on the local machine, e.g. if something remotely is in DEPOT/ProjA/TestingBranch then that is where it is going to be relatively on your working system when you check it out...
<VSpike> With bazaar would it be possible to have a single "working" directory on your workstation and check out whichever branch you wanted to work on at the time to that location?
<VSpike> In otherwords, does it matter to bazaar where you make the branches on your local system?
<jam-laptop> VSpike: Bazaar doesn't care where you put them
<jam-laptop> I might recommend putting a shared repository (bzr init-repo --trees DEPOT)
<jam-laptop> at the root
<VSpike> jam-laptop: I'm doing that on what might be considered the main machine... shoudl I do the same on the second (the laptop) as well?
<jam-laptop> VSpike: having a shared repository means if you have 2 branches of the same code, they can share storage
<jam-laptop> so it sort of depends how you will work
<VSpike> If I do that, the locations under that repository will become important, will they not?
<Lo-lan-do> jelmer: I'm afraid you'll have to bear with me for some time still.
<jelmer> Lo-lan-do, what's going wrong?
<Lo-lan-do> SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)
<Lo-lan-do> (again)
<Lo-lan-do> I had the new and the old branch synced with SVN just fine.
<Lo-lan-do> I tried pulling from another branch called sid, which was originally based from trunk
<Lo-lan-do> Then pushing to SVN.
<Lo-lan-do> Tried that via the old gforge-trunk+bzr branch and the new gforge-trunk-new branch (both being bzr-svn branches), got twice the same result.
<jelmer> you can probably never directly pull from those branches that have the broken revision in their mainline
<jelmer> only merge them
<Lo-lan-do> Darn.
<Lo-lan-do> If I merge them and then pull into them, will I still have the problem?
<jelmer> I don't think so
<Lo-lan-do> It's worth a try.
<jelmer> the problem is that Subversion (the data in the properties) and Bazaar disagree about what the broken revision contains
<VSpike> I'm also trying to understand how to manage the relationship between a project and a library with bzr.  Both are under development by me.  Again, with something like perforce, because it takes a view of the state of the entire repository, the relationship between the project and the library is always controlled, even if you branch both of them, because the branches are just new copies under the depot's tree.  How can I control this with bzr?
<jelmer> Lo-lan-do: this is the sort of bug that is a nightmare for bzr-svn, luckily you've been the only one so far with an issue like this, and this bug is not in any releases
<VSpike> Do I need to make my repo structure contain the lib and the application side by side in each branch, and always keep them together?
<VSpike> Because I started out going with /libA/main, libA/Branch1, /AppA/main, /AppA/BranchX and so on...
<jelmer> Lo-Lan-Do: Once you've merged your branches, I'd recommend thrashing your existing branches and continuing from a fresh clone of the Subversion branch
<VSpike> but will I have to do /main/libA, /main/AppA, /somebranch/libA, /somebranch/AppA instead...
<VSpike> and always make sure I take both the lib and the app at the same time when branching?
<Lo-lan-do> I'd love to, but will I be able to do so without changing them if they're stored in a shared repo?
<Lo-lan-do> IOW: can I replace (or delete) a branch in a shared repository?
<jelmer> No, but you could start over with a clean repository that only contains the main branch imported from Subversion
<Lo-lan-do> Blargh, even merging sid into trunk and trying to push trunk to svn fails :-(
<jelmer> if there are things you can't merge, you could "replay" them using the replay command
<Lo-lan-do> bzr: ERROR: unknown command "replay"
<jelmer> Lo-lan-do, it's part of the rebase plugin
<Lo-lan-do> More recent than 0.1 then?
<jelmer> yes, 0.2
 * Lo-lan-do fetches
<Lo-lan-do> $ bzr replay -r4877 ../gforge-sid/
<Lo-lan-do> bzr: ERROR: exceptions.NameError: global name 'replay_delta_workingtree' is not defined
 * jelmer sighs
 * Lo-lan-do pulls his hair off
<Lo-lan-do> Another plugin I need to fetch? :-)
<jelmer> one sec
<james_w> VSpike: hi.
<james_w> VSpike: can I explain some things that will hopefully help you understand better the model of Bazaar? You're questions got a little lost so it is hard to address them directly.
<VSpike> james_w: I'd appreciate it, thanks
<james_w> Firstly, the branch is the most important concept in Bazaar. Everybody has a branch that they work on. You can work in lockstep so that each branch is a mirror of the others.
<james_w> or you can have branch as the term branch is used in SVN etc., to mean a separate line of development.
<VSpike> I'm just having trouble making a mental switch from the model I'm used to... doesn't help that I just flew +7 time zones
<james_w> Fundamentally Bazaar doesn't make the distinction here, so when 'branch' is used it doesn't always mean 'a separate line of development' it can just mean 'a copy of the code that allows you to make changes and commit'.
<james_w> VSpike: well, give it 7 hours until your brain catches up and all should be fine.
<VSpike> :)
<james_w> The next concept to consider is the 'repository'. There is an unfortunate naming clash here, this isn't the same as an SVN repostiory. I've never used perforce, so I can't say how it differs there.
<james_w> There have been discussion about using a different term in Bazaar, such as 'vault', 'locker' or 'archive', but other terms also have a disadvantage.
<VSpike> perforce is very similar to svn in overall concepts
<james_w> Think of a repository is just a store of revisions. There is no 'tip' revision or anything, it is just a big box where the revisions are kept. A standalone branch has a repository hidden away to keep this separation (you can see this if you do 'bzr init; ls .bzr').
<james_w> This means that a branch is just a pointer in to the 'box' that is the repository, which points at the commit that is the tip of the branch.
<james_w> This tip then points to its parents, and they point to there parents, so if you pull the string that starts at this tip revision you get the full history of the branch.
<james_w> Now, as the repository is just a 'box' you can have many branches that point to tip revisions within. The repository doesn't care if they are related in any way, or if two point to the same tip revision.
<james_w> Therefore you can create a 'shared repository', which is just a box where multiple branches can store their revisions.
<james_w> This is what you do with the 'init-repo' command.
<Lo-lan-do> jelmer: I added replay_delta_workingtree to the "from rebase import ..." clause for class cmd_replay, seems to work better
<james_w> Now when you have two branches of the same project inside a shared repository they can share some of the same revision data, and so save space compared to each having their own repository. This means you can just consider the shared repository as a storage optimisation.
<james_w> and as the repository doesn't care about the branches that use it, you can name a branch inside a repository anything you like.
<james_w> so, to hopefully address what I think was your first question, if you create a shared repository on your central server, then it doesn't matter whether you create one on your development machine or not.
<james_w> If you do also create one on your development machine then you can name the branches within differently to the server if you like.
<VSpike> OK, with you so far
<james_w> This is because the repository knows knothing about the other machine. If you want to associate a branch on your development machine with a branch on your central server then you use the URI to do so.
<james_w> This means you would use something like bzr+ssh://central/wherever/branch1
<james_w> so branches are associated using URIs, rather than by using their position relative to a repository like in SVN.
<VSpike> OK
<james_w> so if you have repo/branch1 and repo/branch2 on your server, you can have repo/branch3 and repo/branch4 on your development box, where 'bzr pull' in branch3 would pull from branch1, but 'bzr pull' in branch4 could pull from a completely different project on a completely different server.
<james_w> This can lose you some convenience, but can be more flexible.
<james_w> VSpike: happy with that? Does it answer your first set of questions?
<VSpike> Yes thanks, I get that.  It doesn't answer one of them, but I don't think that other question was possibly a red herring anyway
<VSpike> So the next big one was about relationship between two sub projects
<VSpike> btw, excellent explanations - thanks
<james_w> < VSpike> With bazaar would it be possible to have a single "working"  directory on your workstation and check out whichever branch  you wanted to work on at the time to that location?
<james_w> that one?
<VSpike> yeah, that one I think is a red herring, but I'm curious
<james_w> ok, short answer, yes it is possible.
<VSpike> I can see how it would work without using a shared repository on the workstation, but I would have thought using a shared repository would make it impossible?
<james_w> (but probably not as easy, as you don't have a known layout on the server).
<james_w> to answer this we need to consider the third bzr concept: working trees.
<james_w> A working tree is the files that you have on your machine to edit and commit from.
<james_w> Many people wouldn't distinguish this from the branch, but they are different.
<james_w> Each working tree has a pointer to a branch that it will commit to when you commit.
<james_w> Usually this is not obvious, as it is just the branch that is in the same directory as the working tree.
<james_w> However you can separate the two physically, and even put them on two different machines.
<james_w> Doing this separation gives you a 'lightweight checkout'.
<VSpike> ahhh okay
<VSpike> I see how that would work I think
<james_w> (Yes, there is a heavyweight checkout, I can explain them later if you like).
<james_w> So, you create a lightweight checkout on your local machine of the branch you want to change on your server.
<james_w> when you want to change the branch you install bzrtools and run 'bzr switch URL', where the URL is another branch on the server.
<james_w> so as I said, it's not as easy, as you have to give a full URL. We would be glad to hear a good scheme to improve this. (You can use env vars to do it now if you do it load).
<james_w> bzrtools is a set of plugins that add sometimes useful features to bzr.
<james_w> does that answer the question?
<VSpike> Yes thanks
<james_w> good.
<james_w> now for the libraries question.
<VSpike> :)
<james_w> This is a very common task, and one that we want to support.
<james_w> The idea is to do something like svn:externals if you have used those.
<james_w> We call it 'nested trees'.
<james_w> The format that will hopefully support doing this is in recent versions of bzr.
<james_w> The commands to manage this are not.
<jam-laptop> I would interject one small thing, though
<james_w> (I might have to go with 'these are not the commands you are looking for' if you look too hard).
<jam-laptop> In that "nested-by-value" does work
<jam-laptop> "nested-by-reference" (svn:externals) does not
<jam-laptop> I've done it with nested-by-value, and it actually works pretty well
<jam-laptop> but it means you have to be more careful when you want to pull any changes out of your subproject
<james_w> I've never properly grasped by-value.
<jam-laptop> james_w: It is just merging the files into the other tree
<jam-laptop> such that they maintain their history and file ids
<james_w> But Aaron is being quite insistent on this issue currently, so I didn't want to encourage it.
<jam-laptop> (bzr merge -r0..? or bzr merge-into from the plugin)
<jam-laptop> james_w: He is talking about by-reference
<jam-laptop> but yeah, that was a pretty strong discussion
<james_w> jam-laptop: I helped someone get merge-into working, did you get the patch for it?
<jam-laptop> I don't remember seeing a patch for it
<james_w> jam-laptop: ah, that distinction wasn't clear, thanks for clarifying.
<VSpike> So maybe the simplest solution for me for now is to keep the two together and treat them as a single entity in bzr?
<james_w> that would work yes. The other alternative is to keep them separate and just branch them both whenever you need them.
<jam-laptop> VSpike: well, *I* would have 2 separate branches, which I then merged together
<jam-laptop> And I would try to make changes to the sub-project in the split-out branch
<jam-laptop> and then merge them into the combined one
<VSpike> I think that will help my other other problem, which is how to make visual studio deal with it... that way, the relative path between one and the other will be unchanging
<jam-laptop> but it *is* extra work
<james_w> jam-laptop: bug #144108
<ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] https://launchpad.net/bugs/144108
<james_w> VSpike: yes, simplest solution is to make one branch, but it gives you less flexibility later.
<jam-laptop> you can always "bzr split" but your sub-project will keep tracking all the extra files from the combined project
<james_w> jam-laptop: the problem that he mentions is what I wanted to ask you about.
<james_w> unfortunately the salient details elude me.
<jam-laptop> (well, grabbing just a branch of the subproject will also copy the history files for files which *used* to be there)
<jam-laptop> james_w: you mean about 144108?
<VSpike> true, but I think - without having used it yet - that the flexible branching in bzr will still allow me to do what I want
<james_w> jam-laptop: yes, his final comment in the patch mail.
<jam-laptop> I'm seeing lots of other failures trying to run with bzr.dev
<jam-laptop> So I'm guessing some api's changed in ways I didn't expect
<jam-laptop> Like instead of getting a path at one point, I'm getting a number
<james_w> this was a while ago that we worked on it, so it might well be broken again.
<james_w> jam-laptop: is it intened to support continually merging from the original branch?
<jam-laptop> 'merge-into' ?
<jam-laptop> Yes, you should be able to continue to merge from the original
<jam-laptop> The only issue is that you need unique tree roots
<jam-laptop> or adding a file in the root of the merged project
<jam-laptop> will add it in the root of the combined project
<james_w> actually I don't know whether he was doing 'merge' or 'merge-into' on subsequent tries.
<james_w> I think that was one issue.
<james_w> The other was that you got some sort of conflict when a file was deleted from the merged project.
<james_w> I said this was a limitation at the time, but I can't remember why.
<jam-laptop> james_w: I think the problem is that you have a rename of the file, versus a deletion
<jam-laptop> so there is a conflict about paths
<jam-laptop> (you have a change, they have a change that cannot apply exactly)
<james_w> that's the badger.
<jam-laptop> but I could be wrong
<jam-laptop> I haven't tried it a lot
<jam-laptop> I need to see if I have the latest version, something is weird
<james_w> yeah, so every deletion is a conflict, because every file is always a rename compared to the other branch.
<james_w> VSpike: all sorted now?
<lifeless> moin
<VSpike> jam-laptop: can you explain what you meant when you said you'd have two separate branches which you'd then merge together, and make changes to the subproject in the split out branch?
<jam-laptop> bzr init project
<jam-laptop> bzr init library
<jam-laptop> cd project
<VSpike> jam-laptop: I read it a few times, but I can't quite get it :) brains still lagging
<james_w> hi lifeless
<jam-laptop> bzr merge-into../library library
<jam-laptop> bzr commit -m "Add library to project"
<jam-laptop> VSpike: At this point, you have a project which has merged library into it
<jam-laptop> Then when you make changes in the standalone "library" project
<VSpike> james_w: on the verge of it, i think, thanks to you both
<jam-laptop> you can then go to "project"
<jam-laptop> and
<jam-laptop> bzr merge ../library
<jam-laptop> bzr commit -m "Merge the latest changes to library"
<jam-laptop> VSpike: do you follow me so far?
<jam-laptop> (of course, this is provided that I get merge-into working again)
<james_w> VSpike: no problem, come back if you have any more issues.
<VSpike> jam-laptop: i do .. yep.. amazingly
<jam-laptop> Now, if you make changes to the library
<jam-laptop> (the copy that is in "project")
<jam-laptop> you have to "cherry-pick" them back into the separate 'library' project
<jam-laptop> cd library, bzr merge -r 10..12 ../project; bzr commit -m "Cherry pick the changes out of project for library"
<jam-laptop> The 10 should be the last revision *before* the changes, and the 12 is the last revision *of* the changes
<jam-laptop> it may be easier if I give more specific examples
<jam-laptop> which I can do
<VSpike> I think I follow you
<jam-laptop> VSpike: but if you follow me so far, it means I don't have to :)
<jam-laptop> VSpike: Anyway, Bazaar should be smart enough to merge changes to the correct files after you do this
<jam-laptop> though as james_w points out, it may tree deleted files as conflicts
<VSpike> What is the advantage of doing it that way as opposed to keeping it monolithic?
<jam-laptop> VSpike: if you want to have 4 projects which all share "library"
<jam-laptop> Or you have philosophical reasons
<james_w> (easy to rectify, but perhaps annoying if you do it often)
<jam-laptop> like wanting to version "library" independently
<VSpike> right, makes sense
<jam-laptop> One company I worked for had about 90 separate branches that built together for the project
<jam-laptop> where each plugin/module was a separate branch
<jam-laptop> but the build stage built everything togethehr
<jam-laptop> together
<VSpike> because I was wondering how easy it would be if I have two branches, each with a monolithic proj+lib combination, and I made some fixed in the in library in branch A and wanted to merge them into branch B without getting any of the changes to the main project
<jam-laptop> *I* think our eventual nested-by-reference will be the "Right Way" to do it.
<jam-laptop> VSpike: that is where having a separate library branch helps
<jam-laptop> in that you can cherry pick those changes out
<jam-laptop> and then just merge them into the other project
<jam-laptop> You actually could do that between just the monolithic projects
<VSpike> But if I had three or four branches, i'd have to do it three or four time, while with your method i basically do the cherry picking once, and then merge into the other branches, right?
<james_w> but that wouldn't necessarily satisfy my definiton of fun for some of the cases you could hit.
<james_w> VSpike: yes, that's correct.
<james_w> or just fix it in the library branch and merge in to all projects, depending on where you want to fix it first.
<VSpike> true
<VSpike> I think the fog is clearing :)
<james_w> VSpike: obviously any help to make by-reference nested trees work better would be appreciated :)
<VSpike> :)
<james_w> I'm not convinced that the time spent doing that would be less that the time you spent cherry picking etc. with jam's system.
<jam-laptop> Time spent getting by-reference working?
<james_w> yeah.
<jelmer> Lo-lan-do: thanks, now fixed upstream too
<lifeless> jam-laptop: I have native update_basis_via_delta working.
<lifeless> jam-laptop: 5 second win
<jelmer> Lo-lan-do, any luck using replay?
<jam-laptop> lifeless: nice
<jam-laptop> certainly avoiding rebuilding the full tree is nice
<Lo-lan-do> jelmer: Nope.  I ended up doing a shell loop around bzr diff and patch -p1
<jam-laptop> lifeless: I had a question about _make_absent
<jam-laptop> for bug #114615
<ubotu> Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615
<jam-laptop> The idea is that it tracks down all references to the row that is being removed
<Lo-lan-do> I'm almost done, then I'll try pushing.  If it works, then I'll trash the old branches and replace with clean new ones.
<jam-laptop> and marks the current value as absent
<jam-laptop> It has an assertion that they are not already marked as absent
<jam-laptop> But that breaks when you rename inside a directory
<jam-laptop> and then remove that directory
<jam-laptop> (so that commit unversions the whole subtree)
<jam-laptop> Because it finds one half of the rename, marks both sides absent, and then finds the other side
<jam-laptop> and tries to do it again
<lifeless> uhm
<lifeless> so this is in set_parent_trees?
<jam-laptop> unversion()
<lifeless> oh
<jam-laptop> I take it back
<jam-laptop> it finds one half of the rename
<jam-laptop> and marks just that entry as absent
<jam-laptop> then finds the other half
<jam-laptop> and tries to mark *both* sides absent
<jam-laptop> Because we don't pay attention to the working tree
<jam-laptop> but we do to all parents
<lifeless> so this is a merge
<lifeless> we have 3 trees
<lifeless> what's the kind and pointer values at the unversioned path ?
<lifeless> path being unversioned that is
<jam-laptop> (it also has a chance to accidentally remove a file which is actually moved out of that directory, but I haven't simplified that down to a simple case yet)
<jam-laptop> lifeless: doesn't have to be a merge
<jam-laptop> see my last test case
<jam-laptop> bzr init; mkdir dir; touch dir/file; bzr add; bzr commit
<jam-laptop> bzr mv dir/file dir/z; rm -rf dir; bzr commit -m "boom"
<jam-laptop> That first finds that all entries in "dir/" need to be removed
<jam-laptop> Then it finds "file"
<jam-laptop> which is shown to be renamed to "dir/z"
<jam-laptop> oh, sorry
<jam-laptop> it finds "dir/file"
<jam-laptop> and marks it as absent
<jam-laptop> then it finds "dir/z"
<jam-laptop> and sees that it is renamed from "dir/file" (because that was the path in the basis"
<jam-laptop> )
<jam-laptop> so it tries to mark dir/file absent again, and dir/z as absent
<jam-laptop> but it fails because dir/file was already marked absent
<jam-laptop> My "fix" is to just remove the assertion
<jam-laptop> There is another bug present
<jam-laptop> but that fixes the assertion error
<jam-laptop> And it passes all the other tests
<lifeless> and were considering dir/file at all because ?
<lifeless> dir/file is not present in tree 0, unversion shouldn't be touching it
<jam-laptop> lifeless: it is in the dirblock of 'dir'
<lifeless> with 'r'
<jam-laptop>                 while entry_index < len(block[1]):
<jam-laptop>                     # Mark this file id as having been removed
<lifeless> which is 'not here but renamed'
<jam-laptop>                     entry = block[1][entry_index]
<jam-laptop>                     ids_to_unversion.discard(entry[0][2])
<jam-laptop>                     if (entry[1][0][0] == 'a'
<jam-laptop>                         or not state._make_absent(entry)):
<jam-laptop>                         entry_index += 1
<jam-laptop> That is 'unversion'
<jam-laptop> You could argue for "entry[1][0][0] in ('a', 'r')"
<jam-laptop> Which I could also accept
<lifeless> I think that would be more correct
<jam-laptop> I'll see if the tests pass with that...
<lifeless> because turning an 'r' into an 'a' is a massive problem
<lifeless> what if the 'r' is outside this directory
<lifeless> we'll lose our pointer, status will start misbehaving
<lifeless> real    1m30.277s
<lifeless> user    1m22.405s
<lifeless> sys     0m4.648s
<lifeless> initial
<lifeless> real    0m25.044s
<lifeless> user    0m17.357s
<lifeless> sys     0m1.284s
<jam-laptop> lifeless: do we have a specific "target" time?
<lifeless> adding 5 files
<lifeless> real    0m11.646s
<lifeless> user    0m10.825s
<lifeless> sys     0m0.632s
<lifeless> changing one and specifying it on the command line
<jam-laptop> lifeless: also, it would be easier to read if you did "/usr/bin/time XXX" rather than "time XXX"
<jam-laptop>         0.14 real         0.00 user         0.00 sys
<lifeless> jam-laptop: I'd like to get our cpu for initial commit down to only twice tar czf
<jam-laptop> lifeless: and what time is that?
<lifeless> for incremental operations, I'd like it to be roughly the time for 'st'
<jam-laptop> sure, I'm just wondering what the actual number is
<lifeless> on my machine, tar czf is
<lifeless> hmm, not sure, but gzip of the tar is 35 seconds
<lifeless> I find the vertical layout easiest to read, it may just be me
<jam-laptop> lifeless: it is much easier to compare 2 copies
<jam-laptop> when they line up
<lifeless> right, I do that left to right
<jam-laptop> then you should paste them here that way :)
<lifeless> these three sets are not meant to be compared
<lifeless> they are different use cases
<jam-laptop> it still would be easier to read :)
<lifeless> heh
<jam-laptop> well, the fact that my IRC program uses a proportional font doesn't help
<lifeless> so fix it ? :)
<jam-laptop> except it is actually easier to read most text
<jam-laptop> (softer on the eyes)
<jam-laptop> lifeless: well if gzip of the tar is 35s, then you still have all the fs overhead, etc. 1m22s seems pretty close to your mark
<jam-laptop> Unless you are just considering user/sys time?
<lifeless> 1m22 is close
<lifeless> but not there :)
<lifeless> 1m30 wall clock time is considerably more clearly 'not there'
<lifeless> 15 failures with this patch.
<Lo-lan-do> jelmer: It's pushed!
<lifeless> LarstiQ: ping
<jelmer> Lo-lan-do: cool!
<LarstiQ> lifeless: pong
<lifeless> how are you?
<lifeless> is your life stabilised ?
<LarstiQ> lifeless: sorta kinda
<jelmer> Lo-lan-do: hope this bug is finally fixed then
<lifeless> I'd love it if you got the subtree patch out and made hot sweet love to it
<Lo-lan-do> jelmer: I hope so too
<jam-laptop> LarstiQ: good to see you around
<LarstiQ> lifeless: anything in specific (ie, I recall a dirstate problem), or the entirety?
<LarstiQ> jam-laptop: thanks
 * LarstiQ wouldn't call himself 'around' just yet, but thanks nonetheless
<lifeless> LarstiQ: there's a heated discussion on malone at the moment
<LarstiQ> lifeless: got a link to that?
<lifeless> that revolves around knit3 repositories existing, but not being something that folk hacking on bzr.dev as the majority of their hacking time want to consider 'fully supported' yet.
<jam-laptop> bug 131667
<ubotu> Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667
<jam-laptop> LarstiQ: ^
<lifeless> LarstiQ: the 'most recently touched' bug links are quite nice
<LarstiQ> lifeless: ah, heated would imply that, yes
<jam-laptop> lifeless: quick question on "unversion" does it's list include child entries?
<jam-laptop> or does it just get the top-level dir ?
<LarstiQ> lifeless: I see.
<lifeless> jam-laptop: IIRC its handed in the user supplied path
<lifeless> jam-laptop: so its expected to recurse
<jam-laptop> lifeless: unversion() takes a list/set of file_ids
<jam-laptop> it is called by the commit code
<jam-laptop> after commit determines things to auto-remove
<jam-laptop> But I can see that the code *does* recurse
<jam-laptop> so I'm starting with that
<lifeless> right, commit stops recursing at the top level path it finds missing
<LarstiQ> jelmer: poke
<jelmer> LarstiQ: porrrr
<LarstiQ> jelmer: are you attending the bapc?
<jelmer> yup, I'll be there
<LarstiQ> jelmer: ok, have time for a chat then?
<jelmer> Sure :-)
<lifeless> bapc ?
<LarstiQ> lifeless: I haven't really kept up, but I thought I saw some changes go into bzr.dev that might make subtrees slightly easier.
<james_w> hi LarstiQ
<LarstiQ> lifeless: I need to take a look at what the current combined status is before an assesement of the time involved can hope to be accurate, but I hope the major hurdles are solved.
<LarstiQ> lifeless: Benelux Algorithm Programming Contest
<LarstiQ> for some reason I got drafted into a spectator team *boggle*
<nDuff> lifeless: I can reproduce having a massive time difference between initial commit and recommit, but the circumstances where it's completely reproducible, the extra time on the recommit appears to be mostly I/O -- it shows up under "real", but not "user" or "sys" under time, as opposed to the first time where it was just about all accounted to user. I'm generating callgrind files.
<LarstiQ> james_w: heya
<nDuff> s/but the circumstances/but under the circumstances/
<lifeless> nDuff: thanks
<jam-laptop> nDuff: are you saying that the total real time doesn't change? Just that it moves out of user time?
<lifeless> nDuff: oh, hangong. Are you saying that recommit got faster ?
<lifeless> or that recommit was *slower* ?
<nDuff> jam-laptop: no; the real time changes dramatically (4min initial vs 45min recommit), but the user time changes comparatively little (~2m40s on both).
<jam-laptop> so recommit is 10x slower than initial commit
<jam-laptop> hmm...
<jam-laptop> that is after just doing
<jam-laptop> bzr uncommit
<jam-laptop> bzr commit
<jam-laptop> right?
<nDuff> yup.
<jam-laptop> Is this the first commit?
<jam-laptop> or an incremental commit
<nDuff> right now, I'm testing with the first commit. previously, it was an incremental.
<jam-laptop> so 4 versus 45 is for the first commit
<nDuff> yes.
<lifeless> nDuff: the only thing I can think of is autopack
<lifeless> if this is a shared repository, or even just a branch you are reusing extensively
<jam-laptop> lifeless: a second commit shouldn't autopack, right?
<lifeless> nDuff: have a look in ~/.bzr.log
<jam-laptop> it would be the 10th
<lifeless> jam-laptop: right, but a reused branch or a shared repo will, because its the global rev count not the branch reachable revcount
<jam-laptop> lifeless: sure
<jam-laptop> but it would be a multiple of 10
<lifeless> nDuff: look for autopack
<lifeless> jam-laptop: well not strictly no. Its whenever the desired pack count is greater than the real pack count
<lifeless> jam-laptop: the desired pack count changes for every 10 revisions; and the real increments by one every write group
<jam-laptop> ah, sure
<jam-laptop> lifeless: I was thinking that maybe it was looking up the indexes for the files
<jam-laptop> which are now non-empty
<jam-laptop> even though the existing revision is not in the current history
<jam-laptop> but autopack could also be an issue
<james_w> it's not the hashcache being dropped again is it?
<jam-laptop> james_w: I don't think that would account for 45 min
<jam-laptop> and doing
<lifeless> jam-laptop: it will look to see that the inserted revisions are really new I think still
<jam-laptop> bzr uncommit; bzr status
<jam-laptop> would restore the hash cache
<nDuff> oh, %#$^
<lifeless> and while the index layer in packs has different tradeoffs, 10x slower is totally unexpected
<jam-laptop> nDuff: ?
<nDuff> I dropped the --experimental from my "bzr init"s
<nDuff> okay, going back and starting from scratch.
<lifeless> nDuff: rofl
<lifeless> well, thank you for letting us know how long commit on knits is :)
<jam-laptop> nDuff: is that for all your tests?
<jam-laptop> (the 4 versus 45?)
<jam-laptop> Or is that just for your --lsprof ones?
<nDuff> jam-laptop: yes. consider everything I've said on the topic invalidated at this point; I'll get back after redoing them.
<nDuff> (actually, this might explain why I couldn't reproduce the 15min-of-user-time case)
<nDuff> oh. we're logging to ~/.bzr.log, eh?
<nDuff> I just thought of something.
<nDuff> my home directory is on very nonperformant network storage.
<nDuff> large amounts of logging could explain cases where I see lots of wall-clock time but not user or system time.
 * nDuff looks into redirecting that to a path on local disk.
<james_w> does BZR_HOME work for that?
<lifeless> yes
<lifeless> I think there is also a specific pathf or that
<lifeless> we shouldn't be logging all that much
<nDuff> lifeless: looking through ~/.bzr.log, I at least see a case where we're logging a line per file added.
<nDuff> lifeless: on my tree, that's significant.
<lifeless> nDuff: yes, that would be. damn, I thought we'd corrected that.
<lifeless> its basically spam.
<nDuff> lifeless: I didn't look at when it was logged; it may be from an older version of bzr.
<lifeless> nDuff: oh, btw, bzr commit -q is faster too
 * nDuff has been using -q
<lifeless> cool :)
<jam-laptop> as is 'bzr add -q' :)
<lifeless> ok, time to see if I've fixed all bugs
<lifeless> fingers crossed
<nDuff> okay, using -packs, I don't get that 4-vs-45min behavior on the initial commit.
<lifeless> whew
<jam-laptop> wow, you mean we get to set Fixed Released to all 581 bugs?
<lifeless> blah
<jam-laptop> thank you very much lifeless
<lifeless> thou knowest what I mean
<jam-laptop> sure, but a man can dream
<lifeless> I had 15 failing tests
<jam-laptop> I mean, I know you wake up early and all
<mkanat> mwhudson: The production loggerhead branch seems to have a pretty serious memory leak.
<mkanat> mwhudson: My process was 1.1GB after a few weeks of running.
<dash> hi. i've got an Interesting Situation
<dash> i have two branches and I want to merge one into the working copy of the other
<dash> but I don't want to merge the two branches together.
<dash> is this even reasonable to think about?
<mkanat> dash: That's what merge does.
<lifeless> wooooo
<lifeless> dash: merge followed by revert --forget-merges is likley what you want
<dash> lifeless: --forget-merges was indeed the thing I was looking for.
<dash> basically, i've got an Eclipse workspace for a java project... and I want to merge in some changes for deployment on another server, in order to make an archive in eclipse
<lifeless> jam-laptop: if you have time, a review of my just-mailed patch would be cool.
<dash> huh. is --forget-merges in 0.90?
<nDuff> lifeless, ~3m30s for the initial commit (and recommit) using -packs, ~20m (15m user time) for the first incremental commit.
<lifeless> dash: no its not
<lifeless> nDuff: thats rather bad isn't it. I've never seen incremental go *up*
<lifeless> (over initial)
<lifeless> assuming the incremental is a small relative change, of course.
<dash> dang. and I thought I was doing so good, running gutsy
<jam-laptop> certainly I would expect it to go up if the basic diffs are drastically different
<jam-laptop> (every file doubles in size)
<nDuff> lifeless: it's a pretty significant set of changes.
<lifeless> nDuff: what revno of the packs branch are you using ?
 * nDuff goes to gather some stats on that.
<jam-laptop> nDuff: have you done a 'make' tobuild the C extensions?
<lifeless> there was a bad list-copy on text construction
<nDuff> lifeless: r2851
<lifeless> nDuff: hmm, that has that fix
<lifeless> 2852 has some bzr.dev fixes, and the new incremental update to the working tree
<lifeless> nDuff: you have 100K files right ?
<sabdfl> evening all
<lifeless> hi sabdfl
<sabdfl> how's tricks in this part of the world?
<lifeless> good
<lifeless> just sent in a review request for a 30% saving on 'bzr commit FOO'
<sabdfl> in addition to prior numbers, or a new win?
<lifeless> sabdfl: incremental on top of the existing
<lifeless> measured with packs naturally
<nDuff> lifeless: in the initial tree, about 100,000 files. after the first update, 127000 files in 25000 directories.
<lifeless> so 15seconds to 10 seconds
<lifeless> nDuff: ok, for this I expect 2852 will help some
<lifeless> nDuff: but not at the scale you're seeing, something else is wrong there - jam-laptop's question about doing 'make' is a good one
<lifeless> 2852 is just reannotating back to knit format for you to pull
<lifeless> time for a new lsprof run with this update_basis code in place
<nDuff> jam-laptop: argh. did that on the tarball snapshot, but didn't have the C extension built for the checkout; that makes a dramatic difference on the initial incremental commit, at least if recommit times are representative.
<lifeless> nDuff: recommit is representative
<jam-laptop> that is using python to do "diff" versus "C"
<jam-laptop> which on my testing can be
<jam-laptop> 100ms
<jam-laptop> versus 5ms
<lifeless> jam-laptop: good call there :)
<sabdfl> lifeless: is there a big queue of bits to land on bzr.dev ?
<lifeless> jam was just commenting yesterday that there is
<lifeless> theres about 15 branches the authors think are finished in flight at the moment
<sabdfl> yikes. hope it can all land before 0.92, before all-hands
<jam-laptop> well, our test suite finishes a bit faster than LP's :)
<lifeless> haha
<lifeless> harsh
<sabdfl> yeah, 15 branches would be 15 hours of PQM happiness in LP
<jam-laptop> just 15?
<jam-laptop> I thought the LP suite was closer to 2 hrs
<sabdfl> we got the test suite down to 59 minutes at present
<jam-laptop> At least it felt that long when we used to be waiting behind it for bazaar merges
<jam-laptop> I'm glad to hear that you've improved it
<sabdfl> there's still plenty of room for improvement
<lifeless> nDuff: pull now
<lifeless> r2852, in the pack-repository.knits branch
<lifeless> nDuff: I'll expect this to cut about 10 seconds off your incremental commits
<nDuff> lifeless: bzr: ERROR: Cannot lock LockDir(http://people.ubuntu.com/%7Erobertc/pack-repository.knits/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<nDuff> ...doing an update
<lifeless> nDuff: oh, if you did 'checkout' just do 'bzr update' ;)
<nDuff> ...yes, that is doing 'bzr-packs update'
<lifeless> oh!
 * nDuff unbinds and does a pull
<lifeless> I swear this has regressed.
<lifeless> but poolie spent time looking at it and thought it hadn't.
<lifeless> don't suppose you could grab the backtrace from your ~/.bzr.log and file a bug with it ?
<nDuff> can do.
<lifeless> you don't need to rebuild the C extensions after pulling
<lifeless> they haven't altered
<nDuff> lifeless: new bug, or look for a previous instance to this to reopen?
<lifeless> uhm, new please
<lifeless> I'll worry about joining if it is in fact a dupe
<lifeless> ok, the callgraph is starting to look tolerable for commit
<lifeless> populate_from_inventory is now up to 70% time
<lifeless> jam-laptop: serialisation of the new inventory is now up to 12% of commit, claimeth lsprof
<lifeless> and get_inventory is 8% + 5%
<nDuff> lifeless: https://bugs.launchpad.net/bzr/+bug/156462
<ubotu> Launchpad bug 156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New]
<lifeless> thanks
<lifeless> so whats your incremental commit time now ?
<nDuff> what I'm most impressed with right now is the time to do a status with a dirty cache. don't know if it was the C extension or the update, but that's dropped *dramatically*.  haven't gotten to incremental commit yet...
<nDuff> (I'm doing the initial add and commit in one tree then moving the .bzr directory to a different tree with the updates already applied; consequently, the cache is always dirty at that point)
<jam-laptop> reading the .bzr/checkout/dirstate file has a C extension
<jam-laptop> but I wouldn't think it would effect the dirty or not...
<jam-laptop> oh, depending on the update, it might include Martin's "sha_file_by_name" fi
<jam-laptop> fix
<ubotu> New bug: #156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New] https://launchpad.net/bugs/156462
<jam-laptop> Which for a 55k tree changed it from 8s to 6s
<lifeless> lsprof I hate thee
<lifeless> brb
<lifeless> jam-laptop: so - can you review that patch ?
<jam-laptop> lifeless: currently in review
<lifeless> cool thanks
#bzr 2007-10-24
<poolie> lifeless, what has regressed
<poolie> jam-laptop, hi
<jam-laptop> hi
<jam-laptop> poolie: 'bzr update' in a checkout
<poolie> the error for trying to commit to a readonly branch?
<lifeless> poolie: no
<poolie> what jam said
<lifeless> 'bzr checkout http://people.ubuntu.com/~robertc/pack-repository.knits', wait while I push a new rev, 'bzr update' && boom
<lifeless> I know you looked at this
<poolie> iirc there is still a bug open on it
<poolie> i haven't fixed it
<lifeless> oh, ok.
<lifeless> ipso facto I was confusedo
<poolie> it may have been working at some time in the past
<poolie> but, it wasn't tested :)
<poolie> i have written some format docs on packs
<poolie> will send them shortly
<poolie> and have done the non-structural review cleanups
<poolie> i am going to see whether the structural cleanups i wanted can be done easily or not
<poolie> if not easy, they can just be turned into todos or bugs or forgotten maybe
<poolie> jam-laptop, ll may have already suggested it, but
<dash> oh. is --forget-merges not in 0.91 either? :(
<poolie> maybe you would look at making interpack fetch make sure that the text delta basis is in the destination
<nDuff> ...odd, initial incremental commit is acting like it isn't using the C extension -- massive amounts of CPU time used while collecting changes.
<poolie> dash, it'll be in 0.92
<dash> i guess I can just write my own script for now
<lifeless> revno 2000 merged support for --lightweight with http checkouts
<dash> =/
<lifeless> dash: heh, sorry :)
<lifeless> and 2019 claimed to fix it for heavyweight checkouts :(
<lifeless> ok no its right
<lifeless> there have been no commits that claim to make heavyweight checkout updates work over http
<lifeless> 2088 did that for lightweight, so I'd say it was a 'just worked' thing initially
<dash> huh. after "bzr revert" i'm not seeing a pending merge. i guess that's sufficient.
<lifeless> jam-laptop: what do you think of a dirstate iterator which _sha_from_stat advances, in commit ?
<lifeless> dash: you'll also have lost your changes ...
<dash> lifeless: which is OK
<nDuff> lifeless: 15m52s wall-clock for first incremental, 15m27s of that being user time.
<lifeless> nDuff: that really is suspect isn't it.
<lifeless> do we list the C extensions anywhere yet ?
<lifeless> nDuff: when it went faster before, how fast was it ?
<lifeless> poolie: call ?
<poolie> in 5m?
<lifeless> sure
<nDuff> lifeless: out of my scrollback buffer right now, sadly, and I didn't record it. that said, recommit (of the same thing that just took ~16min) is completing in 1m52s.
<lifeless> grah
<lifeless> the only thing that makes sense to me is the C extensions not being picked up
<lifeless> perhaps we should make that a nag
<nDuff> ...hmm. seems odd that it would happen only on initial incremental commit and not on recommit. Is there significant work done (prone to throwing an exception based on tree state) while the module is first being loaded?
 * nDuff looks at the code, and yeah -- looks like only an ImportError should result in fallback.
<nDuff> would trace.mutter() append to .bzr.log under normal conditions, or should I be doing something else to instrument?
 * nDuff looks in trace.py, and decides that warning() is more appropriate to the case anyhow.
<nDuff> 1m11s initial commit; 12.2s status w/ bad cache (and new files unknown), 7.6s status with good cache (and new files unknown), 25.4s to add unknowns, 12.1s/9.9s initial/subsequent status after adding unknowns... and now the 15min incremental commit isn't reproducing itself.
<igc> morning all
<jam-laptop> lifeless: would you use a full iterator, or just another "this was the last cached lookup" like you just added
<lifeless> nDuff: trace.mutter does to th elog
<lifeless> jam-laptop: I'm thinking a full generator. Basically lsprof is claiming 10% in _get_entry
<jam-laptop> lifeless: I would wonder if it could actually keep exactly in sync with commit
<jam-laptop> (partial commits, etc have an effect here)
<lifeless> jam-laptop: an alternative would be an equivalent of inventory.iter_entries_by_dir(specific_file_ids=XXX)
<lifeless> with yield_parents=True
<jam-laptop> iter_entries_by_dir() seems like a good route to me
<nDuff> ...hrm, cancel that; still a 15 minute commit, and none of the logging directives I put in in case of an ImportError on the C modules triggered. Time for a callgrind run, I suppose.
<nDuff> appears to get slower near the end of the change-collection process, incidentally.
<lifeless> jam-laptop: the iter_entries_by_dir will need to return the disk data; thats really the disconnect we're dealing with.
<lifeless> jam-laptop: I don't think this is a 2-day piece of code; particularly with win32 sadness.
<lifeless> jam-laptop: so I'll send a mail right now
<jam-laptop> well, the _sha_sum... do you honestly think that would be reasonable?
<jam-laptop> It just seems like it is iterating at a very different layer
<jam-laptop> and you are expecting it to stay in sync
<jam-laptop> I suppose if you pass in the path
<jam-laptop> and you know you are always "incrementing" in path
<jam-laptop> then it can fast forward until it finds what you need
<lifeless> well
<jam-laptop> But we don't have plain python generators that take more data
<lifeless> we don't need one
<jam-laptop> (until 2.5 or later)
<jam-laptop> I guess _sha_... could do the fast forwarding
<lifeless> iter_entries_by_dir on inventory returns inventory objects
<lifeless> we need one that returns the key fields and the path_content_summary details
<lifeless> hmm
<lifeless> I'll test doing a cache lookup; one second
<lifeless> jam-laptop: hmm, do I need to update the _id_index in my update_basis patch ?
<lifeless> jam-laptop: I'm just building a dict of all the stats
<lifeless> jam-laptop: won't be so hot for partial commits, but ...
<lifeless> possibly a threshold of lookups to trigger changing form
<lifeless> nDuff: commit feedback is per-dir, if you have larger dirs at the end that would explain the apparent slowdown, or it may be list accumulation overhead
<lifeless> still, its two seconds faster on incremental commits
<lifeless> initial commit down to 1m29
<lifeless> wall clock :0
<nDuff> lifeless: I've got a .callgrind file; anywhere particular you'd like it uploaded?
<lifeless> mail me or give me a url
<lifeless> they gz well
<nDuff> lifeless: in the mail.
<lifeless> thanks!
<jam-laptop> lifeless: I don't think you want to try to update _id_index, since there is too much stuff going on (some entries will be in the removed parents, etc)
<jam-laptop> lifeless: But you probably should reset it
<jam-laptop> I think self._id_index = None is fine
<lifeless> nDuff: holy fuck. is_inside_any is taking 90% time
<lifeless> nDuff: what parameters did you give commit ?
<nDuff> lifeless: bzr arguments: [u'--lsprof-file', u'../upstream-portage-tree.current.first_incremental_commit.callgrind', u'commit', u'-m', u'first incremental commit', u'--quiet']
<lifeless> nDuff: do you have many deleted paths ?
<nDuff> probably; let me check.
<lifeless> thats likely it
<lifeless> is_inside_any is not that cheap; my strategy to date has been to avoid calling it as much as possible.
<lifeless> looks like we need a smarter structure than linear searching. e.g. bithection
<lifeless> brb, food time
<lifeless> jam-laptop: another dirstate patch for your consideration :)
<nDuff> lifeless: 8045 removes, 35597 adds, 24211 modifications.
<lifeless> nDuff: that will be it
<lifeless> we could make this a list
<lifeless> deletes[bisect_left(deletes, path)].starts_with(path)
<lifeless> or a dict matching the tree structure
<lifeless> jam-laptop: ^ I think bisect is probably good enough, or possibly even best.
<lifeless> we're going to have to do 100K lookups into this
<poolie> lifeless, pack doc sent
<lifeless> another thing is we know when we're going to have to lookup again - when we add a delete, or when we change directory
<lifeless> nDuff: Anyhow, I a) know where the problem lies, b) can definately fix it.
<nDuff> nifty!
<lifeless> nDuff: its the number of deletes that you have in your tree during the commit.
<lifeless> thank you for the callgrind
<nDuff> np. thank *you* for putting up with all my fumbling around.
<nDuff> know when you might have a chance to address this one? if it'll be a while, I'd like to open a ticket so I can get notice after it's happened.
<lifeless> please open a ticket
<lifeless> it may not be a while
<lifeless> but its worth noting
<lifeless> I've put the stat cache improvements into pack-repository.knits too, revno....
<lifeless> 2853
<AfC> In my Darcs days, this sort of thing would trigger the Red Giant bug, but since it was exponential you could usually get around it be making smaller commits with less files/deletes/whatever. Would that be the case here?
<AfC> [Not that you really want to bandy that about]
<lifeless> AfC: nah, I'll just fix it
<lifeless> :)
<nDuff> lifeless: https://bugs.launchpad.net/bzr/+bug/156491
<ubotu> Launchpad bug 156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New]
<fullermd> That's no fun.  It's hard to feel like your software is working hard, if you don't have to occasionally pander to it.
<spiv> fullermd: ah, so you recommend that our tool should be so bad it causes stockholm syndrome? :)
<fullermd> Well, there are people still using arch...   _you_ connect the dots   :p
<nDuff> lifeless: btw, I'm curious, if the explanation is accessible to folks who don't know the codebase -- why is this case hit only on an initial commit, but not on a recommit or other operations which need to determine what is scheduled to be committed/deleted/etc (ie. status)?
<ubotu> New bug: #156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/156491
<poolie> spiv, hi
<spiv> poolie: good morning
<lifeless> nDuff: well, its hit on the first incremental case
<lifeless> nDuff: when both FOO and all the children of FOO are deleted, we like to report only 'FOO deleted'
<lifeless> thats a significant factor in this
<lifeless> nDuff: I'm going to review a patch then do the changes review asked for in one of my patches
<lifeless> then I'll see what I can do about this
<nDuff> graci
 * nDuff wanders off to do some clustering work.
<poolie> spiv, wow, you're right
<poolie> i thought i'd checked that this revision was referenced by its own inventory but in fact it is not
 * lifeless grins
<poolie> which is why it's good to check
<spiv> poolie: yeah.  That had me confused for while :)
<spiv> I'd assumed that if its own inventory didn't refer to it, then no others could.
<lifeless> spiv:  in theory that is right.
<lifeless> spiv: I suggest making 'bad' into a fulltext for now,
<lifeless> with inventory reassembly in the future.
<spiv> lifeless: right.  But reconcile of course is dealing with broken files...
<lifeless> this is oooold data
<spiv> lifeless: ah, that's a clever idea.
<spiv> inventory reassembly is going to be very slow without a fair bit of effort I fear :/
<lifeless> right
<lifeless> not to mention hard
<spiv> Hmm, I think I can see how to do it reasonably efficiently.
<poolie> so just making it a fulltext is not, by itself, going to totally exclude this problem
<poolie> as we talked about on the phone
<spiv> But it's not a trivial amount of work...
<spiv> poolie: why's that?
<poolie> call one of the revisions that references it "bad"
<poolie> um, "dependant" (typo)
<poolie> suppose the destination already has the revision "bad"
<poolie> it probably won't have known to pull that text version
<poolie> then, when it comes to pull "dependent" it will think it doesn't need to pull the text version
<spiv> I see.
<lifeless> poolie: but ifi t has bad already, then it has the text already.
<spiv> You're now doing checks when pulling to make sure the parent is available, though?
<lifeless> poolie: *if it has bad already*.
<spiv> So this would only happen if the repo was constructed before you added those checks?
<lifeless> IMO yes
<poolie> lifeless, are you sure it will have detected to copy this text when pulling 'bad', even though it's not apparently modified?
<poolie> i guess this is easy to test
<lifeless> I guess we're talking slightly different corner cases.
<lifeless> What I'm trying to say is 'if andrew makes the text a full text we will not encounter headaches with bzr.dev'
<poolie> well, that would be good for now
<poolie> even if it may not cover every case
<lifeless> garh bloody lawn mowers
<lifeless> jam-laptop: good call on the parent swap test; found a bug
<lifeless> jam-laptop: ping though
<lifeless> poolie: doco reviewed
<poolie> thanks!
<poolie> re your last point about the pack-names file
<lifeless> igc: can yu review 'use a dict to access stat cache' ?
<poolie> the requirement is that, every pack listed there must exist
<lifeless> igc: also, what part of commit are you hacking on at the moment, so we don't collide.
<lifeless> poolie: yes, every pack in that file must exist. Every pack that exists *may* be in that file.
<poolie> but it is possible to have a window where about-to-be-removed packs are present but not listed
<igc> lifeless: I'll review that soon
<lifeless> poolie: also during insert, we put the pack before we add to the names list.
<poolie> so, you could recreate it, but this might be reintroducing redundant copies of the file
<poolie> oh i was going to mention the file sizes too
<lifeless> poolie: but in that case its arguable that we should add them if we were to notice.
<igc> I'm currently working on bug 115601
<ubotu> Launchpad bug 115601 in bzr "no clean abort after bzr+ssh:// connection timeout. ERROR: exceptions.AssertionError: end of file reading from server." [High,Confirmed] https://launchpad.net/bugs/115601
<igc> as requested by poolie
<lifeless> igc: coolio :)
<igc> code done - just the tests to do now
<lifeless> poolie: You might also be introducing inconsistent data in a post-reconcile scenario
<lifeless> poolie: or data that is being deliberately removed.
<lifeless> poolie: so I'd really encourage the concept that 'the pack-names file is authoritative, precious, and not reconstructable'
<poolie> sure
<poolie> that's just the kind of thing i want to capture
<poolie> i guess for the iix it is graph parents first too, then compression base
<poolie> like for tix?
<lifeless> yes
<lifeless> I should have been more explicit
<poolie> np
<poolie> just brain slippage, i had seen them in the other order
 * igc food
<poolie> lunch for me too.
<spiv> Good idea.
 * spiv -> food
<indraveni> hi all
<lifeless> hi
<indraveni> i have configured the loggerhead as per my bzr branch
<indraveni> but now i am not knowing how i can view it through the browser
<indraveni> how to configure it in apache web server
<i386> http://dharmatech.onigirihouse.com/atari-forth.jpg
<poolie> lifeless, i'm not so sure that having unlock raise an error if a write group is underway is the best thing, as i said in my review
<poolie> i have another reason which is that it tends to hide errors
<poolie> to raise exceptions from things expected to be called from finally blocks
<lifeless> poolie: fair enough, I can buy that, though its good from a correctness point of view
<lifeless> perhaps a debug option or smething
<poolie> or a warning, which can be caught by -Werror
<igc> lifeless: I'll review the 'dict to access stat cache' patch now
<indraveni> i need help in setting up loggerhead
<poolie> indraveni, is there really no documentation?
<lifeless> is there documentation is loggerhead itself?
<indraveni> poolie, i couldn't find any good document
<poolie> indraveni, mwh is the new maintainer, he should be online in a bit
<indraveni> except the commented content in the conf file
<indraveni> ok
<lifeless> theres no README? or INSTALL?
<indraveni> lifeless, there is a README which says
<indraveni> that everything is similar to Tubergears
<indraveni> and i dont have experience with tubergears
<indraveni> and for apache conf some steps are given, but i am not able to udnerstnad how it works
<lifeless> well
<lifeless> AIUI turbogears can run as its own webserver or as a fastcgi script
<lifeless> you can probably find out more via google
 * nDuff is generally familiar with turbogears.
<nDuff> typically, you've got a file start-<yourproject>.py, and a config file with all your installation-specific settings
<nDuff> ...so starting the server is along the lines of running "start-<yourproject>.py foo.cfg"
<nDuff> can't say anything about loggerhead specifically, though.
<nDuff> if you're running through apache, of course, it gets more complicated (unless you're doing it the easy way and using mod_proxy).
<nDuff> lifeless: hmm, just tried pushing from my local (packs-based) tree to a "bzr serve" instance on the LAN (working against a packs-based shared repo). bzr: ERROR: Could not understand response from smart server: ('error', "<bound method GraphKnitRepository.leave_lock_in_place of GraphKnitRepository('chroot-47750944724688:///.bzr/repository/')>")
<lifeless> nDuff: oh, looks like bad marshalling.
<nDuff> full stack trace from the server at http://pastebin.com/d26bd26fa
<lifeless> please file a bug
<lifeless> it won't be hard to fix, the problem is that this is an optional method, and one that packs don't support
<lifeless> because they don't use the previous locking model.
<nDuff> lifeless: https://bugs.launchpad.net/bzr/+bug/156546
<ubotu> Launchpad bug 156546 in bzr "unable to push to packs-based smart server" [Undecided,New]
<lifeless> thanks!
<ubotu> New bug: #156546 in bzr "unable to push to packs-based smart server" [Undecided,New] https://launchpad.net/bugs/156546
<lifeless> spiv: ^
<lifeless> ok, think I have the pieces put back together again.
<lifeless> one more run then onto nDuff's performance issue
<lifeless> poolie: spiv: I think it would be nice to have some way to be sure the remote server handles optional protocols (like leave_lock_in_place) correctly
<poolie> do you mean a way to test it?
<sabdfl> morning all
<poolie> hi sab
<lifeless> hi sabdfl
<igc> hi sabdfl
<igc> lifeless: review sent to the list now
<lifeless> poolie: is it ok to merge the stat lookup via dictionary patch ?
<lifeless> poolie: thats the 5 second win on incremental commit
 * poolie looks
<poolie> i'd like to merge the pack branch with the small changes, then put the larger ones up for separate review
<poolie> ok?
<lifeless> well this is a trivial change
<lifeless> not packs per se
<igc> and I've reviewed it poolie
<lifeless> ''trivial'' conceptually, code wise its something like 20 lines
<lifeless> right, I'm asking you with your RM hat.
<poolie> it looks ok to me
<poolie> sure
<lifeless> poolie.hats().switch("RM")
<lifeless> :)
<lifeless> bbiab
<poolie> packs branch sent up
<lifeless> to pqm ?
<poolie> yes
<lifeless> awesome
<vila_> tada !
<poolie> indeed
<lifeless> sabdfl: ^^^ :)
<spiv> Woo!
 * vila_ send some champagne
<lifeless> poolie: does it have the same disk format string ?
<poolie> yes, still the same
<poolie> and still just called 'experimental'
<lifeless> ok
<poolie> is there any test framework support for checking that an assertion other than a deprecationwarning is raised?
<poolie> (obviously the format and name needs to be changed)
<sabdfl> *pop* goes the champagne :-) great work lifeless et al
<poolie> hm that kind of sucks, the python warning module does not make it very easy to catch them
<lifeless> I'll wait till friday for the champagne :)
<poolie> qantas champagne?
<lifeless> no, but we're all together friday night
<lifeless> FSVO friday :)
<lifeless> also I don't think we get champagne in economny class :(
<igc> hi hi hooray lifeless - well done
<ubotu> New bug: #156557 in bzr "Bazaar does not obey setgid on Linux" [Undecided,New] https://launchpad.net/bugs/156557
<lifeless> current figures are stable - 1m31 wall initial commit, 0m15 incremental, 0m10 partial
<EzeeGuy> hello
<lifeless> hello
<lifeless> poolie: you forgot kthxbye on your commit message :)
<poolie> heh
<poolie> i should have
<lifeless> looks like it's copacetic though, deep in the ascii tests
<poolie> huh?
<lifeless> it looks like it will land and not bounce
<poolie> http://en.wikipedia.org/wiki/Copasetic
<lifeless> yes, thats the definition
<lifeless> righto, I forgot I was going out tonnight
<lifeless> ciao
<poolie> bye
<lifeless> actually cancelled
<lifeless> too tired
<igc> reviewing the lp-login patch currently
<lifeless> woot?! has it landed?!
<indraveni> mwh, hi, are u tehre
<lifeless> you want mwhudson
<indraveni> yes lifeless
<indraveni> i need help in loggehead, yesterday he was helping me
<mdke> morning / evening lifeless
<mdke> svn-import finished successfully yesterday :)
<lifeless> mdke: excellent
<mdke> but now I just have .bzr directories, I can't see the files anywhere...
<mdke> is there another step I need to do?
<lifeless> mdke: you can get a working tree in any branch by doing 'bzr checkout .'
<lifeless> or you can make new branches from these and treat the current directly like a cvs or svn repository
<mdke> righty ho
<mdke> so bzr branch /local/url new/branch?
<lifeless> mdke: yup that will work
<lifeless> mdke: then bzr push /local/url to push back to /local/url
<lifeless> mdke: or you can do 'bzr checkout /local/url new/tree/' which will make it work like svn - when you commit /local/url gets the changes
<mdke> aha, clever
<mdke> lifeless: thanks. I will branch then push the branches to LP, once I'm done with that I'll abandon /local/url
<vila> wikipedia says: 'Copacetic may be a descendant of the Hebrew phrase "hakol beseder"', which I read 'How cool bzr' is :)
<vila> well, you have to read bzr with a french accent though, but wikipedia also says that one possible origin is creole, so I think I'm ok :)
* lifeless changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<Peng> Cool!
<sabdfl> a tour de force, lifeless. very well done indeed.
<poolie> indraveni, mwh should be awake soon
<indraveni> poolie, thankyou
<indraveni> poolie, will wait for him
<lifeless> sabdfl: thanks!. And boy do we have ideas to improve on this improvement.
<lifeless> sabdfl: though as I said a while pack, the very core disk layout is now solid IMO (the pack disk format itself).
<igc> pack on the brain eh lifeless - s/pack/back/ :-)
<lifeless> indeed
<mwhudson> indraveni: hello
<indraveni> mwhudson, hi
<indraveni> mwhudson, good morning
<indraveni> mwhudson, i have edited the loggerhead conf file accordingly but now i am struck with how to make it acess with apache
<indraveni> ?
<indraveni> i have apache installled and i have a vhost entry for my bzr repo
<Lo-lan-do> http://bazaar-vcs.org/BazaarFormats doesn't mention packs...
<AfC> Lo-lan-do: so add it
<lifeless> :)
<Lo-lan-do> I'd gladly paste from the output of bzr help formats, but even that doesn't mention them.
<lifeless> they are still considered experimental
<AfC> Lo-lan-do: so write a patch adding documentation for it.
<lifeless> we have a small amount of work to do to make them be exposed
<AfC> Lo-lan-do: in other words, chill, dude.
<mwhudson> indraveni: you need to use ProxyPass or similar
<indraveni> mwhudson, yes, i saw about it in my README file
<lifeless> well, I like the enthusiasm
<Lo-lan-do> AfC: I'm totally chilled (especially now jelmer helped me fix my bzr-svn problem), I'm just looking for info on this new shiny format that everyone seems so excited about :-)
<indraveni> but how do i need to access it through browser ?
<lifeless> Lo-lan-do: if you want to play, or add docs to the wiki, if you look at my mails to the list about dogfooding they are still valid
<mwhudson> indraveni: here's what we (will) use for testing: http://rafb.net/p/1PMHGs81.html
<lifeless> Lo-lan-do: its just that you don't need anything other than bzr.dev to experiment
<mwhudson> you need to have "127.0.0.88 codebrowse.launchpad.dev" in your /etc/hosts file
<indraveni> mwhudson, but in this where is the info about the bazaar repo ?
<mwhudson> indraveni: there isn't
<indraveni> mwhudson, then how does the apache know where os bazaar
<indraveni> mwhudson, even there is ocnf related to loggerhead location
<mwhudson> indraveni: um
<mwhudson> indraveni: loggerhead runs an http server, listening on some port or other, 8080 by default
<mwhudson> the conf file i pasted above tells apache to forward requests for codebrowse.launchpad.dev to this loggerhead process
<lifeless> Lo-lan-do: in bzr.dev
<indraveni> but where is loggerhead folder in that case in ur system
<mwhudson> indraveni: it doesn't matter!
<lifeless> there is a new doc - doc/developers/index lists it, which describes packs.
<indraveni> mwhudson, how does apache know where is loggerhead ?
<Lo-lan-do> lifeless: Thanks, I'll read up on that.
<lifeless> np
<mwhudson> indraveni: why does it need to?
<mwhudson> it's not running as a cgi script
<indraveni> mwhudson, when i give bzr.indraveni ( which is my servername in apahce file) its showing nothing
<indraveni> i am not understanding how loggerhead, apache and bazaar are related
<mwhudson> indraveni: what are you actually trying to acheive here?
<indraveni> mwhudson, when i configure my apache file with vhost like http://pastebin.ca/747691
<mwhudson> are you trying to show your branches to the wider internet, just to a few people in your team, just browse them yourself?
<indraveni> mwhudson, i am able to see the bazaar repos content in browser, using bzr.indraveni as url
<indraveni> and now , i want to use loggerhead GUI to view the bazaar repo content
<indraveni> mwhudson, i want to show to some people in team, if it works well then wider in internet
<mwhudson> indraveni: ok
<mwhudson> so if you start loggerhead and browse to localhost:8080, does it work?
<indraveni> mwhudson, oops i forgot to start loggerhead
<indraveni> mwhudson, and now statring loggerhead, is showing an error message
<indraveni> mwhudson, this is the erorr when i am starting loggerhead http://pastebin.ca/747697
<mwhudson> indraveni: you need to install turbogears
<indraveni> mwhudson, is it must ?
<mwhudson> indraveni: yes, for now
<indraveni> mwhudson, ok, from source i need to install ?
<Lo-lan-do> Hm.  Can I switch a lightweight checkout to another branch?
<mwhudson> you don't have to install it system wide, i think
<mwhudson> indraveni: what OS are you running on?
<Lo-lan-do> I did bzr bind $otherbranch, but bzr info still tells me about the old one in "repository checkout root"
<indraveni> mwhudson, debian
<mwhudson> indraveni: apt-get install turbogears should work then
<indraveni> mwhudson, there is not such file, there is only, python-turbogears
<indraveni> shall i install that /
<mwhudson> yes
<Lo-lan-do> Erm.  bzr complains it can't acquire a lock, because it's held by the very same bzr process?
<igc> night all
<poolie> nigth
<poolie> igc, thanks for the ssh bugfix
<igc> poolie: np. I thinks it's pretty low risk so I'll merge it if you like once it's reviewed
<lifeless> Lo-lan-do: on the smart server ?
<poolie> i have some tweaks
<igc> cool
<Lo-lan-do> Nope, local branches stored in a shared repo on the same disk
<Lo-lan-do> But I removed the branch and checked it out again, seems to be over.
<Lo-lan-do> Ah, no, it happens again.
<Lo-lan-do> Damn, this time it even survives an rm -rf + checkout :-(
<lifeless> Lo-lan-do: do you know about bzr break-lock ?
 * Lo-lan-do tries that
<lifeless> Lo-lan-do: also, it is possible for the same process to mutual-exclude in bzr, so its likely the specific operation you are doing
<Lo-lan-do> bzr break-lock gives me a backtrace ending in "RuntimeError: maximum recursion depth exceeded in cmp"
<lifeless> grah?!
<Lo-lan-do> And the specific operation I was attempting to perform was a "bzr pull" from another local branch
<lifeless> that definately should not mutual exclude because the source is only readlocked
<lifeless> the only way I know that thsi can be confused is if the tree you are in is a symlink/lightweight checkout of the source branch
<Lo-lan-do> http://paste.debian.net/40520
<lifeless> so its trying to lock /home/roland/debian/bzr-repo/gforge/
<Lo-lan-do> "find -name lock | xargs ls" tells me there are two files called */lock/held in the repo, in .bzr/repository/lock and debian/sid/.bzr/branch/lock
<lifeless> right
<lifeless> 'bzr break-lock /home/roland/debian/bzr-repo/gforge/'
<lifeless> should clear the locks
<Lo-lan-do> If I ^C, the lock files disappear
<lifeless> if it doesn't, please file a bug, because this is an important command (which is well tested, so I'm not seeing why ..)
<lifeless> hmm
<Lo-lan-do> break-lock doesn't do anything (since the files aren't there after a ^C)
<fullermd> Didn't we just have one of those bugs reported?
<lifeless> what is 'bzr info /home/roland/debian/bzr-repo/gforge/upstream-svn/trunk/' ?
<Lo-lan-do> http://paste.debian.net/40521
<fullermd> It's a lightweight co of a branch in the .../bzr-repo/gforge/ repo, ans the branch trying to be pulled from is also in that repo?
<indraveni> mwhudson, now i getting this error while running loggerhead after installing turbogers
<indraveni> mwhudson, http://pastebin.ca/747721
<Lo-lan-do> fullermd: Yes
<indraveni> mwhudson, I dont know anything about pythob
<sabdfl> lifeless: hi, have some initial pack feedback for you!
<lifeless> cool
<indraveni> mwhudson, are u there ?
<mwhudson> indraveni: one moment
<indraveni> ok
<Lo-lan-do> Hmm.  If I try to merge/commit instead of pulling, I get another error: http://paste.debian.net/40522
<mwhudson> indraveni: apt-get python-sqlite should fix that i think
<mwhudson> indraveni: but it's a bit bad of me, you don't need sqlite bindings unless you're using the caches
<mwhudson> so it should work without them installed
 * mwhudson files a bug
<fullermd> Oh ho.  Circular binding.
<fullermd> That could be the source of the initial trouble...
<Lo-lan-do> Strangely, other branches stored in the same repo and whose parent is also upstream-svn/trunk do behave properly.
<fullermd> Yes, but the problem is in that debian/sid branch.
<Lo-lan-do> But whatever.  How can I fix that?
<fullermd> Go into it and 'bzr unbind'
<fullermd> Then pull and all should get back to working normally.
<Lo-lan-do> Yay, it works :-)
<Lo-lan-do> Now how do I prevent that from happening again?
<fullermd> Don't make branches that are checkouts of themselves   ;)
<Lo-lan-do> Erm, I generated that checkout with "bzr checkout --lightweight /home/roland/debian/bzr-repo/gforge/debian/sid/ gforge-sid"
<fullermd> Nono, the problem wasn't the gforge-sid checkout.  It was the debian/sid branch, which considered itself a [heavyweight] checkout of the debian/sid branch.
<Lo-lan-do> I see.
<Lo-lan-do> Maybe I caused that when I was trying to switch a lightweight checkout from one branch to another.
<Lo-lan-do> I did play a bit with bind and unbind at that time.
<Lo-lan-do> (And didn't find a working process...)
<fullermd> Well, it's all path based.  So if you made a heavy checkout of debian/sid somewhere, then just mv'd it over to debian/sid...
<fullermd> But you could have pulled it off manually with bind too; probably the more likely case.
<Lo-lan-do> Probably.
<Lo-lan-do> Is there a proper way to switch a lightweight checkout across branches then?
<lifeless> bzr switch
<mwhudson> Lo-lan-do: bzrtools defines a 'switch' command
<Lo-lan-do> Ah, I need to install bzrtools again then.
<Lo-lan-do> Apparently a bzr.dev installed in ~ doesn't use the plugins installed system-wide :-/
<fullermd> lifeless: How could I easily tell whether bzr was sucking in celementtree?
<lifeless> fullermd: do you mean finding it ?
<lifeless> fullermd: I think it goes in bzr.log
<fullermd> Mmm.  Doesn't seem to...
<bialix> packs have landed! w00t! I don't believe to my eyes
<bialix> will try on win32 tonight!
<bialix> lifeless: congrat!
<lifeless> thanks bialix
<bialix> :-)
<indraveni> mwhudson, in loggerhead.conf, do we need to mention the branch path or the main central repo path ?
<mwhudson> branch path
<indraveni> mwhudson, now i am getting a message like, port not free
<indraveni> when i am starting loggerhead
<indraveni> where as i have only apache running in 8080 and no other
<indraveni> which port dows loggerhead use ?
<mwhudson> 8080 by default
<indraveni> mwhudson, i have apache running in that port
<indraveni> http://pastebin.ca/747741
<indraveni> mwhudson, http://pastebin.ca/747741
<mwhudson> well, change the port loggerhead runs on then
<mwhudson> it can be done in the config file
<indraveni> mwhudson, got it
<indraveni> mwhudson, but the content is not propely displayed in the web browser
<indraveni> mwhudson, i have some more content in the my_project folder which are created using bzr add, and commited, but those are not visible in this
<mwhudson> indraveni: well, i'm not sure how i can help you with that
<indraveni> mwhudson, ok i will try to reosolve this
<indraveni> mwhudson, i think my branch and conf file need some thing to be done
<mwhudson> if you have specific questions i can answer them, but i don't know what your directory layout is like
<mDuff> lifeless: as a general rule, should I be assigning packs-related bugs I file to you?
<lifeless> nDuff: no, but please tag them packs
<lifeless> the ones I work on I'll assign to me, but its not a one-person effort, so assigning to me would be a net negative
<mDuff> thank you -- I was previously unaware launchpad's tagging support.
<lifeless> np
<mDuff> Is there an existing syntax for having a single string specify both a repository URL and a revnum or revid?
<fullermd> To what?
<sandrot> so...what's the best way to distribute in a distributed model? =)
<mDuff> fullermd: I'm looking to fully qualify the path to a specific revision of a piece of code -- both where to contact the server, and what to ask it for. I could just pass the URL and the revision specifier space-separated, but I'm wondering if there's another preexisting, recognized method.
<fullermd> sandrot: Broadly.
<sandrot> heh
<fullermd> mDuff: For bzr?  No.  I'm sure there are URL templates for loggerhead or bzr-webserve...
<sandrot> I'm working with a small team used to svn, in general I think a central server works pretty well for pushing and pulling updates, is that recommended?
<fullermd> Well.  I would say that what's "recommended" is what works best for your situation.  You have a range from everybody working lockstep on a single branch, out to everybody working in individual branches merging full-mesh, and a lot of spots in between.
<lifeless> mDuff: we have planned one but not implemented iot
<lifeless> mDuff: url;revno=xxxx
<lifeless> and url;revid=xxxx
<sandrot> hmm
<lifeless> sandrot: you can work just like you do in svn
<lifeless> sandrot: and experiment as you grow familiar with the available tools and processes that bzr offers
<fullermd> sandrot: Usually, the 'best' answer for a given case is somewhere in the middle.
<sandrot> over http?
<lifeless> bzr+http is a little tricksy; but you can pull and update over http
<lifeless> bzr+ssh or sftp will work just fine
<sandrot> yeah, I'd like the make the transition for my designer as easy as possible
<lifeless> mDuff: I expect a fix for your deletes-during-commit bug tomorrow
<fullermd> lifeless: Incidentally, did I read that bzr+ssh is going to be suffering relative to sftp for packs?
<sandrot> currently I just bzr init locally and push it to my server...then branch and pull on my laptop
<lifeless> fullermd: yes, right now it doesn't work :)
<lifeless> night all
<mDuff> lifeless: graci.
<mDuff> ...and g'night.
<fullermd> Ah.  Minor details...
<sandrot> will bzr+ssh always prompt for password unless public key is on the server?
<LeoNerd> It'll just do the same SSH login as any other ssh into the machine
<sandrot> thanks
<LeoNerd> (Given as.. er.. it is ssh.. and doesn't have any choice but to...)
<sandrot> in the centralized workflow doc it states that commits happen both locally and remotely. how does bzr know that the working tree is in a centralized environment? is it because of the shared repo?
<mDuff> sandrot: if you use "bzr checkout" instead of "bzr pull", that creates a bound branch, which has the behavior in question.
<fullermd> No, because you're working in a dir created by 'checkout' rather than 'branch' (not _quite_ precisely right, but close enough)
<sandrot> huh...
<LeoNerd> 'checkout' == 'branch' + 'bind'
<sandrot> neato!
<LeoNerd> A 'bound' branch is simply one that atomically pushes every commit upstream, when committed locally
 * fullermd drives an extra stake through the heart of 'bind', just to be sure.
<sandrot> I've been using branch all along (Which is good for being able to commit whenever I want) and then pushing...
<sandrot> but you're saying I could have substituted branch with checkout and been bound
<LeoNerd> Ya.. or just 'bzr bind' it now
<LeoNerd> Same effect
<sandrot> you can unbind as well right
<sandrot> so you could checkout, unbind for a bit, bind again
<LeoNerd> Indeed
<LeoNerd> You can also  'bzr commit --local ...' if you want to do a one-off local commit to a bound branch
<LeoNerd> Then push it later.
<LeoNerd> (e.g. useful for sometimes-offline laptops)
<sandrot> interesting
<sandrot> and if you're working with a simple bzr init (no shared repo), then every checkout has a full history of the commits?
<sandrot> sorry, every branch
<fullermd> Well, every branch has the full history whether you're using a shared repo or not.
<fullermd> It's just that if they're in a shared repo, they...   well, share it, instead of individually storing the same info.
<sandrot> so if branch1 and branch2 have similar info they share it in shared repo?
<fullermd> Right.  Saves space (and I/O copying stuff around).
<sandrot> Hmm, I currently don't have a layout...just trunk which I host on my server...but I could bzr init a project with a trunk/ branches/ tags/ layout which then would be appropriate for using a shared repo?
<LeoNerd> Er...
<LeoNerd> That's more of a SVN way of thinking..
<LeoNerd> A 'tag' in bzr is just a friendly name for a revision.. it's not a separate filesystem entity
<sandrot> hmm, thought that's how svn used them =)
<LeoNerd> No
<LeoNerd> In SVN everything is just a cheap referential copy
<LeoNerd> Branches, tags, renames... don't exist
<LeoNerd> They're just copies
<fullermd> Let's not discuss how svn uses them.  I'm planning to eat soon...
<sandrot> lol
<LeoNerd> In bzr, a tag is just a friendly human name for a revision
<LeoNerd> The same way that a hostname is just a friendly human name for an IP address
<sandrot> everything is a branch =)
<LeoNerd> A revision is just a point on a branch.
<sandrot> ya
<LeoNerd> A branch is just an ordered list of revisions
<sandrot> so can I migrate a current branch into a shared repo?
<mDuff> sandrot: yes.
<mDuff> sandrot: just push it into the repository, and there it is.
<sandrot> wouldn't my branch still be carrying around all it's repo data in branch/.bzr
<fullermd> No, when you push/pull/branch/etc a branch into a repo, it stores the data in the shared repo, not a per-branch repo.
<sandrot> very cool
<sandrot> so turning my project into a "checkout commit" system is as simple as pushing my branch into a shared repo =)
<fullermd> Of course, you could have a standalone branch that you 'mv' into a repo, and it will still store everything locally (since when it was created, it didn't know about any repos)
<fullermd> There doesn't have to be a shared repo involved to checkout a branch.
<mDuff> sandrot: you don't strictly need to do that; it's more of a space-efficiency thing.
<LeoNerd> Umm... a "shared repo" only makes any use if you take multiple branches of something...
<Lo-lan-do> LeoNerd: Um?  I thought a branch was also able to store diverged-then-merged revisions?
<LeoNerd> Yes it is..
<LeoNerd> But I mean, unless you actually _do_ that, a shared repo doesn't buy you anything in space savings
<mDuff> sandrot: if you have multiple branches, a shared repository prevents duplicate storage -- but you can do checkouts and all that from a standalone tree.
<Lo-lan-do> Then it's not quite an ordered list of revisions, is it?
<LeoNerd> If you have 10 different separate branches with 10 revisions in each, you have 100 revisions in the repo.
<sandrot> Okay, yeah, thanks, I understand that the shared repo is really just a nice extra
<LeoNerd> Lo-lan-do: Yes... because it's only the merge point that matters... Two diverged branches are still just an ordered list.
<LeoNerd> Lo-lan-do: When one is merged into the other, the target branch gets a special 'merged' revision, that contains sub-revisions of the changes that were merged
<Lo-lan-do> Ah, I see.  I thought these sub-revisions were stored too, so you'd have a DAG with only a partial order.
<Lo-lan-do> But if they're collapsed... then yes, it makes sense.
<sandrot> On a filesystem level, where should I store my branches on my server. Currently they're in /home/me/Code/bzr but should I be worried about having multiple users reading in my home directory?
<sandrot> fullermd: thanks for bringing up the standalone branch 'mv' thingie...that was a concern I had
<LeoNerd> The subrevisions are stored as well, yes... they retain their individual identity in the stored data...
<fullermd> Lo-lan-do: I think you're trying to read _WAY_ too much precision into an offhand statement   :p
<LeoNerd> I keep mine in /var/bzr/$user
<LeoNerd> (so I can point a webserver at them easily too)
<Lo-lan-do> fullermd: Possibly, but since I thought I finally understand how pulling and merging work, I'd rather not have that understanding shattered.
<sandrot> LeoNerd: so a user does an sftp://yourserver/var/bzr/$user ?
<Lo-lan-do> It's currently shaken, not shattered, but I'll think about it some more.
<indraveni> mwhudson, is there any default structure for the bazaar branch /
<indraveni> ?
<mwhudson> indraveni: i don't understand
<fullermd> Lo-lan-do: Technically, a branch is just a set of revisions; the revs themself describe the ordering.  More technically, it's just a pointer to ONE revision, since each rev describes the whole set of revs leading up to itself.  But it's simpler to give a taste by saying 'a branch is a series of revisions'.
<LeoNerd> Yes.. admittedly I hadn't considered merges when I made that statement
<Lo-lan-do> So I wasn't mistaken, yay! *phew*
<LeoNerd> I was just considering a simple linear branch
<indraveni> mwhudson, i have my bazaar branch created ni the path
<Lo-lan-do> One rev can have multiple parents, right?  Like in hg?
<indraveni> /opt/bazaar_samples/my_project
 * fullermd nods at Lo-lan-do.
 * Lo-lan-do dances the joy-dance of understanding
<indraveni> mwhudson, and my directory structure is like this
 * fullermd quickly searches for some random tidbit to totally shatter Lo-lan-do's understanding.
<Lo-lan-do> Don't you dare.
<sandrot> so if my branch is not bound than bzr update tries updating with itself?
<indraveni> mwhudson, my direcory structure and loggerhead.conf file is here http://pastebin.ca/747801
<fullermd> Lo-lan-do: So, if we define each rev of the tree to be a quantum superposition, see...
<indraveni> mwhudson, is my configuartion correct or not ?
<LeoNerd> sandrot: Indeed.. otherwise it wouldn't know what to "update" from
<fullermd> sandrot: 'update' updates your working tree to be up to date with its branch.  It doesn't much matter whether that working tree is colocated with the branch in a standalone tree, or separate from teh branch as a checkout.
<Lo-lan-do> fullermd: You define revs as you like.  I'll use the old analogy, as long as it keeps working for me :-)
<mwhudson> indraveni: the folder= line should give the path to a bazaar branch
<mwhudson> it looks like you've given the path to a folder containing folders which contain bazaar branches
<mwhudson> indraveni: ls -lAR would be better, perhaps
<indraveni> mwhudson, http://pastebin.ca/747804
<indraveni> mwhudson, yes, so my bazaar branch is /opt/bazaar_samples/my_project, so what i wrote in conf is correct ?
<mwhudson> indraveni: oh, yes then
<mwhudson> indraveni: so, what is going wrong?
<sandrot> thanks everyone, super helpful! Earlier I was going to setup a svn repo and export my bzr to svn to make things easy on my designer...not anymore!
<sandrot> bzr is easy enough on it's own =)
<indraveni> mwhudson, what abt the other fields?
<AfC> Someone should grab that and use it as a quote on a website somewhere
<indraveni> whe I typed, localhost:8090 in browser
<mwhudson> indraveni: they're not very important, cosmetic stuff only
<indraveni> it opened up a page which has a link to bzr.dev
<indraveni> and when i clicked that, it shows a page
<indraveni> The path '/branches/bazaar/bzr_dev' was not found.
<mwhudson> oh, one moment
<mwhudson> indraveni: server.webpath = 'http://localhost:8220/branches' <- this seems wrong
<mwhudson> this should be the path you type into your web browser
<mwhudson> so probably localhost:8090 in your case
<indraveni> mwhudson, sorry ,, i am accessing with localhost:8220
<indraveni> so thats right
<mwhudson> i still think you want to remove the "/branches"
<indraveni> mwhudson, got it
<indraveni> mwhudson, now it worked
<mwhudson> indraveni: hooray
<indraveni> mwhudson,thankyou
<indraveni> mwhudson, is it like, only one branch can be pointed for one loggerhead ?
<mwhudson> indraveni: no
<indraveni> mwhudson, in the first page its showing like, bzr.dev on clikcing which shows me the summary of prev revisions
<mwhudson> indraveni: you can have any number of top level sections (e.g. "[bazaar]") and inside each of these any number of branches (e.g. "[[bzr.dev]]")
<indraveni> mwhudson, but here in my case, in the inital page itself ts  showing bzr.dev
<indraveni> where as my bazaar branch name is my_project
<mwhudson> indraveni: that's because it's inside a section called [[bzr.dev]]
<mwhudson> change that to [[my_project]] or something
<indraveni> mwhudson, tell me one thinf
<indraveni> whats the difference between [xxx] and [[xxx]]
<mwhudson> [project]
<mwhudson> [[branch]]
<mwhudson> as i said above
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<lifeless> packs are in bzr.dev
<jelmer> lifeless: nice, thanks for let me know
<lifeless> theres an additional commit performance patch in my repository branch
<jelmer> ok - the one just discussed on the list?
<lifeless> yes, the 'native dirstate update basis ...'
<lifeless> jelmer: UDS and all hands are coming up
<lifeless> jelmer: but if there is *anything* I can do to help the samba guys make the right choice :)
<lifeless> I'd be delighted to e.g. meet up with samba folk in boston
<jelmer> lifeless: Jerry, the driving force behind the git adoption, will be at UDS I think
<lifeless> Jerry who?
<jelmer> Gerald Carter
<lifeless> perhaps you could mail him and poolie and I
<lifeless> or even a general note to the samba list, I don't know - do what you think will have the best effect
<jelmer> I'll bring it in in the internal discussions about git
<jelmer> but I'll keep you informed
<jelmer> when's UDS exactly?
<lifeless> wiki.ubuntu.com has all the details
<lifeless> basically though I'm in boston from friday till the 10th
<lifeless> ok later
<lifeless> mDuff: I think there is quite a simple fix for your performance bug; we currently maintain a set of deleted paths.
<jelmer> lifeless: ok
<lifeless> mDuff: but if we change this to a list, and trim paths from it when we move past them in the loop
<lifeless> mDuff: then the list won't get 1000's of entries long, and in fact will in principle only ever be a single item long.
<indraveni> mwhudson, if i am forgetting to stop loggerhead and again trying to start the loggerhead
<indraveni> mwhudson, its syaing port not free
<indraveni> and when i am seeing the processes, i dont find any loggerhead prcess running
<indraveni> i am not able to kill the processs
<indraveni> instead i am changing the port to anyother, which is  a bad practoce
<indraveni> so, how can i kill the loggerhead processes ?
<niemeyer> Would anyone know how to prevent the error bzr: warning: unsupported locale setting?
<lifeless> ok damn that was easy
<lifeless> niemeyer: set your locale correctly.
<niemeyer> lifeless: You're brilliant
<niemeyer> I wonder how I didn't think of that before
<niemeyer> lifeless: Ok.. now, how do I do that?
<lifeless> the LANG and LC_ variables IIRC
<niemeyer> [niemeyer@burma ..ent/bound/trunk]% echo $LANG
<niemeyer> en_US.UTF-8
<niemeyer> They're all like that
<lifeless> the probable cause is missing language resources then IIRC
<lifeless> uhm
<niemeyer> Which means ...
<mwhudson> indraveni: ./stop-loggerhead.py should kill the process
<indraveni> mwhudson, its not killing
<indraveni> mwhudson, i am forcely killing the processes,
<indraveni> mwhudson, now it worked fine
<lifeless> niemeyer: is this in the DC ?
<niemeyer> lifeless: No, locally
<lifeless> hmm
<mwhudson> the starting and stopping scripts are not amazingly robust
<fullermd> niemeyer: The "right answer" probably varies by the particular system.  'locale -a' might list all the available options...
<indraveni> mwhudson, i have two more doubts on this loggerhead, could u please bear with me for 10 more mins
<lifeless> niemeyer: you might try locale-gen
<niemeyer> [niemeyer@burma ..ent/bound/trunk]% locale -a | grep en_US
<niemeyer> en_US.utf8
<niemeyer> lifeless: Cool, will try it
<fullermd> Well, there you go; it's just spelt a little differently than you have it.
<niemeyer> Says "up-to-date", and still same problem
<lifeless> niemeyer: basically in python terms we're trying to do 'str.encode('en_US.utf8')'
<fullermd> I set $LANG in my shell .rc file...  you can probably override there.
<lifeless> and python is throwing an error
<fullermd> Oh, no.  You're trying to str.encode('en_US.UTF-8'); that's why the error.
<niemeyer> >>> print "Ã¡Ã©Ã­Ã³Ãº".decode("UTF-8").encode("UTF-8")
<niemeyer> Ã¡Ã©Ã­Ã³Ãº
<indraveni> mwhudson, what is the difference b/w [xxx] and [[xxx]]
<fullermd> niemeyer: Your system supports "en_US.utf8", and you're trying to tell it you're using "en_US.UTF-8", so it's flibbering all over itself.
<mwhudson> indraveni: i've explained that twice
<lifeless> niemeyer: thats UTF-8
<lifeless> niemeyer: you have en_US.UTF-8
<lifeless> niemeyer: which is different
<lifeless> try
<luks> en_US is not an encoding :)
<niemeyer> fullermd: I don't think there is a difference..
<niemeyer> fullermd: "UTF-8" and "utf8" should work the same way
<niemeyer> fullermd: And I get the error both ways
<lifeless> niemeyer:
<lifeless> >>>
<fullermd> Not if your system only has a locale def for "en_US.utf8" and you're trying to point it at "en_US.UTF-8".
<lifeless> import locale
<niemeyer> lifeless: en_US shouldn't be used in a Python decode/encode statement
<luks> niemeyer, but python is probably missing the en_US.utf8 -> en_US.UTF-8 alias
<lifeless> locale.getpreferredencoding()
<indraveni> mwhudson, is it, sorry, i dint check, will check now
<fullermd> You get the error with your LANG set to the proper value?
<niemeyer> [niemeyer@burma ..ent/bound/trunk]% python -c 'import locale; print locale.getpreferredencoding()'
<niemeyer> UTF-8
<niemeyer> fullermd: My lang *is* set to the proper value, as far as I know
<luks> LANG=en_US.utf8 bzr something
<fullermd> If locale -a doesn't list the setting your have for LANG, it's not the proper one.
<lifeless> on a machine that has the glitch for me, I get:
<niemeyer> fullermd: It's an alias..
<niemeyer> luks: Yes, fails the same way
<lifeless>  $ python -c 'import locale;locale.getpreferredencoding()'
<lifeless> Traceback (most recent call last):
<lifeless>   File "<string>", line 1, in ?
<lifeless>   File "/usr/lib/python2.4/locale.py", line 417, in getpreferredencoding
<lifeless>     setlocale(LC_CTYPE, "")
<lifeless>   File "/usr/lib/python2.4/locale.py", line 381, in setlocale
<lifeless>     return _setlocale(category, locale)
<lifeless> locale.Error: unsupported locale setting
<lifeless> niemeyer: what about
<lifeless> python -c 'import bzrlib.osutils; bzrlib.osutils.get_user_encoding()'
<luks> niemeyer, is en_US.UTF-8 also in LC_ALL?
<niemeyer> lifeless: Shows nothing
<luks> or LC_*
<lifeless> niemeyer: then its not erroring
<niemeyer> luks: It is, all of them
<lifeless> do you have an alias for bzr or something ?
<niemeyer> lifeless: Nope
<niemeyer> lifeless: It's a bzr update command.. does it make a difference?
<indraveni> mwhudson, got it, thankyou
<lifeless> well, an alias could be overwriting an env variable
<niemeyer> lifeless: Over bzr+ssh.. may I be getting errors from the remote side?
<lifeless> niemeyer: oh yes, that is coming from the remote side
<lifeless> niemeyer: which I bet is the DC
<niemeyer> lifeless: It's from chinstrap, yes
<niemeyer> That's.. hmm.. weird :(
<lifeless> niemeyer: /win 52
<niemeyer> lifeless: Hm!?
<lifeless> mistype
<niemeyer> Getting a locale error due to a setting from the remote repository is super strange
<lifeless> stderr is displayed locally by openssh
<niemeyer> lifeless: Right.. I'm speaking from a user perspective
<lifeless> right
<lifeless> and I agree
<lifeless> but it seems undesirable to hide it
<niemeyer> I definitely desire it :)
<niemeyer> Or at least change the wording of what's shown in these cases
<fullermd> It would be nice to have some sort of indicator that "Hey, this is from the other side, silly!"
<lifeless> you could file an RT ticket :)
<lifeless> fullermd: indeed; that means intercepting stderr and selecting() rather than just reading etc etc.
<fullermd> Well, we could just make nothing ever go wrong, if that's easier  ;)
<niemeyer> Ok.. thanks for the help guys
<Lo-lan-do> Is there a way to remove a branch from a shared repo?
<fullermd> rm -rf, generally.
<LeoNerd> You can rm it, but that'll not remove the individual revisions from the store
<LeoNerd> This won't matter, except in disk space
<Lo-lan-do> Exactly :-)
<Lo-lan-do> So... no garbage collector to clean the unused versions?
<LeoNerd> Not that I know of currently.. You can 'push' each branch to a new shared repo, then 'mv' swap them though
<fullermd> I think lifeless hacked up something once upon a time that did some GC'ing.
<LeoNerd> 'bzr vacuum' or something like that?
<fullermd> But there's no standard, supported thing to do it, no.
<Lo-lan-do> http://doc.bazaar-vcs.org/latest/developers/repository.html does mention GC, but rather vaguely
<Lo-lan-do> lifeless: ^^^ anything you feel I should know? :-)
<jelmer> we discussed a garbage collect command at the sprint this summer
<jelmer> but afaik nothing like that has been implemented yet
<Lo-lan-do> Okay.  I'll keep my temporary branches out of my shared repository then.
<fullermd> Sounds like more trouble than it's worth, unless you start checking in ISO's or something.
<Lo-lan-do> Dead files eating space on my disk make me uncomfortable.  And since it's actually simpler to start a local branch than put it in a repo than get a lightweight checkout of it, I see it as a net positive.
<Lo-lan-do> Less trouble, *and* less discomfort.
 * fullermd shrugs.
<fullermd> I've got dead revs all over the place, from abandoned branches, or uncommit's.  I'm not gonna worry very much about a few hundred k of wasted space...
<fullermd> I probably burn more space holding backup copies of scripts I wrote for use on systems that haven't existed in 10 years.
<Lo-lan-do> Well, as you like, but I don't like institutionalised cruft.  It's like a memory leak, except permanent.
<Lo-lan-do> Am I running into problems if I have a working tree that's both a lightweight checkout of a branch stored in a shared repo *and* a checkout of an SVN branch?
<Lo-lan-do> I guess only the branch (in the repo) is bound to SVN, and the working tree is just something that happens to be a checkout of that branch, but I'd like a confirmation from the masterz :-)
<Lo-lan-do> (If I'm not going to run into problems, then that's probably the setup I'm likely to use)
<jelmer> I see no reason why that shouldn't work, if I understand the setup correctly
<Lo-lan-do> Great
<Lo-lan-do> You'll probably hear about it if it doesn't :-)
<Lo-lan-do> Quite soon, even: I've just received a patch form the BTS, which I'm going to try and merge right now.
<Lo-lan-do> Yay, it  seems to be working!
<Lo-lan-do> I committed a patch in sid (pure bzr, light checkout), then pulled it into trunk (the one which is a light checkout of the branch bound to SVN).
<Lo-lan-do> No error, and svn update in an svn checkout includes the patch.
<Lo-lan-do> Yay yay yay :-)
<Lo-lan-do> Hm.  Would it be possible to do without the SVN properties, or to keep them short?  The commit emails we get include the properties, and they're getting crowded...
<Enquest> how do I put a directory on an ignore list?
<Enquest> I want a certain directory not to be loaded.
<Enquest> update
<dato> Enquest: can you give an example of what you want?
<Enquest> something lik bzr ignore www/uploads/
<Enquest> how do I do this?
<dato> other way than `bzr ignore www/uploads` ?
<Enquest> when I type bzr add ... It starts to add all files. I don't want a directory included
<dato> Enquest: is "www" at the same level as ".bzr" ?
<dato> if it isn't, `bzr ignore www/uploads` will not work
<Enquest> www is deeper
<Enquest> dev/.bzr
<Enquest> dev/www/upload
<fullermd> Actually, I think ignore canonicalizes the path as necessary.  Not sure (I always just hand-edit .bzrignore)
<jam-laptop> fullermd: it does not (yet), I thought there was a bug asking for this sort of thing, though.
<jam-laptop> I think part of it is that you probably don't want to canonicalize: bzr ignore "*.foo"
<mdke> lifeless: seeking your advice with something. Could you look at https://lists.ubuntu.com/archives/ubuntu-doc/2007-October/009758.html which sets out the naming scheme intended to be used for our project's branches on Launchpad. The question is, should we include all the svn revision history (now imported into bzr) in each branch, or just start new branches afresh, maybe keeping revision history from svn around in one of the branches to use if we need it. Uploa
 * mdke hopes his irc client doesn't cut the end of long lines, the last word there should be "solution"
<mwhudson> mdke: nope
<mwhudson> "we need it. Uplo" was as far as we got
<mwhudson> mdke: i should apologise for not replying to your emails, btw
<jam-laptop> mdke: How much history are you talking about?
<jam-laptop> (how many files, how many revisions, etc)
<jam-laptop> I generally would keep history unless there is a real reason not to
<jam-laptop> Oh, and lifeless is usually not for another couple of hours
<jam-laptop> (.au time, I've seen him on in an hour, but that is about 5am his time)
<mdke> mwhudson: that's ok.
<mdke> jam-laptop: i think it's 3500 revisions
<mdke> mwhudson: I wasn't expecting an instant response :)
<jam-laptop> mdke: doesn't seem like too many, Bazaar has 14,519
<mwhudson> mdke: i'll try to have a sensible reply by the morning
<mdke> jam-laptop: well, uploading the first branch took about 3-4 hours this morning, and there will be something like 15 branches...
<jam-laptop> Though at the moment we scale a little bit better with num revisions than we do with num files
<jam-laptop> mdke: uploading from where? And were you using "sftp://bazaar.launchpad..." or "bzr+ssh://bazaar.launchpad"
<jam-laptop> The latter has much better latency characteristics
<mdke> jam-laptop: from my home. The latter
<jam-laptop> (sftp:// requires 3 round trips, etc)
<jam-laptop> mdke: well, if you want, I can "pre-seed" some branches for you
<jam-laptop> If you have one uploaded, I can push it into neighboring ones
<jam-laptop> from a much closer location
<jam-laptop> And then your future pushes of the other branches should be fairly fast
<fullermd> Yeah, I wish LP let you do that, if not actually support repos...
<mdke> jam-laptop: that sounds really helpful. I'm still a bit concerned about the amount of downloading people would have to do to get multiple branches though.
<jam-laptop> fullermd: there is quite a bit of discussion of server side branching, shallow branches, and what we might do for shared repos
<mdke> Still, that may be solved by advising people not to download revision history
<jam-laptop> mdke: If they have a shared repository (recommended) it won't copy everything
<jam-laptop> Just the first time
<jam-laptop> but not 1x per branch
<mdke> jam-laptop: I understood that LP didn't support that. We're planning to use LP as a central server with a relatively centralised workflow
<jam-laptop> mdke: LP doesn't have shared repositories on *its* side. It has nothing to do with letting you use them on your own machine
<jam-laptop> (So you can't tell LP to share the repository between ~user/project/branch1 and ~user/project/branch2, but on your local machine you can.)
<mdke> right... and that wouldn't affect a "bound branches" workflow?
<jam-laptop> mdke: correct
<mdke> very interesting
<jam-laptop> "shared repositories" is just an optimization for how data is stored
<jam-laptop> it doesn't change much else
<mdke> right, I'll have to explore that definitely and look into the docs
<jam-laptop> mdke: you might read http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
<jam-laptop> or even
<mdke> will do
<jam-laptop> http://bazaar-vcs.org/Workflows
<mdke> jam-laptop: as for your kind offer to do the pushing, I'm very interested. I'll have to explain a bit more the structure
<jam-laptop> mdke: can you give me the URL so I can start downloading?
<jam-laptop> (Oh, and if you have troubles, you can always ask questions in IRC)
<mdke> jam-laptop: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<mdke> jam-laptop: so the plan is to make xubuntu-hardy, kubuntu-hardy and edubuntu-hardy from that, and then make some amendments to those.
<jam-laptop> I *think* I can register them under my name, and then assign rights to them to the ubuntu-core-doc group
<jam-laptop> If not, can I get added to the ubuntu-core-doc group?
<mdke> sure
<mdke> jam-laptop: then we hope to do the same thing with each of the branches from the svn repository, ubuntu-gutsy, kubuntu-gutsy and so forth (I haven't pushed an equivalent
<mdke> ... branch for those to Launchpad yet, but they share the revision history of the existing branch up there, as I understand it
<jam-laptop> Well, it took 1m36s to download the 210MB from a very nearby server
<Lo-lan-do> Do you guys keep every Ubuntu package under bzr?
<jam-laptop> Lo-lan-do: not yet
<jam-laptop> I believe things are being migrated over
<jam-laptop> but it certainly isn't 100% of all packages
<mdke> that's my understanding too
<Lo-lan-do> Okay.
<mdke> jam-laptop: added to ubuntu-core-doc
<jam-laptop> mdke: (jameinel, right?)
<mdke> :)
<Lo-lan-do> (I'm manually keeping a bazaar branch for my package, and I was wondering whether I was duplicating work)
<jam-laptop> so you want an ubuntu, xubuntu, kubuntu, and edubuntu for all of -hardy, -gutsy,
<jam-laptop> mdke: what are the specific permutations, so I'll get them all
<mdke> Lo-lan-do: see https://wiki.ubuntu.com/BzrMaintainerHowto
<jam-laptop> (my basic plan is just to write a simple bash for loop, and do some pushing)
<Lo-lan-do> mdke: Oh, but I am already keeping my package in bzr, it's the Ubuntu ones I track (in bazaar) by hand.
<mdke> jam-laptop: the thing is, the ubuntu-hardy branch comes from the svn trunk. The plan is to add branches for each svn branch (so not the same material). As I understand it, they will all have the same revision history
<jam-laptop> mdke: if they were branched around in svn they will likely share some history
<jam-laptop> (probably not 100%)
<jam-laptop> So am I right with (ubuntu, xubuntu, kubuntu, edubuntu) and (hardy, gutsy, feisty, edgy, dapper) ?
<mdke> jam-laptop: ah, so the bzr history will be different?
<mdke> I used svn-import to import the whole repository
<jelmer> mdke: That means you'll have a shared repository already, locally
<mdke> exactly
<jam-laptop> Just that I would expect ubuntu-gutsy to have fewer revisions than ubuntu-hardy
<mdke> I have to leave you for a bit, sorry to be rude
<jam-laptop> and maybe a couple extra that -hardy doesn't have
<jam-laptop> (well, assuming they aren't 100% the same code base, they can't have 100% the same revisions :)
<jam-laptop> mdke: np
<jam-laptop> Lo-lan-do: is your "official" source in Bazaar, or is it svn/cvs?
<Lo-lan-do> jam-laptop: Upstream is in CVS, but I work on the packaging in bzr
<jam-laptop> Lo-lan-do: k, you may want to register your project with vcs-import, and Launchpad will maintain a conversion from cvs => Bazaar for you (for at least the 'trunk' branch.)
<jam-laptop> Though if you just register your project
<jam-laptop> and push up your Bazaar branch as trunk
<jam-laptop> you can use that too
<Lo-lan-do> Uh, sorry, s/CVS/SVN/
<Lo-lan-do> But I'm just asking, don't mind me.
<Lo-lan-do> I'm quite satisfied with my branches so far, I was wondering if you had a branch for the package (so I could keep a copy and/or merge from it) or not.
<jam-laptop> Lo-lan-do: what is the package ?
<Lo-lan-do> gforge
<jam-laptop> either way, if you read https://wiki.ubuntu.com/BzrMaintainerHowto it gives a pretty good description of how to integrate things with Launchpad
<jam-laptop> Lo-lan-do: I don't see a 'gforge' project registered
<Lo-lan-do> It's all right then.
<jam-laptop> Lo-lan-do: so is gforge sort of like Trac?
<Lo-lan-do> Broadly
<Lo-lan-do> It's more like Sourceforge, actually, since it started as a fork of it
<mdke> jam-laptop: ok, back. I've done a little explanation of what I have in my svn import (as a shared repository), and what I'd like to create on Launchpad, so that it's clearer. I think from what you said earlier that I actually have to upload one branch from here for each distribution, and you can't do all the work for me :)
<mdke> http://paste.ubuntu-nl.org/41964/ <-- explanation
<jam-laptop> mdke: what I *can* do is upload a fake branch for each one, which has all of the ubuntu-hardy revisions
<jam-laptop> so that your future pushes only have to push the new/different data
<jam-laptop> and not all of the common ones
<mdke> but the ubuntu-hardy won't have the ubuntu-feisty revisions, is that right?
<jam-laptop> mdke: it will have the ones that are in common
<mdke> I'd previously assumed that bzr used the same revision history (from the shared repository) for them all
<mdke> right
<jam-laptop> when you make a commit in ubuntu-feisty that will not be in the ubuntu-hardy ancestry
<jam-laptop> mdke: are the files on your home machine somewhere that I could access them?
<mdke> I haven't made any commits since doing the svn-import
<mdke> yes, I'd have to setup ssh though, give me a bit
<jam-laptop> mdke: when you do "bzr push" from a shared repository, we don't push 100% of the revisions, only the ones in the ancestry of the branch you are pushing
<mdke> jam-laptop: ok, it's cleverer than I thought, all clear
<jam-laptop> So if you have a project with 10 revisions next to one with 10,000
<jam-laptop> you don't push 10,010 revisions for just a 10 revision branch
<mdke> would the "fake branch" solution be complicated by having revisions in ubuntu-hardy that aren't present in ubuntu-feisty? I.e. would me pushing the real ubuntu-feisty branch just result in those revisions being removed?
<jam-laptop> mdke: they won't be removed, but they will stop being referenced
<jam-laptop> so when someone downloads from the new ubuntu-feisty branch
<mdke> is that acceptable?
<jam-laptop> they won't get the superfluous ubuntu-hardy ones
<jam-laptop> mdke: generally it is fine
<mdke> i see
<jam-laptop> I do it all the time here
<mdke> I'll give you access and then I'm happy to be guided by you on that
<mdke> lemme just tweak the router
<jam-laptop> I personally use 1 shared repository for all of my Bazaar and plugin work
<jam-laptop> (and a different one for other projects)
<jam-laptop> mdke: so am I correct in saying you want a branch for all the permutations of (ubuntu, xubuntu, kubuntu, edubuntu) versus (hardy, gutsy, feisty, edgy, dapper) ?
<mdke> jam-laptop: yes
<jam-laptop> k
<mdke> jam-laptop: although tell me if that doesn't make sense as a workflow too
<jam-laptop> I'm not sure I understand why you want a separate branch for all of (ubuntu, xubuntu, kubuntu, ..)
<mdke> they are separate packages and we want to store the debian directory for each in the same place in the directory structure. It will also allow us to remove unnecessary directories for each package
<jam-laptop> So I'm a little concerned about disk storage consumption, since it is approx 200MB x 4 releases x 4 os's = 3.2GB on Launchpad
<jam-laptop> (that is also one reason why LP is looking into how to have LP-side shared repositories.)
<mdke> right
<jam-laptop> Do you need the full set of permutations?
<jam-laptop> Or would it be reasonable to just do 1 branch for edgy and dapper?
<fullermd> So, are you saying we should get all those branches pushed up ASAP, in order to bump the priority of the LP-side repo feature?   ;)
<mdke> jam-laptop: yes, we could do one branch for everything except hardy and see how it goes, maybe create more if we think it would be very helpful. Is storage spac a problem on Launchpad?
<jam-laptop> I don't know that storage space is super critical
<jam-laptop> but it is my understanding that if LP tried to host all of the LP branches on itself
<jam-laptop> it would run out of disk pace
<jam-laptop> space
<jam-laptop> but LP is developed in a very distributed fashion
<jam-laptop> so there are *lots* of branches
<mdke> should I talk to someone about this?
<mdke> mwhudson, for example?
<jam-laptop> Well, we can summon him by name, but he may have gone home already
<mdke> indeed
<mdke> it was more of a general question
<jam-laptop> yeah, but I think he might be someone who knows
<jam-laptop> maybe spiv
<dato> jam-laptop: (you mean storing all personal branches of people with commit access to launchpad itself? re the running out of space bit)
<mdke> jam-laptop: an alternative would be to upload the derivative branches without revision history, i suppose
<mdke> that might be preferable to not having derivative branches at all
<mdke> although I suppose the disk space would gradually build up
<jam-laptop> dato: right
<jam-laptop> mdke: well, is the disk space usage because you have lots of history, or because you have a big tree?
<jam-laptop> (If you have 100MB in a checkout, then the history cost is actually pretty small)
<dato> jam-laptop: with trees, you mean? otherwise I'm having trouble grasping the idea.
<mdke> if it's the latter, then we'll be pruning the derivative branches so they have much less overlap
<jam-laptop> dato: LP stores an independent repository for each branch
<mdke> a recent svn checkout of svn trunk is 39MB
<jam-laptop> dato: and 1 lp repository is 400MB
<dato> jam-laptop: ah, right
<dato> jam-laptop: I must be still sleeping, since that piece of information was said right before :)
<jam-laptop> dato: which is one of the reasons on the checklist for why to do some sort of shared repositories
<jam-laptop> mdke: so I'm going ahead and making all of the -hardy ones
<jam-laptop> And I have some stubs (with 10 revisions) for a bunch of them
<mdke> what does that mean?
<jam-laptop> https://code.launchpad.net/ubuntu-doc
<jam-laptop> I created the permutations through feisty
<jam-laptop> but only pushed 10 revisions
<jam-laptop> now I'm going back and pushing the full history for *-hardy
<jam-laptop> and then I'll push 1 for ubuntu-*
<mdke> ah, the 10 revision thing is on purpose? it's not a problem?
<mdke> phew
<jam-laptop> mdke: right, I just wanted to get them started
<mdke> hang on a sec
<mdke> let's take this tree vs revision history thing further
<mdke> a recent svn checkout of svn branches/gutsy is over 700MB...
<mdke> so that would suggest the tree is very large
<mdke> I don't know where all that is coming from
<mdke> it may be that we can sort this out and have all the permutations, eliminate overlap in terms of tree size, and so cut down the disk space used
<jam-laptop> well, SVN always creates 2 copies of your working tree
<jam-laptop> (1 pristine copy is stored in the .svn/ directories)
<mdke> I'm going to do an export to check
<mdke> i.e. without the .svn directories
<mdke> damn this slow computer
<mdke> ok, gutsy is about 317MB in a clean export. That would be cut down to about 200MB in the kubuntu and ubuntu branches, and very small for edubuntu and xubuntu
<mdke> jam-laptop: I don't mind what we do with dapper/edgy/feisty for now, let's just do what we can. I already have taken too much of your time
<jam-laptop> Well, right now your total .bzr/repository is about 200 MB
<jam-laptop> Also, I'm not sure that you can break it up quite that easily
<jam-laptop> Just because in the past the branches had "X" which means that a conversion may preserve that
<mdke> I don't follow that, can you give me an example?
<jam-laptop> If I: bzr branch ...bzr.dev local; cd local; rm -rf lots of files; bzr commit -m "remove those files"
<jam-laptop> when I 'bzr branch' this new branch with lots of removed files
<jam-laptop> I still get the history for all the files which used to exist
<jam-laptop> (since you can "bzr revert -r -10" and have it work)
<mdke> true
<mdke> so doing "bzr rm" will transfer the disk space from the tree to the history :)
<jam-laptop> well, bzr rm won't remove it from history
<jam-laptop> just the tree
<jam-laptop> (it doesn't really "transfer" anything)
<jam-laptop> So is the plan to reorganize all your branches?
<mdke> what you're saying is that bzr rm directory won't save space, right?
<jam-laptop> So that instead of having the "gutsy/ubuntu"
<jam-laptop> you would end up with just "ubuntu-gutsy" ?
<mdke> so if I go to the ubuntu-hardy branch and remove the "kubuntu" and "xubuntu" directories, then there won't be a space saving
<jam-laptop> mdke: It only saves space in the Working Tree
<mdke> ok, I'm following now
<mdke> so we have a space problem still
<jam-laptop> now this *might* be a reason to switch to a history-less conversion
<jam-laptop> since you are doing some major restructuring
<mdke> well, it's more of a split. The people working on kubuntu-hardy might want access to the revision history
<jam-laptop> just fyi, your full conversion is 684MB
<mdke> but I think the revision history is more of a luxury than a necessity, we can ditch it if it's important
<jam-laptop> so there seems to  be a lot of stuff in branches/gutsy
<jam-laptop> that isn't in trunk
<mdke> correct, translations
<mdke> these get added at the end of the release cycle for each branch
<jam-laptop> to be clear, 470 MB of stuff :)
<mdke> yes
<jam-laptop> well, that may not be all in gutsy
<jam-laptop> I suppose it could be the others as well
<mdke> 319MB is a clean gutsy export
<mdke> compare that with 16MB for trunk
<jam-laptop> which should compress a bit, when it is stored in a repository
<jam-laptop> but still, a rather large difference
<mdke> in 6 months time, hardy gets the same bump up
<jam-laptop> Any chance it will be approximately the same data as in gutsy?
<mdke> jam-laptop: sure, a lot of it. Not exactly files though
<jam-laptop> (I'm just guessing that you are creating new files, when they are closer to copies from the other branch)
<mdke> the translations vary according to how much the original text varies from release to release
<mdke> but broadly the majority of the text is likely to be present in both
<mdke> jam-laptop: so, what's your recommendation? :)
<jam-laptop> mdke: well, right now I'm going to batch upload your conversion to a machine that is closer to LP using a tarball
<jam-laptop> Your 'ubuntu-hardy' branch isn't huge yet
<jam-laptop> so I would get it cleaned up quickly
<jam-laptop> (split into the actual sub-projects)
<jam-laptop> so that when you go to add the big files
<jam-laptop> you end up doing it in only the sub-projects
<jam-laptop> Is there any development going on on the -gutsy/-feisty/etc branches?
<lifeless> moin
<jam-laptop> morning lifeless
<mdke> I'll be updating translations, and possibly fixing any serious bugs if we find some
<mdke> hi lifeless
<mdke> jam-laptop: so yeah, we'll be touching the -gutsy/-feisty branches, but it wouldn't be the end of the world to just have a single permutation for them (since that is what we do in svn now)
<jam-laptop> mdke: so I would probably go with that
<jam-laptop> leave pre -hardy branches alone
<jam-laptop> (having 1 branch for all versions)
<jam-laptop> and then start the split at -hardy
<jam-laptop> mdke: by the way, you weren't kidding P-III 600MHz
<mdke> jam-laptop: alright
<jam-laptop> (*my* server is a dual P-III *700*MHz)
<mdke> jam-laptop: yeah, my laptop is broken, I had to dig this one out as an emergency measure
<mdke> have to run Gnome on it and all
<bialix> hi, have the question about dogfooding packs
<jelmer> 'evening Alexander
<bialix> hi Jelmer
<bialix> I don't see any instructions about packs in bzr.dev
<bialix> I know it's hidden
<mDuff> bialix: --experimental on init or init-repo
<bialix> aha
<bialix> what's the fuzz about reconcile?
<bialix> check don't suggest it for my non-bzr.dev repos
<bialix> mDuff: branch into pack repo will do conversion w/o problem?
<jelmer> bialix: yep
<bialix> hmm, it seems that branch works blazingly fast
<lifeless> bialix: cool
<bialix> hi, our white mage
<bialix> lifeless: have any suggestions what I should check on win32 (except running selftest)?
<lifeless> let see, what things generally give headaches?
<lifeless> bzr-svn stuff has long file ids
<lifeless> if our minimum index read is too short that could fail
<bialix> I don't use svn, can;t check
<lifeless> what else
<lifeless> is it better at being in deep directories/handling long paths/caps paths
<bialix> will try
<bialix> lifeless: may I ask you comment on this: https://lists.ubuntu.com/archives/bazaar/2007q4/033058.html
<jelmer> lifeless: so far, packs work really well here. The only thing that I've hit so far is NoSuchFile exceptions when I was doing heavy writing to a repository /and/ reading from it
<jelmer> but that was to be expected I guess, since it's moving files around
<jelmer> to obsolete_packs
<lifeless> jelmer: cool
<bialix> lifeless: about deep directories/handling long paths/caps paths: I'm not sure what to test here, because knit file name is shorter that my very long file name for test (I create 127-symbol long filename, but in repository/knits there is 59 chars filename)
<lifeless> bialix: reading it
<lifeless> bialix: then it should be fine
<bialix> lifeless: pack name is 37 chars long. so you win 59+3-37=25 chars
<bialix> but for obsolete_packs directory this win is smaller by 10 chars
<bialix> I don't see why packs should change situation for bzr itself. may be for bzr-svn... but I never used it, can't say anything
<bialix> tomorrow I'm planning to run the whole test suite
<lifeless> very cool
<bialix> (it will take more than hour on my hardware, so I better do it on fast machine)
 * mDuff hasn't found any new issues with packs since yesterday (other than some slightly different server-mode exceptions when running commands other than push).
<lifeless> mDuff: I am working on that delete bug; we iterate directory-at-a-time so I need a little care (a simple string comparison isn't enough to trim the array of deleted items)
<bialix> lifeless: my biggest performance problem with bz 0.91 and before is slow machine (CPU <1GHz). The slowest is first run (cold cache I think), and during branch  build phase takes a lot of time
<jam-laptop> I had some work that improved text extraction time (for build_tree)
<jam-laptop> It sort of conflicts with what lifeless has been doing
<jelmer> LarstiQ: Hi
<jelmer> LarstiQ, can you still reproduce bug 128496?
<ubotu> Launchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Triaged] https://launchpad.net/bugs/128496
<bialix> lifeless: I think we should say now not simply "packs", but: "packs!(TM)" :-)
<lifeless> bialix: :)
<lifeless> jam-laptop: I've largely finished with knits, the only remaining change I have planned there is to decouple 'parents' and 'compression components'
<bialix> guys, I'd like to make new windows standalone installer (with packs) for earlier adopters. any objections?
<lifeless> jam-laptop: I'd *like* to make it arbitrary so we can do the sort of crazy stuff we sketched on the list
<lifeless> bialix: I think that would be nice
<bialix> ok
<lifeless> jam-laptop: that will though impact fetching so we need some care that performance does not go out the window.
<bialix> done
<jam-laptop> lifeless: I was pretty close to getting the parents list into the data portion of packs
<lifeless> jam-laptop: that and the noeol indicator would be good too
<jam-laptop> The internal API changes aren't bad, but figuring out the implications to all the copying code will be a bit tricy.
<jam-laptop> tricky
<lifeless> I do think we should keep the cached index data
<lifeless> about this
<jam-laptop> sure, but make it redundant
<jam-laptop> rather than precious
<lifeless> right
<bialix> packed repo is slightly bigger then knitted one
<lifeless> thats unusual; we drop annotations and the indices are pretty close
<lifeless> perhaps you have something in .bzr.backup, or already have .bzr/repository/obsolete-packs ?
<bialix> well after initial branch from knits to pack I have 5038KB vs 5076KB for my own biggest repo
<bialix> it's the size of .bzr/repository directory
<lifeless> interesting
<bialix> no, obsolete dir is empty
<bialix> after initial branch I have only one pack with the size 4277KB
<lifeless> hmm
<bialix> and 818KB of indices
<lifeless> oh, are you reporting apparent size or used disk size ?
<lifeless> I did mos of my comparisons on used disk size, which includes wasted space in allocated block/clusters/inodes/whatever
<lifeless> s/mos/most/
<bialix> it's the size that I see in my FAR
<bialix> usually it's real size
<lifeless> right
<lifeless> in which case yes I think this is a reasonable result
<bialix> in my old knit repo size of directory .bzr/repository/knits is 3227KB
<bialix> and inventor.knit 1250KB
<bialix> if annotations should be dropped then packed repo should smaller?
<bialix> should be smaller, typo
<lifeless> so
<lifeless> 3227 + 1250 + revision.knit + signature.knit ?
<lifeless> 3227 + 1250 is 4470KB, which is larger than the .pack file :)
<lifeless> add in revisions and it should be a bigger difference still
<bialix> oh! just ran 'bzr check' in source branch and got: 1824 inconsistent parents
<bialix> I need to run reconcile?
<lifeless> if its not bzr.dev, it will probably run ok without reconcile
<lifeless> if it is bzr.dev, you won't be able to branch from the pack version to another pack version.
<bialix> no, it's my own repo
<lifeless> I wouldn't worry about reconcile until andrew gets the additional fix done
<lifeless> then push all your data to knits format, reconcile it there, and make a clean pack repo
<bialix> but '1824 inconsistent parents' is scare me
<lifeless> its likely that they are [A,B] vs [B,A] as at one point we didn't guarantee ordering.
<lifeless> in bzr.dev we have worse
<bialix> it scares me because I have 672 versioned entries and 942 revisions
<lifeless> its per-file
<bialix> ah
<bialix> what's the simplest way to obtain real file size via python?
<lifeless> os.lstat(path).st_size
<lifeless> hmm, what module to put this in
<lifeless> I'm writing a little object to handle deletes; it will be given every path, and given new deletes
<lifeless> when a path is such that one of the deletes it's seen can not be a parent of any future path, it will drop it
<jam-laptop> lifeless: did you see my possible alternate that used a dictionary?
<jam-laptop> otherwise is_inside_any is an osutils function, IIRC
<lifeless> jam-laptop: no. Just path split and walk a tre ?
<jam-laptop> lifeless: basically
<jam-laptop> most paths get rejected quite early
<lifeless> have you tested this? is there a patch ?
<jam-laptop> lifeless: no, it was just a suggestion
<lifeless> so is_inside_any is osutils
<bialix> lifeless: ok, so sum total of all knit files in old repo is 4601310
<lifeless> I guess if I make a replacement is_inside_any osutils is the right place; I was thinking of a alongside-helper.
<jam-laptop> lifeless: where where is it being used?
<jam-laptop> In commit?
<lifeless> yes
<bialix> and pack has size 4379867
<lifeless> bug 156491
<lifeless> 100K commit, 8K deleted files, == 15 minutes to commit
<bialix> pack smaller, but the whole repo slightly bigger
<ubotu> Launchpad bug 156491 in bzr "commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/156491
<bialix> first error with packs: bzr: ERROR: Must end write groups before releasing write locks.
<bialix> when I try to `bzr branch` second branch from knit to pack
<bialix> if I clone treeless branch into shared-repo with trees enabled, it should work?
<bialix> branch w/tree has the same error during clone
<lifeless> it should; either something was using the write group api directly, or you had an exception occur somewhere that is missing a try:except:else:
<lifeless> if you change that exception that is being raised to be a 'pass', you should see the real exception
<bialix> sent to list
<lifeless> bialix: right, you need to change the excpetion raise to a pass temporarily to debug
<lifeless> bialix: it raises an exception because data loss can occur
<bialix> where to change?
<bialix> may be it's important detail: second branch is subset of first branch, i.e. all data is already cloned by first branch
<lifeless> pack_repo.py 1538
<bialix> PermissionDenied then
<lifeless> right, thats the bug then :)
<lifeless> could you please file a bug in lp, tagged packs, with the backtrace you got this time ?
<bialix> ok
<bialix> wait
<bialix> this time it's error in raise error agin
<lifeless> PermissionDenied sounds like a file system issue though?
<lifeless> oh! I bet its the transaction cleanup. We have to close the file before removing.
<lifeless> === modified file 'bzrlib/repofmt/pack_repo.py'
<lifeless> --- bzrlib/repofmt/pack_repo.py 2007-10-24 05:17:39 +0000
<lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-10-24 21:48:01 +0000
<lifeless> @@ -274,6 +274,7 @@
<lifeless>      def abort(self):
<lifeless>          """Cancel creating this pack."""
<lifeless>          self._state = 'aborted'
<lifeless> +        self.write_stream.close()
<lifeless>          # Remove the temporary pack file.
<lifeless>          self.upload_transport.delete(self.random_name)
<lifeless>          # The indices have no state on disk.
<bialix> http://pastebin.com/m7ed4075c
<bialix> lifeless: ^
<lifeless> try that patch please
<lifeless> if it fixes the problem, revert your other changes and just send it in :)
<lifeless> (to pqm I mean - +1 from me and you should do it )
<bialix> error 32 on windows it's: 32 The process cannot access the file because it is being used by another process.  ERROR_SHARING_VIOLATION
<lifeless> bialix: yes, I think my patch will fix it
<bialix> let me a couple of seconds
<bialix> yeah, clone is successfull now
<bialix> (when you linux guys teach yourself to close files explicitly?)
<lifeless> hey now
<lifeless> I used to be a core cygwin guy
<lifeless> its taken me years to forget about files
<bialix> :-D
<bialix> so you want me to send this patch to PQM?
<lifeless> that one liner yes please
<lifeless> its trivially correct, and the test suite on windows will fail without it
<bialix> ok, will do
<bialix> anybody know is 'Linus Torvalds on Git' talk is available as text somewhere in the net?
<dato> bialix: google "google video torvalds git"
<bialix> I have video, I'd like to have plain text because I'm not very good in english
<dato> bialix: aah, sorry. I missed the "as text" in your line, sorry.
<bialix> it's nice talk, and I really like this guy, he talk very much about distributed system in generals, not about git tiny details
<tchan> http://git.or.cz/gitwiki/LinusTalk200705Transcript
<tchan> google search for "linus torvalds git transcript" and that URL pops up as the first response
<bialix> tchan: wow, thank you, you save my day. I owe you beer
<bialix> who this guy Andrew, who speaks first 10 secs?
<tchan> the Google employee that arranged for Linus to give the lecture
<bialix> thanks
<tchan> perhaps its "Andrew Morton" also a kernel hacker god ?
<bialix> "where is Linus, why hasn't he merged my tree -- he does not love me anymore". :-) probably
<hendrixski> anybody have problems with pushing a bzr branch into an ftp server?
<lifeless> hendrixski: probably your server does not support REST/APPE
<hendrixski> I'm on version .15 (standard from ubuntu feisty because the one on the bazaar-vcs didn't want to work)
<lifeless> hendrixski: you might try bzr.dev which has a new format you can use (currently labelled '--experimental') and this works much better on FTP
<hendrixski> lifeless, oh... so just because I can ftp into it, doesn't mean I can push stuff on it?
<lifeless> hendrixski: some FTP servers disable parts of the protocol
<lifeless> hendrixski: for FTP, bzr 0.15 requires the REST/APPE commands to work
<hendrixski> I C. and that's only fixed in the current dev branch?
<lifeless> thats right
<lifeless> new disk format that does not need the ability to append data to an existing file.
<hendrixski> can I just FTP my folder with the bzr information using ftp and then can people can branch from that?
<lifeless> sure
<lifeless> that will work fine
<lifeless> though you may get errors from your client
<lifeless> for the same reason -
<hendrixski> with a standard ftp send?
<lifeless> yes, because bzr changes the content of files, and your client will need to know to delete the file at the remote end and upload the new one
<hendrixski> ah.. you mean for when I over-write changes in the future
<lifeless> yes
<lifeless> nDuff: I think I have your fix.
<hendrixski> I C
<lifeless> nDuff: just profiling to make sure its not a regression in the common case
<lifeless> nDuff: which it is somewhat
<ddaa> jelmer: hello
<ddaa> jelmer: I need your help as buddy for a bug in svn 1.4.4
<lifeless> nDuff: ok, its fixed, pushing it in a second
<ddaa> nDuff: hey nDuff
<ddaa> (that was redundant...)
<jelmer> ddaa: Hi
<ddaa> jelmer: come to #svn?
<ddaa> I exposed my problem there, but nobody seemed to care enough to reproduce it :/
<lifeless> nDuff: its revno 2856 in the same branch you've been testing with
<lifeless> nDuff: I'm popping out for a few minutes, its just reannotating into knit format at the moment.
<pattern> are there any tools or docs that could help me migrate projects from RCS to bazaar?
<ddaa> o.O RCS, as in /usr/bin/co ?
<mlh> where's the best place to browse bzr source?  it's not obvious (to me) how to do it in launchpad
<ddaa> mlh: https://code.edge.launchpad.net/~bzr/bzr/trunk
<pattern> ddaa: yep :)
<mlh> ah nevermind, found it
<ddaa> then click on "Browse code"
<mlh> "code" tab
<pattern> i never bothered to learn cvs... so all my personal projects are in RCS
<pattern> so now that i'm starting to get with the times, i'd like to migrate them to bazaar, if possible
<ddaa> looks like you'll have to write your own conversion tool
<ddaa> even Tailor does not appear to support RCS
<pattern> **sigh**
<mlh> pattern: you can convert from rcs with cvs2svn, then use bzr-svn
<ddaa> maybe you can find something to convert RCS->CVS, then use Tailor?
<pattern> well, can't say i'm surprised
<pattern> ah yeah, that's a good idea, mlh
<pattern> both of you :)
<mlh> rcs is close enough to cvs that you can just put some (empty) cvs crap to convince tools that your rcs is actually cvs
<mlh> there are howtos floating around somewhere
#bzr 2007-10-25
<mlh> pattern: you're not alone in avoiding cvs; I preferred rcs to cvs
<mlh> for my simple needs
<pattern> i just asked on #cvs about tools to convert RCS to CVS
<pattern> <pattern> are there any tools that i could use to migrate my RCS project to CVS ?
<pattern> <lynx> none needed
<pattern> <lynx> cvs uses rcs format for storage
<pattern> lynx> just do a 'cvs init' to create a repository, then move the ,v files in there
<mlh> yep
<pattern> well, that's simple enough :)
<mlh> I've heard it's even simpler than that
<hendrixski> hey, my friend and I are tinkering with bzr... and we both downloaded a branch from an FTP thing... and we want to merge each others stuff between our computers without having to upload to a server.  Is that possible?
<bialix> yes, you can use merge via emails
<hendrixski> bialix, merge via email?  that's awesome is there a manual you can point me about that?
<bialix> look at 'send' command
<mlh> bialix: your bzr win 0.92 is 'not found'  -- there is a exe.part
<Odd_Bloke> hendrixski: Or you could look at 'bzr serve', if you're on the same network.
<mlh> oh never mind, you were uploading.  I was too quick
<hendrixski> wow
<ddaa> I think there's even a plugin somewhere for zeroconf discovery
 * hendrixski doesn't see send in the man page
<ddaa> bzr help send
<ddaa> bzr is self-documenting
<ddaa> the man page is just to make Debian packagers happy ;)
<mlh> is there a tags command for python?
<ddaa> etags works fine with python
<ddaa> ctags probably too
<bialix> ctags rocks
<ddaa> pah, vi user ;)
<mlh> thanks, I didn't match python in the man page, but ctags --list-languages lists it.  Sorry for wasting your time :-)
<bialix> no, FTE
<mlh> FTE?
<bialix> yep
<bialix> fte.sf.net
<mlh> oh yeah
<pattern> where can i download cvsps-import ?
<lifeless> ddaa: bzr-avahi
<lifeless> pattern: the bzr plugins page has a link I think
<bialix> lifeless: your patch have landed
<bialix> night all
<pattern> the link from the bzr plugins page pointed me to:  https://launchpad.net/bzr-cvsps-import
<lifeless> right
<pattern> and from there i clicked on "Download project files"
<lifeless> oh, I don't think John has uploaded a tarball
<pattern> and it tells me "No download files are linked to this series."
<lifeless> try the devel link
<pattern> i don't see one
<lifeless> timeline - trunk
<pattern> ah
<pattern> well hidden :)
<pattern> that gives me a "Download URL" of http://bazaar.launchpad.net/~bzr/bzr-cvsps-import/trunk
<pattern> which is a broken link
<lifeless> see the word 'example' below it ?
<pattern> ah, yes
<lifeless> thats a bzr command line to download it
<pattern> ok, that worked
<pattern> thanks for holding my hand through this :)
<lifeless> n
<lifeless> np
<pattern> ok.. so, next question... now that i've downloaded the plugin, where do i put it?
<pattern> should i just copy the entire directory to /usr/lib64/python2.4/site-packages/bzrlib/plugins  ?
<pattern> there are no installation instructions in the README
<AfC> eeep
<hendrixski> and... publishing is atomic right?  so if two people are publishing (to ftp let's say) it won't confuse both of them?
<AfC> UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 7: ordinal not in range(128)
<lifeless> pattern: hmm, I thought we had generic instructions
<AfC> bzr commit --author 'Emrah  Ãnal <eunall@gmail.com>'
<lifeless> pattern: just link ~/.bazaar/plugins/cvsps to the directory you downloaded.
<ddaa> pattern: btw, "bzr branch https://launchpad.net/bzr-cvsps-import" works too
<pattern> i just found http://bazaar-vcs.org/UsingPlugins
 * AfC has been trying all morning to give credit to the guy who wrote the software that I just happen to be sticking into a repository
<ddaa> AfC: if that guy has a profile in Launchpad (there are a bunch of automatically created profiles, for packagers or translators)
<ddaa> you can set the "Author" of the branch
<poolie> AfC, i think your $LANG must be set to something that uses ascii
<lifeless> AfC: what bzr version do you have ?
<lifeless> I have a vague memory of a recent bug in the -- author support
<ddaa> Here he is https://edge.launchpad.net/~eunall
<ddaa> he's actually a real lp user :)
<hunmonk> can anybody tell me the current version of bzr that's in the ubuntu packaging system??
<hunmonk> can't seem to find that info
<poolie> packages.ubuntu.com/bzr
<lifeless> 0.91
<poolie> in hardy; 0.90 in gutsy
<hunmonk> colossus$~/bzr: bzr --version
<hunmonk> Bazaar (bzr) 0.17.0
<hunmonk> i guess it's safe to say i'm a bit behind??  ;)
<poolie> try 'apt-cache madison bzr'
<igc> morning all
<poolie> hi ian
<hunmonk> poolie: oh i'm on a mac.  i was checking for somebody else who's on ubuntu
 * hunmonk examines fink...
<igc> poolie: can we chat about the --experimental name? I'd like ot change it before 0.92
<poolie> me too
<poolie> i think 'experimental' is more an attribute of formats than a name for them
<igc> I think knit-pack or something like that is far better
<poolie> agree
<Peng> Are packs still to be considered experimental?
<lifeless> ell
<lifeless> well
<AfC> poolie: I just went through the exercise of [re]setting my terminal to take UTF-8 characters.
<lifeless> they are not a consideration-free improvement
<lifeless> so I think calling them experimental in 0.92 is fine
<igc> agreed
<AfC> and I can compose them into the command line. LANG=en_CA.UTF-8
<AfC> lifeless: bzr 0.91
<poolie> did you do 'export LANG'?
 * poolie reads the delete performance patch
<hendrixski> do you need to run a bazaar server on your computer if you want to merge across a network? we're having some problems figuring this out?
<AfC> It's set desktop wide on login by gdm et al
<igc> lifeless: can we compromise on experimental-pack say?
<igc> my fear with just plain experimental ...
<igc> is that it's way too generic
<igc> and another one called that in 2 years say ...
<poolie> sure, you might want to use that name for something else in future
<poolie> spiv, ping?
<igc> could cause confusion and breakage ...
<igc> given the name with start to appear in blogs, etc.
<igc> s/with/will/
<hendrixski> to send across a network, do you need a bzr server running on your computer?
<AfC> Try try again
<lifeless> igc: yes we can
<poolie> afc, i'll try it
<igc> thanks
<poolie> igc, what are you up to today - would you like to do a patch for format naming?
<igc> I can
<poolie> my idea would be something like this
<poolie> it's accessed by --format knitpack
<poolie> the help says it's experimental - indeed maybe there's an attribute on the format object that says it's experimental
<poolie> the format string changes
<poolie> as a straw man, maybe you should have to say eg
<poolie> bzr init-repo --format knitpack --enable-experimental
<poolie> that may be overdoing it
<poolie> or alternatively maybe it should give a notice when one is created
<lifeless> poolie: I think thats overdoing it
<igc> hmm
<lifeless> poolie: I think that just changing the text and label is sufficient for now
<lifeless> poolie: a link to the doc.bazaar-vcs.org copy of the pack repo doco in the help for it
<igc> is the idea of pack-0.92 dead?
<pattern> do i need to run "bzr init ." and/or "bzr add" before running "bzr cvsps-import" ?
<poolie> the user-orientted docs
<lifeless> poolie: yes, based on my how to dogfood mails
<igc> lifeless: what impact will changing the name have on existing dogfooders?
<lifeless> igc: zip
<poolie> pattern, i doubt you need to run add
<lifeless> igc: change their scripts is all
<igc> really? it's that clean?
<poolie> you may need to run init - try without and see if it gives an error
<lifeless> pattern: bzr help cvsps-import should be useful
<lifeless> igc: I'm not talking about changing the disk format label, only the user visible label
<igc> ah
<lifeless> igc: the disk format is 'Bazaar Experimental no-subtrees\n'
<poolie> i think we should change the disk format
<lifeless> if we change that, existing dogfooders need to edit .bzr/repository/format
<lifeless> but that is quite easy to do.
<poolie> and today, so that only a few people are disrupted
<lifeless> sure
<pattern> lifeless: thanks, but that help says nothing about what other commands i should run
<igc> poolie, lifeless: so I'm happy to put the patch up re renaming formats
<lifeless> jam-laptop: perhaps you can spare a minute to help pattern
<poolie> ok
<lifeless> jam-laptop: pattern is having some trouble figuring out cvsps-import
<pattern> i just tried running "bzr cvsps-import /path/to/my/CVSROOT myfile.c output" and got an error
<poolie> maybe you could also collect robert's notes on how to try them out
<poolie> it needs to go into some kind of extended release note i think
<igc> agreed
<igc> abentley: ping
<pattern> "Processed 0 patches (0 new, 0 existing) on 0 branches (0 tags) in 0.1s (0.00 patch/s)"
<pattern> "bzr: ERROR: cvsps did not return successfully. return code: -11 for command cvsps --cvs-direct -A -u -q --root /path/to/my/CVSROOT/myfile.c"
<abentley> Pong
<igc> abentley: any further thoughts re 'merge directive' to 'merge recipe'?
<igc> I'd like to do it
<pattern> maybe this is because i just imported my RCS project to CVS by runing "cvs init" and copying "myfile.c,v" from my RCS repository in to my CVSROOT
<igc> as a doc change as least
<lifeless> pattern: bzr doesn't version single files, only full trees.
<pattern> ah
<lifeless> pattern: try 'bzr cvsps-import . output'
<pattern> ok
<abentley> igc: It's my favourite out of the things we discussed.
<igc> it's good I think ...
<lifeless> pattern: also, you need cvsps installed
<abentley> I wouldn't change the default format marker.
<igc> like a normnal recipe, the 'diff' is a picture of the end result. :-)
<pattern> cool, that seems to have worked
<pattern> yeah, i installed cvsps
<igc> abentley: agreed
<lifeless> abentley: default format marker ?
<igc> just the external name as the plan
<igc> s/as/was/
<abentley> lifeless: The format marker used for merge directives.
<pattern> ok, now that i've seemed to have successfully imported my old RCS project, on to actually learning bazaar!
<pattern> thanks everyone!
<abentley> I wouldn't change it to use the string "merge recipe" instead.
<abentley> But I would consider adding non-default support for that.
<igc> I was planning to leave the old merge-directive cmd untouched as well
<pattern> and, btw, the command had to be "bzr cvsps-import /path/to/my/CVSROOT . output"
<abentley> igc: Yes, that makes sense.
<igc> poolie, lifeless, jam-laptop: any objections to renaming 'merge directive' to 'merge recipe' at the UI level (bar the old cmd) ?
<igc> I want to stop talking about bundles
<poolie> hm
<igc> and say 'merge recipe' instead
<poolie> i agree a better name would be better
<poolie> i'm not 100% happy with 'merge recipe' for two reasons
<poolie> - it's maybe still a bit cute
<poolie> - more important, it suggests it's going to be just "merge $chocolate into $bowl" whereas in fact it normally carries the revisions with it
<poolie> though i guess aaron's framework does allow it to be just the instructions
<igc> the metaphor of a pre-mix cake isn't far off
<poolie> indeed - recipe plus ingredients
<igc> you get the recipe and the ingredients
<poolie> and a mediocre-to-ok cake :)
<igc> but only the recipe is mandatory
<igc> so that's why I favour 'merge recipe' over 'merge pack' say
<lifeless> I'm nonplussed by all this
<lifeless> cart is looking quite nice
<lifeless> I think its great to have an answer to trac for bzr projects that don't want to use lp
<poolie> is that a sequiter or not?
<lifeless> non
<poolie> is 'merge request' already struck out?
<hunmonk> quick question: my version of bzr is using knits.  is there a newer branch format now?
<lifeless> I'm not going to enter into the discussion other than to note that 'merge directive' works fine for me and I've not seen anyone confused by it
<pattern> ok.. more stupid questions...   "bzr cvsps-import /path/to/my/CVSROOT . output" created an "output" directory (with "bzr" and "staging" as subdirs)... so, what do i do with this output directory to get bzr to recognize it as a repository?  where do i put it?  do i need to cd in to it to use it?
<poolie> hunmonk, there is a new experimental repository format, 'packs'
<poolie> it is in bzr.dev and will be in 0.92
<poolie> if you'd like to try it and give feedback that would be great
<hunmonk> poolie: will it be the default in 0.92
<hunmonk> ?
<poolie> not in 0.92
<hunmonk> hm.  fink is still at 0.18-1...
<lifeless> pattern: you can cd into it
<lifeless> pattern: if your files are not present in the output dir, its a tree-less repository, try 'bzr checkout .'
<lifeless> pattern: or it may be that the cvsps-import wants modules, in which case doing 'mkdir project && mv myfile.c,v project' in your CVS repo and converting via
<pattern> would i type "bzr checkout ." while i'm cd'ed in to "output" ?
<lifeless> cvsps-import ...CVSROOT project output
<lifeless> pattern: yes, I think so
<pattern> bzr: ERROR: Not a branch: "/path/to/output"
<pattern> that's from "bzr checkout ."
<pattern> earlier i had copied myfile.c,v to /path/to/my/CVSROOT before running "bzr cvsps-import /path/to/my/CVSROOT . output"
<poolie> abentley, the cart site looks really nice
<abentley> Thanks, poolie.
<poolie> though http://cart.aaronbentley.com/issue/26 does remind me, in the fondest way, of C64 BASIC line-renumbering tools
<pattern> which told me "Creating cvsps dump file: output/staging/ROOT.dump" and "Read 4 patchsets (string cache hits: 0, total: 25)"  "Processed 4 patches (4 new, 0 existing) on 0 branches (1 tags) in 0.3s (14.40 patch/s)"
<abentley> poolie: Yeah, that's actually what I'm working on now.
<poolie> but i kind of wish launchpad had something like that - just 'importance' is a bit coarse
<poolie> is the frontpage just static text?
<abentley> I *think* this is a clear way of providing priority ranking.  The alternative would be a linked list.
<abentley> The front page is rendered from a ReST file and shoved into a template.  So the *file* is static, if that's what you mean.
<lifeless> 10:10 < lifeless> cart is looking quite nice
<lifeless> 10:10 < lifeless> I think its great to have an answer to trac for bzr projects that don't want to use lp
<abentley> But it's actually dynamically generated.
<lifeless> abentley: ^ ;)
<abentley> lifeless: Coolness.
<abentley> poolie: the argument against "merge request" was that a merge request is actually the email that you send to the list, not the attachment the email contains.  But I suppose we could use that...
<spiv> poolie, lifeless: just sent a bundle for 155730 to the list.
<poolie> abentley, well, it would be neat if you could just drag them around in the browser...
<abentley> poolie: Yeah, I want to support that too.
<poolie> gah
<poolie> it's pretty annoying that there are several similar implementations of, say, unlock in remote.py :-/
<spiv> Yeah :/
<poolie> spiv, lifeless: so, remoterepsoitoyr.unlock
<igc> lifeless: just confirming, experimental supports tags doesn't it?
<lifeless> igc: different layers
<igc> let me ask differently ...
<poolie> (igc, but yes, it does)
<igc> compatible with dirstate-tags?
<poolie> rr.unlock does the unlocking twice: once at the vfs level, once at the rpc level
<lifeless> igc: yes, the branch format referred to by the experimental label is the tags format.
<igc> that's how I remembered it from the review. Thanks
<poolie> at present, if the vfs unlock fails, the rpc unlock is not done - this seems strange to me
<poolie> any comments?
<spiv> Hmm.
 * spiv looks
<poolie> about line 500
<spiv> Yeah, that is a little weird I guess.
<spiv> I guess ideally the self._real_repository unlock shouldn't be able to fail, we're only invoking it to keep the state of the self._real_repository object in sync with the state in RemoteRepo.
<spiv> We don't expect _real_repository.unlock() to actually remove the lock, because we acquired it with a lock_token.  And we're about to try the real unlock via a remote method.
<pattern> when i type "bzr checkout ." in /path/to/output i get an error: "bzr: ERROR: Not a branch: "/path/to/output""
<pattern> how would i list the branches bzr knows about?
<spiv> So letting _real_repository.unlock() do any work at all is just inviting failures (and roundtrips) for no real benefit.  (except for the benefit of leaving the locking API unchanged...)
<AfC> pattern: branches are all peers and independent. When a branch has a relationship to another you can see it with `bzr info`
<poolie> pattern, you need to cd into one of the branch directories
<poolie> or run 'bzr info BRANCH_DIR'
<poolie> spiv, ok, so now that we have write groups
<poolie> it can fail, if for example the write group is not finished
<poolie> and, in general, you know it is a method that can fail
<poolie> and there are the round trips as you say
<spiv> poolie: but it's still correct to say that any failure that would happen would also happen on the RemoteRepository._unlock() instead?
<poolie> spiv, well, no, it currently delegates its write groups entirely to the real repository
<lifeless> so
<lifeless> write groups are not something that should cross the wire IMO
<lifeless> we should 'buffer' the data and do a single insert over the wire
<lifeless> where buffer currently is 'write to the remote location an upload pack', but could mean 'buffer in /tmp'
<poolie> "not cross the wire" in the sense of there's no write-group related rpc
<poolie> i agree
<lifeless> right
<poolie> hm
<poolie> spiv, when you say that real_repository.unlock shouldn't touch the lock
<poolie> hm
<spiv> Well, _real_repository.unlock should leave the lock in place.
<poolie> is that because the lock will ultimately be removed by the _unlock call being passed to the server and releasing it there
<spiv> Because a lock_token was passed to _real_repository.lock_write
<spiv> Right.
<spiv> We only call lock_write/unlock on _real_repository to keep its knowledge of the lock state in sync with what's happened at the RPC layer.
<poolie> hm
<poolie> maybe we could arrange for them to share a lock object or something
<poolie> not right now
<spiv> So that it won't e.g. try to acquire a new lock for the repo when the repo is already locked by RPC.
<lifeless> poolie: they are sharing a lock object - thats the lock token concept
<lifeless> poolie: its a shared lock across the wire
<poolie> sure
<poolie> my point is, unlock() has several effects
<poolie> so it's a bit of a blunt instrument for telling the vfs repo "be aware i've unlocked you"
<spiv> Well, my reconcile fix completes on bzr.dev without blowing up, that's a good sign...
<lifeless> spiv: can you: init --experimental foo; cd foo; bzr pull ../reconciled-bzr.dev; bzr push ../new-dir
<lifeless> spiv: where foo is *not* within a shared repo
<spiv> lifeless: Will do.
<spiv> I've just verified that the relevant kndx now has a fulltext for that record.
<spiv> (And now has only 2 versions of that file; the other 10 were never referenced by anything and so the new reconcile removes them.  Brings du -hs .bzr/repository down from 73M to 71M, even with the extra fulltexts.)
<spiv> lifeless: it'd be nice if push actually gave a progress bar...
<lifeless> spiv: yes, but its so fast who cares? :]
<spiv> lifeless: well, here's the funny thing... it isn't.
<lifeless> spiv: initial local branch spends a lot of time ungzipping
<spiv> lifeless: 2m 42s real, mostly spent on CPU...
<spiv> Ah.
<spiv> I was starting to wonder if my reconciled repo had sent it off into an infinite loop somehow.
<spiv> lifeless: so, those commands all appeared to work.
<lifeless> cool
<lifeless> thats the acid test
<spiv> lifeless: I have 61M of repo data according to du -hs, and all appears to be well.
<spiv> (I guess the 10M reduction is partly due to the lack of annotations?)
<lifeless> yes
<pattern> ok, well, looks like cvsps-import isn't working for me, so i'm giving tailor a try
<pattern> but tailor tells me "Common base for tailor exceptions: 'bzr' is not a known VCS kind: cannot import name compare_trees"
<pattern> the only thing i could find through google on this error says it could be due to using python 2.3 instead of 2.4, but i'm definitely using 2.4
<pattern> 2.4.4, to be exact
<pattern> ok... a completely unrelated question...
<pattern> when i do a "bzr init", is all the data that bzr needs stored in the "./.bzr" directory?
<jam-laptop> pattern: I just came back, I can try and help you with cvsps-import
<jam-laptop> (I would generally recommend it over tailor)
<pattern> or does "bzr init" modify data elsewhere on my filesystem (as in somewhere around where it was installed, for example in "/usr/lib64/python2.4/site-packages/bzrlib") ?
<pattern> ok, cool
<jam-laptop> pattern: generally we only store data in .bzr/*
<pattern> great
<jam-laptop> pattern: so what are you trying to do?
<jam-laptop> the only other place might be $HOME/.bazaar/*
<jam-laptop> for your configuration files, etc.
<pattern> well, i'm trying to migrate my RCS repository to bazaar
<jam-laptop> RCS or CVS?
<pattern> RCS
<jam-laptop> hmm...
<pattern> someone on #cvs told me all i had to do was do a "cvs init" and then copy my ,v files from RCS in to my CVSROOT directory for me to migrate from RCS to CVS
<pattern> which is what i did
<jam-laptop> pattern: does "cvs -d CVSROOT rlog", etc work?
<jam-laptop> (I can see that it could, but I'd check that first)
<pattern> yes, it works
<pattern> rlog does, anyway
<jam-laptop> ok, and do you have "cvsps" installed?
<pattern> yep
<pattern> and the first time i tried cvsps-import, it actually didn't give me an error, and seemed to work... and i got an output directory
<jam-laptop> And you have cvsps-import installed ~/.bazaar/plugins/
<jam-laptop> as something like
<pattern> but then i couldn't get bzr to work with it
<jam-laptop> "cvsps_import"
<jam-laptop> ok, the output directory should have several things going on
<pattern> and now i've deleted and recreated my output and CVS directories a million times, trying to get this to work, and now i always get errors from cvsps-import
<pattern> yes, i have the plugin installed in ~/.bazaar/plugins
<pattern> and bzr recognizes the command, and runs it
<jam-laptop> give me a couple of seconds to remember all about cvsps-import.
<jam-laptop> But I'm guessing you were trying to do something with the top-level
<jam-laptop> when the actual data is lower down
<jam-laptop> I split the target directory into 2 paths
<jam-laptop> one is for the conversion data
<jam-laptop> (stuff cvsps needs to keep track of, but you don't need after the conversion)
<jam-laptop> well, cvsps-import needs to keep track of
<jam-laptop> also, if you are messing with your cvs repo
<jam-laptop> you should delete the cvsps cache
<jam-laptop> in ~/.cvsps
<pattern> ah!
<pattern> i knew there must have been something cached somewhere
<jam-laptop> So when you run the conversion, there will be a bzr repository in "OUTPUT/bzr"
<pattern> ok.. this might work better now
<jam-laptop> and individual branches in
<jam-laptop> OUTPUT/bzr/branches/
<jam-laptop> the important one being
<jam-laptop> OUTPUT/bzr/branches/HEAD
<pattern> ok, great, no errors now
<jam-laptop> oh, sorry
<jam-laptop> OUTPUT/bzr/MODULE/branches/HEAD
<jam-laptop> the repository is at OUTPUT/bzr/MODULE
<jam-laptop> you should be able to
<pattern> i just did "bzr cvsps-import /path/to/CVSROOT . output", so i have "output/bzr/branches"
<jam-laptop> bzr checkout --lightweight OUTPUT/bzr/MODULE/branches/HEAD my-project
<jam-laptop> so that would be
<jam-laptop> or at least do
<jam-laptop> bzr log output/bzr/branches/HEAD
<jam-laptop> lifeless: I see you went with the tree of dicts, have you had nDuff play with it to see if it fixed his problem?
<pattern> from "bzr log output/bzr/branches/HEAD" i get "bzr: ERROR: Not a branch: "/FULLPATH/output/bzr/.bzr/branch/"
<jam-laptop> hmm.. I wouldn't expect output/ to be considered a branch
<pattern> where "/FULLPATH/output" is the full path to the "output" directory
<jam-laptop> sure
<jam-laptop> what does the output of
<jam-laptop> ls -al output/bzr/branches give?
<jam-laptop> (It seems like it isn't finding a branch at .../branches/HEAD)
<pattern> oops, i just noticed that when i ran "bzr log output/bzr/branches/HEAD" i was already in "output/bzr"  :)
<pattern> sorry
<pattern> now when i'm in the parent directory of "output" it works
<pattern> you still there, jam?
<jam-laptop> yeah, just had to do something real quickx
<pattern> no problem
<jam-laptop> so, it sounds like it worked just fine, we just need to explain how things are laid out
<pattern> so, since it seems to work, where should i put these bzr files?
<jam-laptop> to start with, bzr branches are always referenced by path
<pattern> i don't need the output/staging stuff
<jam-laptop> right
<jam-laptop> all you need is the bzr/* stuff
<pattern> ok
<pattern> so should i put that in ./.bzr ?
<jam-laptop> can you confirm that there is output/bzr/.bzr/repo
<jam-laptop> output/bzr/.bzr/repository
<pattern> output/bzr/.bzr/repository exists
<jam-laptop> pattern: ok, that is your Bazaar "shared repository"
<jam-laptop> So I would usually do something like
<jam-laptop> mv output/bzr /srv/project-repository
<jam-laptop> well, I would call it "project-repo" or something like that
<pattern> hmm... well, it's just me here.. so my machine is my server...
<pattern> so you recommend creating a central repository for all of my projects?
<jam-laptop> I recommend it, but it certainly isn't required
<jam-laptop> You might want to read a bit about what Bazaar lets you do
<pattern> i'll definitely go by the recommended way, at least while i'm learning :)
<jam-laptop> http://bazaar-vcs.org/Workflows has a few hints
<pattern> cool
<jam-laptop> because there isn't a one-size fits all
<pattern> so, could you tell me how the ./.bzr directory relates to the central repository?
<pattern> i'll definitely check out the link too, btw
<pattern> i've already started reading the user guide
<jam-laptop> So in Bazaar you have 3 basic objects
<jam-laptop> Repository, Branch, WorkingTree
<pattern> right, i remember that from one of the tutorials
<jam-laptop> a Repository is where the bulk of the history data is stored (all the different versions of the file texts, etc)
<jam-laptop> In your conversion
<jam-laptop> that is the "bzr/.bzr/repository"
<jam-laptop> well "output/bzr/.bzr/repository"
<jam-laptop> though you would reference it by "output/bzr"
<pattern> ok
<jam-laptop> Then you have branches, which are pointers into this repository
<jam-laptop> which are in "output/bzr/branches/*"
<jam-laptop> The converter doesn't actually create a WorkingTree
<jam-laptop> Because it just extracts things into memory and writes them out.
<pattern> so the WOrkingTree isn't the directory you're working in?
<jam-laptop> So at this point, you want to create one
<jam-laptop> pattern: it is the directory you *will* be working in
<jam-laptop> where you see all of your projects files
<jam-laptop> If you want the simple way, I would do
<pattern> just one project's files? or all the project's files?
<pattern> i mean
<jam-laptop> well, if you converted from the top, then you get all projects
<jam-laptop> in 1 bazaar project
<jam-laptop> you may want to convert module by module
<pattern> one project's files, or all the projects' files?
<pattern> :)
<jam-laptop> You converted the "." module
<jam-laptop> which is the whole cvs repository
<pattern> right
<pattern> and that makes up one project
<pattern> so in my WorkingTree i'll get everything in that project, right?
<jam-laptop> correct
<pattern> but if i check in more projects...
<pattern> then will i get all the projects' files in my WorkingTree?
<jam-laptop> pattern: so generally projects are separated at the "Branch" level
<pattern> or will i have a separate WorkingTree for each project?
<jam-laptop> And you would have a separate WorkingTree for each
<pattern> so there's a single repository, but many branches (one for each project) ?
<jam-laptop> pattern: as many branches as you want for each project
<jam-laptop> as many projects as you want in the repository
<pattern> ah, ok
<jam-laptop> some people prefer to create a separate repository for each project
<pattern> so a WorkingTree for each branch
<jam-laptop> *I* tend to mix and match
<jam-laptop> unrelated projects get separate repositories, related projects share repositories
<pattern> hmm
<pattern> could i migrate branches from repository to repository?
<jam-laptop> pattern: it is just a "bzr branch repo1/branch repo2/branch"
<jam-laptop> pattern: branches float from repo to repo all the time
<pattern> and will i ever check out entire repositories?  or do people generally check out just a single branch at a time?
<jam-laptop> just a single branch at a time (at the moment)
<pattern> ok, so the choice of whether to have separate repositories or not is simply a matter of how you want to organize your data
<jam-laptop> (we are working on ways to make one branch reference another, so checking out one, checks out others.)
<jam-laptop> pattern: exactly
<pattern> kind of like directories on a regular file system
<jam-laptop> very much like directories on a filesystem
<jam-laptop> http://bazaar-vcs.org/SharedRepositoryLayouts
<pattern> cool
<jam-laptop> Some "recommended" layouts
<pattern> ok... back to the output directory, for a second
<jam-laptop> k
<pattern> let me just get this all in my head...
<pattern> so the output/bzr directory is a repository, right?
<jam-laptop> correct
<pattern> and ./.bzr is what?
<jam-laptop> I don't know what is in ./.bzr, did you do "bzr init" manually?
<pattern> yeah
<jam-laptop> ok, you just created what we call a "standalone branch"
<jam-laptop> which is a Branch, WorkingTree, and Repository all in the same location
<pattern> interesting
<jam-laptop> at this point you could just rm -rf ./.bzr/
<pattern> ok
<jam-laptop> but if you want to poke at it
<jam-laptop> you can ls .bzr/
<jam-laptop> and you should see a "repository"
<jam-laptop> and a "checkout"
<jam-laptop> and a "branch"
<jam-laptop> subdirectory
<pattern> so, say i "mv output/bzr /path/to/my/brand/new/central/repository"
<jam-laptop> k
<pattern> i suppose once i set some environment variable, bzr will know to look there for its files
<jam-laptop> actually, we generally always use full paths
<pattern> and then i can just check in new projects as usual?
<jam-laptop> (we don't have a repository env var, because you usually have many of them)
<jam-laptop> So the big difference is doing
<jam-laptop> bzr checkout /path/to/repository/foo
<jam-laptop> rather than "bzr -d/path/to/repository checkout foo"
<pattern> but that could be an alias, i guess
<jam-laptop> pattern: sure, you can use "bzr checkout $REPO/foo
<pattern> or "alias XYZcheckout='bzr checkout /path/to/repo'"
<pattern> but, my main question is whether i can just use the output/bzr repository as my central repository
<jam-laptop> sure
<pattern> cool
<pattern> so new projects can be checked in to there?
<jam-laptop> just that "output/bzr" is probably not the optimal name for it :)
<jam-laptop> pattern: yep
<pattern> great
<pattern> earlier you had me do "bzr log output/bzr/branches/HEAD"
<jam-laptop> right
<pattern> is there a way to specify that i just want the log for a given project?
<pattern> or a given file?
<jam-laptop> ... isn't that for the project?
<pattern> well, it's not called "HEAD"
<pattern> :)
<jam-laptop> You can do "bzr log output/bzr/branches/HEAD/filename"
<pattern> ah, i see
<jam-laptop> HEAD is the name of the branch of your project
<jam-laptop> That is CVS's terminology
<pattern> ah
<jam-laptop> you can "mv HEAD project"
<jam-laptop> if you prefer
<pattern> wonderful
<pattern> ok, this is making much more sense now
<jam-laptop> As long as you keep the branch inside it's repository
<pattern> thank you, jam
<jam-laptop> you can rename it to whatever you want
<jam-laptop> so you can move the branches, etc around
<jam-laptop> so that they make sense to you
<pattern> and no metadata changes needed to inform bzr of my name change?
<jam-laptop> correct
<pattern> awesome
<pattern> so, i think i'm going to go and read up some more on how bzr works
<pattern> thanks again!
<jam-laptop> pattern: happy to help
<jam-laptop> Feel free to stop by when you have questions
<jam-laptop> someone is usually around :)
<pattern> oh, and by the way, the "Download project files" link on https://launchpad.net/bzr-cvsps-import says "No download files are linked to this series."
<Odd_Bloke> I wonder if LP's error message would be better pointing people to available branches/project home pages...
<pattern> it turned out i had to click on the "trunk" link in the bottom of the main page, under "Timeline"
<pattern> and then click on "Main development branch of cvsps import"
<igc> poolie, lifeless: pack renaming patch send to the ML
<igc> s/send/sent/
 * igc food
<pattern> and then use the command listed in "Example" to download cvsps-import
<pattern> which isn't very intuitive
<pattern> if i didn't have help from this channel, i don't think i would have figured it out on my own before i gave up in frustration
<poolie> igc, thanks
<pattern> and the other thing is that the README file does not contain installation instructions
<poolie> pattern, well, i'm glad you could get help here
<poolie> the download files feature is still new and i agree it's not very obvious yet
<poolie> in fact i have a bug open ...
<pattern> i had to move "trunk" to ~/.bzr/plugins/cvsps"
<pattern> poolie: yeah, the help in here is fantastic
<pattern> i really appreciate it
<poolie> see bug 139052
<ubotu> Launchpad bug 139052 in launchpad "link to project downloads from the project home page" [High,Confirmed] https://launchpad.net/bugs/139052
<pattern> any bug for detailed installation instructions?  :)
<pattern> might save you some work explaining this all over again to the next guy who tries to install cvsps-import
 * Odd_Bloke has also just filed Bug #156919.
<ubotu> Launchpad bug 156919 in launchpad "More information on where to download files needed" [Undecided,New] https://launchpad.net/bugs/156919
<pattern> not just where to download them, but a couple of simple things like: "To install, 'mv trunk $HOME/.bzr/plugins/cvsps"
<pattern> and "'output/bzr' will be your repository.  you can access it by, for example, typing 'bzr log output/bzr/branches/HEAD'"
<pattern> oh yeah, and maybe a suggestion to delete the cvsps cache ($HOME/.cvsps) if you run in to problems
<Odd_Bloke> Heh, poolie in before my suggesting a bug report. Bug #156920.
<ubotu> Launchpad bug 156920 in bzr-cvsps-import "cvsps-import readme needs install instructions" [Undecided,New] https://launchpad.net/bugs/156920
<pattern> ok... i think i'm done suggesting :)
<pattern> thanks for writing a useful tool
<pattern> and for the great support
<poolie> you're welcome
<poolie> tell your friends! :)
<pattern> i will!
<poolie> off for lunch and pre-trip foo
<jam-laptop> poolie: you leave tomorrow, right?
<jam-laptop> poolie: good luck
<poolie> yeah, i'll be at the airport this time tomorrow
<poolie> thanks
<jam-laptop> have a safe and restful flight :)
<poolie> thanks
<jam-laptop> We missed our call this week, but I think it's not a big deal
<poolie> yeah, we talked friday?
<jam-laptop> sounds right
<poolie> how's stuff? i've seen you posting more again
<jam-laptop> things are going pretty well
<jam-laptop> just working on going through the critical bugs
<jam-laptop> and fixing that old dirstate bug
<jam-laptop> fullermd sure likes to do crazy stuff
<ubotu> New bug: #156920 in bzr-cvsps-import "cvsps-import readme needs install instructions" [Undecided,New] https://launchpad.net/bugs/156920
<Odd_Bloke> ubotu: ORLY?
<ubotu> Sorry, I don't know anything about orly? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Odd_Bloke> Â¬.Â¬
<poolie> jam-laptop, i think when andrew's reconcile patch and igc's format name patch are in we can do an rc
<poolie> anyhow, i should really go
<poolie> have a good night, talk to you next week
<lifeless> jam-laptop: he hasn't played with it yet AFAIK
<lifeless> nDuff: ping
<fullermd> It's not my fault.  The Internet made me do it.
<igc> lifeless: re your idea re referring to the pack doc in the help, what name do you think that doc ought to have?
<igc> e.g. ..
<igc> NEWS.0.92
<igc> Using Packs
<igc> en/user-guide/using-packs.html?
<igc> other???
<igc> I could just say the -using-packs help topic and ...
* mthaddon changed the topic of #bzr to: LP going down in 15 mins for approx 1 hour for update - The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<igc> extend help to lookup unknown topics in en/user-guide?
<igc> I like that idea myself by YMMV for others
<lifeless> igc: http://doc.bazaar-vcs.org/...
<lifeless> igc: for now the reference packs doc that already exists is good; thats the one that I think the how to dogfood stuff should go in
<lifeless> igc: help is planned to support references to the docs. e.g. 'seealso= ['userguide/foo.txt']' already works.
<igc> lifeless: developers/knitpack.txt you mean?
<lifeless> igc: right, so http://doc.bazaar-vcs.org/en/latest/developers/knitpack.txt
<lifeless> or whatever it is
<igc> cool
<igc> thanks
<lifeless> mthaddon: why the topix change? Its not really relevant here is it ?
<mthaddon> lifeless, if you're not interested I'll take it off the list for next time - I can change it back if you like
<lifeless> well, if poolie hasn't asked for it, I would say we're not that interested
<mthaddon> (I mean if it's not relevant to this channel)
<mthaddon> ok, fair enough - thx
<lifeless> not that we don't use launchpad, but checking #launchpad is really quite easy
* mthaddon changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<mthaddon> cool, thx
<mthaddon> one less thing for me to remember to change back afterwards :)
<pattern> when i type "bzr status foo" then bzr returns without any output
<pattern> foo is an existing file which i checked in via cvsps-import
<pattern> shouldn't "bzr status foo" tell me that foo was added?
<nDuff> lifeless: I'm still not seeing anything newer than 2852 in the knits-based tree.
<spiv> pattern: if there's no output, then that file hasn't changed since the last commit.
<spiv> pattern: i.e. that version of foo is already committed
<pattern> is there a way to see what files are versioned in a given branch?
<lifeless> nDuff: hmm, let me check
<Odd_Bloke> pattern: bzr ls --versioned
<lifeless> nDuff: 2856 is there; perhaps you have an aggressive cache ?
<lifeless> pack-repository.knits $ bzr revno
<lifeless> 2856
<pattern> cool
<pattern> thanks
<pattern> hmm... i have a directory "CVSROOT" which i wanted to remove from bzr, so i typed "bzr remove CVSROOT"
<pattern> and it said it deleted that directory and all the files in it
<pattern> but when i do "bzr checkout ~/bzr/branches/myproject", it still checks out CVSROOT and all the files in that directory
<poolie> (back)
<pattern> oops, i mean "bzr checkout ~/bzr/branches/myproject ."
<spiv> pattern: did you commit after your removed CVSROOT?
<pattern> ah
<pattern> nope
<pattern> alright.. that works now :)
<pattern> groovy
<pattern> i like this system already
<pattern> nice and simple
<pattern> intuitive
<pattern> command line drive
<pattern> driven
<poolie> igc, lifeless, i'd expected the commandline name for the format would not say '-experimental'
<poolie> so that it would be stable once it is released
<poolie> i mean, once it is nonexperimental
<igc> well, I had that in my 1st patch and ...
<poolie> i saw, robert objected
<poolie> i'll just reply by mail
<poolie> i don't want to flap about it
<igc> I agree with lifeless that it's proably safer to name it -experimental in 0.92
<poolie> ok
<nDuff> lifeless: oh -- forgot that I unbound.
 * nDuff does a pull rather than an update, and all's well.
<lifeless> poolie: we can remove -experimental from the human name in 0.93
<lifeless> poolie: and the disk format does not say experimental
<poolie> it's ok
<poolie> >>Launchpad is offline for scheduled maintenance. We should be back soon.
<poolie> feh
<lifeless> oh btw
<lifeless> mthaddon updated the topic here,w hich I thought was fairly uninteresting for bzr folk
<lifeless> conversation should be in your scrollback
<pattern> RCS has a feature where you can write "$Revision: $" and "$Date: $" anywhere in a file, and when you check out that file, RCS will automatically insert the version and date before the last "$" in the respective parts of the file
<pattern> is there anything like that in bzr?
<pattern> or, bazaar, rather :)
<spiv> pattern: no, we don't have keyword substitution, although it gets discussed from time to time.  (e.g. at http://bazaar-vcs.org/KeywordExpansion)
<pattern> ah, ok
<pattern> i guess i can live without it :)
<pattern> but would be nice
<pattern> looks like there's a plugin to do the version, though
<pattern> i'll try it
<lifeless> pattern: its in core
<lifeless> pattern: bzr version-info
<pattern> oh, it is
<pattern> i see it's not quite the same, though
<pattern> it doesn't actually modify the file in question
<Odd_Bloke> poolie: When LP's back up (which it partially is now) throw me a link to the bug in question.
<pattern> it just outputs version information, and it's up to you to do what you want with it
<Odd_Bloke> pattern: Potentially you could use that and a commit hook, but I expect it would be complex.
<pattern> just a bit of keyword substitution
<pattern> or just run m4 on it
<pattern> not that i know m4
<pattern> but it can't be that hard
<pattern> anyway, that's a project for another day
<pattern> i'm still learning basic bazaar... don't want to jump in to writing commit hooks already
<pattern> thanks for the suggestion, though :)
<igc> poolie: abentley feels pretty strongly about keeping the subtrees stuff pretty hidden for now
<igc> are you sure you want knitpack-subtrees-experimental mentioned in NEWS?
<lifeless> nDuff: how does it perform now ?
<igc> poolie: in case you missed my Q ...
<igc> abentley feels pretty strongly about keeping the subtrees stuff pretty hidden for now
<igc> are you sure you want knitpack-subtrees-experimental mentioned in NEWS?
<poolie_> igc, it can be mentioned as "for people who are testing the prototype subtree support, you can test xxxx"
<igc> ok
<poolie_> put as many warnings on it as you/abentley feel is appropriate
<poolie_> do you think he'd disagree with this?
<abentley> It is okay
<igc> thanks
<igc> the main user base seems to be bzr-svn users right now
<lifeless> btw, abentley igc jam-laptop poolie_ - I've written a possibly inventory serialisation change proposal to the list
<poolie_> lifeless, i'm reading it
<lifeless> input/critique valued
<poolie_> it's interesting
<fullermd> pattern: You probably shouldn't hvae had the CVSROOT dir in the conversion in the first place...
<poolie_> i probably should not spend as much time on it as it deserves, so as to review anything else for .92
<igc> saw that lifeless - shall get to it soon :-)
<lifeless> read it on the plane :)
<lifeless> it's probably not something I'll get off the plane with.
<lifeless> it might be a tad big. Or maybe not.
<poolie_> i was a bit worried about a fait accompli
<poolie_> :)
<poolie_> well, 'worried' is not quite right
<lifeless> hey, we have a review process :)
<pattern> fullermd: yeah, i agree... i think i got via cvsps-import because i had done a "cvs init"
<lifeless> poolie_: hopeful would be a good word :)
<pattern> fullermd: maybe if i just deleted the "CVSROOT" subdirectory out of my $CVSROOT directory before doing the cvsps-import, then i wouldn't have it in my branch
<lifeless> pattern: I think making a subdir will work
<lifeless> pattern: in the dir that CVSROOT is in, mkdir 'project'
<lifeless> pattern: then move your ,v files into project
<lifeless> pattern: and import again, passing 'project' rather than '.'
<lifeless> pattern: also, please file a bug :)
<pattern> yeah, i had tried that before.. and thought it didn't work, but at the time i didn't know how to really check if it worked properly
<pattern> so that may well work.. and i might try it again
<pattern> i will file the import of the CVSROOT directory as a bug
<fullermd> Well, if you delete CVSROOT, it's not a CVS repo anymore.
<fullermd> Only way I could imagine getting it in the conversion would be if you tried to convert the root of the repo into a bzr branch, though.  And that would be nonsensical.
<lifeless> fullermd: thats what he did
<lifeless> fullermd: and it makes perfect sense; modules are convention in cvs
<fullermd> You'd really only want to import a module (or part of a module).  Of course, if you never made the RCS->CVS jump, that sounds gibberish...
<lifeless> fullermd: having a cvs repo that has one module '' is fine, works well.
<fullermd> Well, yes, but it's an awful strong convention (made only stronger by the fact that CVSROOT is one of them)
<fullermd> "one module" != "files in the root".
<fullermd> Dealing with files outside of a module in CVS is rushing in where angels fear to tread.  I don't think you CAN do it at all without at least some initial hand-hackery.
<lifeless> fullermd: dude its totally trivial
<lifeless> fullermd: it is in fact the defalt mode of operation
<pattern> well, what i did was "export CVSROOT=/path/to/myproject/CVS ; mkdir $CVSROOT ; cvs init ; cp /path/to/myproject/RCS/*,v $CVSROOT ; bzr cvs-import $CVSROOT . output"
<lifeless> fullermd: 'cvs -d ...ROOT co . project'
<fullermd> trivial doesn't mean sensible.  Any setup which ends up with CVSROOT as a directory in your branch along side your working files I'm willing to declare insensible in the absence of extraordinary evidence that it's intended.
<lifeless> fullermd: :)
<pattern> so, after "cvs init ; cp /path/to/myproject/RCS/*,v $CVSROOT" the contents of $CVSROOT were my RCS/*,v files and the "CVSROOT" directory
<fullermd> pattern: Right.  In the CVS idiom, those ,v files would actually all be in $CVSROOT/myproject (or some similar name)
<pattern> so why import $CVSROOT/CVSROOT ?
<fullermd> You wouldn't.  It's just part of the structure of a CVS repo.
<fullermd> (well, I can conceive of cases where someone _might_, but they're really wacko, and _you_ wouldn't)
<pattern> so couldn't cvsps-import just ignore it and not import it?
<fullermd> You'd import $CVSROOT/myproject into a bzr branch.
<pattern> yep
<fullermd> That would probably be over-smartness on its part.  You could have a dir called CVSROOT inside your project, for instance.
<lifeless> bleh
<lifeless> file a bug
<fullermd> (unrelated to a CVS repo's CVSROOT magic dir)
<lifeless> let john worry
<pattern> well, aren't there some special files in CVSROOT that only CVS puts there?
<pattern> a whole bunch of files, actually
<pattern> and they're pretty standard for CVS
<pattern> so, if they're in there, and nothing else is there, then i'd say it's safe to delete the directory
<pattern> but i think odds are no one's going to have a CVSROOT directory in their $CVSROOT unless it was put there by CVS
<fullermd> They are.  But I'd consider magically seeing files with those names in that directory way too DWIMish for something as important as a conversion (unlikely as the trigger case may be)
<pattern> in which case, it's safe to delete it
<pattern> no, not just names, you could check contents too
<pattern> but even the names would be enough
<pattern> it's almost like an md5 :)
<fullermd> Really, I think the bug is "cvsps-import shouldn't allow importing the root of a repo"
<pattern> what are the odds of having 20 files with the exact name that CVS uses in a directory called CVSROOT and not have them be put there by CVS ?
<lifeless> fullermd: actually, cvsps-import should be easier to use
<lifeless> guys, this is a non argument.
<fullermd> I can conceive of cases where I'd have something looking exactly like a real CVSROOT in a tree, and I'd be royally honked off if a VCS imported dropped my data on the floor because of a heuristic like that.
<pattern> i guess that's concievable
<lifeless> fullermd: OTOH the only reason you'd do that is to cause trouble.
<pattern> but it's even more conceivable that you wind up importing junk 99.99999% of users don't need
<fullermd> lifeless: Well, that's my specialty, isn't it?   :p
<lifeless> fullermd: because, by definition, CVS will consider that to be a repository itself.
<fullermd> Not really, because You-the-CVS-user wouldn't want to import the root of a repo as a branch, so...
<pattern> that's true
<fullermd> At least, not without --force or something, in which case You(tm) presumably _would_ want the CVSROOT versioned.
<pattern> but you'd still want to ignore CVSROOT
<fullermd> I'm willing to demote the "I want to convert the root of my repo into one branch, EXCEPT not CVSROOT" case into some rebase-with-filter territory.
<fullermd> I know I've occasionally made CVS commits spanning modules, but I'm pretty sure I've never done it for a good reason that should be preserved.
<pattern> well, what you do with files in the root of $CVSROOT is a separate issue from what gets done with $CVSROOT/CVSROOT
<fullermd> But to drag back to something remotely topical, I have a number of CVS repos around that started their lives in RCS, and just copying the files into a module always came off without a hitch (and I may have cvsps-imported one or two of them once, not sure)
<pattern> that sounds like the right way to do things
<pattern> when i dumped my RCS/*,v files in to $CVSROOT i was just following the instructions of someone on #cvs
<fullermd> Yah.  It's dangerous to say "no CVS user ever would XYZ", 'cuz I KNOW some of the wake-up-screaming things CVS users have done.  But I would say the case of having files directly in $CVSROOT is vanishingly rare, and probably a bad idea where it does exist.
<poolie_> spiv, hi?
<spiv> poolie_: hello
<pattern> ok... i just created myself a brand spanking new launchpad account...
<pattern> so... should i file a bug for cvsps-import to not import $CVSROOT/CVSROOT or not?
 * fullermd shrugs.
<fullermd> _I_ don't think that's a/the bug.  But I can just file a comment on it and move on.
<pattern> ok, then i'll file it
<pattern> for the record
<poolie_> pattern, i have not followed the whole thread
<lifeless> nDuff: ?
<pattern> and let the winds blow where they may
<poolie_> but it seems like it could be a useful option
<pattern> poolie_: cvsps-import imports $CVSROOT/CVSROOT
<fullermd> Yah.  Paper trails are good.  At least, until the grand jury convenes.
<pattern> where i think it should only import $CVSROOT (or possibly just the rest of the directories under $CVSROOT) but not $CVSROOT/CVSROOT
<pattern> as that's a directory full of CVS metadata that bazaar has no use for
<indu> hi all
<pattern> at least that's my understanding of it
<indu> i have installed bazaar and loggerhead, both are well working
<pattern> as i'm not a CVS user
<pattern> but fullermd thinks there are corner cases where $CVSROOT/CVSROOT might have data the user wants to keep
<indu> but i am wondering how i can acess it remotely, as it uses apache web server, it should be able to access using the ipaddress
<indu> but when i tried to access my loggerhead gui from a remote system, using my system ip address, it couldnt' fetch it
<indu> could some one tell me, how to do it
<Odd_Bloke> indu: Can you access other things via that IP address?
<AfC> pattern: yes, go ahead and file the bug. The powers that be can make their mind up about how to deal with such a corner case if it actually exists.
<indu> Odd_Bloke, yes
<Odd_Bloke> indu: Can you access other Apache-served things via that IP address?
<poolie> pattern, it's possible that it has hook scripts you might want to keep for historical interest
<poolie> or just to be completest
<poolie> ist?
<indu> Odd_Bloke, yes i am able to access
<poolie> lifeless, were you wanting "thousands of deletes" for 0.92
<Odd_Bloke> indu: Are you running it on a different port?
<indu> Odd_Bloke, yes, logggerhead is running in port 8220
<lifeless> poolie: I think its small and safe;
<indu> and apache in 8080
<fullermd> I expect you could use .bzrignore (probably only in the form of ~/.bazaar/ignore) to ignore CVSROOT in a given case if you wanted to.
<Odd_Bloke> indu: Any chance that 8220 is blocked somewhere?
<lifeless> poolie: until nDuff reports on performance I don't know if its enough or not, but I think it probably is.
<poolie> spiv, igc, could either of you read that patch if you're free?
<indu> Odd_Bloke, no, this is a simple lan that i am checking in
<poolie> igc, did you do some user docs for packs, or is that what you're doing now?
<indu> Odd_Bloke, is it possible to make loggerhead and apache to use the same port
<igc> doing now
<poolie> cool
<indu> as this port blocking problem may come when i implement it for internet access
<igc> also tweaks to bzr+sssh patch
<Odd_Bloke> indu: I don't know, that's the extent of my ideas/knowledge on the subject. :p
<igc> poolie, lifeless: pack renaming patch sent to pqm 10 minutes back
<pattern> poolie, i guess that's possible... in which case you could just rename it to something else
<pattern> perhaps cvsps-import could ask the user whether to delete $CVSROOT/CVSROOT, with a default of yes
<Odd_Bloke> A switch to the call would be better, to avoid breaking automation.
<spiv> igc: I'm really happy to see that bzr+ssh bug fixed, btw.
<poolie> me too
<igc> spiv: any feedback on the tests?
<spiv> igc: I'll take a closer look now and let you know.
<igc> poolie thought you might have some
<poolie> some?
 * poolie reparses
<poolie> oh, right
<pattern> yeah, you could have a switch too... and something in the README warning that $CVSROOT/CVSROOT will be deleted by default
<poolie> igc, i meant to say, a better way to test the exceptions would be
<poolie> take the return code from assertRaises, which is the exception object
<poolie> coerce it to a string and check it's reasonable
<igc> ah - ok
<poolie> this gives better coverage - makes sure it's constructed the right way in the place it's raised
<poolie> (this is an enhancement to assertRaises in bzrlib, it's useful)
<igc> yeah
<igc> poolie: instead of 'connection timeout', is 'connection closed' clear enough?
<poolie> yes
<spiv> igc: +1 for 'connection closed'
<indu> mwhudson, hi, this is indraveni
<igc> and is a case for setting orig_error to something while construction those exceptions?
<igc> s/is/is there/
<pattern> ok... i'm going to sleep... thanks for your help everyone!
<pattern> bug filed
<ubotu> New bug: #156974 in bzr "cvsps-import imports $CVSROOT/CVSROOT" [Undecided,New] https://launchpad.net/bugs/156974
<lifeless> poolie: replied to you
<spiv> igc: I have some comments; I'm sending them to the list.
<igc> thanks spiv
<igc> lifeless: can you please do an email to everyone re changing the file on disk once the rename patch lands?
<igc> you know exactly what to say ...
<igc> and the masses will most likely expect it from you rather than me
<mdke> morning all. I'm looking for some tips on setting up a shared repository to manage history for a number of branches which I'd like to bind to launchpad
<mdke> I tried the command in the CentralizedWorkflows page and then "bzr branch" and received this error:
<igc> in particular, the timing is important I guess: pull bzr.dev, then edit the file?
<mdke> bzr: ERROR: Repository KnitRepository('file:///home/matt/ubuntu/ubuntu-doc/.bzr/') is not compatible with repository KnitRepository3('http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/.bzr/')
<mdke> oh, it's just a stupid command, I apologise
<mdke> damn, I still get it
<Odd_Bloke> mdke: What command are you running?
<mdke> Odd_Bloke: http://paste.ubuntu-nl.org/42052/
<fullermd> It's -with-subtrees, you're not.
<mdke> fullermd: how can I fix that?
<fullermd> Well, you can upgrade your existing repo (I'd be leery of that if you have other branches in it, though), or create a new one in -with-subtrees format.
<spiv> igc: sent.
<igc> thanks
<mdke> there aren't any other branches, I just created the repo in the line above (see pastebin)
<fullermd> Well, then just upgrade --format=dirstate-with-subtrees should do it.
<mdke> is there a way to do that when creating the repo in the first place?
<fullermd> init-repo has a --format option too.
<mdke> ok. Would it be useful to add this information to SharedRepositoryTutorial, do you think?
<mdke> hmm. bzr: ERROR: Bad value "dirstate-with-subtrees" for option "format".
<fullermd> Maybe it's singular 'subtree'...
 * fullermd quickly looks aroudn to see if abentley is lurking, ready to pounce...
<mwhudson> it's singular yes
<mwhudson> i always make that mistake
<mdke> morning mwhudson :)
 * mwhudson rubs his bleary eyes
<fullermd> We really want to keep -with-subtree in the closet...
<mdke> mwhudson: you and me both
<mdke> fullermd: it works now, thanks
<mdke> but I'd like to recommend to the whole team to use a shared repository when getting these branches because they are so similar, so I'll need to remember that command
<fullermd> Well, you'd want to give that in your instructions, yah.
<fullermd> But putting it up on the official docs would...   well, it would be a good way to attract attention to yourself   :]
<fullermd> See enthusiastic discussion last week on bug 131667
<ubotu> Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667
 * mdke looks
<mdke> ah, that's why it is enabled in the LP branch, because it was created with bzr-svn
<mdke> fullermd: would it have been better to remove it from the branch than to add it to the repository? if it is experimental?
<fullermd> Well, you can't [readily] remove it from the branch.  That's the biggest "oomph" with the format; it's a 1-way change.
<mdke> damn
<mdke> "the format enables dangerous
<mdke> behavior
<mdke> "
 * mdke is scared
<fullermd> I'd try not to get TOO freaked out over that.  It can do "dangerous" and scary and undocumented things, but it won't turn your code into midget donkey pr0n.
<fullermd> At least, not overnight.
<mdke> what sort of things?
<fullermd> Mmm.  Now you're pushing the edge of my knowledge.  It can end up creating by-reference nested trees sometimes.  Maybe if an 'add' in one branch hits another branch underneath?
<fullermd> And there's no commands or UI to do things with those trees, so I think you can end up in somewhat sticky situations.
<fullermd> There's probably other stuff along similar lines.
<mdke> if it's dangerous, I think what we would consider doing is deleting those branches and importing them in some other way than by using bzr-svn
<fullermd> I _think_ if you don't put one tree inside another, there shouldn't be any other surprising side effects.  But I don't really know.
<mdke> mwhudson: got any tips about this issue?
<mwhudson> mdke: sorry, not been tracking this conversation, can you summarize?
<Odd_Bloke> jelmer: The above conversation would seem to be relevant to your interests.
<spiv> mwhudson: bzr-svn requires a repository format that is marked experimental.
<fullermd> abentley would be the best one to ask about it.  I think LarstiQ knows the code a bit too, but he's not very around lately.  jelmer might be able to tell you more too.
<mwhudson> oh that
<mwhudson> mdke: i don't really have any deep insight here
<mwhudson> i've been using -with-subtree branches for a few things and they haven't eaten any babies or anything
<Odd_Bloke> fullermd: I didn't want to ping abentley in case I had to face his nested-tree-related wrath. :p
<fullermd> Odd_Bloke: That's why you do it now; it's the middle of the night for him.  You can get him all wound up, and have time to get out of the country before he springs out   ;)
<spiv> mdke: basically, at the moment that repo format is a requirement for using bzr-svn
<spiv> mdke: bzr-svn isn't exactly 1.0 software either ;)
<spiv> mdke: so I wouldn't worry about it any more than I'd worry about using bzr-svn anyway.  Just take care not to accidentally use that repository for other things.
<mdke> spiv: what I'm slightly concerned about is starting out on the wrong foot. if in the long term this will all straighten itself out, then fine. If I can sidestep any future issues by using another tool to import the svn revisions, then I'd rather do that now than later because it won't be possible later
<mdke> does that make sense?
<spiv> mdke: Personally, I'd stick with bzr-svn.  jelmer has done a good job so far of making sure that upgrades to newer versions of bzr-svn go smoothly, even as the new versions change how stuff is stored.
<fullermd> mdke: As I said above, I _think_ if you avoid putting one branch inside another in your fs (or checkouts of the branches), none of the scary/automatic behavior will come into play.
<mdke> i.e. if in 3 months the -subtree format is likely to be no longer experimental, then I'm happy
<mdke> spiv / fullermd - ok, I'll take the advice, thanks
<lifeless> igc: its 'edit .bzr/repository/format and put the text in there'
<igc> lifeless: and timing?
<lifeless> igc: I'm on the way out to a last night @ home dinner
<igc> sure
<lifeless> igc: well, pull the latest code first
<igc> thanks
<lifeless> so you have it on disk. Also note that *my* repository branch doesn't have this yet, so they need to pull/merge bzr.dev.
<igc> have fun - see you next Wed
<lifeless> my branches will be done late tonight, real early tomorrow morning
<igc> ok
<LarstiQ> mdke: I wouldn't be too worried.
<poolie> igc, did you send the ssh fix?
<igc> not yet - still making spiv's tweaks
<Kinnison> Morning
<indu> mwhudson, hi
<mwhudson> indu: hello
<indu> mwhudson, this is indraveni
<indu> mwhudson, i am able to create much more branches and view through the loggerhead
<indu> mwhudson, but now the problem is, remotely i am not able to see
<indu> if i am using my system ip in the url, its not woring
<indu> *working
<mwhudson> this is probably mostly a question about apache
<indu> mwhudson, in the loggerhead conf file, it should be always localhost or any
<mwhudson> the server.webpath entry?
<indu> yes its apache question, but ther sites in this apache server, are well accessed remotely except the loggerhead
<igc> poolie: just retesting that bzr+ssh change now
<indu> mwhudson, yes
<poolie> spiv, i'm reading the reconcile patch
<mwhudson> indu: it should be the url you use to access loggerhead
<mwhudson> indu: the "outside name", that is
<indu> mwhudson, ip address:port?
<mwhudson> indu: probably
<indu> mwhudson, and what about the other url's in the [project] and[[branch]] section ?
<mwhudson> those are cosmetic only
<indu> mwhudson, i have edited the server.webpath value but it doesn't seem to work
<mwhudson> as i think i said several times yesterday
<mwhudson> indu: have you read "how to ask smart questions" ?
<indu> no
<mwhudson> indu: could i ask you, politely, to be a little more respectful of my time?
<mwhudson> so: "it doesn't work" --> bad
 * igc food
<indu> mwhudson,sorry for that
<mwhudson> "i can see the list of branches but clicking on a link to a branch gives a 404" --> better
<indu> mwhudson, ok. i made my server.webpath value to ip:port  what about my apache conf, is the conf here correct ? http://pastebin.ca/748903
 * Lo-lan-do thinks it might be interesting to put something in branches without trees, so directory listings aren't empty
<Lo-lan-do> Something like an empty file called "this-is-a-bzr-branch.txt"
<poolie> agree
<Lo-lan-do> Or maybe not an empty file, but one which contains a minimalist explanation.
<indu> mwhudson, in my loggerhead.conf fle, except the server.webpath value all others are localhost
<Lo-lan-do> "This directory may look empty, especially if you look at it from the web, but you can still use it for "bzr branch http://..." operations"
<Odd_Bloke> indu: You might want to try playing around with those values to find out if they do anything, rather than bothering mwhudson.
<mwhudson> indu: ProxyPass        http://localhost/
<mwhudson> you need the port number loggerhead is running on here
<indu> mwhudson, and is that port in vhost is ok? its the port used by loggerhead and not apache
<indu> so do i need to have port in line NameVirtualhost *:8220 and <VirtualHost *:8220>
<mwhudson> oh, no, that should be the port apache listens on
<indu> mwhudson, i have changed the necesasry values, but  the error message saying, Page not found is displayed in the browser
<indu> and the log says, internal dunny connection
<mwhudson> "internal dunny connection" ?
<indu> mwhudson i dont think that error is related to this, let us leave that point
<indu> mwhudson, my loggerhead.conf file and apache configuration part is here http://pastebin.ca/748920
<indu> mwhudson, am i bothering u much ? if so very sorry for it
<mwhudson> indu: well, you're reaching the limits of what i can help with
<mwhudson> indu: i don't know that much about apache
<mwhudson> indu: i can usually get it to work with enough fiddling, but that doesn't help get it set up on your machine
<indu> mwhudson, which is ur  OS ?
<mwhudson> ubuntu]
<indu> mwhudson, ubuntu and debian are same i think then there should notbe any problem with aoache confs,
<indu> ur confs should wrok for me also
<indu> which port is ur loggerhead using mwhudson
<mwhudson> 8080
<indu> mwhudson, and ur apache ?
<mwhudson> 80
<mwhudson> our configs are more complicated though, for reasons that aren't relevant here
<indu> mwhudson, can u send me ur apache conf file,
<mwhudson> indu: no. sorry
<mwhudson> as i said, it's way more complicated than you need
<indu> mwhudson, ok
<fullermd> Oh joy, another round of the VCS discussion for pgsql.
<weigon_> jelmer: I ran into a new issue with bzr-svn: bzr: ERROR: changing lhs branch history not possible on repository root
<weigon_> on bzr push to the svn-repo
<gabe> does bzr create a .bzrignore file in every branch? I thought it was only supposed to in the home folder
<spiv> gabe: you can define ignore patterns in a branch, as well as specifying ignore patterns per user.
<gabe> oh
<gabe> right
<spiv> gabe: e.g. if a branch has a Makefile that produces .o files, you probably want a *.o ignore in that branch (although that's in the default patterns).
<gabe> and it seems bzr wants to keep .bzrignore in the branches under revision control too
<gabe> yeah
<gabe> well i version control websites
<gabe> they have folders called /upload/   which don't need versioning
<gabe> so i think i need to edit bzrignore in my home
<spiv> gabe: and if as a user I have an editor that makes *.BACKUP files or something, then that'd probably belong in my per-user ignores, rather than in the branch ignores.
<spiv> Right, .bzrignore is versioned.
<gabe> would I just write "upload" in to .bzrignore?
<mwhudson> yay for 2942
<spiv> Being versioned like any other file makes dealing with merges (and conflicts) of changes straightforward to understand.
<spiv> gabe: see "bzr help ignore"
<mwhudson> spiv: can i talk to you about smart server terminology for a bit?
<gabe> spiv: thanks very much
<Kamping_Kaiser> hi all. i'm having trouble checking a project out of launchpad. i'm running bzr 0.18 (from backports.org) the error i get is this:
<Kamping_Kaiser> kgoetz@wesnoth:~/public_html$ bzr branch http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/edubuntu-hardy
<Kamping_Kaiser> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/edubuntu-hardy/.bzr/repository/inventory.knit: Bad status line received
<mwhudson> ouch
<mwhudson> Kamping_Kaiser: does it fail quickly?
<Kamping_Kaiser> mwhudson, no, but i'm downloading. i can stop the download and try again if it will help
<mwhudson> Kamping_Kaiser: let me try it
<spiv> mwhudson: ok
<spiv> Kamping_Kaiser: do you have an HTTP proxy?
<Kamping_Kaiser> spiv, yes
<Kamping_Kaiser> dont know if bzr is using it or not
<mwhudson> spiv: i've just found that bzrlib.smart has lots of docstrings :)
<spiv> Kamping_Kaiser: it's quite possibly the HTTP proxy not liking the Range: request bzr sends.
<spiv> mwhudson: hooray :)
<mwhudson> spiv: so i should probably read those first
<spiv> mwhudson: are they any good? ;)
<mwhudson> spiv: dunno, the first one is broken reST
<Kamping_Kaiser> spiv, is there a way i can test wether bzr goes through the proxy?
<mwhudson> so i'll fix that, at least...
<spiv> Kamping_Kaiser: I think new bzr's might detect that problem and fallback to a safer method, so you could try upgrading.
<spiv> Kamping_Kaiser: vila would know more, if he were around...
<mwhudson> spiv: the grammar is iffy
<spiv> Kamping_Kaiser: I'm fairly sure bzr respects the http_proxy environment variable.
<Kamping_Kaiser> spiv, i dont see any bzr hits in the proxy cache
<Kamping_Kaiser> dont think its set
<Kamping_Kaiser> hm. $http_proxy is set, but i dont see anything for 'bazaar.launchpad' in my proxy cache
<spiv> mwhudson: is this bzrlib/smart/__init__.py?  That docstring is one of those "braindumps that got tidied a bit" docstrings.
<Kamping_Kaiser> i'm sorry, i stand corrected. bzr connects are being intercepted by http-replicator. (checked the log).
<mwhudson> spiv: yes
 * Kamping_Kaiser hangs around incase vila shows up
<mwhudson> spiv: i'm in one of those situations where the code changes i want took me, ooh, 15 minutes
<mwhudson> spiv: and working out where to plug in the tests has taken over a day so far :)
<spiv> Heh.
<mwhudson> spiv: this is for https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/93606
<ubotu> Launchpad bug 93606 in launchpad-bazaar "Better reporting of codeshosting permission errors" [High,Confirmed]
<spiv> mwhudson: if it weren't dinner time, I'd be more inclined to talk it over ;)
<mwhudson> spiv: fair enough
<mwhudson> spiv: i can beat the details out of jml and you in person soon enough
<mwhudson> spiv: quickly:
<spiv> mwhudson: part of the difficulty here is that ideally we'd rework the error handling significantly.
<spiv> mwhudson: poolie filed a bug outlining the basic plan; at the moment the error serialisation/deserialisation is a bit ad hoc.
<mwhudson> spiv: is the an overview document of the architecture of launchpad's codehosting service
<mwhudson> spiv: at the moment in my branch this is what the user sees https://pastebin.canonical.com/716/ :)
<mwhudson> (apologies for the private url)
<spiv> mwhudson: not that I know of.  There are various half-formed specs around, of varying obsoleteness ;)
<mwhudson> spiv: hooray
<spiv> mwhudson: ugh
<spiv> mwhudson: it would be good to improve that error :)
 * spiv -> food
<mwhudson> bzr: ERROR: Generic bzr smart protocol error: Permission denied: 'ERROR:  new row for relation ...' possibly is over it's colon quota
<mwhudson> spiv: it beats <Fault 8002 ''>
<mwhudson> spiv: enjoy your food
<jelmer> weigon_: That is intended behaviour
<jelmer> weigon_: you can't push changes that change the lhs revision history to the root of the subversion repository
<weigon_> was this the rebase ?
<jelmer> weigon_: As a workaround, you can use either rebase or push to a path that is not the root, such as /trunk
<weigon_> how can I see which changeset it is complaining about ?
<weigon_> $ bzr push --verbose doesn't add anything extra
<jelmer> I'll make it a bit more verbose, one sec
<ubotu> New bug: #157017 in bzr-eclipse "steppenwolf.selfip.net down -> -install eclipse plugin" [Undecided,New] https://launchpad.net/bugs/157017
<eoin> Hello all; I'm trying to track down some strange behaviour that I suspect is being caused by my web server: I've pushed a branch to a remote server via sftp, this branch is then served publicly. When I try to branch locally from this remote version bzr complains the checkout/format is being being redirected. There is no checkout on the server. My question is; does bzr check for the presence of this file as part of the branching process?
<eoin> i.e. if my webserver was sending a 404 for the request of checkout/format, does bzr interpret this as a treeless branch?
<spiv> eoin: right, if there's no checkout, then .bzr/checkout/format should not be there, which in HTTP terms means 404.
<spiv> eoin: although I wouldn't expect "bzr branch" to care if there's a checkout or not though.
<fullermd> Certainly not over sftp.
<fullermd> I didn't think it even checked for a tree.
<eoin> The exact error I see is as a result of "bzr branch http://example.org/bzr/project" is: "bzr: ERROR: http://example.org/bzr/project/.bzr/checkout/format is permanently redirected to /bzr/project/.bzr/".
<eoin> My webserver is indeed redirecting instead of sending a 404 (I'm using cherokee).
<eoin> Time to try apache methinks
<eoin> This is bzr version 0.90.0
<fullermd> I hate servers that do that...
<eoin> Yeah, it's pretty annoying.
<ubotu> New bug: #157026 in bzr "bzr log --short/--line does not show committer if it has only e-mail" [Undecided,New] https://launchpad.net/bugs/157026
<jelmer> mdke: Fixed
<ubotu> New bug: #157027 in bzr "bzr push/pull/missing: branches are diverged message should be improved for completely unrelated branches" [Low,Confirmed] https://launchpad.net/bugs/157027
<jelmer> s/mdke/weigon_/
<weigon_> I'll bzr up and try again
<igc> night all
<weigon_> bzr: ERROR: Unable to push revision 'jan@kneschke.de-20071023184229-d6h68lxxdgjxv6jj' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path ... looks better
<weigon_> jelmer: new problem :)
<weigon_> basicly it is the old problem again
<jelmer> weigon_: what, the error message you mean?
<jelmer> I've just clarified it
<weigon_> bzr: ERROR: libsvn._core.SubversionException: ("File already exists: filesystem '/svnroot/mysql-proxy/db', transaction '269-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020)
<weigon_> after the rebasing the svn-bzr tree, I could push again and it gave me this errormsg
<weigon_> is latest bzr-svn
<jelmer> was this the same tree you had problems with earlier, pushing?
<weigon_> yes
<weigon_> r269 is not marked as "missing" in $ bzr missing --show-ids anymore
<weigon_> let me paste the backtrace
<weigon_> jelmer: http://p.caboo.se/110758
<Kamping_Kaiser> spiv, i set the http_proxy to '' for this run of bzr, and its working, so its definiately somethign to do with the proxy
<jaavaaguru> Hi. We're trialling using Bazaar in place of SVN at work, and some people are asking about diff utility support on Windows
<jaavaaguru> Can anyone recommend a graphical diff program that works on WIndows and with Bazaar?
<jaavaaguru> We use CruiseControl.NET, and I have written a plugin for it which allows Bazaar to work with CC.NET: http://www.sorn.net/projects/bazaar-ccnet/
<jaavaaguru> There is a launchpad project linked from there if anyone's interested
<spiv> jaavaaguru: I think the bzr-gtk plugin has a graphical diff in it
<jaavaaguru> spiv: that only appears to be able to diff between the working tree and the branch you're on
<spiv> Kamping_Kaiser: Interesting.  I guess you can workaround it.
<Kamping_Kaiser> spiv, yeah. is it a bug in bzr or the proxy? i'm guessing the proxy?
<jaavaaguru> We have bzr-gtk running on a few machines here and being able to diff things other people have committed or merged would be handy
<spiv> jaavaaguru: I use "bzr viz" for that sort of thing sometimes (also part of bzr-gtk)
<spiv> Kamping_Kaiser: a bit of both, iirc ;)
<jaavaaguru> thanks, I'll have a look at that
<Kamping_Kaiser> spiv, ok :)
<spiv> Kamping_Kaiser: The proxy is rejecting a perfectly reasonable HTTP request, but rejecting it is possibly reasonable too... I'm not an HTTP guru.
<Kamping_Kaiser> spiv, ok. not my area (TM)
<spiv> Kamping_Kaiser: but I believe newer versions of bzr gracefully notice that error and fallback to a method that should always work.
<Kamping_Kaiser> spiv, guess i'll use work arounds until the updated versions hit debian backports
<spiv> Kamping_Kaiser: hmm, although I according to the NEWS file, the fix I'm thinking of was in 0.18rc1
<jaavaaguru> spiv: viz seems more of a graphical log/branch viewer than a tool for viewing differences between revisions, unless I'm missing something
<spiv> Kamping_Kaiser: and you're running 0.18, I think?
<Kamping_Kaiser> spiv, i belive so.
<spiv> jaavaaguru: it can show you the differences between revisions.
<spiv> jaavaaguru: but only between direct parents atm, I think :/
<Kamping_Kaiser> spiv,  Bazaar (bzr) 0.91.0 (so bzr in backports has been updated in the last 30~ hours)
<spiv> jaavaaguru: there's probably a feature request worth making there... ;)
<jaavaaguru> aha
<jaavaaguru> I'll play around with it and see how I get on... may make a feature request later
<spiv> jaavaaguru: and obviously it's not so helpful for comparing two diverged branches, but if you've already merged something in and just want to examine the history, it's a very good start.
<fullermd> bzr-gtk has a 'gdiff'...
<fullermd> It takes a -r which I presume works just like diff's -r.
<jaavaaguru> it does seem quite handy. Is there a way to let it use an external diff tool?
<jaavaaguru> Also, being a mixed linux/solaris/windows team, we're having issues with line endings being a mixture of \r\n and \n... merging doesn't handle this too well... is that worth a feature request too?
<lifeless> jaavaaguru: cool that you've done a plugin for cc.net
<weigon_> jelmer: I just uncommitted all the broken revisions and will merge them again
<jelmer> weigon_: merging won't help, you'll have to recommit them
<mwhudson> bzr send is nice
<mwhudson> fullermd: what's "SS" ?
<mwhudson> smart server?
<fullermd> Yah.
<weigon_> jelmer: what shall I do ?
<weigon_> I somehow have to get over this hump
<jelmer> weigon_: Yes, indeed. How much revisions do you have after r269?
<weigon_> I uncommitted them in the bzr-svn branch and its related bzr branch, but still have them available in the other child to recommit
<jelmer> weigon_: If you now create a clean copy of the svn branch (different repository), you should be able to commit and push them again
<jelmer> without merging/pulling from the original branch
<weigon_> jelmer: stupid question: I just check out the svn tree with bzr branch ... mysql-proxy-svn-2 or shall I move the old tree away instead ?
<weigon_> jelmer: I wonder about how the other related branches will get aware of the new branch otherwise
<jelmer> weigon_: No, they all contain the same data
<jelmer> weigon_: so how you call it shouldn't be relevant
<weigon_> just that $ bzr info on the child-branches points to the broken branch
<weigon_> is there a bzr switch or something like that ?
<weigon_> or just pull --remember on the child branch ?
<fullermd> I occasionally wish to be able to do that without it actually trying to pull.  I usually fake it by sticking my grubby fingers in the branch.conf and doing it manually...
<weigon_> jelmer: trying to branch, but now it the clean branching breaks with: bzr: ERROR: exceptions.StopIteration: ...
<weigon_> jelmer: http://p.caboo.se/110773
<spiv> mwhudson: thanks for the docstring patch
<mwhudson> spiv: np
<mwhudson> spiv: thanks for the docstrings in the first place :)
<mwhudson> spiv: my next trick is working what lp's bzr+ssh does differently :)
<mwhudson> s/working/working out/
<gabe> hi all
<gabe> there is a file that was delete from my bzr branch several revisions ago, how might i go about recovering it?
<jam-laptop> bzr revert -r -10 filename
<gabe> ohhh
<gabe> is there a way of browsing what files existed at a certain revision?
<gabe> or do i need to checkout that revision to browse them?
<jam-laptop> bzr inventory -r XXX
<jam-laptop> or bzr ls
<uws> bzr help inventory
<gabe> ha!
<jam-laptop> but I'm not sure if ls supports --revision
<gabe> wow
<gabe> didn't know about this one
<uws> jam-laptop: what is exactly the difference between inventory and ls?
<jam-laptop> uws: 'ls' is meant to be "the way of the future" :)
<jam-laptop> At the moment it supports a few more arguments that are helpful when scripting
<jam-laptop> like "bzr ls --null"
<jam-laptop> bzr ls --null | xargs -0 ...
<gabe> how does one use the --kind switch for bzr inventory?
<jam-laptop> bzr inventory --kind=file
<jam-laptop> bzr inventory --kind=directory
<jam-laptop> bzr inventory --kind=symlink
<gabe> ahhh
<jam-laptop> (print out all files, all directories, all symlinks, respectively)
<gabe> and how could you make it show only the items from the pwd rather than recursively?
<jam-laptop> I don't think inventory has that switch
<jam-laptop> 'bzr ls' does
<fullermd> --kind is easy; it's --sadistic and --short-tempered that get tough to manage.
<gabe> mm
<jam-laptop> You might try "bzr inventory ."
<jam-laptop> gabe: "." does it
<gabe> aha bzr ls
<gabe> jam-laptop: that did it but recursively from the pw
<gabe> PWD
<gabe> perhaps bzr ls is better
<jam-laptop> ah, rather than recursively
<jam-laptop> bzr inventory . | grep -v "/"
<gabe> but
<jam-laptop> :)
<gabe> bzr ls
<gabe> says it has an option for non-recursive
<jam-laptop> gabe: correct, "bzr ls --non-recursive" only prints out the entries in the current directory
<jam-laptop> at least, it works that way here
<gabe> yup
<gabe> and here
<gabe> i knew I could use grep
<gabe> but that seemed a bit hackish
<gabe> if bzr had it internally
<jam-laptop> well, there is the Unix philosophy of having tools do limited things individually, but do more when combined.
<jam-laptop> But there is usually a balance to be struck
<jam-laptop> Obviously we struck it differently for "bzr inventory" versus "bzr ls" :)
<luks> which doesn't work well if you are not on unix :)
<gabe> mmm
<gabe> bzr ls is gorgeous
<gabe> like timemachine for leopard
<gabe> but with a CLUI
<uws> We should have a bzr-fuse fs
<uws> with read-only revision-123 directories and such ;)
<gabe>  wow
<gabe> when is that set to become available?
<uws> gabe: never? ;)
<gabe> gah
<gabe> mmm
<jam-laptop> gabe: whenever someone decides to write it. I don't know of anything in the works.
<jam-laptop> And *I* don't know Fuse :)
<gabe> i might be able to hack out a simple ruby script to do something similar
<gabe> but not using fuse
<jam-laptop> You would probably find doing it in python easier, just because we have a very rich bzrlib there.
<gabe> prob
<gabe> but i can't use python
<gabe> i just don't get along with it
<Alien_Freak> does bzr have an equivalent to svn's hooks, mostly just care about email commit logs to list
<fullermd> Alien_Freak: There are hooks that can be run at commit time.  They currently only run locally, though; not on the server, if you're working like that.
<Alien_Freak> hmm.. but then each client would need either to bind to an smtp server or have their own mailserv...      well, still haven't hammered down our layout for bzr yet.. so not sure yet
<fullermd> Somebody wrote a hookless-mail thing.  I think it sits around getting run via cron and sending out mails for stuff it hasn't seen yet.  That may work.
<jelmer> re
<jelmer> weigon_, You need the patch I posted to the bzr mailing list today
<jelmer> weigon_: sorry about that
<ubotu> New bug: #157145 in bzr-eclipse "Dont check untracked files in commit window by default" [Undecided,New] https://launchpad.net/bugs/157145
<besonen_pidgin> is there a portable version of bazaar for windows available?
<jelmer> besonen_pidgin, yes, it should be linked from the website
<besonen_pidgin> thanks jelmer, i'll take a look.
<rif_> hi, guys how can I apply a bundle?
<luks> bzr pull or bzr merge
<rif_> ok, thanks it worked
<rif_> I hava 0.90 but help merge did not mentioned anything about it
<lifeless> pyfuse is kindof nice
<jam-laptop> lifeless: don't you ever sleep?
<jam-laptop> (Are you getting ready for flying, or is poolie leaving before you)
<besonen_pidgin> jelmer:  the closest thing to portable installer i could find was a "stand-alone" installer at http://bazaar-vcs.org/WindowsDownloads
<jelmer> besonen_pidgin: what exactly do you mean by portable?
<besonen_pidgin> jelmer:  meaning it can be installed on removeable media and used on any computer.  like these apps:  http://portableapps.com/
<jelmer> besonen_pidgin: The resulting directory of any of the installers should be portable afaik
<jam-laptop> jelmer: well, if you use the python installer, you have to have python installed.
<jam-laptop> The Standalone one should be fully portable, afaik
<jam-laptop> once it is installed
<lifeless> jam-laptop: I leave here in 50 minutes
<luks> but the config can be only in the home dir, no?
<jam-laptop> luks: you can set BZR_HOME if you want it somewhere else
<luks> oh
<jam-laptop> lifeless: have a safe trip, I look forward to whatever you manage to hack up
<lifeless> jam-laptop: also, 'sleep is for the weak'
<jam-laptop> Sometimes I think you travel internationally just for the hacking time. :)
<lifeless> :)
<lifeless> in the journalled inv thread
<nDuff> lifeless: now at 4m25s for the first incremental commit (vs 1m29s on recommit).
<lifeless> nDuff: ok, so theres still a glitch
<lifeless> nDuff: another callgrind please :)
<lifeless> nDuff: I think the different is that when you uncommit the working tree is not being reset, so it knows that the deletes have already occured.
<lifeless> nDuff: what would a 'good time' be for you for the incremental commit? Obviously we'll keep addressing the problem, but I'm curious when it moves from 'damn' to 'ok' for you
<nDuff> lifeless: I think it's already done that, really.
<besonen_pidgin> thanks jelmer and jam-laptop
<lifeless> nDuff: oh wow, cool.
<lifeless> nDuff: anyhow, I'm on a plane for the next 24 hours or so
<lifeless> nDuff: but drop me a callgrind of it and I'll see what I can do once I'm back on the ground
<jam-laptop> nDuff: so is that 4m25 down from 15m?
<nDuff> jam-laptop: yes.
<jam-laptop> nDuff: care to CC me on the callgrind?
<nDuff> jam-laptop: sure.
<james_w> I'm hacking on bzr-git some more, I have tried to fix the repo copy code to copy the file texts. However there is still a problem.
<james_w> The last commit in git is a merge commit (I'm not sure if that is significant), and when it tries to build the working tree after copying it dies as the knit for a file doesn't include an entry for the last commit's id.
<lifeless> james_w: have you looked at bzr-hg ?
<james_w> I though that the file knits were only supposed to get an entry when the file was modified.
<lifeless> james_w: have a look at repository.py, record_entry_contents in bzr.dev
<jam-laptop> james_w: It is whenever metadata changes as well
<jam-laptop> so if you have 2 branches which both modified a file
<jam-laptop> then when it is merged, there should be an update
<jam-laptop> (if 1 branch changes it, but not both, then there should not be a new entry)
<lifeless> nDuff: I've just pulled across the latest code, this changes the disk label for packs.
<lifeless> nDuff: well, its annotating now. give it a few secs
<lifeless> theres a mail on the list from Ian about this
<lifeless> or you can just nuke your test repositories. Also its now --knitpack-experimental
<lifeless> though I'm not sure why it has the word knit in it.
<james_w> jam-laptop: it is modified in the LCA and in the left hnd ancestor of the merge, but not in the right hand side or the merge itself.
<jam-laptop> lifeless: presumably because we may have xdelta packs in the future
<jam-laptop> or something other than knit-format deltas, etc.
<lifeless> jam-laptop: well, sure, just shrug.
<jam-laptop> I agree 'knit' may not be the best word, but we didn't have any other name for it
<jam-laptop> I don't really like "knitpack" either
<jam-laptop> but I don't have anything better
<lifeless> '1'
<lifeless> pack1-experimental
<jam-laptop> Yeah, 'pack1-experimental' for nwo
<jam-laptop> now
<lifeless> care to mail the list and propose that? The disk format does not say knit, so this is purely ui
<jam-laptop> I'll mention it at least
<lifeless> thanks!
<james_w> ah, so ie.revision should be an older revision if you are stealing that version's text?
<james_w> that makes sense.
<nDuff> lifeless: ...so do you want me to wait for that update, or send a callgrind against r2856?
<jam-laptop> I don't think there were code optimizations for 2856, were there?
<jam-laptop> just the format string change
<lifeless> nDuff: callgrind now is fine
<lifeless> jam-laptop: its against my repository branch
<lifeless> nDuff: but 2857 is there now
<lifeless> james_w: so - any mod to a file == new version in the knit per-file graph.
<lifeless> james_w: if two versions of a file are merged == new version, even if its not a content change
<lifeless> james_w: but if two versions are merged and and there is only one head, == not a new version
<lifeless> james_w: which is why I suggested you read record_entry_contents, this is tricky to 'get' from just text, and the code is pretty clear
<james_w> lifeless: yeah, that helped thanks.
<james_w> it works no though, woo.
<jam-laptop> lifeless: yeah, I'm just saying that 2857 in your repository branch doesn't add any performance changes
<lifeless> ok, my pulblic pack repo is now in bzr.dev's pack disk format
<jam-laptop> as it sounded like you had already merged all of them.
<lifeless> yup
<lifeless> I was just being clear
<pattern> since bzr will not do keyword substitution within source files as they're committed, what's the right way to have a single source file (say, a one-file perl program) print out its version information to the user?
<jam-laptop> bzr version-info --format=XXX > file.txt
<jam-laptop> We have format=python
<pattern> right
<jam-laptop> and =rio
<pattern> but i'd like to type "foo.pl --version" and get the version info
<pattern> and that "foo.pl" file is just a single file
<pattern> that would be copied to /usr/local/bin or whatever
<pattern> it would be distributed with no other files
<jam-laptop> foo.pl is the whole app?
<pattern> yep
<fullermd> You'd have to do some sed'ery in your distribution to cram the values into the script.
<jam-laptop> I can imagine doing some perl hackery to get it to work
<jam-laptop> Such as having a variable defined at the top
<jam-laptop> which gets redefined at the bottom as part of a "make" step
<pattern> but there is no make
<jam-laptop> That is a bit ugly
<pattern> still, i get the point
<jam-laptop> pattern: well, as any sort of "build the final file" step
<pattern> there's no way to do it with bazaar
<jam-laptop> I'm sure it would be easier to do in Perl than in Makefile
<jam-laptop> pattern: I can give you the whole discussion for why we don't support keyword expansion yet
<pattern> yeah, i just read the thread on the list
<jam-laptop> but generally the way CVS does it is *really* broken especially as you get into a distributed system
<jam-laptop> SVN is significantly better in that regard
<fullermd> The way CVS does it is really broken even for CVS.  's why my commit scripts collapse down the keywords on the way in.
<mwhudson> subversion is still broken though
<jam-laptop> mwhudson: I won't say SVN is perfect, just better than CVS :)
<LeoNerd> That's debatable
<jam-laptop> fullermd: oh definitely, I've done branch to branch merges with CVS, and it is pretty awful if you have any auto keywords
<LeoNerd> I like the fact that branches and tags _actually_ exist in CVS
<jam-laptop> LeoNerd: I was talking strictly about keyword expansion
<LeoNerd> Ahh..
<jam-laptop> The branch and tag is probably the big complaint about svn versus cvs
<jam-laptop> since they abuse a namespace
<jam-laptop> rather than creating an orthogonal one
<jam-laptop> for some it is more obvious
<jam-laptop> for others more confusing
<mwhudson> http://subversion.tigris.org/issues/show_bug.cgi?id=2783
<LeoNerd> It means you can't ask questions you'd like to
<LeoNerd> "Who else has branched this?"
<nDuff> okay, that's odd.
<LeoNerd> "When's the latest RC tag on this file?"
<pattern> anyway, i'd just like to make clear why automatic keyword substitution within source files would be useful
<jam-laptop> nDuff: ??
<jam-laptop> mwhudson: oooh.
<pattern> i write lots of (relatively) small, one-file scripts that i keep under version control
<nDuff> on r2857, I just got 1m35s *with lsprof enabled* for that initial commit.
<jam-laptop> mwhudson: But considering I can do "svn commit" and someone else can do "svn update" and get a different tree
<jam-laptop> It seems $Id$ is a lot less of an issue :)
<pattern> and it would just be nice to know what version a given script is, once it's out in the wild
<jam-laptop> pattern: well, you have 1 advantage in that we have a revision id which is globally unique
<jam-laptop> so you *can* embed that
<jam-laptop> Just we don't prefer to munge your files in place
<mwhudson> jam-laptop: well, maybe
<mwhudson> i was still surprised by that one
<jam-laptop> mwhudson: I actually remember discussing that one a long time ago.
<jam-laptop> What was the specific reason?
<mwhudson> it broke an import on launchpad
<pattern> i understand (at least some of) the arguments for not having bazaar doing automatic keyword substitution
<jam-laptop> Was it that files that didn't change on one side would get $3064$
<jam-laptop> and the other would get $3061$ (because they weren't updated)
<pattern> but i think some users will lose out in terms of convenience and simplicity, when they actually do need keyword substitution
<fullermd> pattern: I think the general concensus is "Yes, we'll do some variant of it, but not any time soon"
<pattern> and there are certain situations, like mine, where keyword substitution is a valid need, imo
<fullermd> At least, I hope that's still the general feel, 'cuz I'm too tired to run that argument again.
<jam-laptop> fullermd: well, I get that feeling from: http://bazaar-vcs.org/KeywordExpansion
<pattern> hey, i know, i'll just run bzr and RCS at the same time
<pattern> and whenever i check in a file via bazaar, i'll also check it in via RCS
<pattern> and then i'll get my version info :)
 * fullermd bursts into tears.
<fullermd> I'm gonna have nightmares for a week just from reading that   :(
<LeoNerd> I have dual Arch/CVS trees at wrok
<LeoNerd> *work
<jam-laptop> LeoNerd: I had that, too
<LeoNerd> I even use it to maintain two parallel sets of code
<jam-laptop> But more so *I* could use one
<lifeless> see some of you on the flip side
<LeoNerd> CVS -> arch -> arch (different branch) -> CVS (different repo)
<jam-laptop> and "upstream" used the other
 * lifeless waves
<jam-laptop> lifeless: have a good trip
<LeoNerd> It's fun having to move it back again
<jam-laptop> lifeless: see you F2F real soon :)
<lifeless> jam-laptop: cool!
<jam-laptop> LeoNerd: ooh, multiple cvs repos even
<jam-laptop> I haven't done that
<LeoNerd> Well, same repo but different modules
<LeoNerd> It's "old" vs. "new" code
<jam-laptop> I did have 2 Arch branches (one for the exact upstream CVS, and the other for my changes, etc.)
<LeoNerd> "old" is maintained on the live boxes, "new" is some stuff in development
<LeoNerd> In CVS they're totally unrelated
<LeoNerd> I use arch to backport new changes on dev into live, or bugfixes from live back to dev
<jam-laptop> I guess Arch would handle cherry picking a bit better
<jam-laptop> lifeless: well, I won't see you until next week, but still fairly soon
<jam-laptop> :)
<LeoNerd> Yeah.. I use the cherrypick a lot
<LeoNerd> Occasional dev->live moves, but not all of it
<LeoNerd> Which is largely the reason I'm not doing it in bzr
<jelmer> g
<james_w> bye lifeless.
<jam-laptop> nDuff: do you have the callgrind file?
<nDuff> jam-laptop: haven't been able to reproduce against r2857.
<jam-laptop> I wonder if it was actually an incremental and you didn't realize it
<nDuff> jam-laptop: It was explicitly an incremental ("<nDuff> lifeless: now at 4m25s for the first incremental commit (vs 1m29s on recommit).")
<jam-laptop> nDuff: "nDuff: on r2857, I just got 1m35s *with lsprof enabled* for that initial commit."
<nDuff> oops.
<jam-laptop> maybe you meant incremental
<nDuff> yes, I did.
<nDuff> (mean "incremental" rather than "initial")
<jajmon> hi, how do i start eclipse with -clean switch on mac osx (and what does it do?)
<jajmon> (trying to get the bzr plugin to work)
<beuno> jajmon, Verterok, the plugin developer isn't around right now
<beuno> he's usually here a few hours ahead
<beuno> you might want to file a bug or a question in Launchpad
<weigon_> jelmer: is the patch committed already ?
<jelmer> weigon_: it's being processed for inclusion in bzr.dev right now (see http://pqm.bazaar-vcs.org/)
<hunmonk> does anybody have an idea if/when the fink repository will be updated to the latest version of bzr?  it has 0.18 right now
<gotgenes> How does bzr svn-import work?
<gotgenes> Do I need to have already done a bzr co of the SVN repo?
<jam-laptop> gotgenes: I don't believe so
<jam-laptop> I think you can just give it the svn url
<jam-laptop> but I haven't done it myself
<fullermd> I think if you've done a bzr co of the SVN repo, you don't need bzr svn-import   ;]
<jam-laptop> fullermd: well, svn-import can import all branches
<jam-laptop> And I think it can work from an svn dump
<jelmer> gotgenes: you can either give it a SVN repository URL or a dump file
<jam-laptop> (though it does so by creating an svn repo, and loading the dump into it)
<keir> abentley, ping
<jam-laptop> mwhudson: ping
<mwhudson> jam-laptop: pong-ish
<jam-laptop> mwhudson: nm, I got my question answered on #launchpad
<jam-laptop> Though I guess if you are here...
<jam-laptop> Is it a really bad idea to upload a 400MB tarball as a project file?
<jam-laptop> I'm trying to get a dev snapshot of a big repository uploaded
<jam-laptop> so people don't have to download the 600+ MB of revision data
<jam-laptop> (they can bootstrap from a shared repo)
<mwhudson> jam-laptop: no idea, sorry
<jam-laptop> np
<cr3> I'm getting the following error, what does it mean: bzr: ERROR: parent_id {main-20070417180124-c9x1bsweu2uhbgcr-86} not in inventory
<abentley> keir: pong
<keir> abentley, i'm trying to get cart going
<keir> abentley, but i think there are some sqlalchemy 0.40 issues
<abentley> I haven't tried it with 4.
<cr3> by the way, I'm using Bazaar (bzr) 0.17.0
<keir> abentley, i mailed you at panoramicfeedback.com
<keir> abentley, basically, easy_install cheerfully installs 0.4.0, which is incompatible with the version of elixer that's installed. supposedly you need trunk elixir. so i got that, but there's still issues
<abentley> I see it.  Thanks.
<cr3> apparently, this happens for selective commits. so, I guess I won't do selective commits anymore
<abentley> keir: Would you like a Cart account so that you can post bug reports directly?
<keir> abentley, yes
<abentley> What password would you like?
<keir> abentley, user keir if possible
<abentley> keir: It is done.
<keir> abentley, great
<abentley> cr3: A lot of work has been done to fix problems like that in recent releases.
<keir> abentley, is it possible with setuptools to 'bake' a set of deps? the most annoying thing i find with the python web stuff is the tangle of dependencies
<abentley> I'm not sure what you mean by bake.  You can control versions pretty strictly, and you can provide your own copies of dependencies.
<keir> abentley, yes, providing our own copy would be nice
<keir> abentley, anyway, that's for later
<keir> abentley, login with mierle@gmail.com? or keir? neither is working
<abentley> keir
<gotgenes> Is there any way to use bzr-svn when the SVN operations require a username and password?
<abentley> I just tried it and it worked.
<keir> oh weird
<keir> i didn't see the login button
<keir> so i clicked 'accounts' then 'keir mierle'
<keir> it wanted me to login
<keir> so i did
<keir> it said 'bad login/pw'
<keir> but if i nav back to main cart, i'm logged in (or so it says in the top corner)
<keir> this is repeatable
<keir> abentley, i have to run. i'll be back later.
<abentley> keir: I should hide accounts if you don't have privs.
<jelmer> gotgenes: Yes, connect to the repository first with the native svn client
<igc> morning
<gotgenes> jelmer: Thanks. Worked well.
<gotgenes> jelmer: when I do an svn-import of the repo from the URL, it creates a directory within called trunk, but that directory is empty
<gotgenes> except for a .bzr file
<jelmer> gotgenes: that's right, it doesn't create working trees by default
<jelmer> you can run "bzr checkout" in that directory to create it
<gotgenes> jelmer: oh
<gotgenes> jelmer: well how about that
<jelmer> gotgenes: or specify the --trees argument to svn-import
<gotgenes> so this would be a... hmm, would this be called a bare bzr repo?
<jelmer> yes, that'd be the git term for it I guess
<gotgenes> something meant to sit on a remote server and get pushed to
<jelmer> in this case, it's being done to prevent you from running out of disk space
<gotgenes> jelmer: ah, okay
<igc> the patch for adding some user doc for knitpack has just been submitted to PQM now
 * igc breakfast - bbiab
#bzr 2007-10-26
<me_too> How do you ignore a file or directory?
<me_too> bzr ignore 'mask' isn't making anything get ignored..
<me_too> NEVERMIND
<me_too> IT WILL ONLY IGNORE THINGS WHICH ARE NOT VERSION CONTROLLED ALREADY..
<me_too> WOW, I WISH THAT WAS IN THE DOCS ( ! )
<Odd_Bloke> me_too: What version are you using?
<Odd_Bloke> More recent versions give you a list of versioned files that an ignore rule would otherwise ignore.
<spiv> igc: could you review the reconcile fix for bug 155730?
<ubotu> Launchpad bug 155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Fix committed] https://launchpad.net/bugs/155730
<igc> I can try :-)
<igc> spiv: ^^^
<spiv> igc: poolie said he might not get it done today, and it's blocking the rc...
<spiv> igc: excellent :)
<igc> np
<igc> don't know much about how it works but there's no better time to learn
<spiv> igc: it's a pretty tricky area of the code, so feel free to ask lots of questions, or even give me a call.
<igc> thanks
<spiv> I tried to remedy some of the horrible lack of docstrings a little, but it's probably going to have a few head-scratching moments still...
<me_too> odd_choke: Whatever the latest buntu version is
<Verterok> moin
<Verterok> beuno: ping
 * igc food
<keir> any ReST experts here?
<keir> i'm writing up some docs in ReST, and i'm not sure how to link between them
<igc> keir: I'm not an expert but might be able to help ...
<keir> all i want to do is make a link that is valid after converting to html
<igc> I usually just reference the other as an external link ...
<keir> should i just use http syntax?
<igc> asmmunig it's been converted to html
<keir> i want to eventually use latex..
<keir> also, why is ###### used in index.txt for the user guide? instead of ---- or ====?
<igc> try something like ./other.html
<igc> because the topics uses === and --- for their top 2 levels of heading so ...
<igc> the user guide needs to pick something else
<igc> the expectation is that the User Guide will include the others soon ...
<keir> ok
<keir> i hadn't seen the ### mentioned in the ReST docs
<igc> i.e. using .. include:: instead of just referencing external topics
<keir> what is .. later include:: xxxxx.txt?
<igc> There are a heap of chars you can use ...
<keir> on an aside: i really like ReST.
<igc> almost any from memory
<keir> how does it determine what the ordering is? by nesting?
<igc> yes
<keir> so you can start with ---- then ==== then #### if you want?
<igc> .. starts a comment
<igc> when a space comes right after the ..
<keir> i thought .. was a directive?
<keir> .. _Gmail: http://www.gmail.com
<igc> yep - the 'empty' directive is a comment :-)
<keir> what is  .. later include::?
<igc> it's ..include with ' later ' added to turn it into a comment
<keir> aah
<igc> the intention is to remove the ' later ' bit once the text is ready
<keir> i'm confused then; because .. _Blah: my_link_here is not a cmoment
<keir> *comment
<keir> yet has a space after the ..
<igc> hmm
<igc> not sure - as I said, no expert
<keir> ok
<keir> thanks for the help
<igc> np
<nDuff> has smart-server support for packs been addressed yet?
<igc> nDuff: spiv can probably give you the best answer on that
<nDuff> hrm. is there a simple way to get "bzr info" output in a form intended for parsability?
 * nDuff actually rather likes the --xml arguments to several of svn's commands -- easy to pipe output into xmlstarlet to run xpath queries or such.
<abentley> nDuff: I don't think there is.  Getting it human readable was a lot of work as it was!
<nDuff> abentley: heh, granted. that said -- bzrlib is great when I'm writing Python, but not so useful when trying to do integration with shell; parsing human-targeted output with sed (and hoping it doesn't change between versions) isn't my idea of fun.
 * nDuff supposes he can write some python glue
<abentley> I agree it would be nice.  It's just not properly factored yet.
<abentley> There's a bunch of code that's too tightly tied to console output.
<nDuff> ooo, heh.
 * nDuff finds https://launchpad.net/bzr-xmloutput
 * AfC waves to all the strange people who bring him such a wonderful version control tool
<abentley> AfC: Say, is Richard Dice a colleague of yours?
<AfC> abentley: indeed he is
<abentley> I know him through musician friends.  Say Hi from me.
<AfC> abentley: We go way back. He's one of my best friends, and is also one of my business partners http://www.operationaldynamics.com/about/staff/
<abentley> Very cool.
<abentley> I know he's been through some rough times lately.  I hope things get better.
<AfC> abentley: Turns out we did Shad Valley the same year (though not the same campus) and actually met in 1993 but started working together in late 1996
<abentley> So you don't know Sarah Ternoway, do you?
<AfC> abentley: he's the one who introduced me to Linux. I'm the one who explained to him that the blinking cursor after the $ sign on the screen was a Unix shell
<AfC> Sure I know Sarah
<abentley> I'm in a band with her.
<AfC> [been a long time, mind]
<AfC> Awesome
<abentley> Yeah, small world.
<AfC> Richard is right up there as one of the smarter people I know, period. Open Source wise he's very engaged in the Perl world. He and I don't really intersect there but he _is_ the one that got me onto Perl 5 in the first place.
<AfC> (of course, I always have to point out to him that I remember the day when Perl 1 came across comp.source.unix, and along with everyone else on the planet I went "what the hell is this")
<abentley> Yes, I heard about his involvement.
<abentley> It was a funny conversation -- I don't usually have people asking for more and more technical details of my job.
<AfC> [incidentally, that might be an angle if we want to try and win a major community over to Bazaar usage]
<AfC> He's also a champion scotch drinker.
<AfC> Didn't see him when I was up in Toronto couple weeks back but he and Vera were at my wedding there in June.
<abentley> We talked VCSes.  He was on real Eclipse kick-- any VCS had to work with Eclipse as well as svn does.
<AfC> abentley: I've run into that in my work. It's a genuine source of pushback
<AfC> and frankly, a legitimate point [So much so that it took me from looking good to looking suspect for having suggested bzr in the first place]
<abentley> Oh, I agree about Eclipse integration being worthwile.
<AfC> because the CVS integration into Eclipse is *so good* that, in essence, you are not using CVS. You are using something which is damn close to a distributed (or at least disconnectable) VCS
<abentley> The lack is mainly because Bazaar hackers tend to be happy with text editors.
<AfC> *you and I* know about multiple branches and merging and cross platform cross architecture and command line usability and all that other tough stuff
<AfC> but for anyone in a average [and nothing wrong with being average] corporate or workplace environment with perfectly competent {Java, whatever} programmer
<abentley> I know work is progressing on Eclipse integration, but I'm sure it would be faster if we were all using Eclipse.
<AfC> s the advantages of Bazaar (or the other two 3rd generation DRCS) are not as readily apparent
<AfC> abentley: yeah
<AfC> abentley: and since most of you are Python ninjas and terminal based text editor guys, that's not likely any time soon
<abentley> I feel that it's important for people to scratch their own itches.  If you try to scratch someone else's itch on a volunteer basis, you'll do it wrong or get bored before it's complete.
<AfC> [more to the point, its mere existence (with due credit to those working hard on it) is insufficient - if it doesn't have the blazing usability and downright SMARTS that Bazaar (cmd line) itself has, then it's not advantageous to even show anyone or claim "it's being worked on"]
<AfC> abentley: yes indeed
<AfC> abentley: I wouldn't dream of arguing against that
<AfC> [although, I might note that there is a middle ground of 3rd party ... climate:
<abentley> I just wish we had a better answer to that.
<AfC> if people are at least supportive, then things tend to work out
<AfC> but when people pooh pooh something (rightly or wrongly) that tends to be more than enough to suppress any possible enthusiasm]
<AfC> I suppose I am more aware of this than most, being the Java guy in the GNOME world
<abentley> Yeah, I can see that would be an unpopular choice.
<AfC> I must admit that over the last 4 years patient work on my part to at least be a good GNOME citizen combined with Sun finally having started the ball rolling towards freeing their Java implementation plus
<AfC> the retarded amount of work I am putting into developing a new java-gnome has added up to the "at least grudging tolerance" level of support rather than constant derision, for example
<AfC> which makes a big difference
<AfC> One final interesting angle, though, is that my project is kinda in this netherworld -
<abentley> Mind you I have no idea why people are doing Mono instead of Java.
<abentley> If you want a Java-like language, why on earth would you want the one from Microsoft?
<AfC> Inheriting from the almost 10 years of history in the project there is certainly an established ... way approaching API ... that is uniquely java-gnome and not 100% faithful to GTK;
<pattern> how can i change the log message for a given revision?
<AfC> but on the other hand, most of the "traditional" ways of doing things in Java are _utter crap_
<AfC> so it's not 100% Javaish either
<keir> AfC, i'm sure eclipse integration will come. bzr doesn't have the 7 years of maturing that svn does... given the same amount of time bzr will be compelling too :)
<keir> pattern, if it's the last rev you can uncommit
<abentley> Hi keir.
<keir> abentley, hey
<pattern> keir, uncommit won't touch the file in my WorkingTree, though, right?
<keir> abentley, i'm still interested in 'relaxing' with some css or inkscaping, but i gotta get cart working first :) did you try with 0.4.0?
<abentley> No, I thought I'd make it a dependency on 0.3.11 instead.
<keir> abentley, ok, great.
<AfC> keir: perhaps, but reality is that this project is in fierce competition with many others, and is trailing in the adoption curve. If Bazaars developers want more people to use it (and indeed to win vs others) then perhaps rather faster progress on Eclipse integration (among many things) will be necessary.
<keir> AfC, yes, i have noticed that.
<AfC> keir: as Aaron points out, this is a tricky problem
<abentley> pattern: Correct.  It will leave you ready to repeat the commit.
<keir> AfC, i don't really understand why either. at least, compared to hg, we are easier to use (though slower on some counts). compared to git, we are certainly easier to use.
<pattern> great
<AfC> abentley: Re vs dot Net ... indeed. That's probably why I'm getting grudging support as opposed to derision. The whole mono thing is insane, and most people quietly get that.
<pattern> now, how about if i want to change the log message in a revision that's not the latest revision?
<keir> AfC, though personally i *vastly* prefer gitweb to any of the bzr visualizers. the tabular log format is _way_ easier to scan than the multi-line-per-commit views.
<AfC> keir: it's not about that. Sun chose hg for Open Solaris. No shit they then chose it for Open JDK. Suddenly that has infected almost the entire Free Java hackers world with using hg and being ok with it.
<abentley> keir: Unfortunately, it seems 0.3.11 is not easy_instalable.
<keir> AfC, yeah. losing sun was really unfortunate.
<keir> AfC, i totally agree that we need to get some big adopters to get people onto bzr
<AfC> keir: meanwhile Ketih chose Git for X, told Carl to use it for Cairo and now all the freedesktop hackers (making up a not insignificant chunk of GNOME ones) are thrilled with Git.
<AfC> keir: which leaves people like me outlying loners for having chosen Bazaar.
<keir> AfC, yes.
<AfC> Yeah
<AfC> So like it or not, the momentum isn't what we want,
<AfC> and much as we'd love to not have to worry about such politics and just concentrate on coding on things we love,
<keir> i know, it is important.
<AfC> it nevertheless is concerning
<keir> #mercurial - 84 people. #bzr - 95 people. #git - 200
<AfC> You know, that's not bad as a rough sampling technique :)
<keir> AfC, i agree :)
<pattern> what does KDE use?
<keir> pattern, they are switching to git
<AfC> Subversion, I think
<keir> from svn
<AfC> keir: really? Oh shit
<keir> AfC, yes. their repos are 20 gigs
<pattern> how about gcc?
<keir> AfC, in git they dropped to about 1gig
<keir> gcc is also going git
<AfC> You see, unlike GNOME, they are rather monolithic in their development practices; they do make central decisions and impose them
<AfC> haha
<AfC> Yeah, that was one of Keith's points against svn at the time - Mozilla went to 3 GB in Subversion and broke svn; in Git it was 600 MB or something
<keir> yes
<AfC> Anyway, things we take for granted
<keir> unfortunately, to win over big players bzr needs to do size reductions like that too
<AfC> like merges actually working, correct internals, testing,
<keir> i'm not sure how well packs are
<AfC> usability, etc
<AfC> are things we REALLY need to push
<AfC> to make it clear why you _don't_ want to use Git, for example
<keir> AfC, exactly. that's why i chose bzr
<keir> AfC, however, you can't win by extoling how BAD the competition is, you have to win by being BETTER
 * AfC makes his tiny contribution by things like http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html
<AfC> and the rest of http://research.operationaldynamics.com/blogs/andrew/software/version-control/
<AfC> keir: dead wrong
<AfC> keir: that's engineers pretending that they are objective talking.
<AfC> keir: tools use is an emotional choice. Always has been
<AfC> keir: and _especially_ when the prevailing sentiment is that [in this case, "the other two"] are ok
<keir> from a practical standpoint, they are. which makes getting people to switch hard.
<AfC> then effort needs to be invested to pretty clearly point out what's wrong with the others (thence leading to the perfectly reasonable why Bazaar is an improvement)
<keir> yes. and this is not clear at all from the website
<AfC> keir: **exactly**
<keir> and right now the launchpad integration is not well explained
<keir> or at least, it's not well sold
<AfC> Unfortunately, I'm not really competent to contribute to writing more [for Bazaar's website, taking your example] about what the problem is or why bzr is better. I hang out with Robert Collins and Peter Miller enough to truly believe it is so,
<AfC> and have heard many arguments on the topic over the last 24 months,
<AfC> but I can't articulate about things like hash collisions or merge complexity from an expert standpoint
<AfC> else I would contribute more that way. So I've tried to blog about it, instead.
<AfC> And encourage clients to use it... although that's when I ran smack into "Eclipse integration not even alpha quality. Screw off"
<keir> AfC, your blog is nice. we need more 'customer stories' like yours on the bzr site.
<AfC> Mostly I've taken the trouble to write stuff like that because I *am* on planet.gnome.org, and so that's my way of injecting into the debate there.
<pattern> speaking of the website, there are pages worth of whitespace at the top of it when you view it in opera (at least on linux)
<pattern> so at first it looks nearly empty (at least in the main frame)
<AfC> pattern: ouch!
<pattern> you have to scroll down a bunch of pages to see the content
<keir> one thing that sounds wacky, but is actually very compelling, is video tutorials.
<AfC> pattern: Please do file a bug for that - that's the sort of thing that people Canonical employs for just that sort of marketing & publicity can fix
<keir> no joke, they make a big difference to some people.
<AfC> keir: my keynote at foss.in this year will effectively be one
<keir> we need to get bzr talks youtube'd and posted
<keir> really good ones, should be prominently featured!
<keir> if you make a good video tutorial, it's also likely to get programming.reddit'd or somesuch
<pattern> screenshot of main bazaar-vcs.org page in opera/linux  -  http://img187.imageshack.us/img187/2995/bazaarci6.jpg  (shrunk down from 1600x1200 resolution down to 800x600)
<AfC> pattern: you could always just reduce the browser window to 800x600ish and then take a screenshot
<pattern> yeah, i guess that would work too :)
<pattern> i'm just not used to resizing my browser windows, pretty much ever
<AfC> pattern: sure. It's just a good trick when you're screenshooting
<AfC> pattern: I did that just yesterday when taking a snap of Rhythmbox to show someone - reduced a 150kB PNG to 30 or so
<pattern> i don't really care about how much disk space the image takes up
<pattern> i just resized it for the convenience of people with lower resolutions
<pattern> not everyone uses 1600x1200, alas
<pattern> bug filed
<help> hi all
<ubotu> New bug: #157330 in bzr "bazaar-vcs.org blank in Opera/Linux" [Undecided,New] https://launchpad.net/bugs/157330
<help> hi all
<help> what is the difference between bzr-init and bzr init-repo
<help> *bzr init
<AfC> help: that's a wicked nickname
<AfC> help: bzr init creates a new branch in the [specified] directory.
<AfC> As it happens...
<AfC> {sigh}
<AfC> Let me guess. He's trying to use a registered nick
 * ksp is help
<ksp> in the specified direcotory means, no need for the directory to be a repository ?
<ksp> for which repo it would be a branch ?
<AfC> Let's see, where were we
<AfC> Ah yes
<AfC> As it happens, Bazaar needs somewhere to store revisions you create and/or pull from other branches of this project
<AfC> and so it will quietly create a directory called repository in .bzr
<spiv> igc: btw, I got a call from poolie, saying he'd read my reconcile patch and is ok with me landing it.
<ksp> AfC, so for creating a project initially, we should use bzr init-repo ? is it ewual to svnadmin create repo in subversion
<AfC> no no
<igc> spiv: good - just finished it myself
<spiv> igc: he had some comments about clarity but he's happy for those to be dealt with after merging.
<AfC> just bzr init and you're on your way
<spiv> igc: ah, great.
<spiv> igc: I'm very glad to have more eyeballs on this code :)
<igc> spiv: a question ...
<AfC> igc: P.S. I wanted to mention one thing to you about your slides but didn't have time to write an email
<AfC> igc: it can wait
<igc> all_versions() in the tests ...
<igc> why are things removed in your changes?
<spiv> igc: oh, right.
<ksp> AfC, just bzr init is enough to create  the iniial repository ?
<spiv> igc: I think I should probably rename all_versions :)
<igc> to?
<AfC> ksp: now. You might begin to wonder if it is necessary for each and every branch clone you make of the same source project to have its own ./.bzr/repository full of revisions
<AfC> ksp: and that is what bzr init-repo is for
<spiv> igc: that's the list of file versions that will have their SHAs checked before and after reconcile.
<AfC> You use it (typically) in ..
<AfC> where it creates ../.bzr/repository that will hold the revisions for all the branches in .
<spiv> igc: the idea being that reconcile shouldn't change the SHA (or contents) of a file version, just the metadata.
<igc> spiv: ok - I'll write up a quick email mentioning the one small tweak I want
<AfC> In the case of the project I work on, I tend to group a bunch of branches under a given directory
<spiv> igc: but now reconcile removes some file versions if they are unreferenced, so just simply listing all the versions that were there initially isn't appropriate, because we don't care that their contents are preserved (they're not; the whole version is gone)
<AfC> eg,
<AfC> in src/andrew/
<AfC> I created src/andrew/java-gnome/
<ksp> AfC, so initially i will use bzr init-repo which will create the main project repository and cd /to/the/repo-directory, i can create sub folders using bzr init or jsut bzr add ?
<AfC> to hold src/andrew/java-gnome/mainline/, src/andrew/java-gnome/treeview/,  src/andrew/java-gnome/website/ etc
<AfC> where {mainline,treeview,website,...} are branches
<spiv> igc: so I guess something like 'versions_to_verify_shas_of', although that's a pretty awkward name, would be better than 'all_versions'
<AfC> ksp: init
<AfC> yes
<AfC> ksp: the idea of repo is just a storage optimization.
<nDuff> hrm -- I can't export from a packs repository over http
<AfC> ksp: you don't _need_ it like you do with Subversion
<igc> spiv: yes
<AfC> ksp: and yes, I initially did bzr init-repo in src/andrew/java-gnome/ before creating the first 'mainline' branch there subsequently
<nDuff> http://pastebin.ca/750051
<AfC> That's it, really
<AfC> ksp: If you hadn't asked I'm sure we would have just told you to `bzr init` and carry on.
<ksp> AfC, if i am going to use bzr init under directory created using init-repo then there will again exist number of .bzr directories under each , right? and that will too complicated tree
<AfC> You can always create a "repository" in a new directory tree later and move (using `bzr clone`) the branches there later
<AfC> ksp: correct
<AfC> ksp: what you will see is top/.bzr/repository/
<ksp> ok fine, so i will conclude like this................ bzr init-repo java-gnome, cd java-gnome, bzr add mainline
<AfC> ksp: and top/mainline/.bzr/branch/
<AfC> ksp: and top/experimental/.bzr/branch/
<ksp> is this we can do have a simple repo ?
<AfC> ksp: and top/bugfix-the-wacky-code/.bzr/branch/
<ksp> AfC, yes exectly
<ksp> AfC, so is it needed to have so many .bzr folders?
<AfC> but you WON'T see .bzr directories further down. There's just one per branch
<AfC> If you HADN'T made top as a "repository" with bzr init-repo,
<AfC> then what you would see would be
<AfC> ksp: top/mainline/.bzr/branch/ AND
<AfC> ksp: top/mainline/.bzr/repository/
<AfC> that's it
<AfC> (oh, and nothing in top/)
<AfC> ksp: get it?
<nDuff> ksp, wait, are you talking about doing "add" commands directly within your repository, rather than in a working tree?
 * nDuff doesn't know that that's valid.
<ksp> i'll be back in momment
 * AfC notes to the wizards in channel that this continues to be a source of confusion to new users. We almost need to make this go away. That was one thing Darcs (and Git, maybe?) did nicely - they just hardlinked the files between branches thus no repository-quietly-pushed-up-to-parent concept
<AfC> s/files/revisions/
<nDuff> ksp: if you do "bzr init-repo ~/java-gnome.repo", then you can inside your mainline source tree do "bzr init", check in whatever code, then "bzr push ~/java-gnome.repo/mainline" to create and populate your mainline branch from the tree you're currently in, for instance; that's the approach I most commonly take when using repositories. Not that there aren't other ways of getting going.
<AfC> ksp: Just do mkdir whatever ; cd whatever ; bzr init .  and then carry on with bzr add ; bzr commit
<AfC> ksp: that'll get you started. You can always do what nDuff or I have been suggesting later
<AfC> nDuff: (that's interesting, and more traditional. I sorta got focused on working-on-the-peer-branches-I'm)
<ksp> nDuff, this is where i am getting the doubt. as u said, we will create the repo using "bzr init-repo ~/java-gnome.repo" later, we can jsut do mkdir, add codes and other suffs using bzr add , then bzr commit. why do i need to use bzr init again /
<nDuff> init-repo and init are different
<nDuff> ksp, you want to do the init before you can add
<igc> spiv: review sent to the list now with minor tweaks requested
<spiv> igc: thanks!
<nDuff> ksp, but init-repo is to make a shared space to store multiple branches efficiently
<nDuff> ksp, if you don't have multiple branches, you don't need a shared repository yet, so don't need to do anything with init-repo.
<AfC> ksp: yeah - just insert "bzr init" between "mkdir" and "add codes and others suffs"
<AfC> and you're all set
 * AfC doubts ksp is working on java-gnome :)
<ksp> nDuff, yes, now i tried live, by using bzr init-repo and then bzr add , which threw an error saying, NOWorkingTree exists
<ksp> so i used bzr init and then added using bzr add, it worked
<ksp> so repo will hold number of branches under which we can add stufss
<nDuff> ksp, yes; init-repo makes a shared repository *without* a working tree; you don't add in it.
<ksp> AfC, nDuff now its clear for me
<ksp> and now when other users want to get the data, they use bzr branch url and checkout the source
<ksp> modify it and upload using bzr push. right ?
<spiv> ksp: right, you always need a branch (which is what 'bzr init' creates).  A separate repository to optimise storage of branches (what 'bzr init-repo' creates) is completely optional.
<nDuff> ksp: ehh. if you want a traditional workflow (where everything goes into the shared repository as soon as it's committed), you should have your users use checkout and commit rather than messing with pull and push.
<spiv> ksp: yes, that's a reasonable workflow.  nDuff's suggestion (users use 'bzr checkout' rather than 'bzr branch') is fine as well.
<nDuff> ksp: if you want a distributed workflow, then what you described is roughly correct -- folks can make multiple commits on their local tree between when they pull and when they push.
<ksp> hold on, again, what is difference between,  bzr branch and bzr checkout ?
 * nDuff looks at push's help and sees that --overwrite is so named... good; was concerned it might be named --force, which would be a little bit less clear about the need to merge up before pushing.
<nDuff> ksp: if someone does a branch, they can commit locally without those changes going back to the tree they pulled from; if you checkout, as soon as you commit it goes back to the place you did a checkout from.
<ksp> so, branch allwos, commit offline and checkout allows commint online
<nDuff> ksp: pretty much. you can change your tree between the two types using "bind" and "unbind".
<ksp> ok
<ksp> and if i come to uor first procedure, forgtting about bzr init-repo, if i use bzr init for creating the initial java-gnome and then add the other stuff using bzr add, still it acts as the aboe discussed repository ?
<ksp> or anything is there which varies ? nDuff
<nDuff> no, nothing that varies.
<ksp> is it possible to have a nested branches ?
<nDuff> in a repository, sure.
<ksp> like bzr init abc; cd abc; bzr init xyz ?
<nDuff> no idea.
<ksp> ok, how can i allow  authentication of users in bzr
<ksp> like svn apache conf has, SVNAuthZFile
<spiv> ksp: you can nest branches like that; the abc branch will just ignore the xyz branch inside it.
<ksp> spiv, ignore ?
<spiv> ksp: so e.g. a commit in abc will not have any effect on xyz, or vice versa.
<ksp> spiv, oh, so if u commit in abc thenonly the modifications done in abc branch are applied to the repo, and isgnores the modifications done in xyz
<spiv> Right.  It's basically the same as if the branches weren't nested.
<spiv> (There's some experimental code to do more advanced stuff with nested branches, but it's not ready for general consumption)
<ksp> spiv, what about authenticating the commits
<spiv> bzr has no authentication builtin at the moment.
<spiv> Mostly people rely on something like SSH.
<ksp> spiv, then how can we keep track of who is pushing which code ?
<ksp> bzr+ssh ?
<spiv> bzr stores a committer ID on each revision (see also the "bzr whoami" command).
<spiv> And you can also configure bzr to GPG sign your revisions.
<ksp> yeah, i remember now
<spiv> Yes bzr+ssh, or even just sftp.
<spiv> And leave the access control to your operating system/filesystem permissions.
<ksp> spiv, fine. got the concept
<ksp> spiv, one more silly question
<spiv> ksp: I haven't seen a single silly question from you yet :)
<ksp> spiv, i am used to subversion for more than a year and now planning to shift to bzr
<ksp> and onw most advantage i read in bzr tutotial is that, we can do bzr commit when we are offiline
<AfC> ksp: that is correct
<ksp> that is it allows us to work offline also without connecting to the main repo
<AfC> ksp: that is also correct
<ksp> but how is it advantage
<AfC> ksp: so, for get about "repositories" for a sec
<AfC> bah
<nDuff> ksp: are you a commercial or open source user?
<AfC> ksp: so, forget about "repositories" for a second
<ksp> ksp, open source
<AfC> ksp: and just think about branches;
<ksp> ok
<AfC> ksp: each branch contains full history and is _entirely_ independent and self-sufficient
<nDuff> ksp: then think of it this way: people can make their own branches without you giving them commit privileges for your repository. it makes the barrier to entry for new contributors much lower.
<AfC> and is a peer of all the other branches in the project.
<AfC> you move changes between them by "merging".
<nDuff> ksp: they can keep their branch on their own server, and then you can merge from it if and when you like.
<AfC> but because you have a fully power branch, you can do anything you like to it (like committing, like viewing history, etc)
<AfC> ksp: roger so far?
 * ksp is trying to understand he above
<AfC> There are two techniques which ... enhance ... matters, but the basic essence of fully distributed version control is the above
<nDuff> ksp: so that way, even people you don't trust with direct commit privileges get the benefit of having revision control tools. for a open source project, that's a big win.
<AfC> ksp: so you get that a branch is self-contained and everything you ever needed and its own little island?
<ksp> AfC, yes
<AfC> nDuff: [I really do believe that starting with centralized version control and trying to explain distributed is suboptimal; better to start the other way round and then connect back, as I am about to do]
<AfC> Right
<AfC> ksp: so the two ... enhancements ... I mentioned are as follows:
<spiv> ksp: If I'm on a train, with no net access, and I have a bzr branch on my laptop, I can still do everything I want to with it: I can make commits, I can make new branches from that branch, I can merge other branches into it, I can examine the history (log, annotate, etc) of that branch.
<AfC> ksp: the first is a storage optimization. Obviously since every branch is it's own island and has everything, it might get to be a little large (on disk), right?
<AfC> [or rather, lots of branches each with everything might get to be a little large on disk]
<AfC> ksp: that's where Bazaar's idea of a (local, ie at .. or somewhere near ~) "repository" comes in. It doesn't change the fact that each branch has everything it needs
<spiv> ksp: I don't need any access at all to a central blessed "repository" for any of that (and I don't need to be an official committer.  I can just work on the code, and I can publish my work when I get online just by pushing my branch somewhere.
<AfC> it just means that the various branches stored under that repository can share all the revision data (history, etc) so there's one copy rather than n copies of all that data.
 * AfC notes that spiv is explaining this remarkable well :)
<spiv> AfC: I suspect we've both had a bit of practice :)
<AfC> ksp: so you got the Bazaar idea of full power "branch", now hopefully you see where (local) "repository" fits in.
<AfC> ksp: Good so far?
<ksp> AfC, spiv so far I understood well
<AfC> Now onto the the second ... enhancement ... one that I actually regard somewhat askance.
<ksp> here my query comes up
<AfC> wait
<ksp> AfC, ya, please go ahead with sec enhancement
<AfC> Some people like to create a setup where they are _not_ allowed to commit to their branch unless they also simultaneously commit to some central (typically remotely hosted) branch
<AfC> [the word repository is often misused here, but branch is correct]
<AfC> this is known as a "bound" branch in Bazaar terms
<AfC> and typically is created by using the
<AfC> bzr checkout
<AfC> command instead of the
<AfC> bzr branch aka bzr clone
<AfC> command.
<AfC> This is what powers the 1st generation centralized version control model that Bazaar is capable of supporting even though it is otherwise a 3rd generation decentralized version control tool.
<AfC> Now: here are the catches: (or details)
<AfC> A checkout is still a full stocked branch
<AfC> It's just that you're not allowed to commit to it unless you have commit rights to the central (probably remote) branch.
<AfC> There is an additional sub type created with
<AfC> bzr checkout --ligthtweight
<AfC> which, quite exceptionally and in variance with everything else that's going on,
<AfC> does NOT create a full power branch and does NOT copy all the history which means it really IS crippled unless you have live network access to the remote branch.
<AfC> (in other words, Subversion. Yetch)
<AfC> So now that you've heard about it, don't touch it.
<AfC> Final catch,
<AfC> or detail or feature
<AfC> and actually, this is the best part,
<AfC> a proper bzr checkout (which is a branch that just happens to be bound to some other [typically remote] branch) can't be committed to
<AfC> unless you have write rights on the central branch,
<AfC> BUT
<AfC> you *can* always just create a local copy [with bzr clone aka bzr branch, same thing]
<AfC> of the checkout aka bound branch
<AfC> thus creating a new branch locally that you DO have write access to, wherein you can carry on doing whatever you want, committing, etc
<AfC> If you hadn't guessed, the final part of the story is submitting the revisions you've made locally in your own branch back to the parent project if you don't have write access to it, but that's kinda another topic.
<AfC> That's how I handle the "can't commit to remote" thing, but there is also a concept called "local commits" which allows you to make revisions for later return to a remote branch (repository, sigh) that you do have write access to.
<AfC> ksp: Well, that's about it I think.
 * nDuff files bug #157335 (can't export from a packs repository over http)
<ubotu> Launchpad bug 157335 in bzr "AssertionError trying to export from a packs repository over http" [Undecided,New] https://launchpad.net/bugs/157335
<ksp> AfC, great explanation. i understood everything well now
<ubotu> New bug: #157335 in bzr "AssertionError trying to export from a packs repository over http" [Undecided,New] https://launchpad.net/bugs/157335
<ksp> AfC, how to set priviliges for users to commit, read or write etc
<nDuff> ksp: through whatever mechanism is native for the transport you use. if you're using a shared filesystem (or something that uses one like sftp), use file permissions.
<ksp> ok
 * AfC recommends bzr+ssh for the case where the remote system has ssh logins for the various users
 * nDuff is using packs (needs it, 100K+ file tree), so bzr+ssh doesn't work for him.
<ksp> AfC, nDuff spiv thanks a lot
<AfC> ksp: frankly, I'd recommend just getting used to working with Bazaar in its basic full power local mode for a bit. You can then explore the ways of shipping revisions around later.
<spiv> ksp: you're welcome.
<spiv> nDuff: we'll fix that soon I hope
<AfC> ksp: have a peek at http://java-gnome.sourceforge.net/4.0/HACKING.html for discussion of the other way of shutting revisions around - manually.
<spiv> nDuff: thanks very much for finding these issues!
<nDuff> spiv: heh, not a problem. Wish I had more time to get involved in fixing them.
<ksp> i just got theoritical knowledge, i will do experiments in local as AfC suggested and then may come out with lot more queries
 * AfC runs for the ferry.
<ksp> spiv, i am plannig to use for a large project named BOSS GNU/Linux, http://bosslinux.in
<ksp> to maintain the source of BOSS (based on debian) and thus thinking that, do i need to make a sturcture like each package is a seperate branch
<nDuff> ksp: the packs format works well for very large trees. that said, I don't know your requirements -- if folks will want to check out and work on only one package at a time, then that would make sense to break them out.
 * nDuff finds that he can work around the export thing by using lightweight checkouts, which appear to work over http.
<nDuff> (well, using lightweight checkouts and then deleting the extra files)
<nDuff> ...hmm, though I'll bet I could do an export from the checkout
<spiv> ksp: I think a branch per package sounds like a good way to do it.
<ksp> ok, thankyou for the suggestions
<spiv> Argh, poolie's callCatchWarnings breaks under python -Werror.
<spiv> I guess as part of its hackery of global state in the warning module it should temporarily disable -Werror.  Hmm.
<mwhudson> have fun with that
<ksp> if i have a problem in accessing loggerhead using http protocol (throught the browser) then where will be the related logs be  available ?
<mwhudson> ksp: loggerhead dumps files to logs/debug.log
<mwhudson> relative to the start-loggerhead script
<ksp> but, when i access it through http://ip:port, ten it doesn't appear in browser, to trace that, where do i need to check the logs?
 * ksp is indraveni , yesterday
<mwhudson> oh, i thought there was _another_ person with loggerhead problems
<mwhudson> it's probably worth checking the apache logs too
<igc> night all - have a great weekend
<spiv> igc: g'night
<igc> thanks spiv
<spiv> Gar, *and* the test for callCatchWarnings didn't pass under 2.4.
 * spiv fixes
<spiv> igc: Btw,
<spiv> igc: Once this final branch lands, we're ready to cut the rc
<spiv> igc: I'll do that sometime tonight.
<igc> cool
<igc> hope it goes well
<spiv> Me too!
<dato> can somebody suggest an option name for sorting the output of `bzr tags` chronologically? --chronollogically seems too long, maybe `--bytime`?
<Peng> What about --sort=time?
<Peng> Or "date".
<Peng> Do any other commands do sorting?
<fullermd> I like --sort.  That gives you options for future extension.
<LeoNerd> --sort is also what GNU ls takes, so might be an idea to see what it does and do things similarly
<dato> yeah. plus if you alias tags=tags --sort=time, you should be able to run `bzr tags --sort=alpha` afterwards.
<dato> only, I don't know off-hand how to implement it. :)
<fullermd> I'm more of an idea rat...
<ksp> mwhudson, from whom can i get i get help about apache configuration for loggerhead
<mwhudson> ksp: i don't really know
<mwhudson> ksp: there's nothing very special about loggerhead though
<mwhudson> ksp: so i'd start with apache's mod_proxy documentation
<ksp> mwhudson, i have done the confugurations what u explained but i think there is something else that i am missing
<ksp> i have downlaoded the bzr-gtk , olive plugin
<ksp> how to enable that plugin
<ksp> i have done the steps given in the README and then when i executed, i am getting an error message ....
<ksp> Unable to load plugin 'bzr-gtk' from '/root/.bazaar/plugins': It is not a valid python module name.
<fullermd> You have to call it 'gtk'.
<fullermd> (of course, first you have to stop running as root...)
<ksp> u mean rename ?
<fullermd> Yah.
<ksp> i am seeing a good gui of olive here http://bazaar-vcs.org/Olive
<ksp> i added the olive plugin under the  ~/.bazaar/plugins and executing the bzr viz int eh working tree gave me a window
<ksp> but how can i see such a GUI given in site, ?
<ksp> i think its using nautilus and i have done the nautilus way of installation as per README explained
<ksp> copying the nautilus.py file into the nautilus extensions path but i am not knowing how to use it
<ksp> can some one here help me, in getting a good GUI like OLIVE work for me
<jam-laptop> ksp: I don't think nautilus.py is what you want
<jam-laptop> You probably just want to run "olive-gtk"
<jam-laptop> which should be in ~/.bazaar/plugins/gtk/olive-gtk
<ksp> jam-laptop, yes running olive-gtk gave me the window
<ksp> jam-laptop, i am not ablet o do any operation like pushing, pulling, branching or any
<ksp> do i need to run it from a working tree
<jam-laptop> ksp: probably, I haven't used olive a whole lot
<jam-laptop> Though I thought you could browse for a working tree
<ksp> jam-laptop, then do u use commands prompt ?
<jam-laptop> I use the command prompt for most of my work
<jam-laptop> but I keep bzr-gtk installed for
<jam-laptop> gannotate
<jam-laptop> gviz sometimes
<jam-laptop> sorry, 'viz'
<ksp> i checked viz, its good enough
<ksp> but how to use gannotate ?
<jam-laptop> bzr gannotate filename
<ksp> jam-laptop, should i be in the working tree /
<ksp> ?
<jam-laptop> yes
<jam-laptop> well, you need to give the path to the file you want to annotate
<jam-laptop> so it might be
<jam-laptop> bzr gannotate tree/filename
<jam-laptop> (that should work)
<ksp> jam-laptop, thats popping up an error , http://pastebin.ca/750314
<ksp> jam-laptop, do u use loggerhead ?
<jam-laptop> ksp: well, I use it in as much as codebrowse.launchpad.net uses it
<jam-laptop> http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes
<jam-laptop> But I have not personally set it up
<jam-laptop> hmm.. your gannotate error confuses me, as Branch objects have  never exposed "get_transaction"
<jam-laptop> Let me investigate bzr-gtk
<jam-laptop> ksp: can you give me the output of "bzr revno ~/.bazaar/plugins/gtk" ?
<ksp> jam-laptop, error,
<ksp> bzr: ERROR: Not a branch: "/root/.bazaar/plugins/gtk/".
<jam-laptop> ksp: where did you install the 'gtk' plugin?
<jam-laptop> You at least said you put it under "~/.bazaar/plugins"
<jam-laptop> Did you put it there as 'olive'?
<ksp> no, its as, gtk only
<fullermd> I think he got a tarball, not a branch.
<jam-laptop> ah, you probably just downloaded one of the snapshots/releases where did you ge
<jam-laptop> where did you get it from?
<jam-laptop> (just to make sure I'm using the same one as you)
<ksp> jam-laptop, i downloaded the tar.gz file from http://bazaar-vcs.org/Olive
<jam-laptop> ok, that would be a very old version (0.12)
<jam-laptop> They have a warning at the beginning, but that should probably be made clearer on the "install" section
<jam-laptop> ksp: http://bazaar-vcs.org/bzr-gtk
<jam-laptop> Has a link for
<jam-laptop> https://launchpad.net/bzr-gtk/0.91/0.91.0/+download/bzr-gtk-0.91.0.tar.gz
<fullermd> Probably should move those links off to an Archive page somewhere...
<jam-laptop> try that one
<ksp> jam-laptop, should i the above source?
<jam-laptop> you should download it
<jam-laptop> and then put it in the same location
<jam-laptop> just rm -rf ~/.bazaar/plugins/gtk
<jam-laptop> and put the new one there
<ksp> yes, now gannotate worked
<ksp> jam-laptop, thankyou
<ksp> i am facing difficulty in setting up the loggerhead for remote access through apache webserver
<ksp> need help in this aspect
<jam-laptop> I really don't know how to set up loggerhead
<jam-laptop> mwhudson might know
<fullermd> I think he's through all the loggerhead part of it, and having issues with the Apache side.  He's been with mhudson on it the last couple days.
<jam-laptop> ah
<jam-laptop> Isn't it just a proxy redirect?
<fullermd> Dunno.  I've been mostly ignoring it in favor of alternating between a flood of Real Work, and spewing verbiage about multi-branch commands.
<jam-laptop> of course, he left before I noticed
<jam-laptop> ...
<fullermd> He didn't _leave_, he's just 'distributed'.
<fullermd> Disconnected IRCing is just ONE of the benefits...
<jelmer> hmm, not good:
<jelmer> bzr: ERROR: Revision {('pqm@pqm.ubuntu.com-20071025022746-ftudwmzir8v2lccc',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x9a57f4c>".
<jelmer> that's what I get pulling from bzr.dev into my own copy (that is using packs)
<siretart> any idea what could be causing this? http://paste.debian.net/40689
<jam-laptop> jelmer: did you run "bzr reconcile" before you converted to packs?
<jam-laptop> There are some known data inconsistencies with bzr.dev
<jam-laptop> which 'bzr reconcile' should fix up
<fosstux> Hi! I'm really new to bazaar. In a local directory I entered bzr init and bzr add - and then I changed everything again. How can I completely delete the revision history?  Or how can I start from scratch?
<jam-laptop> (that I believe are not caught by the pull into packs)
<Lo-lan-do> Hi there
<fosstux> Is the bzr directory dependant?
<LeoNerd> If you remove .bzr, you'll remove all the bazaar history and start from scratch
<fosstux> ah ok
<fosstux> thanks
<jam-laptop> siretart: unfortunately the most likely cause of that is actual disk corruption
<Lo-lan-do> I'm looking for a git-vs-bzr shootout, or a migration guide from one to the other, or something along these lines.
<jam-laptop> We can try to work with you to investigate
<jam-laptop> siretart: but whenever we've seen that, it seems that parts of the file are set to all NULL's
<jelmer> jam-laptop: No, I didn't - I started off with poolie's copy of bzr.dev, which I thought was reconciled
<jam-laptop> (it has happened with people using XFS, and people with machines that are a little flaky)
<jam-laptop> jelmer: I don't know when/if poolie's was reconciled
<jam-laptop> you might try reconcile or 'check' after the afct
<jam-laptop> fact
<jelmer> jam-laptop: k, thanks
<jam-laptop> Lo-lan-do: http://bazaar-vcs.org/BzrForGITUsers
<jam-laptop> though i'm not sure if it is fully fleshed out
<Lo-lan-do> Not much, but it'll be a start
<Lo-lan-do> Thanks :-)
<Lo-lan-do> Is there a public bzr mirror/gateway for the kernel (or for Mozilla)?
<siretart> jam-laptop: could you imagine that file permissions could cause such an error?
<jam-laptop> siretart: that specific error is caused when we try to uncompress a chunk
<jam-laptop> Which means that we've already read the data
<jam-laptop> it just happens to not contain gzip data
<jam-laptop> So I'm guessing permissions aren't the issue
<nekohayo> hello, is it only deltas that are saved between commits, or is a whole copy of the repository created? (I think I can guess the answer, but I'd just like to be 100% sure)
<fosstux> Hi! How long can the initial push last? My initial push is at phase 1 of four - after 2 hours???
<jam-laptop> nekohayo: Generally it is a delta against the previous commit
<jam-laptop> There are times when we store a fulltext, just so you don't have to apply 10,000 deltas to get the newest revision
<fosstux> All together I have 65000 small files - with 404 MB!
<jam-laptop> fosstux: There are a few factors involved, but if you have a lot of files in your project, and a lot of latency, it can take a while
<fosstux> ok thanks
<jam-laptop> fosstux: where are you pushing to? (launchpad?)
<fosstux> yes
<fosstux> The project is an icon theme for kde and gnome, but other desktops as well
<jam-laptop> make sure you are using "bzr+ssh://" rather than "sftp://"
<jam-laptop> 65k icons? Sounds interesting
<jam-laptop> anyway "bzr+ssh" has about 1/3rd the round-trip latencies
<fosstux> that number is including the bzr directory
<fosstux> https://launchpad.net/lila-theme
<jam-laptop> jelmer: ping
<jelmer> jam-laptop, pong
<jam-laptop> jelmer: are you a list admin for bzr-gtk?
<jam-laptop> I just sent a big patch, and it is pending moderator approval
<nekohayo> jam-laptop: thanks for the info :) is there a page documenting in which cases that fulltext is saved? (for the space-constrained cases)
<jelmer> jam-laptop: no, I believe you and poolie are
<phanatic> jam-laptop: i've already approved your mail
<jelmer> jam-laptop: but I do have moderator access, so I can approve it
<jam-laptop> jelmer: technically I am, but he forgot to give me the password
<jelmer> never mind then :-)
<jam-laptop> phanatic: thanks
<jam-laptop> nekohayo: It is based on a simple heuristic, once the size of all deltas ~= size of the previous fulltext
<jam-laptop> we create a new fulltext
<jam-laptop> Or at 200
<fosstux> jam-laptop: all together there are icon themes, backgrounds, window decorations, Login manager themes etc included
<nekohayo> jam-laptop: actually, even if it stores the fulltext, it's only a per-file thing, not the whole repository is saved full text periodically I presume?
<jam-laptop> (the maximum delta length == 200)
<jam-laptop> nekohayo: right, per-file
<nekohayo> jam-laptop: this is great to know, thank you
<fosstux> jam-laptop: and there are even color mods for some files
<jelmer> hmm, looks like the bzr-gtk pqm is down
<phanatic> jelmer: is there a pqm for bzr-gtk?
<jam-laptop> jelmer: then just approve it offline :)
<jelmer> s/pqm/bundlebuggy/
<dato> jam-laptop: I'm not sure I quite understand your last paragraph, "Just do it as part of the "--format" documentation, rather than doing it as separate options.". do you mean mentioning all the possible values in the help="" of the option?
<jam-laptop> The trunk is accessible to all ~bzr developers
<jam-laptop> dato: I'll try to give you an example
<dato> jam-laptop: (I also prefer --foo=bar, fwiw)
<jelmer> jam-laptop: we use bundlebuggy though, and hope to start using pqm at some point (lifeless was going to add bzr-gtk)
<dato> jam-laptop: what I have is http://dpaste.com/23448/
<jam-laptop> dato: http://dpaste.com/23449/
<jam-laptop> dato: sure, that will let you set
<jam-laptop> --sort=alpha
<jam-laptop> It just doesn't document it
<jam-laptop> if you had value_switches=true
<jam-laptop> you could do
<jam-laptop> --alpha
<dato> jam-laptop: right, so I have to add the documentation by hand.
<dato> jam-laptop: yeah, I understand the difference :)
<jam-laptop> dato: unless you want to write support for doing it like http://dpaste.com/23449/
<jam-laptop> Which *I* think would be nice
<dato> I'm just not sure what whoever wrote RegistryOption wants users of value_switches=False to do wrt documentation
<jam-laptop> jelmer: sure, but you need to have a bit more of a test suite before pqm would help a lot :)
<jam-laptop> dato: Abentley wrote RegistryOption, and added value_switches because he wanted --knit instead of --format=knit
<jam-laptop> The documentation just falls out
<fullermd> While we're speaking of those sort of options, does it annoy the crap out of anybody else how --format's description of "default" gives the description of that format, rather than telling me which of the formats IS the default?
<jam-laptop> because you easily add documentation for a *real* option
<jam-laptop> (optparse does it for us)
<jam-laptop> We need to do a bit more custom hacking to add it as part of RegistryOption to add them to the normal help
<fosstux> why is the latency for bzr+ssh so big?
<dato> I see. though in the thread he said not including the documentation for v_s=False was *intentional*
<jelmer> jam-laptop: true, but we've got to start somewhere :-)
<jelmer> jam-laptop: your bundle has some conflicts against current trunk
<jam-laptop> jelmer: probably, I can go through and try to clean them up
<jam-laptop> Not listing the possible values was intentional
<jam-laptop> But I think that was because of the "not adding them as command line switches/options"
<jam-laptop> not because he wanted to hide the documentation.
<jam-laptop> I'll reply to aaron and see what he sasy
<jam-laptop> sasy
<jam-laptop> says
<dato> ok
<jam-laptop> argh...
<dato> I wouldn't mind taking a stab at implementing it
<jelmer> jam-laptop: I've almost got them fixed, ok if I just send an updated version of it to the list?
<jam-laptop> jelmer: I'm happy to have you do my work for me :)
<fullermd> Well, he saw the way you were typing...
<dato> heh
<lifeless> hola
<james_w> hi lifeless
<james_w> lifeless: where have you made it to?
<lifeless> now I just need to fogure out the time here
<lifeless> now I just need to fogure out the time hereand I'm set
<lifeless> bleh, I swear I didn't ht up arrow thre.
<lifeless> LA
<lifeless> notice my sparkling latency crippled typing
<lifeless> fosstux: bzr+ssh - the startup time is likely/probably ssh handshaking; how long does 'ssh host echo' take ?
<fullermd> Might just be that LA air.
<lifeless> I'm using the bottled stuff
<dato> jam-laptop: thanks for the mail
<fosstux> lifeless: well the prompt to enter my passphrase comes instantly
<jam-laptop> lifeless: I don't think you can do "ssh echo" to bazaar.launchpad.net
<fosstux> I entered 'ssh bazaar.launchpad.net echo' - then my passphrase - then I have to press Ctrl-C to quit
<jam-laptop> I suppose you could do "time sftp bazaar.launchpad.net" and then quit right away
<fosstux> well... that time sftp... takes 7 secons to launch and quit - so ssh is not the problem
<jam-laptop> lifeless: do you know any way to time the "ping" to launchpad.net ?
<jam-laptop> ping bazaar.launchpad.net is blackholed
<fosstux> I canceled my bzr push - when I try to restart bzr push I get the following error: Unable to obtain lock bzr+ssh://fosstux@bazaar.launchpad.net/%7Efosstux/lila-theme/main/.bzr/repository/lock held by fosstux@gmail.com on host fosstux [process #11873] - locked 1 hour, 55 minutes ago
<fullermd> I can ping code.  ~150 from here.
<fosstux> what is wrong?
<james_w> fosstux: the lock was not removed when you cancelled.
<fosstux> and what can I do about it?
<jam-laptop> fosstux: you just need to
<james_w> you can 'bzr break-lock bzr+ssh://fosstux@bazaar.launchpad.net/%7Efosstux/lila-theme/main/'
<jam-laptop> bzr break-lock URL
<fosstux> ok. thanks.
<lifeless> jam-laptop: no
<lifeless> jam-laptop: but its the same dc, so pingling lp is equivalent except in exceptional crcumstances
<fosstux> I'll simply let bzr push run - however long that lasts...
<jam-laptop> well, if you got 65k files from 'find', and 150ms latency
<jam-laptop> that would be something like 65k*.150 = 9750 seconds
<jam-laptop> or 2.7 hours of round trip time
<jam-laptop> and then add a bit more for other stuff
<jam-laptop> which is why 0.92 is going to have a streaming protocol
<jam-laptop> to avoid all the round trips
<james_w> is it sha1s that log -v --show-ids puts by the filenames?
<fullermd> I'm pretty sure it shows the file-ids...
<james_w> ah, that makes more sense, thanks.
<jam-laptop> james_w: so if you are using a hash for bzr-git, then you would see something that looks a lot like a hash :)
<james_w> yeah, that's what confused me.
<james_w> I should have spotted it was too short for a sha though.
<fullermd> So it's a sh then?
<lifeless> also
<lifeless> packs for the  win
<lifeless> james_w: I don't think 0.92 has streaming push, only sreaming pull
 * fullermd blinks.
<fullermd> It isn't the same operation?
<lifeless> no
<lifeless> while it is symmetrical, wire protocols that are request-response are not symmetrical
<lifeless> symmetry is broken
<fullermd> So it has "gimme a box full of crap" but no "here's a box full of crap", even though both boxes would be packed up identically?
<lifeless> right
<lifeless> and the support code for crapping, and pawing through the crap is reusable
<lifeless> it just has to be [heh heh] glued together
<fullermd> Well, as long as we have a box to hold the crap until we get around to gluing it...
<lifeless> rofl
 * fullermd contemplates titles that could be printed on spiv's business cards...
<lifeless> I think that may have not been the best impression to give
<lifeless> possibly the most accurate
<fullermd> Hm.  Y'know those "how shit happens" lists of religions?  We should write one for version control systems based around "you crap in a box"...
<jam-laptop> fullermd: One of the big reasons is that it is easy to send a HTTP POST and stream the response that is sent back
<lifeless> making me squeal in an airport lounge is nasty
<jam-laptop> it is *hard* to stream the POST
<jam-laptop> I don't know if you saw spiv 's comments
<jam-laptop> but basically, the problem is the remote side may not support the request
<fullermd> Darcs: You crap in a box, and put it with all your other boxes.  When you're not looking, your boxes are rearranged.
<LeoNerd> SVN: Any time you want to change the crap, you just take a cheap copy of it and modify it in some small way
<jam-laptop> and you don't really want to POST up a 10MB stream
<jam-laptop> just to get back "not supported"
<lifeless> jam-laptop: this is not http related though
<lifeless> jam-laptop: this is our initial smart server protocol model
<jam-laptop> lifeless: sure, I'm just mentioning why some of it is that way
<jam-laptop> at least at a conceptual level
<lifeless> right, I'm only objecting to the HTTP thing there
<lifeless> request-response protocols are hard
<lifeless> so I'm down to only two uses of inventories in commit.py
<jam-laptop> I have a feeling there is a big jump from 2 to 0
<jam-laptop> but nice to see progress :)
<lifeless> one is 'set of all ids'
<lifeless> the other is record_entry_contents
<lifeless> once this is done, the uses of inventory are hidden on the tree interface
<jam-laptop> why is bzr.0.91 in Launchpad owned by jml?
<jam-laptop> https://code.edge.launchpad.net/~jml/bzr/bzr.0.91
<lifeless> if we then implement a native iter_entries_by_dir
<jam-laptop> lifeless: I would like to see a way to get the root id for a tree
<jam-laptop> That Tree.inventory.root.file_id is a bit ugly
<jam-laptop> that is separate
<lifeless> jam-laptop: add a tree_implementations/test_root_id.py with a trivial test and trivial method
<jam-laptop> lifeless: so you consider it worthy?
<lifeless> yes
<jam-laptop> I just know it is one of the inventory accesses I need to do for tests
<lifeless> its punishing to do a full conversion to inventory for that one attribute
<lifeless> I really want to promote most things to tree
<lifeless> inventory is a great *impklementation*, not a great generic interface
<jam-laptop> jml: ping
<lifeless> rofl
<lifeless> 3am  for him
<lifeless> on saturday
<jam-laptop> lifeless: I've seen you and igc around at those times :)
<jam-laptop> I can always just create the 0.91 mirror
<jam-laptop> It just seemed silly to have 2 of them
<lifeless> what is the issue ?
<lifeless> is his one wrong? or just wrong owner ?
<jam-laptop> just the wrong owner
<jam-laptop> and marked as Development/New rather than Mature
<lifeless> hmm
<lifeless> I think you are confused
<lifeless> thereis no 0.91 blessed branch - https://edge.launchpad.net/bzr/0.91
<lifeless> jml has chosen to have a 0.91 branch of his own is all
<jam-laptop> you are probably right, but there is a mirror of 0.91 already in launchpad
<jam-laptop> And I *think* you can't register 2 mirrors
<jam-laptop> for the same branch
<jam-laptop> But maybe that is just for the same user
<lifeless> per user
<lifeless> because otherwise randoms could attack namespaces
<jam-laptop> weird, it allowed me to register a branch as ~jml
<jam-laptop> by going to code.../~jml/+addbranch
<jam-laptop> Or at least it tried and failed because it was already mirrored
<jam-laptop> lifeless: you are wrong
<jam-laptop> It is failing to register as ~bzr
<jam-laptop> because it is registered as ~jml
<lifeless> uhm
<lifeless> oh, this is a nonsense IMNSHO
<lifeless> hang on I'll fix, but please file a bug :)
<jam-laptop> I'll file a bug
<jam-laptop> is this under launchpad-bazaar?
<jam-laptop> Or just launchpad
<lifeless> launnchpad I think and let it get moved by them
<jam-laptop> k
<lifeless> actually wait a second
<lifeless> no do it
<lifeless> whats happened though is that the owner/registrant thing has confused you
<jam-laptop> how so?
<jam-laptop> I am unable to change the status for that branch
<jam-laptop> which means it has the wrong owner
<lifeless> the owner/reigstrant split for branches is a hack
<lifeless> its not done generally thoughout the lp datamodel yet
<lifeless> https://code.edge.launchpad.net/bzr/
<lifeless> look for 0.91 there
<jam-laptop> sure, it is down low for bzr.0.91
<jam-laptop> And the link is to ~jml/...
<lifeless> but the name beside it is 'bazaar developers'
<lifeless> anyhow, fixed
<lifeless> registrant/auhtor split I should have said
<jam-laptop> sure, the Author was Bazaar Developers, but the registrant was ~jml
<lifeless> so jam-laptop journalled inventories, did my reply make sense?
<jam-laptop> I think so, but I haven't fully parsed it yet
<lifeless> coo
<lifeless> nDuff: did you mail me another callgrind file? I may have missed it but I didn't see one
<lifeless> ok, time for pancakes. Just because.
<lifeless> next stop cambridge
<Vantage> hi, how do you revert out all changes from a specific branch/merge (older than the previous merge)?
<james_w> Vantage: you can use bzr merge.
<Vantage> eg. if I merge files from brance a, then branch b, then branch c into my branch and commit each.  How do I later revert out the changes from branch A?
<james_w> I'm not positive it works for merge commits though.
<james_w> if you give the revisions "backwards" then merge will undo those changes.
<james_w> so 'bzr merge -r4..3' will revert the changes between 3 and 4.
<james_w> if you don't like what happens, simply bzr revert.
<Vantage> are the revono per file or for the whole tree
<Vantage> or how do I see the history of merges in the repo?
<james_w> whole tree.
<james_w> bzr log will show you.
<james_w> commits that were merged in will be indented.
<Vantage> k.  I thought that was per file, but that's good to know it's the whole tree
<Vantage> hrmm when I do a bzr merge -r14437..14436 I get "bzr: ERROR: Requested revision: u'14437' does not exist in branch: BzrBranch5"
<Vantage> but those are the numbers I get from bzr log
<james_w> try adding a '.' at the end.
<james_w> doing that will make it use your current branch as the merge source.
<Vantage> ah.... :)
<james_w> at the moment it is using the remembered merge source.
<Vantage> that works.  Of course this means you can't cherry pick out a previous merge, right?  Only rolling back to a previous revision?
<james_w> sorry, I don't understand the question.
<Vantage> If I'm at rev 10, I can go from 10 to 9 or 10 to 7, but I can't keep revisions 10 and 9, but remove 8
<james_w> if you do 'bzr diff' does it just show the changes that were introduced by that merge being reverted?
<james_w> yes, you can, that is what this should be doing.
<james_w> 'bzr merge 9..8' should do that.
<Vantage> oh really?  That would be really cool.  Let me try that (I was only trying new commit to older)
<james_w> (though sometimes I get the numbers wrong)
<james_w> remembering what the boundaries should be can be tricky.
<fullermd> I think removing 8 would be 8..7
<james_w> see :)
<jam-laptop> -rX..Y is "merge the changes from Y versus X"
<jam-laptop> so the change of 8
<jam-laptop> is against 7
<jam-laptop> -r 8..7
<jam-laptop> is correct
<jam-laptop> just like cherry picking revs 8, 9 and 10 is the difference from 7 - 10
<jam-laptop> so bzr merge -r 7..10
<james_w> thanks fullermd and jam-laptop.
<jam-laptop> also "bzr diff -r X..Y" should give you a preview of what it will do
<Vantage> jam-laptop: so when you say "preview" how would you do that before you merge?  specify the other repo?
<jam-laptop> Vantage: yes
<Vantage> jam-laptop: very cool
<jam-laptop> Just saying that diff takes approximately the same arguments as merge
<jam-laptop> There may be a bug about "bzr diff -r X..Y http://remote/branch" not working
<jam-laptop> jelmer: any comments on my patch?
<jelmer> jam-laptop: Yes, they're coming up
<jam-laptop> (I'm guessing if you are submitting it under your name that you like it :)
<jam-laptop> k
<bos> jelmer: ping
<jelmer> jam-laptop: will send them once I finish my slot in the open week session
<jelmer> bos: Hi
<bos> jelmer: what does bzr-svn do when you try to push changes from a branchy bzr repo to svn?
<bos> does it create temporary branches in the svn repo so all of history is preserved?
<jam-laptop> I'm pretty sure it just pushes the mainline revs
<jam-laptop> and just marks the others as theoretical merges
<bos> oh, right, bzr has a mainline :-)
<jelmer> bos: yes, it just pushes the mainline revisions
<jam-laptop> but jelmer would know better
<bos> ok, thanks.
<jam-laptop> bos: long time no see
<jelmer> bos: and ignores the merged revisions
<jam-laptop> how are things going?
<bos> i'm trying to decide what the hg equivalent ought to do, since we don't have a mainline.
<jelmer> bos: when pulling changes in, they're recognized as ghosts
<bos> jam-laptop: all's well. and yourself/
<bos> ?
<jelmer> bos: How's hg-svn going?
<bos> jelmer: i just started work on it.
<jam-laptop> bos: things are going well here
<bos> i'll probably just pick the hg branch with the most accumulated changes and push that
<jam-laptop> do you know how git-svn does it?
<jam-laptop> Since they have similar ancestry as hg would
<bos> git-svn picks an arbitrary branch
<bos> the doco says "please please oh please keep your history linear", pretty much
<jam-laptop> bos: so for hg, you don't preserve merge parent order, right? (you sort() the hashes?)
<bos> we do preserve the order, yes.
 * fullermd blinks.
<bos> the left parent is "mine", and the right parent is "theirs".
<jam-laptop> so when you merge, you remember which was left and which was right?
<jam-laptop> ok
<jam-laptop> I thought I saw a sort() in the past
<fullermd> That sounded almost like the question was "which branch do you push", and the answer was "these are the revs in the branch we push"...
<jam-laptop> But that might have been something else
 * bos detests the svn client API
<jam-laptop> ah, it is just when you generate a child hash
<jam-laptop> you sort the parents first
<jam-laptop> and then hash the set
<bos> heh. that's probably not even worth doing, since the hash is going to depend on the order of the parents anyway.
<Vantage> Hi, I did a cvs import of a project to bzr, and when I checkout/branch from one of the CVS branches, I get the knit files for the whole repository, which causes the branch to be really slow.  Is there a way to only get what's required for the branch?
<fullermd> Well, those files _are_ what's required for the branch   :)
<fullermd> If you wrap a shared repository around the branches, you'll save the copying time (as well as space).
<Vantage> fullermd: all of them?  I should just need the ones for the branch I'm checking out, right?
<Vantage> fullermd: I end up getting 791MB worth of knits for a 200MB checkout...
<fullermd> Well, it should only copy the revs for the branch you're making.
<fullermd> Well, with a reasonably length history, that sounds reasonable.
<Vantage> fullermd: it doesn't seem to.  If I look in the repo created by bzr-cvsps-import the knits are all stored together, not sorted by branches.  When I checkout I get all of them
<fullermd> That doesn't mean you get all the data from the kints, though.  There's a knit per file, and all the branches probably have the same files, so you'd get all the same named knits.
<fullermd> But I'm pretty sure you should only get the revs in each knit that apply to the given branch.
<Vantage> fullermd: hrmm, I think your right.  The sizes don't seem to match up quite right
<fullermd> Still a lot of history, 'course.  Using a shared repo around your branches would be a big savings cvsps-import puts all its branches in a repo together already, I think)
<Vantage> fullermd: yeah, but you have to do lightweight checkouts, right?
<fullermd> Wow, how'd I miss the ( before cvsps-import in that line?  I must be tired...
<fullermd> Not necessarily.  You could use lightweight checkouts, or you could use normal bzr-ish colocated working trees in the branches.
<Vantage> normal bzr-ish colocated working trees in the branches?
<Vantage> fullermd: what's that?
<fullermd> Hrm.  What's your bzr experience?
<Vantage> fullermd: just getting started :)
<fullermd> Ah, OK.  CVS background?
<Vantage> fullermd: yup and trying to get a fairly large repo converted over
<Vantage> fullermd: the conversion has gone fine, I'm just trying to figure out the best way for us to use it
<jam-laptop> Vantage: how big is your CVS repo
<Vantage> fullermd: so far lightweight checkouts is the front runner, but i'm curious if there's  a way to speedup normal branching
<fullermd> 'k.  Well, let's skim over concepts quick first, then look at what you'll do with it.
<fullermd> In CVS you have your two pieces; your checkout, and the repo.  In bzr there are 3 pieces; your working tree (which is equivalent to the CVS checkout), the branch, and the repo (those two together roughly correspond to the CVS repo)
<fullermd> All 3 can be in the same place; that's what you get with a normal "bzr init"; your working tree is right there, and your branch/repo are in the .bzr dir in the root of that tree.
<Vantage> right, took awhile, but I've got that one figured out :)
<Vantage> right
<fullermd> Or all 3 can be in different places, or 2 can be in one place with the third in another.
<fullermd> What you have from cvsps-import should be a shared repo (with the repo in somedir/.bzr), with a set of branches in it (somedir/branch1, somedir/branch2, etc, or some slightly differing layout, but all inside somedir/)
<Vantage> yup
<fullermd> And no working trees at all (they don't _have_ to exist for bzr to have the data, any more than a CVS repo _needs_ checkouts)
<fullermd> Of course, you need the working trees to...   y'know.  Work.  So you'll have to get 'em somewhere.
<fullermd> You can have them "normal bzr-fashion", colocated with the branches (that happen to be in the repo, though that's just a detail).  Or you can have them somewhere separate from the branches.
<fullermd> To work out how you should go, now we need to look at your particular use-cases.
<fullermd> So, how big is this, how many people are working on it, and what sort of physical infrastructure are you working over?  All on one box, 3 guys on the moon, etc?
<Vantage> well the repo size for the one module i'm testing with is 2.3GB in cvs.  We have several large modules we might be converting
<Vantage> each module has roughly 5-10 developers working on it
<Vantage> the repo is on one machine, everyone else has their own checkout sandboxes they develop in
<Vantage> plus testing environments
<Vantage> so shared repo with lightweight checkouts seems to fit from what I've been reading
<fullermd> OK.  I presume you're also intending to mostly duplicate your existing CVS workflow and then phase in more distributed pieces over time, rather than try to jump whole-hog into an uber-distributed setup.
<Vantage> fullermd: right
<jelmer> abadger1999: Please feel free to send patches you include in the fedora packaging for bzr-gtk to the bzr-gtk mailing list
<fullermd> Lightweight checkouts would work well, as long as you're one one machine.  Across a fast LAN, they may work OK (I've not tried).  But they would be unpleasant on anything slower.
<jelmer> abadger1999: we'd be interested in including some of them
<abadger1999> jelmer: Cool.   Where's the bzr-gtk mailing list?
<abadger1999> I'll sign up and start sending.
<jelmer> the address is bzr-gtk@lists.canonical.com
<jelmer> details on https://lists.ubuntu.com/mailman/listinfo/bzr-gtk
<abadger1999> Thanks
<fullermd> (me, I'd use normal 'heavy' checkouts any time the branch wasn't on local disk)
<Vantage> fullermd: more unpleasent than cvs?  The checkins are more resource intensive than the cvs ones?
<fullermd> Well, theoretically, it could be much better.  In practice, right now, going across the network is slow and somewhat clumsy.
<fullermd> (clumsy internally, I mean; from the outside it's all black-box)
<Vantage> fullermd: is it bad to the point of unusable?
<fullermd> You wouldn't notice it on commit or update, probably.  But things like diff and log would probably be really sluggish.
<Vantage> fullermd: now we also do feature based branching, so a lot of new branches with small changes are created.  This is where heavyweight checkouts and branching can become a problem, since these are very slow even on the local machine...
<fullermd> Well, the [first] heavyweight checkout will be slow to initially create.  But later branches, as long as they're done in a repo, should be pretty fast.
<fullermd> And later checkouts of related branches should be pretty fast in a repo too, since they'd only have to copy non-shared data.
<Vantage> fullermd: I'm not sure I follow.  So I'd do a heavyweight checkout (slow), and then how would I make the branches within the repo?  Or is the new branch the repo?
<fullermd> Well, this is a mental departure from CVS.  In CVS, the repo is pretty important; in bzr, it's conceptually not.
<jam-laptop> Vantage: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
<jam-laptop> Vantage: you can have a *local* "shared repository" and a centralized one
<fullermd> A shared repo can exist or not, and the only difference generally is performance/space.
<fullermd> Right, what jam-laptop said.  The devs would have a shared repo on their system, into which they checkout (and within which they branch).
<radix> the problem is that "shared repository" sounds an awful lot like a thing used to share branches between developers.
<fullermd> There's also a shared repo on the server, containing the branches there.  The two don't have any necessary relation to each other; it's all about the branches.
<Vantage> fullermd: So with a shared repo and lightweight checkout I can create a new branch on the remote server (fast) and then use bzr switch on my local checkout (also fast).  With a heavyweight checkout what would be the equivelant process?
<jam-laptop> "shared" is between branches, not between people
<fullermd> Pretty much the same.
<Vantage> fullermd: also, when you branch into your local shared repo do these have to be manually merged back to the central shared-repo
<jam-laptop> radix: but I agree there isn't a good term for distinguishing
<fullermd> I think 'switch' doesn't work for heavy checkouts, so the steps there would be a bit different.  But there's no reason it _couldn't_ (and probably should).
<fullermd> If you _branch_ locally, that branch you created only exists locally.  So if you want it visible outside, you either need to merge it into an outside branch, or push it somewhere.
<fullermd> Here's a common workflow I have:
<Vantage> fullermd: right, switch doesn't, so i'm wondering what you would do instead with heavyweight checkouts.  branch from remote, branch local, commit, merge back?
<fullermd> - Central branch on a server way out 'cross the Internet from me.
<fullermd> - [Heavy] Checkout of that branch on my workstation.
<fullermd> (that checkout called 'trunk' let's say)
<fullermd> - I 'bzr branch trunk feature-x' to make a branch to work on some feature, then I go off and work in that branch for a while.
<fullermd> So feature-x accumulates commits for a while, independently of trunk.  That branch doesn't exist and isn't known about anywhere but on my system.
<fullermd> (meanwhile, other people can be making commits in trunk.  Or _I_ can, for other stuff that comes up while I'm working on the feature)
<fullermd> Eventually, feature-x is done (or done enough to take live).
<fullermd> I go into my 'trunk' checkout, do an 'update' to be sure I'm up to date (just like with CVS).
<fullermd> Then I "bzr merge ../feature-x" to merge in my feature changes.  Check it over, resolve any conflicts, then commit.
<fullermd> Since 'trunk' is a checkout of the main trunk, that commit then takes all those changes live and widely visible.
<fullermd> The feature-x branch itself has never lived or existed anywhere but on my workstation.  But after the merge, its revisions are in the trunk, so they're visible to everywhere.
<fullermd> Now, if feature-x were going to be a longer project involving other people, I'd make the feature-x branch on the server instead of my workstation, and we'd all check it out alongside/instead of 'trunk'.
<Vantage> fullermd: so does bzr branch trunk feature-x create another working tree?
<fullermd> Well, it creates another branch, which may or may not have a WT with it.  In my case, it does.
<Vantage> fullermd: and once you've merged it to the central server could someone conceivably checkout specifically that branch?  Or is only the history available?
<jam-laptop> Vantage: if the history is available, you can checkout a WT
<Vantage> fullermd: Is there a way to do it without another working tree?  That's another appealing part of the bzr switch.  Only one copy of the working tree
<Vantage> jam-laptop: thanks
<fullermd> Well, somebody could _recreate_ the branch (not _quite_ entirely, but near enough)
<fullermd> Well, you could use local lightweight checkouts, and not have WT's in your local repository.
<Vantage> fullermd: how would you get the local repository without doing a checkout/working tree and still have commits in the local tree go back to the central server?
<fullermd> Then you'd have (lightweight checkout) -> (local heavy checkout with no working tree) -> (remote branch you checked out)
<Vantage> fullermd: how do you get "local heavy checkout with no working tree"?
<fullermd> It would take a few more commands to work with, but it's workable.
<fullermd> I dunno if you can easily make it happen directly.  What you'd do is make the local heavy checkout the normal way, then dispose of its working tree ("bzr remove-tree").
<Vantage> ah..
<jam-laptop> "bzr branch + bzr bind" into a repository with "no-working-trees" set
<fullermd> I s'pose you could branch (into a non-tree repo), then bind.
<jam-laptop> Is the easiest way
<jam-laptop> You could leave no-trees set
<jam-laptop> and then just manually "bzr checkout ."
<fullermd> That works because as an implementation detail, a heavy checkout is actually a branch, with some extra fixins to push changes upstream.
<Vantage> of course it's not too bad to have one extra working tree, as long as we're not keeping many working trees...
<fullermd> (which I really wish we'd de-emphasize)
<fullermd> And don't forget, you can dump working trees with remove-tree and re-create them with checkout at will.
<fullermd> So if you're not gonna work on a branch for a while, you can just get rid of its tree until you need it again, just like you could rm -rf the checkout of a CVS module you don't need for a while.
<Vantage> nice
<Vantage> ok, well this gives me some stuff to play with.  Thanks for the tutorial guys!  I'm sure I'll be back with more questions later :)
<fullermd> Gaah.  CentralizedWorkflow has that evil "make ~ a repo" thing going on   :|
#bzr 2007-10-27
<TeTeT> any idea what's wrong here:
<TeTeT> % bzr push
<TeTeT> Using saved location: bzr+ssh://tspindler@bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta/
<TeTeT> No handlers could be found for logger "bzr"
<TeTeT> Connection to bazaar.launchpad.net closed by remote host.
<TeTeT> bzr: ERROR: exceptions.AssertionError: end of file reading from server
<jkakar> Do the --fixes and --author options to 'bzr commit' do anything other than add metadata to the revision?
<jkakar> TeTeT: That looks a misconfiguration in Launchpad (which is a complete guess on my part).
<TeTeT> jkakar: ok
<jelmer> jkakar: no, revision metadata is all it is
<jkakar> jelmer: Ah, cool.  Thanks.
<jkakar> Hmm.
<jkakar> Can one pass multiple bug numbers to --fixes.  ie: Is it just a string that can be used like: bzr commit -m "My message." --fixes "1234,2345"
<jkakar> Hmm.
<jkakar> Am I missing something or are --fixes and --author values not shown in bzr log?
<jkakar> How do I discover this data?
<jkakar> Actually, it does appear to include an "Author: ..." line in the log.
<lifeless> rofl
<lifeless> btw, hi
<jdub> how much space does bzr use when committing binary files?
<spiv> jdub: "some" ;)
<jdub> does it have another complete copy of the binary file in the repo, and a new one for each change, or...?
<spiv> jdub: if you commit multiple versions of a binary file, it'll typically do ok deltas of that (splitting on \n, just like text files), and I think there's also some gzipping on top of that.
<jdub> but the initial commit will pretty much double the size (between the working dir and repo)
<jdub> ?
<spiv> I'm not sure what you mean.
<spiv> The initial commit has to make a copy of the file to record it in the repo.
<spiv> So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping).
<jamesh> jdub: it depends on how well the binary compresses
<jamesh> same for text
<spiv> jdub: still here?
<jdub> yeah, sorry
<jdub> back
<spiv_> <spiv> I'm not sure what you mean.
<spiv_> <spiv> The initial commit has to make a copy of the file to record it in the repo.
<spiv_> <spiv> So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping).
<spiv_> <spiv> bzr doesn't cope particularly gracefully with large files yet (binary or not).
<spiv_> <spiv> (hooray, lag)
<spiv_> <spiv> It'll hold the entire file in memory (sometimes two or three times) to do some operations.  So depending on the files, that might be a larger problem for you than the repo size.
<spiv_> (not sure how much of that got through the first time)
<jdub> yep, go all that
<spiv_> Ah, good :)
 * jdub has a starting point of 514MB of binary files... ;-)
<jamesh> ISO images?
<spiv_> Ah-hah.  I thought you might have large files given that you were worried about repo size...
<jdub> jamesh: almost -- windows xp install files 8)
<jamesh> jdub: ah.  514 MB of files total rather than a single 514 MB file
<jdub> yeah
<jamesh> jdub: so you probably need to worry more about the maximum sized file
<jamesh> and the gzip compression probably won't help much, since the install files would already be compressed
<spiv> The good thing about compressed files is they typically have \n bytes at regular intervals...
<weigon_> jelmer: g'morn ... bzr branch against a svn-tree still doesn't work: http://p.caboo.se/111476
<fullermd> Boy, it sure is nice and quiet when everybody's off at meetings...
<lifeless> morning
<lifeless> fullermd: bite your tongue
<lifeless> :)
<fullermd> Did that yesterday, actually.  It'll be a few more days yet before I forget how much it hurt and do it again.
<lifeless> heh
<lifeless> hi thumper, phanatic
<phanatic> hey lifeless
<thumper> lifeless: howdy
<Verterok> beuno: ping?
<beuno> Verterok, pong!
<Verterok> Hi!
<bialix> hey lifeless
<beuno> hey, I finally re-implemented the new XML format and been using it for a week or so
<bialix> luks: ping
<Verterok> beuno: availabale for a chat about xmloutput? (mainly about log --xml)
<beuno> Verterok, everything works great. Just had that small glitch with the XML format, which I saw you already fixed in trunk
<beuno> Verterok, sure
<luks> bialix, hi
<Verterok> beuno: nice!
<bialix> hello, luks
<bialix> did you see my e-mail about QBzr(qlog) + packs
<Verterok> beuno: it's fixed more or less :P. I found a few cases not handled (correctly) by the plugin
<luks> yes
<luks> it probably just need some lock_read/unlock calls
<luks> *needs
<beuno> Verterok, is it skipping revisions, or just XML correctness?
<luks> but I haven't tested it on any pack repo yet
<bialix> luks: I think so
<Verterok> beuno: xml correctness in deep merges
<bialix> luks: goffredo did good job with unidiff, I integrated second version of his patch to my branch.
<beuno> Verterok, when specifically does it fail?  I haven't bumped into it these days yet
<Verterok> beuno: the current issue is how to correctly show some cases like a merge who has a merge inside it
<beuno> (I'm parsing XML in a much more stricter way so I can eventually release the code and help test the XML a bit better)
<Verterok> beuno: I found it testing with in bzr.dev
<beuno> Verterok, so it's when you have nested merges?   how does the regular bzr log output show that?  it keeps tabulating?
<Verterok> beuno: running bzr log -r 2420..2481 in bzr.dev (with and without --xml switch)
<Verterok> beuno: the case can be found in the revno 2447.1.7
<Verterok> beuno: the nested merge is revno 2208.4.4
<beuno> Verterok, that's odd, 2447.1.7 is only one level deep
<beuno> I see 2466 > 2447.1.7
<beuno> Verterok, I see what you mean with 2208.4.4
<Verterok> 2447.1.7 -> 2208.4.4 (without a log )
<Verterok> beuno: the current xml don't support this kind of nested merge, the problem seems to be that we expect that all merge have a <log>, but this case doesn't have one :P
<Verterok> beuno: it's not a problem for your parser (at least I think so), because the revision is included in the xml, but it isn't nested correctly
<beuno> Verterok, AFAIK, it breaks the structure, right?  the <merge> bit
<Verterok> beuno: yes
<beuno> Verterok, I don't think we have 2 level merges yet, but I do want to make the parser as strict as possible, to help test the plugin out as much a possible
<Verterok> beuno: I'm working in a test case for it and thinking how we should handle this case. any ideas are wellcome :D
<beuno> Verterok, <merge> within <merge> comes to mind
<beuno> although it isn't pretty, but come to think of it, neither is XML  :p
 * Verterok agrees
<Verterok> ok, if it's ok with you, I can fix this with nested <merge> tags
<beuno> Verterok, absolutely, I can't think of a better way
<Verterok> beuno: I finished almost all unittest, only misssing is missing (what a problem ;) )
<beuno> Verterok, hahahah, I saw, I'm still not sure how the tests work though, haven't played around with em
<Verterok> beuno: no prob, I'll write it.
<Verterok> beuno: Also, I created a XMLLineLogFormatted to use it in pending merges, i think it can be usefull for missing
<beuno> Verterok, I've been thinking on the best way to structure that, even for future use cases
<beuno> I might try and actually put my idea down as code
<Verterok> sure! if you need some help, and I can do something, just tell
<Verterok> beuno: ah, I see your fix to the path escaping. I found that in bzrlib.xml_serializer there is a _escape_cdata to handle entities escaping
<beuno> Verterok, oh, yeah, I was pretty sure that wasn't the best approach, I just needed to get it working at that point, so I did one of those ugly workarounds expecting you to come up with a much more elgant solution  :D
<beuno> did you implement that on all user input?
<Verterok> jajaja
<beuno> because I only fixed it where I had the problem, didn't sanitize all the XML as I probably should of
<Verterok> not sure if it's in all user input, i need to check that. I added it to path, commiter, commit message
<beuno> Verterok, I think all that would be left is branch-nick
<Verterok> beuno: the branch-nick it's handled in log, but not in version, fixing it. thanks!
<beuno> Verterok, np, you're basically fixing things that I won't have to, so it's convenient :D
<beuno> about the code restructure thing, I was thinking we might want to have a specific class that takes a revision number and returns it in XML, and we can use that from all commands
<beuno> then just loop through whatever command, and add any magic needed (<merge>, etc)
<beuno> that way we can centralize all data sanatization in one place
<beuno> (I'm thinking ahead here, for when we try and push this as part of the actual bzr code)
<beuno> that might make it easier to re-use that bit of code from everywhere else
<beuno> I was thinking maybe just passing the revision number to it, and let it return it nicely formated
<Verterok> sure, in the case of log, this is done in XMLLogFormatter.logrevision, but it recieves a LogRevision not revno
<beuno> not sure how that would hit on performance though
<beuno> right, LogRevision sounds saner
<beuno> but don't we have much duplicated code?
 * beuno goes and looks at the latest version
<Verterok> LogRevision actually is bzrlib.log.LogRevision
<beuno> Verterok, right, the code *is* already structured pretty much that way...
<Verterok> yes, but in not convinced with the current logformatter in bzrlib, in the case of the xml output we need to do a lots of workarounds to handle merges, etc
<beuno> right, that does seem the root of the messy code
<Verterok> the issue is that the logformatter recieves one revision at a time, and doesn't known anithing about the context of that revision (if it's in merge or whatever)
<Verterok> s/anithing/anything/
<beuno> we should atempt to clean that up in a way that's convenient to format, and see if that still works cleanly with bzrlib
<beuno> Verterok, the current output adds tabs to it, so it does know at some point if it's a merge
<beuno> maybe we can hook there
<beuno> tab == merge
<beuno> no tab now, but yes before == close merge
<beuno> might be cleaner
<beuno> and offloads the scaling problem to bzr devs  :D
<Verterok> yes, last night I make some cleanup of the xml logger and started to work that way cheking the merge_depth value
<beuno> ah, you've been doing a lot of "doing", I haven't gotten past tossing it around in my head
<Verterok> I'm quite sure that the way to go, and keep the logfomatter untouched
<Verterok> me neighter ,I screwed log --xml badly  :D
<beuno> muahahah
<beuno> well, aside from the little tweak I added, the rest went perfectly this week
<beuno> even added the feature for users to see their commits from our software
<Verterok> great!
<beuno> so everybody had their attention put on if they actually showed up
<beuno> found a few bugs in the way I was doing things thanks to that
<beuno> I'm confident I'll be able to release a loggerhead-like thingie in php in a near future
<Verterok> user feedback is really helpful
<Verterok> thanks to that I have 4 or 5 bugs to fix in bzr-eclipse, but first I need to close the nested merges things
<beuno> yes, once I gather the patience to listen to absurd complaints from the windows-using graphic designers, feedback is great  :p
<beuno> Verterok, ah, yes, I have steared a few ppl asking questions about bzr-eclipse here towards Launchpad these days
<beuno> to bugs/questions
<beuno> haven't atempted to use it in a long time know, so I'm not confident enough to answer anything
<Verterok> it's slowly becoming more usable, maybe in a few days (with xmloutput fixed, and the changes to bzr-eclipse) I can promote it to "beta" and make a 0.1 release
<Verterok> tought, the pre_alpha warning scared some users :P
<Verterok> maybe a "its' beta" warning is more user friendly :D
 * Verterok lunch
<Verterok__> beuno: seeya later
<beuno> Verterok__, buen provecho
<Verterok__> thx!
<hsn_> release schedule for 0.92?
<jelmer> weigon_: thanks, fixd
<weigon_> what ever I touch breaks :)
<jelmer> that was actually a bit of carelessness on my side
<Peng> "knitpack"? Not "knit-pack"?
<weigon_> jelmer: I'm on 760 now, but still exploding
<weigon_> but I think "StopIteration" is the bzr.dev on from 2-3 days ago
<weigon_> jelmer: http://p.caboo.se/111576
<weigon_> bzr.dev and bzr-svn are current
<weigon_> it is a clean 'bzr branch'
#bzr 2007-10-28
<Peng> bzr upgrade --help links to http://doc.bazaar-vcs.org/latest/developers/knitpack.html, but that's a 404.
<fullermd> I think those docs are manually generated, not auto.  Probably hasn't been done since that doc got put in.
<Peng> Who gets bribed to run the update script?
<fullermd> poolie usually, I think.
<fullermd> But being as everybody is IRC'ing from airports these days...
<xxxYURAxxx> A music messaging session has been requested. Please click the MM icon to accept.
<xxxYURAxxx> how much IDE supported bazaar?
<Peaker> hey, googlecode is offering svn servers. Is there any free code hosting service that can run bzr serve for free?  Or at least any file hosting service usable for this purpose with bzr?
<Peaker> I am sick of svn :-(
<radix> Peaker: Anyone who can host ssh or sftp or ftp can be a bzr host
<Peaker> radix: which free services can guys here recommend though?  What do you use for bzr hosting?
<radix> Peaker: mostly launchpad
<radix> which actually supports bzr+ssh, in addition to sftp
<Peaker> cool, it does free project hosting?
<radix> yes
<Peaker> can I import all of my svn history into a bzr branch that I upload to launchpad?
<radix> Peaker: if you have a project, you can push/etc with bzr+ssh://bazaar.launchpad.net/~<username-or-team>/project-name/branch-name
<radix> Peaker: yes
<radix> Peaker: you have several options
<radix> Peaker: use the bzr-svn plugin, use svn2bzr, or get launchpad to do the code import for you
<Peaker> radix: the last one sounds interesting
<Peaker> radix: thanks for the tips!
<radix> Peaker: it's often pretty convenient :)
<radix> no worries
<jelmer> weigon: you're running bzr.dev ?
<jelmer> r2943 should've fixed the issue you mentioned
<weigon> bzr.dev$ bzr revno
<weigon> 2946
<weigon> $ bzr --version
<weigon> Bazaar (bzr) 0.92.0.dev.0
<weigon> hmm, did I forgot to setup the install
<weigon> *doh*
<weigon> I though I was running from the branch
<jelmer> ah, that'd explain it :-)
<weigon> all the modules from the branches directly with symlinks, just bzr.dev itself I "installed" with ./setup.py install --home ~
<weigon> ok, setup done, branching ... it is copying
<weigon> jelmer: ok, my fault
<weigon> jelmer: ok, branching worked
<jelmer> weigon: ok
 * jelmer is looking into another potential bug at the moment
<jelmer> if that doesn't turn out to be an issue, I'll try to release 0.4.4 together with bazaar 0.92.0
<lifeless> hi jel	
<lifeless> hi jelmer
<lifeless> jelmer: whats the current recommended bzr-svn stuff to test with packs ? is there a version ready?
<jelmer> lifeless: 'evening
<jelmer> lifeless: bzr-svn's 0.4 branch should work with packs
<jelmer> I've run the testsuite with packs set as default format in bzr.dev and that passes ok
<jelmer> but still need to modify bzr-svn's fetch tests to be run against both knits and packs repositories
<lifeless> jelmer: if you test against packs only that should be fine IMO
<lifeless> jamesh: packs are the more restrictive format
<lifeless> jelmer: ^
<lifeless> damn latency
<LarstiQ> I see tree.revert(filenames=[]) is deprecated as of 0.91. Are there plans to do anything else with it?
<jelmer> lifeless: ah, ok - wasn't sure
<lifeless> LarstiQ: long time no see!
<LarstiQ> lifeless: you asked me about subtrees the other day! :)
<lifeless> yes :)
<LarstiQ> but yeah, been quite a while since I stuck my nose in bzr code.
<LarstiQ> woot, it looks like things have improved
 * dato waves to LarstiQ 
<LarstiQ> heya dato!
<LarstiQ> dato: thank you for your last blogpost, and if I can do anything for you, just mention it.
<dato> LarstiQ: thanks! nothing in particular, since everything is just normal at present :)
<dato> I can keep it in mind, tho
<LarstiQ> dato: that's ok, no time limit on the offer :)
<abentley> LarstiQ: tree.revert(filenames=[]) will be a no-op.
<LarstiQ> abentley: thankyou!
<abentley> tree.revert(filenames=None) reverts all files, and None is the default.
<LarstiQ> abentley: which is exactly what I want.
<abentley> Great.
<dato> abentley, thanks for the `bzr tags` review.
<abentley> No problem.
<mwhudson> abentley: fwiw, you read the -ize vs -ise part of my patch wrong
<mwhudson> i made it consistently use -ize
<lifeless> abentley: so, is the export patch ok? The lack of docs on pack format is kindof separate...
<abentley> mwhudson: Sorry about that.
<abentley> lifeless: I haven't read the patch.
<lifeless> abentley: ah, ok.
<weigon> jelmer: I'm after the fresh check out, shouldn't $ bzr pull --remember /fresh/branch/ from the old bzr tree work ?
<jelmer> interesting statistics on X-Vcs.* in Debian: http://blog.orebokech.com/2007/10/vcs-statistics.html
<jelmer> weigon: No, that will probably break
<weigon> it does http://p.caboo.se/111781 :)
<jelmer> weigon: ideally, you should just throw out the old branch
<weigon> I have 3 branches: the svn-tree, the bzr-svn'ed tree and a bzr tree from the bzr-svn'ed tree
<weigon> the bzr-svn'ed tree got borked and is the one I refreshed
<weigon> now I wanted to sync the bzr-tree against the bzr-svn'ed tree, assuming that 2 bzr-svn'ed branches are equal
<jelmer> but bzr-tree is that branch that hit bug 145148, no?
<weigon> the bzr-svn'ed branch, yes
<weigon> that's why I wanted to make a fresh branch "mysql-proxy-svn-refresh"
<weigon> and change the parent of the mysql-proxy tree to that branch
<weigon> http://p.caboo.se/111781 was the result
<lifeless> jelmer: local push bug fixed
<weigon> jelmer: anyway, how do I get my other branches (or at least their changesets) synced with the new checkout ?
<jelmer> weigon: It's not the bzr-svn'ed tree that is broken, it's the svn-tree
<jelmer> it disagrees with the other bzr branches about history
<jelmer> weigon: You should be able to fix it by replaying the changes of the bzr-tree in the "new" bzr-svn'ed tree
<jelmer> lifeless: Packs speed?
<weigon> jelmer: that's my problem, how ? :)
<weigon> I would like to make that automatic, without $ bzr diff | patch; bzr commit
<jelmer> weigon: "bzr replay" from the rebase plugin can do that for you
<weigon> thanks, there we go
<lifeless> jelmer: yes, local push of packs from X to X/10 time
<jelmer> nice (-:
<LarstiQ> how does X/10 compare to pre-pack?
<james_w> jelmer: thanks. That's interesting. It is taken from the browse, and as gitweb is git.d.o and there is nothing on bzr.d.o that might skew it slightly.
<james_w> but I think the numbers are in the right area, as git in Debian is certainly getting more talk at the moment.
<lifeless> jelmer: yes; local push was doing many 'list.__contains__' calls.
<lifeless> sets are faster
<dato> jelmer: have you thought about adding support for modifying svn:date when pushing from bazaar?
<bagueros> 1:58 < ryan> 1- proposal - additional techmeet meeting
<bagueros> ops
<jelmer> dato: not possible
<jelmer> dato: subversion doesn't allow you to set the commit time
<dato> jelmer: uh, can be configured to.
<dato> as in, touching a hook, that is.
<dato> so you can if the repo is yours, or you convince the admin.
<jelmer> dato: Optionally, we could set it I guess, but wouldn't want to rely on it
<dato> if you mean other parts of bzr-svn relying on it, certainly not.
<dato> jelmer: I wouldn't mind trying to contribute that, if you'd like; though it'll be addmittedly little code.
<dato> (the hook is pre-revprop-change)
<jelmer> dato: that'd be very nice
<jelmer> dato: you may also be able to fix bug 140001 while you're at it (same issue, for svn:author)
<chx> hi. I know this is no Ubuntu channel  but in the past I had success with finding Canonical man in here. https://blueprints.launchpad.net/sprints/uds-boston-2007/+roadmap this has a typo Improve Windows integration as a sever and a client for Ubuntu <= either sewer or server. both would fit Windows :P
<lifeless> chx: #launchpad or #ubuntu-devel/#ubuntu-motu please
<chx> lifeless: thanks.
<chx> lifeless: i first tried the #ubuntu channel with not much success
<dato> jelmer: there's seems to be a "double utf8" bug in bzr-svn (or the bindings?) have somebody else mentioned to you before?
<lifeless> jelmer: try 2859 in my repository branch
<igc> morning all
<lifeless> hiya
<lifeless> spiv: ping
<spiv> lifeless: pong
 * spiv is very glad his sore throat has finally abated.
<lifeless> you've been sick? :(
<lifeless> I was wondering if there was a release?
<spiv> lifeless: not yet, that's #1 task for this morning.
<spiv> lifeless: is there a PQM branch for 0.92?
<lifeless> spiv: there can be
<spiv> lifeless: I'm looking at http://bazaar-vcs.org/ReleaseChecklist, it seems to say there ought to be one.
<jelmer> re
<jelmer> lifeless: thanks, will do
<jelmer> dato: no, haven't heard of that before. please file a bug
<lifeless> jelmer: its still probably 50% slower than it needs to be
<lifeless> spiv: there is one
<spiv> lifeless: I just saw it, thanks!
<lifeless> dinna time
#bzr 2008-10-20
<lifeless> poolie: ping
<poolie> hi
<lifeless> can I ring?
<poolie> apparently yes :)
<grettke> Hi guys. Newbie question: When I create a mirror branch, I must first run init-repo. Doing so tells it to store new revisions in the src repo, not the branch. When I create a task branch, though, how does it know to keep revisions in the branch. I am confused about the role of init-repo...
<Verterok> grettke: the init-repo creates a shared repository, where you 'll create/branch your feature branches
<Verterok> grettke: maybe 'll help if you just see the shared repository as a revision storage
<lifeless> grettke: init-repo creates a database for the bulk content to be stored in; all other commands operate on branches - pull works branch to branch
<lifeless> grettke: runnning 'init-repo' is *entirely optional*. If you just want to mirror one branch of a project, don't bother with init-repo.
<Verterok> lifeless: hi
<lifeless> Verterok: hi :>
<Verterok> thanks for the detailed explanation of shared repos :)
<grettke> Verterok: Ok. So this is something like an optimization, don't check out the entire history for every single branch I want to create, since I should just do it once for the mirror and levergae that for branches of the mirror?
<grettke> lifeless: I see. I'm looking at mirroring and then branching multiple projects.
<grettke> Thanks guys.
<lifeless> grettke: yes, shared repos are precisely an optimisation
<grettke> Verterok and lifeless: What repo structure do you recommend for the "Team collaboration, distributed style" of development?
<lifeless> grettke: any
<lifeless> repo structure is orthogonal to workflow
<grettke> lifeless: I see. We are all "used to" the svn style.
<lifeless> grettke: svn conflates repository and branches
<lifeless> grettke: workflow in bzr is focused purely on branches
<lifeless> grettke: commonly every developer will have one or more repositories whereever they have branches
<grettke> lifeless: So if there are two centralized projects, proj1 and proj2, then a developers run init-repo twice (creating separate directories) , one for each project?
<grettke> lifeless: Why are centralized repos initialized with the --no-trees option?
<lifeless> grettke: a developer could have one repo for both, or two repos, or one repo per branch - whatever suites their needs (multiple machines, etc etc)
<lifeless> grettke: the --no-trees option is useful for wherever you won't be editing the source code
<lifeless> grettke: central servers don't generally have people editing code on them :P
<grettke> lifeless: Understood. Thank you. I just finished reading the user-guide, so I was dying to ask some questions.
<grettke> lifeless: One good thing about SVN is that it will get people off of CVS and onto a Distributed VCS quickly ;)
<lifeless> :P
<grettke> lifeless: Here is what I mean: It is not radically different from CVS, and it "fixes" some things. If you dig into SVN more than superficially, and you learn how it works, the SECOND thing you will start asking for (the first is merge tracking) is "disconnected-commits".
<grettke> lifeless: So I wasn't teasing, SVN lowers the barrier for CVS users!
<grettke> Thanks lifeless, Verterok, goodbye.
 * vila not really here, yet, but soon
<lifeless> vila: thanks for your email
<lifeless> vila: a bundle would have been better
<lifeless> ok, night all
<vila> hi all
<vila> lifeless: sry, I keep forgetting that (my editor provides shelf-like features for bundles as well as any bzr command output)
<vila> poolie: ping
<beuno> mornin' vila
<vila> hi beuno !
<beuno> how's it going?
<vila> better and better, mouth can open by 2cm in the morning, reaching 3 or 4cm in the evening, eating has become a possible alternative again :-)
<poolie> hi vila
<vila> hi poolie
<vila> lifeless: If you pass around and have some minutes to spare, I'd like to chat a bit (not more than some minutes, I swear :)
<gour> hi, do you recommend 'dive into python' book for learning the lang?
<gour> (so we can help hacking bzr one day)
<spiv> gour: its pretty good, IIRC.
<spiv> gour: it might be slightly dated w.r.t. to current versions of Python, but probably not enough to matter.
<gour> spiv: thanks. i was reading 'learning python' but it's kind a slow, although it covers 2.5 with the reference what 2.6/3.0 changes
<spiv> gour: http://docs.python.org/tutorial/index.html isn't too bad either
<spiv> gour: it depends a bit on the audience, I think.
<gour> spiv: how much of the language is covered by tutorial?
<gour> stuff like generators, decorators, new-classes etc.
<spiv> gour: it covers generators, it doesn't cover decorators or new-style classes that I can see.
<gour> spiv: thank you
<spiv> (although new-style classes hardly warrant covering, except to say "unless you know what you're doing, always use 'class Foo(object):' rather than 'class Foo:', or use '__metaclass__ = type'".
<spiv> )
<gour> hmm, good to know
<spiv> gour: http://docs.python.org/glossary.html may be another useful resource for a novice Pythonista.
<spiv> gour: e.g. it gives a succint description of new-style class :)
<gour> spiv: thanks a lot
<chandlerc> do svn:externals work in bzr-svn?
<gour> chandlerc: not (yet) :-(
<chandlerc> k, i suspected as much
<gour> that forces me to still fetch via svn :-/
<jelmer> chandlerc, bzr-svn can't support externals atm since bzr itself doesn't have any feature they could be mapped to
<chandlerc> jelmer: the sub-tree thing?
<chandlerc> that may be an experimental feature that i was playing with, but it seemed a pretty direct mapping onto svn:externals
<jelmer> chandlerc, subtrees always refer to a specific revision
<jelmer> chandlerc, svn:externals can (and usually does) point at the latest revision
<chandlerc> odd, from a subversion developer, i was told to only use svn:externals to point to a specific revision
<chandlerc> because the other behavior isn't well defined (what version it points to isn't itself versioned)
<lifeless> jelmer: subtrees can have policy to update to a newer rev according to the design
<jelmer> chandlerc, sure, but they do support it and it's the most common behaviour
<jelmer> *commonly used
<lifeless> vila: hai, not really here
<lifeless> vila: drop me a mail though
<chandlerc> well, as all the projects I want to use externals in would use them locked at specific revisions... ;] any chance of partial implementation with those semantics?
<vila> lifeless: ok, asap
<jelmer> lifeless, sure, what I'm saying is that atm there is no such policy
<jelmer> chandlerc, not likely while by-reference nested tree support is still experimental
<chandlerc> k
<vila> lifeless: email sent
<bugabundo_work> hi
<bugabundo_work> is it a good idea to use bzr as a TimeMachine?
<bugabundo_work> I made two local repos on my machine
<bugabundo_work> on for /etc and another for /home/me/
<beuno> I don't think it is
<beuno> it will blow up with large files
<beuno> doesn't do binary deltas
<beuno> etc etc et
<bugabundo_work> I filtered *.avi *.mp3 and stuff
<bugabundo_work> plus I'm just adding files by hand
<bugabundo_work> not add . recursive
<bugabundo_work> can that be the cause of
<bugabundo_work> https://bugs.launchpad.net/bzr/+bug/286266 ?
<ubottu> Launchpad bug 286266 in bzr "bzr add crash" [Undecided,New]
<bugabundo_work> it crash every time on some PDFs
<beuno> well, if it
<beuno> it's for text files, maybe
<beuno> still not sure if it's the best choice
<luks> bugabundo_work: crashes in what way?
<bugabundo_work> it gives a backtrace
<bugabundo_work> its attached to the LP ticket
<luks> hmm
<g0ph3r> hi folks, i've just tried pushing one of my branches to an FTP server of my web hoster and got temporary ftp errors 451. digging in the bazaar bugs revealed bug #154259. this bug description indicates that the ftp append/restart commands may depend on the repository format (knit in this case). my question now is: could i workaround this issue by upgrading to a newer repository format?...
<ubottu> Launchpad bug 154259 in bzr "traceback on temporary ftp error" [Undecided,Fix released] https://launchpad.net/bugs/154259
<g0ph3r> ...anybody familiar with the ftp commands required by the different repository formats?
<spiv> g0ph3r: the pack-0.92 format (which is the default in current releases) probably does avoid using append/restart over FTP.
<g0ph3r> hm... upgraded a temp. branch of my branch to the 1.6.1-rich-root format but still got the same errors when trying to push to the FTP server... so it seems as if there's no easy workaround available :(
<g0ph3r> spiv: thx, but my branch is already using pack-0.92 format...
<spiv> g0ph3r: ah, 1.6.1-rich-root should behave the same as pack-0.92 in this respect, so I guess you're stuck.
 * g0ph3r nods
<g0ph3r> well, would have been nice...
<spiv> There's a limit to what we can do to workaround broken FTP servers.
<g0ph3r> yep, unfortunately, there probably even less i can do to convince my ISP to fix their server ;)
<lifeless> vila: I replied
<vila> lifeless: Me too, unless you replied again but then it's in the pipe
<trotek> .
<strk> so, it looks like bzr-gtk plugin makes X a requirement to even pull...
<strk> apt-get remove --purge bzr-gtk # fixed it (I think I filed a bug already, just wanted to make sure, somebody here should have it assigned IIRC)
<strk> ops, bzr-gtk didn't fix it, must be bzr-dbus
<strk> yep, confirmed
<dereine> can i export a certain update between 2 versions
<dereine> so i can copy the update to another pc and merge it
<beuno> dereine, bzr send -r rev1..rev2
<beuno> should do it
<beuno> unless you just want a diff
<dereine> thx
<vila> jam: ping
<jam> vila: pong
<vila> bug #279831 is back but a bit different
<ubottu> Launchpad bug 279831 in bzr-gtk "C-extensions in bzr.dev cause "bzr gcommit" to issue exception" [High,Fix committed] https://launchpad.net/bugs/279831
<vila> Can we chat a bit about it in around 2 hours ?
<jam> vila: it isn't back, it was never fixed
<jam> bzr-gtk never accepted my patch
<vila> ouch
<jam> I'm not sure if it got enough visibility
<jam> lifeless didn't really think it was worth patching bzr.dev, because it is really a bug in bzr-gtk that it was expecting exactly "True"
<vila> I'm sure it isn't, but the new case make it worst as if the gap between commit and gcommit was growing
<jam> anyway, I'm a bit here and gone because my son is sick, but if I'm around I'm happy to chat
<vila> jam: ok
<vila> take care of him
<DimmuR> hello everyone - is it possible to configure bazaar to work only with passwords (for update to and from bzr) ?
<eka> hi all
<luks> jelmer: hi, is there any known workaround for https://bugs.launchpad.net/bzr-svn/+bug/260416 ?
<ubottu> Launchpad bug 260416 in bzr-svn "corruption when "pull" on a bazaar repo" [Critical,Triaged]
<SmileyChris> does bzr have a command to apply a patch?
<SmileyChris> (a diff)
<LarstiQ> SmileyChris: `bzr patch` is in bzrtools
<LarstiQ> SmileyChris: alternatively, the standalone patch utility will do too.
<SmileyChris> LarstiQ: cheers, but the standalone one dosen't handle renames does it?
<LarstiQ> SmileyChris: if you have a bundle instead of a patch, you can use `bzr pull` or `bzr merge`
<LarstiQ> SmileyChris: if you have a plain patch produced by the diff program, that doesn't handle renames natively, no matter how you apply it.
<SmileyChris> it's a diff from bzr
<LarstiQ> SmileyChris: but you can use `bzr mv --after` to tell bzr about renames after they happened
<LarstiQ> SmileyChris: produced in what way?
<SmileyChris> bzr diff i guess
<LarstiQ> SmileyChris: (or, can you show me the first 10 lines of it)
<LarstiQ> SmileyChris: if `bzr diff` produced it, then it's in the same format as regular patch and diff, no added help from bzr there.
<SmileyChris> ok, I'll just do the moves manually... thanks
<SmileyChris> hrm, I can't - it says the new folder is not version
<SmileyChris> *versioned
<LarstiQ> SmileyChris: I don't know what situation produced this diff, but for distributing changes a bundle (produced by `bzr send`) is more useful
<SmileyChris> i agree :)
<SmileyChris> i'll let my colleague know
<LarstiQ> SmileyChris: it complains about the new folder being unversioned even if you supply --after to mv?
<SmileyChris> nah, I was just doing something wrong (didn't need --after)
<LarstiQ> ok :)
<dereine> how can i show which files changed, and not what changed
<luks> dereine: bzr status
<dereine> thx
<guilhembi_> jam: hi! about https://bugs.launchpad.net/bzr-gtk/+bug/279831, it says "fix committed", but committed where?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/279831/+text)
 * LarstiQ looks at the activity log
<balor> Will "bzr merge -r14..14 ../project-branch" cherrypick r14 from project-branch and merge it onto the cwd?
<LarstiQ> balor: I'd use -c14
<balor> LarstiQ: Thanks
<LarstiQ> balor: or -r 13..14 if you want to provide a range
<LarstiQ> guilhembi_: seems r3767 of bzr.dev
<LarstiQ> or no
 * LarstiQ mistyped the bug number
<balor> Should cherry-picking retain the providence of the patch?
<LarstiQ> balor: the what? :) Cherry-picking doesn't record as much information as would be nice.
<balor> LarstiQ: The ancestory of the merged patch i.e. where it came from and its change history.  But I guess not.
<LarstiQ> balor: correct, unfortunately.
<LarstiQ> balor: could you clarify 'change history' also?
<LarstiQ> probably different terminology, but it sounds intrigueing :)
<balor> LarstiQ: I think I'm talking about the entire revision tree associated with the patch....which you probably don't want to merge over :)
<LarstiQ> just noting which revision it was should be enough for filling in later, yes
<abpend> Anybody here?
<poolie_> yes
<grettke> When you create a mirror branch, do you normally use checkout or branch, and why?
<poolie_> i'd normally branch
<poolie_> if you don't commit in it it doesn't make much difference though
<abpend> My question: when setting up bazaar for a central-server workflow, how is access control typically handled on the server?
<grettke> poolie_: Understood. The workflow I'm envisioning is that there is a mainline on a shared repo on the server, I create a branch locally, then I create a "task" branch of that and merge my changes to the trunk branch and vice versa.
<grettke> poolie_: This is based on reading the user guide along with my desired workflow.
<balor> Silly question...If I check out -r 7 (of say 17 revisions) into a new tree.  Is there any way to upgrade r7 to r8, and then to r9 (I'm thinking about demo'ing tutorial code).
<poolie_> balor: "update" :)
<balor> poolie_: But update doesn't take a --revision, it'll update to the latest revision not just the next (AFAIK)
<poolie_> hm
<lifeless> balor: pull -r 8 source
<balor> lifeless: thanks
<Peng_> Wow, YUI is big..
<beuno> blame rockstar
 * rockstar hides
<rockstar> Wait, why am I being blamed for YUI being big?
<beuno> yes
<rockstar> Suddenly, everything is so clear now.
<beuno> rockstar, so, loggerhead tomorrow?
<lifeless> YUI?
<rockstar> beuno, perhaps.  I need to finish up some personal projects.
<rockstar> lifeless, Yahoo! UI library
<beuno> rockstar, aiight, I'll catch up with my LH stuff either way
<Peng_> lifeless: It's a really big JavaScript library.
<beuno> I have a branch that's almost finished to user paths instead of fileids
<mlh> people do like jquery - it's smaller
<rockstar> beuno, Maybe we ought to get something really quick and hack for a few hours tomorrow night.
<beuno> rockstar, oh, sure, that's what I had in mind. Get out hands dirty
<rockstar> mlh, jquery is also my favorite.  However Launchpad is moving to YUI, so LH coincidentally is as well.
<beuno> but there's no rush
<mlh>   intewesting
<Peng_> I think adding YUI made Loggerhead's repo 20% larger. :D
<rockstar> beuno, yea, let's make it a plan then.
<rockstar> Peng_, in all fairness, Mochikit will go away soon.
<beuno> rockstar, deal
<beuno> and, well, mootools is what's going away in LH
<beuno> but yeah, lp is lossing mochikit
<rockstar> Ah yes, that's what I meant.
<beuno> loosing even
<beuno> mootools isn't small either
<rockstar> beuno, did you get an email from me?
<Peng_> yui-min.js /is/ smaller than MooTools.
<beuno> rockstar, gpg?
<beuno> if that's what you mean, than no
<beuno> oddly enough, I've just ogtten emails from people sending from other addresses than @canonical
<beuno> anyways
<beuno> off to bed
<mlh> beuno: "losing" :-)
#bzr 2008-10-21
<spiv> Gar, gnome-terminal just crashed.
<lifeless> spiv: uxterm FTW
<mneptok> Terminator treats me right.
<mneptok> but then, terminal emulator religious wars have nearly as many victims as text editor conflicts.
<fullermd> Yeah.  I mean, what's with all you freaks who don't just use xterm?   :p
<mneptok> what's the "x" for?
<mneptok> :P
<fullermd> A beginning.  Obviously   :)
<mneptok> how linear. how pedestrian. ;)
<fullermd> Well, I don't own a bicycle, so...
<lifeless> terminator is nice
<lifeless> it needs less gnome widget embedding love though
<sevenseeke1> I installed bzr via easy_install (1.8), when I try to branch (even with bzr itself -> bzr branch lp:bzr) I get: bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<sevenseeke1> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x85d7f2c>
<sevenseeke1> my ~/.bazaar/bazaar.conf only contains my launchpad name
<lifeless> sevenseeker_: try an http url
<lifeless> sevenseeker_: like http://bazaar-vcs.org/bzr/bzr.dev
<spiv> sevenseeker_: do you get "Permission denied (publickey)" as well?
<sevenseeker_> hmmm, no I don't
<sevenseeker_> although it is going veeeeery sloooooow
<lifeless> sevenseeker_: ok, if http is working and lp: isn't
<lifeless> sevenseeker_: then https:// is probably firewalled on your machine/network
<sevenseeker_> hmmm, this is new
<lifeless> sevenseeker_: (or ssh: is firewalled, if you have done bzr lp-login)
<sevenseeker_> I wonder if something updated that interferred
<sevenseeker_> I greatly appreciate the help
<sevenseeker_> ok, I checked with some https sites and I connect fine (through the web that is)
<sevenseeker_> netstat -l isn't showing anything that I am aware of that would interfere either
<lifeless> sevenseeker_: try 'ssh bazaar.launchpad.net'
<lifeless> sevenseeker_: if that gives a network error (rather than an authorisation error) then you have a networking issue
<sevenseeker_> just 'Permission denied (publickey).'
<lifeless> ok
<lifeless> your network is fine
<lifeless> now try ssh LPUSERNAME@bazaar.launchpad.net
<sevenseeker_> same thing
<lifeless> ok
<lifeless> you haven't told lp your ssh key :>
<spiv> lifeless: "ssh `bzr launchpad-login`@bazaar.launchpad.net" ;)
<sevenseeker_> must have done that with another 'puter, I hope that is all it is :)
<spiv> FWIW, I just bumped up the importance of https://bugs.launchpad.net/bzr/+bug/238776, which is the bug about how bzr's error messages in this case aren't as helpful as they could be.
<ubottu> Launchpad bug 238776 in bzr "Confusing error message if ssh login fails while using lp url" [High,Confirmed]
<sevenseeker_> cool, thank you... registering now
<fullermd> poolie_: I understood that a lot of bzr ops did things in a staging dir under .bzr/ and then rename()'d over into the final location (which would fail hard across file systems)
<lifeless> fullermd: splitting .bzr/ over mounts is not supported in any way
<fullermd> I mean to/from the WT.
<lifeless> fullermd: splitting a tree over mounts will also fail with tree transform which does lots of mv's
<lifeless> because it writes to .bzr/checkout/limbo and mv's from there
<fullermd> Yeah, 's what I thought.
<fullermd> (re bug 286268)
<ubottu> Launchpad bug 286268 in bzr "bzr commit removes files from unmounted folders" [Undecided,Invalid] https://launchpad.net/bugs/286268
<lifeless> but perhaps mv on some platforms will work cross fs
<lifeless> by copying and rming
<kingfishr> If I'm working with a partner, and he's branched the project and made changes, then to get those changes _I_ need to merge?
<kingfishr> i.e. am I correct in saying that to work in the method, both people need ftp/ssh/.../ access to the other's computer?
<kingfishr> s/the method/this method/
<fullermd> Well, both people would need access to the other's branch.
<kingfishr> right
<fullermd> That could as easily be a copy of your branch you push somewhere "as often as necessary", as your local copy of the branch.
<kingfishr> fullermd, I don't follow you
<fullermd> Well, I could give you access to my system, and you could "bzr merge bzr+ssh://fullermd/home/fullermd/whatever"
<kingfishr> is there a way for him to push his changes to me instead of me merging with him?
<fullermd> Or I could push a copy of my branch up to somewebserver, and you could "bzr merge http://somewebserver/whatever", or any other step around.
<fullermd> If you gave him write access he could push over your branch.  That's usually not as good an idea for various reasons.
<fullermd> He could as above plunk a copy of his branch somewhere public
<fullermd> He could use 'bzr send' to email you a bundle of his changes which you could merge from as if it were a branch.
<kingfishr> hmm
<lifeless> kingfishr: there are three ways he can give you his content:
<lifeless>  - he can mail you a bundle
<fullermd> Depends on details of how you want to work and where the two of you can "meet up" logically.
<lifeless>  - he can put them in a branch you can access (e.g. on http, or on launchpad, or on an NFS share somewhere, or on your machine somewhere)
<lifeless>  - he can push them directly into a common branch (which requires a common branch you can both write to, just like cvs/svn)
 * lamont wonders when bzr_1.8-1~$mumble will be available
<lamont> ditto for bzrtools>1.7.0-1
<lamont> referring, of course, to https://edge.launchpad.net/~bzr/+archive
<lamont> s/edge.//
<lamont> stupid edge urls
<lifeless> lamont: poolie is working on it
<lamont> cool
<lamont> once it's there, I have a dance card to fill
<kingfishr> let me give you more context: I'm working right next to a guy on a project, we're both making changes, and so far he's been merging changes from me via ftp. Now I need his changes. He'd have to set up a new user on ssh or something for me to merge his changes.
<kingfishr> Basically, what's the easiest way for me to get his changes, if we're both feeling lazy?
<fullermd> Well, you've given him ftp access.  Let him give you ftp access.
<fullermd> (or ssh, better; any opportunity to stamp out FTP is a good opportunity...)
<lifeless> kingfishr: 'bzr serve' in the directory he is working on
<lifeless> kingfishr: then 'bzr browse' followed by 'bzr merge <reported url>'
<lifeless> kingfishr: assuming you both have bzr-avahi installed
<lifeless> kingfishr: without bzr-avahi, its
<lifeless> 'bzr serve'
<lifeless> which reports a ip and url
<lifeless> then 'bzr merge bzr://his-ip/'
<kingfishr> lifeless, awesome
<lifeless> fullermd: never forget adhocing :>
<kingfishr> fullermd, yes, normally I'd use ssh over ftp but I already had an ftp server set up with correct permissions...again, being lazy
<fullermd> I tend to, because I never do it   :p
<fullermd> Think the only time I ever used 'bzr serve' was in a bug filing...
<lifeless> fullermd: use bzr+ssh ?
<poolie_> ah, lifeless is probably right about tree transforms
<poolie_> it's arguably a bug if we don't fall back to copy&delete
<fullermd> I don't mean the SS, I mean "bzr serve" itself directly.
<lifeless> poolie_: well, arguably. OTOH its not exactly a common use case
<poolie_> right
<fullermd> The atomic link()'ing has the advantage that there can't be any half-formed files polluting the working tree.
<fullermd> (of course, the files can still be out of sync with each other, so whether that increment really matters is somewhat questionable)
<poolie_> 1.8 is in the ppa now
<abpend> Not sure if anyone is around...
<abpend> But with the standalone bzr installer on windows, are bzr+ssh checkouts supposed to work out-of-box?
<abpend> Or does something special need to be done?
<spiv> abpend: They should work, I believe.
<spiv> abpend: although it may depend on you having a working SSH client already installed?
<lifeless> poolie: Do you want to talk today?
<poolie> abpend, spiv, it's meant to work without it
<poolie> lifeless: only if you want to
<lifeless> poolie: briefly would be good
<poolie> and i suppose you want a cooperative attitude too?
<poolie> :)
<lifeless> gnight all
<poolie> night!
<vila> hi all
 * fullermd waves at vila.
 * vila waves back !
<spiv> gnome-terminal has crashed for the second time today.
<spiv> Not happy.
 * gour uses urxvt
<AfC> Really?
 * AfC hasn't had gnome-terminal crash in years and years.
<fullermd> Hey, no fair!  We already had the your-terminal-emulator-sucks discussion earlier on!
<fullermd> You can't double-dip.
<gour> today?
<fullermd> Less than 7 hours ago.
<gour> ahh, that's almost yesterday here ;)
<luks> 02:50 < fullermd> Hey, no fair!  We already had the your-terminal-emulator-sucks discussion earlier on!
<luks> oops, sorry
<spiv> For bonus points, I also had X crash today.
<fullermd> Has bzr eaten any of your repositories?
<spiv> Nope.
 * gour is learning python (reading DIP book) and wrapping his head around python's 'and-or trick'
<spiv> bzr has given some scary errors that superficially looked like repo corruption on the repo my wife keeps her PhD thesis in, though.
<spiv> But that's as close as it's got.
<fullermd> Well, just replace X and your terminal with bzr then!  With that easily-extensible architecture, you should be able to bang up a plugin in no time flat!
<spiv> fullermd: bzr vte?  Scary thought.
<fullermd> Well, it'll take 10 times as long to start up as gnome-terminal, but it'll only be 3x slower once it's running.  And the UI will be nicer.
 * fullermd . o O ( bzr -geometry 80x25-58+49 -iconic [...] )
<alf_> Hello, I am bit confused about 'bzr update'.
<spiv> AfC: I hadn't had gnome-terminal crash in a very long time either.  It's a bit disorienting :)
<spiv> alf_: any specific aspect of it, or just the command in general?
<alf_> All it does is to update the working tree according to the branch information?
 * fullermd nods at alf_.
 * gour prefers working in DVCS env and uses pull
<spiv> alf_: right (although that may involve doing a merge if there are local changes)
<alf_> spiv: I am actually puzzled because when using it on a non-checkout branch it does nothing, it says all is up-to-date
<fullermd> Well, that's what it does in any branch when the working tree is up to date with the branch  :)
<alf_> So it only acts locally even though the remote branch may have diverged.
<AfC> alf_: pull does an implicit update. So you're probably not used to thinking about it.
<fullermd> IT works on your working tree, and the branch it's a WT of.  If that branch is local, it only acts locally; if the branch is somewhere else, it acts there too.
<alf_> fullermd: Sorry, by remote branch I meant the mainline the local branch is the copy of.
<alf_> So if I have a bound branch the 'local' branch information is actually the remote one and that is why it actually works like 'bzr pull'.
 * fullermd drags "bound branch" out behind the woodshed and drops a load of buckshot into it.
<fullermd> When do you "bzr checkout bzr+ssh://wherever/" (or any other URL/path of course), you're making a new working tree on the branch at bzr+ssh://wherever/.  So 'update' will involve updating that working tree to that branch.
<fullermd> When you have an all-in-one (e.g., the fruits of 'bzr init', or 'bzr branch foo'), the branch at the WT are colocated there, so update would update that WT to the branch sitting there.
<fullermd> Mostly, it's harder to get those out of sync.  One way is by push'ing to the branch from somewhere else; that'll update the branch, but won't touch the WT, so it will then be outdated.
<fullermd> But the point of checkout's is to allow multiple WT's to share a single branch, like in CVCS, so it's much more common for the branch to move ahead of the WT.
<fullermd> Which is why, speaking very roughly, 'update' is mostly used with explicit 'checkout's.
<alf_> OK, I got it, thanks. As a side note the
<alf_> 'bzr help update' documentation could use some clarification on the matter.
<fullermd> Probably.
<Peng_> I just realized that the branch/checkout pull/update thing totally makes sense. I used to think it was just an icky svn-ism.
<Peng_> That doesn't make it ideal, but at least I get it now.
<alf_> Peng_: exactly my thoughts, too. Perhaps this conversation (or the gist of it) should be added somewhere in the wiki or the guide.
<fullermd> Well, it makes sense if you (a) concentrate on Checkout, Branch, and Repository, and keep track of which piece is where in your setup, and (b) shoot "bound branch" in the back of the head when it's not looking, and with it any concept of the special-ness of heavy checkouts...
<fullermd> It's when you get those implementation details in your mind that otherwise rather clear things start getting really muddy and special-case-looking.
<fullermd> I keep meaning to try and write up a good defense/exposition from that angle.  I plan to as soon as I get caught up on some other things.  2063 is looking like a good year for it.
<Peng_> Eh, I didn't think about heavyweight checkouts.
<fullermd> Well, don't   :]
<Peng_> I only understand it because of the implementation details.
<Peng_> I mean, of course I knew how to use branches and checkouts, but I didn't understand why the commands were different.
<Peng_> And now I do. :)
<fullermd> Update updates a working tree to match a branch.  Pull updates a branch to match another branch.
<fullermd> (it also often updates a colocated working tree if one's there, but that's a side matter)
<Peng_> Colocated working tree?
<fullermd> It's not quite as simple as "branch->pull, checkout->update"; pull can make perfect sense used in a checkout, if that's what you're intending to do, and I use update in non-explicit-checkout trees all the time.
<fullermd> Yah, when you have a branch and WT sitting in the same place.
<Peng_> Oh.
<fullermd> I don't have a better term.  "standalone branch/tree" already has meaning in opposition to "repository b/t".
<Peng_> I need to stop thinking about this. I understand it now, and if I think any more, I might confuse myself.
<fullermd> "tree" by itself is way too generic, though it's the component of the rest of out terms that refers to the construct.
<Peng_> (Psst, hg is simpler. :P )
 * Peng_ hides
<fullermd> Well, so is RCS   :P
<Peng_> :)
<fullermd> And safer, too, 'cuz it has locks!
<fullermd> Really, what makes hg simpler here is that it doesn't let you separate the WT from the branch.
<fullermd> So, if you just edit bzr to remove 'checkout', it'll be just as simple   :p
<Peng_> It doesn't exactly separate branch and repo as much either.
<fullermd> Kinda sucks all around, this bzr/hg/git thing, y'know?
<fullermd> They're so similar, you forget the differences, and cause yourself no end up pain working between them.
<fullermd> And they're so different, you forget how similar they are deep down and start ending up with invalid conclusions about relative capabilities.
<spiv> bzr does lack a neat way to work with groups of branches.
<fullermd> On the other hand, we DO already have all this capability of working with the pieces independantly, which makes it conceptually much EASIER for us to add that feature, than for e.g. git to add the capbility to split up as we do.
<fullermd> We'd be 90% of the way there by having a WT and Repo colocated, with the Branch's elsewhere, that elsewhere being somewhere under .bzr/, with better support for sibling-pathing in various branch-referencing commands.
<spiv> That's the main point of its UI that actually seems to be a bit weaker than some other systems, rather than just being more flexible :)
<spiv> fullermd: well, looms give you something sort of like that, but with perhaps a bit too much policy builtin.
<fullermd> Eh.  Looms give you a stack, not a set.
<spiv> fullermd: but looms do demonstrate that such a thing isn't fundamentally hard to build.
<fullermd> Useful, but for different things.
<fullermd> The biggest stumbling point is, that, sibling-reference syntactic sugar aside, branches are named by location rather than name.  That can make some things harder.  You end up doing a lot of heuristics to make things in a multi-tree LOOK like they're using names locally.
<fullermd> And threads in a loom are like branches, except different.  I think in designing multi-trees we need to try to avoid making a new branch-like object; it just adds more special cases and confusion.
<fullermd> Gotta just adjust how they can be referenced and moved around.
 * fullermd has it all figured out...   everything but the code to make it happen!
<fullermd> Yet another on my list of things to braindump in 2063   :p
<AfC> Has anyone had trouble getting `bzr serve` to run as at bzr 1.8?
<fullermd> Not in a quick test (or in the various bzr+ssh'age I've done since the upgrade)
<AfC> Hm.
<AfC> Well, bug filed. I have no idea WTF, but I had to downgrade back to 1.7.1
<fullermd> What bug?
<AfC> (holy christ launchpad is slow)
<Schalken> Q: What is the difference between a merge and a pull?
<AfC> fullermd: Here we are: https://bugs.launchpad.net/bzr/+bug/286871
<ubottu> Launchpad bug 286871 in bzr "bzr serve doesn't" [Undecided,New]
<fullermd> Found it.
<fullermd> Note that it's blowing up AFTER trying to raise the error for failing to bind to the address/port.
<AfC> fullermd: yeah, I saw that too
<fullermd> So the tuple out of range is a secondary failure.
<AfC> But it shouldn't be having trouble binding
<fullermd> The real question is why can't it bind, and that wouldn't change 1.7.1->1.8 I wouldn't think.  Weird.
<fullermd> Maybe you had a TIME_WAIT socket hanging around?
<AfC> fullermd: I wouldn't have thought so either.
<AfC> fullermd: I tried different ports
<AfC> fullermd: so that's not it,
<fullermd> Got me, then.
<fullermd> Always a little disturbing, when something gets an error trying to give an error...
<AfC> I can't duplicate it locally, of course, which makes it even more of a piss-off
<fullermd> Some sorta weird selinux-like thing screwing around with what it lets bind where?
<AfC> {shrug}
<AfC> If it works with 1.7...
<fullermd> Well, if the program/lib/whatever were in a different place...
<AfC> Fair enough. But no, we don't run SE or any of that.
 * fullermd is inclined to blame selinux for any fault on any linux system.  Or most non-linux systems, for that matter...
<AfC> fullermd: Ok, you've gone from being intelligent to talking shit.
<fullermd> Er, yeah.  In about 1992.  Try and keep up here   :)
<AfC> :)
<poolie> night
<spiv> AfC: Looks likely to be due to the change to allow bzr to bind to IPv6 addresses -- I've added a comment to the bug.
 * lamont grumbles about bzrtools/dapper being ftbfs
<cyberix> A Bazaar icon suddenly appeared in my notification area
<cyberix> What am I supposed to do with it?
<beuno> cyberix, it's part of bzr-gtk
<cyberix> Why do I need it?
<beuno> I don't think you do
<beuno> there's a bug open for that
<AfC> spiv: I'll have a poke in the IPv6 direction in the morning.
<Linuturk> anyone have a good guide as to using bzr to publish a website?
<jelmer> there's one on the wiki afaik
<CardinalFang> Hi all.  I want to add a new feature to bzr using a plugin, a feature that (I think) goes beyond the foresight of the designers.  Is there a place in the .bzr/ tree that is safe for me to use?  I want a guarantee that I'm not going to break anything and future updates to bzr aren't going to break because of my addition of a new file in .bzr/ .  Essentially, I want a /usr/local/ inside .bzr/ .
<jelmer> CardinalFang, afaik you should be able to use anything under .bzr as long as it's not named {branch,repository,checkout}{,-format}
<CardinalFang> Even in 10 years?
<jelmer> CardinalFang, never say never
<CardinalFang> Instead, write specs that say "MUST".
<jelmer> CardinalFang, there's no mechanism to maintain who can use what
<jelmer> CardinalFang, s/maintain/determine/
<jelmer> CardinalFang, bzr-svn sometimes uses a "svn" directory there, for example
<jelmer> so probably best to just take some name that is unlikely to clash with anything else
<CardinalFang> Okay.  May I suggest "plugin-local/%(plugin_project_name)s" ?
<jelmer> TBH that seems a bit overengineered to me, generally plugins don't have to write anything there
<CardinalFang> I just don't want bzr or another author stomping on my toes when I name something "attributes".
<CardinalFang> "plugin-local" is to protect bzr.  project name is to protect me.
<jelmer> It doesn't prevent somebody else from creating a plugin named "attributes"
<jelmer> Your best bet probably is just to make sure the name is unique
<CardinalFang> My plugin is uniquely named.  I'm referring to a file I want to create in .bzr/ .
<CardinalFang> Alright, i guess I got all I'm going to get.  Thanks, j.
<jelmer> There's not really a good way to solve these things.. you need a central authority to control who gets to use what names or something :-)
<vila> CardinalFang: If you tell more you may get more, for a start what .bzr are you talking about ? The repo one (shared or not), the branch one (with or without tree), the tree one ? Do you expect that directory to propagated on pushes, updated on pull, can there be conflicts ? etc. Otherwise .bzr is private to bzr if you put something here, *you* are responsible for maintaining it and protecting it
<CardinalFang> The branch .bzr .  It will /not/ be propagated on pulls or pushes (that's the point).  I know it's private to Bazaar; I want a reserved space for plugin authors to use.
<CardinalFang> vila, ^
<vila> There is no reserved space that I know of at that point, but an addition to the branch that doesn't propagate sounds strange... Are you sure it's not for the working tree ?
<CardinalFang> Yes, I'm sure.  This is not versioned information.  It /must not/ be.
<vila> Well, I can't provide advices in the dark, I've done my best with what you provided and my limited knowledge... The last thing I can mention is that you can specify some info in branch.conf and locations.conf that are related to branches
<CardinalFang> vila, Yes, thanks.  De facto standards as good as de jure.  I'll just do it and mention it in the wiki.
<jam> vila: ping
<vila> jam: pong
<jam> how's it going?
<jam> Were you able to merge my bzr-gtk patch without any problems?
 * jam is still not sure why he isn't a part of the bzr-gtk developers, but it doesn't really matter in the end
<vila> yup :) bundle are smarter than I thought, your commit is now on trunk
<vila> because you didn't register there ?
<jelmer> jam, I wasn't aware you weren't part of the bzr-gtk developers at least :-)
<jam> well, I probably never tried
<vila> jam: It's quite paradoxical given that you're quite high in bzr stats output :)
<jam> for now, I'm happy enough with that :)
<vila> jelmer: same here :)
<jelmer> jam, you're not a member of the launchpad team or voting rights in bb?
<jam> vila: that's just because when I develop I commit a lot
<vila> jam: yeah, sure :)
<jam> jelmer: I'm not part of either
<jam> vila: I only developed the per-file commit code
<jam> and maybe some diff tweaking
<vila> jam: haaa, you're the one... We need to talk then :)
<jam> Probably my total lines of code is smaller than my total # of commits
<vila> What is the rationale of iter_changes_to_status() in diff.py and why not using tree.iter_changes more directly ?
<vila> Because it was private in this time ?
<vila> jam: Anyway, it sounds that iter_changes_to_status() traceback when invoked on trees with conflicts (or partially resolved conflicts)
<vila> In particular it seems to fail when invoked on contents conflicts, but I've yet to reduce the reproducible scenario
<vila> seeing file names ending in .OTHER.OTHER in bzr st output, added section, makes my eyes bleed
<jam> vila: I'm not really sure. My guess is that iter_changes_to_status is meant to build up the 'status' style listing which breaks things into added/removed/etc sections
<jam> rather than just spitting everything out as one-line changes
<jam> (consider 'bzr st' versus 'bzr st --short'
<vila> but gcommit presents them in their raw form and the columns (type, path) are not even sortable...
<vila> anyway, see https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/5
<ubottu> Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Confirmed]
<jam> I wish direct links to comments had an obvious way back to the bug
<jelmer> james_w, I'll have a look at hiding that bzr-gtk icno when it's not used
<james_w> jelmer: cool, thanks
<vila> jam: Exactly my thought a few hours ago, I ended up editing the url
<jam> vila: yeah, me too. Did you try my reproducible way?
<jam> It is pretty trivial to trigger with "bzr add foo; rm foo"
<vila> jam: eerk, where did you write that ?
<jam> vila: look at https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/4
<ubottu> Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Confirmed]
<jam> or https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/3
<jam> (you want comment 3)
<vila> damn it, my page was already opened when you wrote that :-(
<vila> ok, then I may have a guess on what files trigger that, it seems to occur when repeatedly merging from a branch where, at the first merge, you said I don't want that file (or containing dir even) and then they keep coming back
<vila> jam: or something along those lines,
<vila> s/,//
<vila> at least the ones I got when doing 'bzr resolve --all' without solving the conflicts seem to match the pattern
<jam> so for 'bzr resolve --all' I would expect the merge to conflict on deleting a file
<jam> and after resolve --all it will have implicitly deleted the .OTHER file
<jam> so
<jam> touch foo
<jam> bzr add foo
<jam> bzr commit
<jam> bzr branch . ../other
<jam> bzr rm foo
<jam> bzr commit -m rm
<jam> cd ../other
<jam> echo mod >> foo
<jam> bzr commit -m "mod foo"
<jam> cd ../ths
<jam> bzr merge ../other
<jam> bzr resolve --all
<jam> bzr gcommit
<vila> jam: watch your language :)
<vila> jam: works
<jam> vila: so I think the fundamental issue is needing a way to represent "added but missing" files
<jam> I would probably be fine with just a plain "missing" category
<jam> and ignore whether they were just added or have been around a while
<vila> addding a foo.OTHER file ?
<jam> kinds[1] is None and versioned[1] is True
<jam> vila: when you have a delete conflict, we add .OTHER
<jam> as a way to "restore the file" but indicate "it was deleted in this"
<jam> we need to put the modified content somewhere
<jam> I think abentley thought .OTHER was the best way to do it.
<vila> But *committing* that ?
<jam> I'm not sure that I have a strictly better solution
<jam> vila: that is why it is marked conflicted
<vila> It's likely a user error
<jam> so you can't commit until you do something to resolve it
<jam> (resolve --all, being a really big hammer)
<vila> I strongly suspect that a bzr resolve [--all] was issued in a hurry and that the intent is *not* to commit that file
<vila> Now 'bzr commit' does indeed commit it... obeying user orders...
<vila> jam: on second thought, I see your point about a missing section and indeed that seems to be the missing bit (ha ha) in iter_changes_to_status()
<vila> jam: thanks for the help, I'll fix it from there
<jam> vila: np
 * vila runs to the school meeting
<jelmer> james_w, btw, how's your archive importing going, or is that on hold until intrepid?
<james_w> it's going ok
<james_w> I need to stop working on other things to get the final bits in place
<james_w> the main two tasks are to document everything, and write the incremental importer that imports new uploads outside of bzr
<lamont> if someone with upload privs to ~bzr wants to fix bzrtools/dapper, that'd be lovely.  (sed -i s/central/support/ debian/{rules,control}; bump version, upload)
<jam> lamont: If you want to post that as something I could actually do with "patch" then I'll be happy to bump the branch
<jam> I'm currently on win32, though, so I can't rebuild the package
<lamont> jam: I'll do that in a bit and poke you
<lamont> jam: http://people.ubuntu.com/~lamont/bzrtools_1.8.0-1~bazaar~dapper2_source.changes et al
<jam> lamont: doesn't seem to be there yet
<jam> lamont: is there a subdir I'm missing?
<lamont> with wget? shouldn't be
<jam> lamont: with Firefox atm
<jam> and wget also gives a 404
<lamont> 10:47:11 (52.29 MB/s) - `bzrtools_1.8.0-1~bazaar1~dapper2_source.changes' saved [899/899]
<lamont> wget loves me
<lamont> wget http://people.ubuntu.com/~lamont/bzrtools_1.8.0-1~bazaar1~dapper2_source.changes
<jam> the 1 works better than the 2
<lamont> ah, yeah.  missing 1 on the bazaar bit
<lamont> bad monte.
<lamont> anyway, the .changes needs to be resigned, and the 3 files uploaded to the ppa (obviously)
<jam> lamont: well, I was hoping to have a patch that I could apply and 'bzr commit' first
<lamont> oh.
<lamont> meh
<lamont> http://people.ubuntu.com/~lamont/bzrtools.diff
<lamont> keep or don't keep the debian/changelog part of that. :-)
<synic> are there any graph generators for bzr?  Something to graph commits between certain dates
<james_w> synic: there is something in bzrtools that may do what you want
<Odd_Bloke> synic: Does 'bzr viz' in bzr-gtk do what you want?
<jam> lamont: odd, when I go to apply your diff to ~bzr/bzrtools/packaging-dapper  it already has the right values
<jam> I'm not sure what happened with Martin's packaging
<lamont> jam: I was just going off the bzr repo packages...
<lamont> so yeah
<jam> Isn't that the bzr repo ?
<jam> or you're saying that didn't make it into the .changes file, and you were just copying it?
<mkanat> There's some way to do external dependency branches in modern bzr versions, yeah? Like having one branch get checked out into a specific place when checking out another branch?
<Peng_> mkanat: That's been experimental for ages.
<Peng_> Is it even possible right now?
<lamont> jam: visit https://edge.launchpad.net/~bzr/+archive and note the big red X at the bottom of the page...
<lamont> the bits uploaded to the bzr ppa, are not the ones that build
<lamont> (for dapper, bzrtools, that is)
<guilhembi_> vila: tu es lÃ ?
<lifeless> jam: the T_LONGLONG thing is probably a new-pyrex-old-python thing
 * Linuturk starts playing with bzr as a document repository/backup solution
<Linuturk> how well does bazaar handle non text files
<Linuturk> ?
<Linuturk> like images and office docs?
<Linuturk> video and music files as well
<Linuturk> things you'd find in your typical /home directory
<Linuturk> I currently use unison to sync, but revision control might be a better method
<luks> depends on your definition of ""2Dhandle
<poolie> hi
<Linuturk> luks: I mean, it will allow me to push them to my server?
<Linuturk> and, if they are deleted, remove them as well?
<luks> Linuturk: of course, in fact bzr handles every file as binary
<Linuturk> mmk
<Linuturk> so, let's say I create a branch of my /home/username/
<Linuturk> add all the files
<Linuturk> initial commit
<Linuturk> then, I push over ssh to server:/home/linuturk/
<Linuturk> I would just see a .bzr directory there, right?
<luks> after some (long) time, yes :)
<Linuturk> I'd have to checkout before the files showed up on server
<luks> right
<Linuturk> that checkout comes from the local .bzr directory though, right?
<Linuturk> not the network
<luks> yes
<Linuturk> ok. I'm starting to get the idea
<luks> I think it's a bad idea, though
<Linuturk> then, I could pull any changes back to my laptop, correct?
<Linuturk> why a bad idea?
<luks> bzr, or any other vcs, is not designed to do that
<Linuturk> so, I'd probably just be better off syncing with unison like I am already
<Linuturk> ?
<luks> well, it depends on your needs
<Linuturk> well, i want to have my files redundant across multiple machines incase of a single failure
<Linuturk> and
<Linuturk> easy online/offline access to said files
<Linuturk> crossplatform
<Linuturk> autosync would be lovely too
<Linuturk> my own personal hosted dropbox would be ideal, but I don't know of any way to do that
<Linuturk> ie, I don't trust them with my data and I want more than 2GB storage
<luks> I think you will be disappointed using bzr for this, but you can try
<beuno> Linuturk, rdiff-backup may be what you want
<Linuturk> do you know of any other solutions?
<beuno> if you want diff
<luks> no, I don't
<beuno> it saves reverse diffs, so you can go back in time for files, etc
<beuno> it does diff on binaries as well
<Linuturk> hmmm
<Linuturk> neato
<Odd_Bloke> I'm getting http://bzr.daniel-watkins.co.uk/bzr-twitter/foo when attempting to do anything with http://bzr.daniel-watkins.co.uk/bzr-twitter.  How can I resolve this to recover some data?
<BasicPRO> Hello Odd_Bloke  I'm the person who email you regarding bzr-twitter :-)
<Odd_Bloke> BasicOSX: Hi. :)
<BasicOSX> What's a bzr info give you?
<Odd_Bloke> I just responded.
<Odd_Bloke> http://paste.pocoo.org/show/88712/
<Odd_Bloke> "(format: unnamed)" is interesting.
<BasicOSX> Did you create the repo with an older version of bzr? Perhaps a  'bzr upgrade' ?
<Odd_Bloke> Oh, no, I was just failing at restoring backup.bzr.  It's actually giving http://paste.pocoo.org/show/88714/
<spiv> "bzr info -v" is helpful when bzr reports "format: unnamed"
<Odd_Bloke> http://bzr.daniel-watkins.co.uk/bzr-twitter/bzr-info-v
<Odd_Bloke> spiv: ^
<Odd_Bloke> Well, I'm heading to bed.
<BasicOSX> night
<Odd_Bloke> Having a job FTS.
<BasicOSX> thanks for trying
<Odd_Bloke> BasicOSX: No worries, I'll look at it again tomorrow.
<Odd_Bloke> This might actually be enough incentive to attempt a recovery from the broken drive. :)
<mae^> why would bzr report a file as unmodified inside eclipse, but outside on the console its marked as modified?
<Verterok> mae^: maybe bzr-eclipse fault? :)
<Verterok> mae^: try refreshing the project
<Verterok> mae^: bzr-eclipse should refresh the decorators
<Verterok> mae^: also, if you can reproduce this behaviour, please file a bug :)
<mae^> yeah, i think this started when I upgraded to 1.1.0
#bzr 2008-10-22
<treeform> hey is there plans on adding some thing like a transfer rate and progress when you checkout etc... ?
<jelmer> treeform, there has been talk about it, not sure if there are any concrete plans
<poolie> both vila and i would like to work on that, i for one have not got a patch yet
<treeform> oh ok
<treeform> i say this because we use bzr for our project and lots of 3d art people try to use it too
<treeform> and they complain about this alot because our bzr downloads are in GB's
<poolie> ok
<poolie> we'll try to do it soon
<ferringb> c
<ferringb> *cough*.  damn screen :/
<vila> hi all
<vila> spiv: ping
<vila> spiv: thanks for updating bug #286834 description ! Are you working on it right now ? I talked with jam about it yesterday and I know how to fix it, just checking we aren't both working on it.
<ubottu> Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Confirmed] https://launchpad.net/bugs/286834
<spiv> vila: no, I'm not working on it
<spiv> vila: I was just gardening :)
<vila> spiv: ok, thanks for that
<spiv> Not a problem.
 * spiv heads to yoga.
<mwhudson> abadger1999: hello?
<jandem> are there any plans for developing a light-weight built-in webserver like mercurial has?
<jandem> i like bazaar a lot but i just miss that feature sometimes
<mwhudson> jandem: you've seen loggerhead
<mwhudson> ?
<jandem> mwhudson, but doesn't that need apache?
<mwhudson> no
<jandem> mwhudson, ok then i got that wrong, i will look at it again
<jandem> it looks nice here: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes :)
<mwhudson> yeah, it's nice and pretty these days :)
<nir> How can I install bzr-1.7.1 back on Ubuntu 7? I need it for bzr-svn. Or how can I install a bzr-svn version that supports 1.8.1?
<mwhudson> nir: ubuntu 7 ?
<nir> y
<mwhudson> nir: no such thing
<mwhudson> nir: do you mean 7.10 (gutsy)?
<nir> correct
<mwhudson> the debs for 1.7.1 will still be in the librarian i guess, i don't know how to find them though
<mwhudson> jelmer: you here?
<nir> mwhudson: so the only solution is to install 1.7.1 and bzr-svn from source, in a separate location, for bzr-svn work?
<mwhudson> nir: i admit, i get the versioning issues confused
<mwhudson> nir: do bzr 1.8 and bzr-svn tip not work together?
<nir> apt-get won't let you install bzr-svn because it requires version < 1.8
<mwhudson> nir: i was trying to suggest using the bzr 1.8 deb and bzr-svn from source
<nir> mwhudson: I'll try that
<LarstiQ> nir: http://bazaar-vcs.org/BzrForeignBranches/Subversion does not list a released version of bzr-svn that works with 1.8, but the 0.4 branch on launchpad should
<nir> bzr-svn 0.4.13 seems to work with bzr 1.8
<jelmer> mwhudson, hi
<mwhudson> jelmer: i can't remember what i wanted to ask you now :)
<gour> does latest bzr-svn works with 1.8..
<tvainika> jelmer: is it possible that bzr-svn has some race condition while committing to svn repo? my co-worker used svn merge to merge one change, and on same minute I had committed with bzr-svn my changes. co-workers commit went in first, but commit I made silently discarded his commit and applied my changes to revision before my co-workers commit.
<tvainika> i tried to reproduce this yesterday at home, but could reproduce it with some scripts looping commits to artificial repo
<jelmer> tvainika, yes, there's an open bug about this
<jelmer> gour, yes, 1.8 works with 0.4.13
<jelmer> tvainika, requires some fixes in bzr
<tvainika> oh, didn't notice that bug report
<gour> jelmer: ta. i guessed that's what mwhudson wanted to ask
<mwhudson> it wasn't actually, but it was a good question
<mwhudson> ah right
<mwhudson> jelmer: you made some debs for loggerhead, right?
<jelmer> mwhudson, yep
<mwhudson> jelmer: can you tell barry where they are? :)
<mwhudson> hm, he's not in here
<jelmer> the two branches are here: http://bzr.debian.org/pkg-bazaar/loggerhead/
 * lamont needs a bzr-svn that works with bzr 1.8, preferably in the ~bzr PPA
<jelmer> there is one in Debian, not sure why it hasn't been imported into ppa yet
<lamont> the BzrSvn homepage doesn't even mention 1.8
<lamont> jelmer: so 0.4.13-4 loves 1.8?
<lamont> as indicated by the changelog, *facepalm*(
<jelmer> lamont, 0.4.13-4
<lamont> yeah
<lamont> grabbed and stuck where I need it, thanks
<jelmer> I hadn't had time to do a proper 0.4.14 release yet
<lamont> heh
 * lamont understands ENOTIME
<LarstiQ> jelmer: so http://bazaar-vcs.org/BzrForeignBranches/Subversion can be updated to include 1.8?
<jelmer> not really, it does still warn about 1.8
<jelmer> the debian package has a patch to silence that
<LarstiQ> aha
<lamont> jelmer: mind you, someone will need to upload bzr-svn to the ppa
<abadger1999> mwhudson: hi
<fynn> what's the equivalent of `git stash` for bzr?
<fynn> the shelve plugin?
<LarstiQ> fynn: I'm afraid I don't know what `git stash` does.
<mwhudson> fynn: yes
<LarstiQ> but mwhudson does! :)
<fynn> LarstiQ: apparently, it does what shelve does in bzr ;)
 * mwhudson is a compulsive factoid acquisition machine
<mwhudson> fynn: the plugin that provides 'shelve' is called 'bzrtools' though
<LarstiQ> until abentley has finished the shelve previewtrees rewrite, then it might go into core
 * LarstiQ runs off to practice
<mwhudson> spiv: i seem to get your blog posts three times in my rss reader :)
<matkor> Hi ! Is it possible to "revert update" ? I had WT in rev A , did bzr update and WT got updated to rev B ... I want it back in state when it was in rev A ...
<matkor> when I do bzr revert -r A WT contains proper files but files are marked as modified ...
<matkor> TIA
<whitelynx> try 'bzr update -r A WT'
<whitelynx> revert would revert the _files_ to the state of A, whereas update works on the tree iirc
<clemente> I'm looking for ways to debug Bazaar (or Python in general) comfortably. For instance I'm at pdb and I wrote âp working_tree.â and now I would like to see a list with possible completions (e.g.: methods and variables of working tree)
<clemente> How do you debug Bazaar?
<james_w> clemente: if you install ipython you can get that
<james_w> it takes some fiddling to make it work inside pdb, bug it can be worth it
<clemente> clemente: is ipython a superset of pdb?
 * clemente must add a filter to his IRC client to forbid doing monologues
<james_w> http://libreamoi.com/index.php/starting-ipython-from-pdb/
<james_w> heh :-)
<james_w> it's an alternative REPL, with tab completion and other goodies
<james_w> you can use that ^ to get those goodies when you hit a pdb prompt
<matkor> whitelynx: Thanks but my bzr 1.8 does not have option -r for bzr update ...
<whitelynx> hm -.-
<clemente> I didn't know that it could also debug. And what about ipdb?
<james_w> I think that's just an easier way to do the above
<james_w> I've never tried it, but I'd appreciate it knowing if it works if you do
<LarstiQ> clemente: I like http://pypi.python.org/pypi/ipdb/0.1dev-r1716
<LarstiQ> matkor: update brings the content of the working tree to the same revision as the branch
<clemente> LarstiQ: that seems simple and easy
<LarstiQ> clemente: it is a very simple package, it imports some convenience things from ipython and then wraps pdb
<LarstiQ> matkor: do you want to roll the branch back? It isn't entirely clear to me what your desired outcome is.
<matkor> LarstiQ: I had checkout in rev_a ... I did bzr update which updated to rev_b ... I would like to revert that update - get back to state before
<matkor> I do not want to have rev_b in that WT now ...
<matkor> I just want stick with rev_a for while
<LarstiQ> matkor: you have a checkout, something bound to a master branch, but you specifically don't want the state to be synchronized? *boggle*
<matkor> yes
<LarstiQ> ok
<LarstiQ> matkor: do you intend for it to become a proper checkout again later on?
<matkor> yes.. I just want to delay "bzr update" I have done already
<matkor> I fact I need files being in rev_a ...  so bzr revert -r rev_a would be OK, but I am courious is there way to not keep modified files .. becouse sb may comit that later by accident ...
<LarstiQ> matkor: I'm trying to wrap my head around the reasoning. What makes revert -r A difficult for you?
<LarstiQ> ah, you do commit there
<LarstiQ> matkor: wouldn't it make more sense to not be a checkout at all?
<matkor> hmm make it branch ?
<LarstiQ> matkor: a 'standalone branch', yes
<matkor> so do: bzr unbind ; bzr revert -r rev_a ?
 * matkor is checking term standalone branch ....
<LarstiQ> matkor: bzr unbind; bzr pull . --overwrite -r rev_a
<LarstiQ> matkor: now whitelynx was right that an `update -r` would be useful in this case.
<LarstiQ> but the pull . --overwrite accomplishes the same thing
<matkor> yeah ! great idea .. Thats exactly what I need, thank you both very much !
<LarstiQ> glad you got to where you wanted to be
<matkor> Yup, after rebinding I am exactly in state I wanted :)
<clemente> james_w: ipdb is very simple: I just installed it from the egg here: http://pypi.python.org/pypi/ipdb/0.1dev-r1716 (installing python-setuptools before and learning how to install eggs), and then you just use:  from ipdb import set_trace; set_trace() .   You get a prompt like pdb, but coloured code for âlâ and âwâ, bash-style completion with TAB for members and Python+pdb commands, and maybe more
<clemente> It could also colour-code the completions, specially when there are many (ex: >300)
<clemente> But in general, it seems better than pdb
<whitelynx|work> i'm having a permissions issue on my shared repository
<whitelynx|work> when written to with bzr+ssh
<whitelynx|work> I put the whole problem description in pastebin: http://gne.pastebin.com/m23a731ad
<LarstiQ> whitelynx|work: umask?
<whitelynx|work> LarstiQ: can you set the umask just for a single bzr repository?
<whitelynx|work> i don't want all the files the user creates to be group-readable; just the ones in /bzr
<whitelynx|work> brb
<matkor> whitelynx: I solve that with using ACLs
<whitelynx|work> matkor: that would probably do it... never used ACLs before though
<clemente> What still confuses me about (i)pdb: if you do âlâ some times, it shows you the next and next source lines. But how can you tell it to go back to the current line again?
<whitelynx|work> and this server is going to be our web, bzr, svn, ftp, etc. server
<whitelynx|work> so i don't want to screw it up too much
<whitelynx|work> although it is a VPS, so it's not too difficult to redo
<whitelynx|work> but yeah... brb
<matkor> whitelynx: you have to remount filesystem with ACLs and than: setfacl -r -d --set u::rwX,g::rwX,o::- repo
<whitelynx|work> hmm
<whitelynx|work> ok
<clemente> Is there some way to refer to the currently debugged line in pdb?
<clemente> So that I can say: l $that_line
<clemente> to list the currently debugged source
<clemente> Mmmm... sorry, better would it be in #python
<orospakr> What does the "Gateway to LAN" option in the tray icon do?
<mxpxpod> I'm using bzr 1.8 with bzr-svn 0.4.13 and it's telling me that bzr-svn is not up to date with the installed bzr version... what does that mean since the plugin works?
<LarstiQ> orospakr: send out commit notifications to the lan
<LarstiQ> mxpxpod: bzr-svn is being conservative, the debian package has silenced the warning as 0.4.13 does work with 1.8 (as you noticed)
<mxpxpod> LarstiQ: ok, thanks
<orospakr> LarstiQ, using avahi?  I assume that means that any other computers with bzr-notify on the LAN will pop up a libnotify toaster or something I make a commit?
<orospakr> s/something/something when/
<LarstiQ> orospakr: that's the idea, but I don't know what the current status is
<whitelynx|work> grah... the only gentoo/acl howto i'm finding is on gentoo-wiki.com, which is down because their provider went under -.-
<whitelynx|work> thank god for the wayback machine
<LarstiQ> whitelynx|work: hmm, it may be coincidence, but vim.org isn't working for me either
<whitelynx|work> LarstiQ: that's probably a different thing... gentoo-portage.com and gentoo-wiki.com have been down since friday: http://www.gentoo-wiki.com/
<LarstiQ> whitelynx|work: ouch
<whitelynx|work> yeah -.-
<whitelynx|work> that's one of the single most useful sites on the web for any Gentoo user
<whitelynx|work> and they can't even get at the data for it right now to put it up somewhere else -.-
<LarstiQ> whitelynx|work: yeah, I read a bit of that page, really sucky situation
<whitelynx|work> yeah
<whitelynx|work> i've been keeping up on it for the past few days, since i use that site all the time
<whitelynx|work> that's really shitty behavior on the part of skiplink though
<whitelynx|work> they should have notified their customers
<whitelynx|work> and allowed them to make backups
<whitelynx|work> damn... matkor quit -.-
<whitelynx|work> i wanted to ask him more about ACLs
<whitelynx|work> since i'm still not entirely convinced they'll fix the issue
<LarstiQ> whitelynx|work: as poolie said in that mail, it should work without acls
<whitelynx|work> LarstiQ: it doesn't
<LarstiQ> whitelynx|work: are you sure there is not an umask set somewhere that influences this?
<whitelynx|work> i tried following the email and the bzr docs
<whitelynx|work> this is using a newly-created user with no modifications to its config files
<whitelynx|work> completely vanilla gentoo install
<whitelynx|work> in a VPS
<LarstiQ> whitelynx|work: ok
 * LarstiQ tries to reproduce
<whitelynx|work> thanks :-)
<LarstiQ> whitelynx|work: happens here too
<whitelynx|work> ok, so it's confirmed...
<whitelynx|work> hm
<whitelynx|work> any ideas on how to work around it?
<LarstiQ> let me try
<whitelynx|work> or musings on how ACLs might actually help?
<whitelynx|work> ok :-)
<whitelynx|work> thank you
<LarstiQ> whitelynx|work: https://bugs.edge.launchpad.net/bzr/+bug/50568 seems relevant
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]
<whitelynx|work> hmm
<whitelynx|work> that does sound relevant
<whitelynx|work> can't check it right now because firefox froze up again
<LarstiQ> whitelynx|work: also contains some ACL info
<whitelynx|work> hmm
<whitelynx|work> ok
<LarstiQ> which I really should look into sometimes
<whitelynx|work> i wish chrome ran under linux -e-
<whitelynx|work> *-.-
<whitelynx|work> firefox is pissing me off
<LarstiQ> whitelynx|work: for basics, you could try aurora
<LarstiQ> no, arora
 * LarstiQ always gets that name wrong
<whitelynx|work> haven't even heard of that... i'll take a look
<whitelynx|work> heh
<whitelynx|work> ooh!
<whitelynx|work> webkit/qt ^_^
<whitelynx|work> what's the difference between that and konqueror?
<LarstiQ> whitelynx|work: no kde dependencies iirc
<LarstiQ> whitelynx|work: and well, it's very basic
<whitelynx|work> hmm
<whitelynx|work> i'll give it a shot
<whitelynx|work> i already have konqueror installed though
<whitelynx|work> i like chrome because it's fast and stable
<whitelynx|work> and standards-compliant, afaict
<LarstiQ> whitelynx|work: but not because it has a missing GUI? :)
<whitelynx|work> i'm talking under windows :-P
<whitelynx|work> right now they just have to finish fixing the code to build in linux, and it should be pretty well ready to go
<whitelynx|work> i'm surprised it isn't done yet... they're accepting help from the community with it
<whitelynx|work> i wish i had time to work on it
<luks> by 'fixing the code' you mean write the GUI code for linux?
<whitelynx|work> ?
 * whitelynx|work wishes firefox would stop freezing and crashing
<LarstiQ> whitelynx|work: Google chose to implement a (Windows) gui on top of GDI
<LarstiQ> whitelynx|work: so for Linux they have to write a gui from scratch
<whitelynx|work> hm
 * LarstiQ hasn't followed closely after the first two weeks though
<LarstiQ> so no clue what the status currently is
<james_w> clemente: thanks, I'll look at packaging it
<whitelynx> LarstiQ: that bug on launchpad seems to pertain to sftp, not bzr+ssh
<whitelynx> although i haven't seen anything there that confirms that it shouldn't happen on bzr+ssh
<LarstiQ> whitelynx: right, I added a comment to revive it
<whitelynx> cool
<LarstiQ> whitelynx: did the acl info help?
<whitelynx> i'm still testing
<whitelynx> LarstiQ: someone responded
<whitelynx> i'm not even sure which repo format i'm using... whatever the default is, i would guess
<LarstiQ> whitelynx: let me respond
<whitelynx> ok cool
<whitelynx> LarstiQ: thanks for all the help with this :-)
<LarstiQ> whitelynx: thank me when it works as you want :)
<whitelynx> :-)
<LarstiQ> whitelynx: done, and now I need sleep
<LarstiQ> another day tomorrow
<whitelynx> :-)
<whitelynx> have a good night
<LarstiQ> thanks, you too when that is applicable :)
<whitelynx> :-)
<whitelynx> another 5-7 hours
<whitelynx> i am headed home from work now, though
<whitelynx> thanks for the help, and ttyl
<poolie> hello LarstiQ
#bzr 2008-10-23
<toddw> howdy, anyone know if I can get bzr status to work non-recursively, i.e. to not report on child directories?
<spiv> toddw: bzr st `find . -maxdepth 1 ! -type d`
<spiv> toddw: I think adding a --no-recurse option to bzr status would be a reasonable feature request.
<toddw> spriv: nod, what about windows :D
<toddw> spiv: thanks, I'll make the bug request
<spiv> toddw: cygwin ;)
<ericvw> oders
 * ericvw wrong window
<lifeless> toddw: a use case would be good too
<lifeless> toddw: because all the times I've seen someone want that so far, its really been a svnism
<toddw> heh, it's for a GUI that does only wants to show the status of a particular directory
<lifeless> I'd much rather guis use the scriptable interfaces -
<lifeless> ls, xmlrpc, or plain python
<lifeless> I'd also ask *why* the gui wants to only know one directories status
<toddw> nod, I don't know a lot on the scriptables, does that require the GUI to provide their own install of bzr?
<lifeless> no
<lifeless> the reasoning here - status is for humans, we will continually adapt it to make it more useful
<lifeless> GUI's that are generating data should depend on programmatic interfaces that are less subject to make-it-pretty changes
<lifeless> as for doing one dir vs the whole tree
<lifeless> its much more efficient to do the whole tree once than to call into bzr once per directory
<lifeless> (and I mean _MUCH_ more efficient)
<toddw> is there info on these scritables part?
<lifeless> yes
<lifeless> the IntegratingWithBazaar wiki page talks about the xmlrpc interface used by bzr-eclipse and other IDE's
<lifeless> the bazaar pydoc/pydoctor API documentation talks about using the python interface directly, and there are examples on th ewiki
<toddw> there is an additional plugin to provide xmlrpc, does not seem that friendly - additional step(s)
<toddw> or use the python bzr library files, which sounds good, but I'm guessing I'd need to find both the library files and the correct python installation to run it
<toddw> honestly, the --non-recursive command line option is looking much simpler for me
<fullermd> Oh look, another project doing a source control vote between hg and git...
<lifeless> fullermd: whom
<fullermd> Dragonfly[BSD]
<fullermd> Git seems to be leading about 2:1
<fullermd> Right up top of http://news.gmane.org/gmane.os.dragonfly-bsd.kernel/
<uniscript> any idea when a bzr-svn update to correspond to bzr 1.8 is due out?
<jelmer> uniscript, 0.4.13 works with 1.8
<uniscript> so why did the bzr update from ppm push out bzr-svn?
<jelmer> uniscript, ppa hasn't been updated yet
<uniscript> for bzr-svn?
<jelmer> yeah
<uniscript> OK, any idea when?
<uniscript> I want my bzr-svn back :)
<jelmer> no, sorry
<uniscript> ah so I should get the source package and change the depends and rebuild
<uniscript> OK
<jelmer> jam usually does the ppa uploads, not sure what his plans are
<uniscript> is he uk TZ based?
<jelmer> uniscript: yeah, or alternatively you can install the debian experimental package
<jelmer> US based
<uniscript> package built
<uniscript> aah build failed ah well time to add ppa to pdebuild :)
<jfroy> jelmer: how goes 0.5, BTW?
<jfroy> I never sent you an update on those Unicode exceptions, BTW, because I couldn't reproduce them with the current top of tree
<jfroy> jelmer: also, in the event of a catastrophic "you screwed up", doing a Subversion repository dump and re-import, with a filter to leave out the bzr-svn properties, should allow a clean start, right?
<vila> hi all
 * fullermd waves vila.
<poolie> hi vila
<vila> hi !
<ace> hi the happy community
<ace> can you give me a link to a nice doc that compare bzr and git?
<luks> you can't find anything objective
<ace> ok
<ace> is there a doc that explain big changes between CVS/svn and bazaar ?
<AfC> ace: are you already a Bazaar user?
<ace> no
<ace> i m a CVS/SVN user for 8 years
<AfC> ace: tell you what, then. Why don't you just use Bazaar, and then you won't have to worry about comparing it to Git.
<ace> and i want to discover what make bazaar so different and better before using it :)
<fullermd> That's one way to shortcut documentation   :p
<AfC> fullermd: I thought so, yes
<ace> ok i ll continue to googlize then
<uniscript> ace, which one do you want to win the comparison? If you want git to win, go to the git site and if you want bzr to win got to the bzr site :)
<ace> lol
<uniscript> it really depends what is important to you
<fullermd> Which one wins if you go to the darcs site?
<AfC> ace: have you read Bazaar's user manual? Why don't you start with that.
<ace> afc: i ll do that
<uniscript> fullemd - mercurial of course!
<fullermd> Blast their sneaky liquid metal hides!
<uniscript> btw here's my take given a dev team here just went from svn -> git -> hg (I wonder how long before the see real sense)
<uniscript> svn is centralised, yawn. git is fast, powerful and nearly unusable,
<ace> uniscript: why unusable?
<uniscript> hg doesn't have hgpushsvn which makes it useless if you want to work with an svn repo
<ace> too hard to setup?
<ace> what is hg?
<uniscript> the strikes against git are: revisions are all shar hashes and auto tagging is a pain
<uniscript> hg is mercurial
<ace> ah ok
<ace> why hg?
<uniscript> mercurial is perceived to be nice on windows due to tortoisehg
<ace> there s no H nor G in mercurial
<luks> which is a gtk application ;)
<uniscript> why there can't be one big tortoise project with plugable backends I have no idea
<fullermd> ace: Check your periodic table of elements   :p
<ace> aaahhhh lol they are crazy
<uniscript> so ease of use and model goes to bzr
<uniscript> integration with svn goes to bzr
<uniscript> speed still doesn't go to bzr but it's getting better
<uniscript> I *like* bzr it just feels right
<uniscript> the rest all seem to be that you are working around stuff
<uniscript> if you are workign on the kernel, you will have to use git
<uniscript> as I say, it all depends on what is important to you
<LeoNerd> ace: Hg is the chemical symbol for mercury
<ace> LeoNerd: yes i understood :)
<ace> i have a big source tree, bzr will be too slow?
<luks> big is pretty relative
<luks> how big is big?
<AfC> ace: unless your big is >>> Mozilla, no, it'll be fine.
<fullermd> Also depends on what way the big is.
<LeoNerd> I've used bzr on trees of 4,000 HTML and Perl files. That worked just fine.
<LeoNerd> Hellofalotquicker than the CVS that used to run it
<fullermd> Long histories are where bzr really eats itself.  Large trees with lots of files, not so hard.  Very large files, hard again.
<ace> let me check
 * fullermd considers "big" to start at a hundred thousand revs of a hundred thousand files.
<ace> 5000 Cpp sources ode for a total of 60mb of text files
<AfC> ace: that's tiny.
<ace> ok
<sabdfl_epic> you won't have performance issues with that tree and bzr
<ace> perfect then
<sabdfl_epic> not even if the tree grows 4x
<luks> you will only have the usual startup performance issues :)
<AfC> The ones that really blow my mind are the Apache mob. They have *all* projects in a *single* Subversion repository. It has over 700,000 revisions in it. Gadzooks.
<mwhudson> AfC: kde too
<luks> AfC: why exactly is that bad?
<sabdfl_epic> it just really constrains your options
<fullermd> Well, it's not by itself; only after you point bzr-svn at it   :p
<AfC> mwhudson: Oh yeah? Haven't tried to import any KDE code lately :)
<mwhudson> it's about the same size i think, ~750k revisions
<luks> that's the price for abusing svn :)
<fullermd> s/ab//
<luks> if you use it the svn way, it's fine
<AfC> luks: well, for one thing, it means several hundred completely unrelated projects are entirely dependent on a single on disk structure.
<AfC> luks: Another is that it means they are all contending for unique resources (the primary key problem).
<luks> AfC: that's a problem apache sysadmins have to consider, not you
<AfC> luks: Third is, well, "HELLO, no bloody way am I putting my precious source code in a single point of failure like that!"
<AfC> :)
<AfC> luks: see point 3 then :)
<fullermd> Well, and that's the sort of load and use-case svn is designed to push for.
<sabdfl_epic> i would have recommended a more granular structure
<AfC> yeah.
<sabdfl_epic> makes it just that much easier to reconfigure, rearrange
<sabdfl_epic> teaches better coding practice!
<luks> sabdfl_epic: actually, it's not true
<sabdfl_epic> but would have required more thought and possibly more sophisticated project infrastructure
<luks> one big svn repository is much more flexible
 * fullermd gets all snarky at the thought of "better coding practice" and "java and XML everything"...
<sabdfl_epic> fsvo flexible
<luks> moving history from one repo to another is a pain
<AfC> ... but you know the Apache mob mindset. Not even "Our way or the highway" because they tend to just focus on "Our way"
<luks> with a single repo you can rename/move anything
<luks> I personally use svn the same way
<luks> it's just easier
<sabdfl_epic> does svn not provide a facility for nested trees through externals?
<AfC> Well. Nice jamming with you lot. Time to get out for a drink.
<fullermd> That's not the only use case.  Take splitting off a part of a project into a new project of its own; in one big repo, you can do that with svn.  You can't, with the same capability, do it with bzr at all.
<AfC> fullermd: that's true. The join/fork story here could be a lot nicer. Alas.
<fullermd> Yeah.  Your choices are either (a) throw away all the history, (b) drag along a lot of unrelated history, or (c) recreate a mirror of the history (which may or may not be sufficiently easy, but still breaks all previous and future merging across the boundary)
<fullermd> It CAN'T be done as simple as svn, internally.  And it would take a lot of infrastructural work and papering to make something functionally equivalent work reasonably well.
<fullermd> (which isn't bzr-specific at all of course.  git or hg or anybody else who conceptually works in full trees would have the same issues)
<jml> if I move my branches, how do I make my checkouts point to the new location?
<LeoNerd> Personally I'd  vim .bzr/branch/branch.conf
<bob2> bzr bind blah
<LeoNerd> That doesn't fix up all the locations though... push/missing etc
<mwhudson> vila: hello!
<spiv> jml: bzr switch, possibly with --force, if I'm understanding the question correctly?
<vila> mwhudson: hi !
<jml> spiv: probably
<spiv> jml: (or edit .bzr/branch/location manually, assuming these are lightweight checkouts...)
<jml> spiv: thanks.
<mwhudson> vila: Ng would like to talk to you, i hope :)
<jml> btw, if anyone is curious, bzr on a largish tree in an encrypted filesystem is basically unusable.
<spiv> jml: lifeless would be, I bet
<Ng> vila: it's about bzr's http requests
 * vila listening
<Ng> if I see this in a .bzr.log.....
<Ng> 22.384  * About to connect() to squid.internal:3128(proxy for bk-internal.mysql.com)
<Ng> 22.384  > GET http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack
<Ng> 22.385  > Host: bk-internal.mysql.com
<Ng> is that *exactly* what was sent? ie there was no HTTP/blah after the URL?
<Ng> the request looks like HTTP/1.1, but afaik if you don't *say* HTTP/1.1 you may not get it, and in this case it's not
<vila> What that produced with -Dhttp ?
<mwhudson> yes
<vila> urlib or pycurl ?
<Ng> how would I determine that?
<vila> nm, if it's .bzr.log it's urllib, sry
<mwhudson> the puller forces urllib
<vila> Ng: Ok, relevant line is 517 in _urllib2_wrappers and indeed is restricted to method and url, so the don't worry, the right headers should be send, but if you used -Dhttp, you should see that too in .bzr.log
<vila> But if you're observing the whole file being transfered instead of just the range requests, there is a known bug in Squid, what version are you using ?
<Ng> vila: 2.6.18
<vila> and for the first part of the question ? Did I guess right ?
<Ng> vila: I'm not exactly sure, bzr just seems to hang
<vila> Can't remember the squid version it was fixed in, spiv and lifeless knows it by heart I'm pretty sure...
<vila> hang for how long ? What size is the pack file ?
<Ng> it's 8MB, it hangs for about 10 minutes and then says: InvalidHttpResponse: Invalid http response for http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack: Expected a boundary (squid/2.6.STABLE18:CDF2964E12A3A3AF0D83A580AC47D079) line, got ''
<vila> Yeah, sounds like it, I'm still searching the relevant bug report, sorry for the delay
<Ng> np
<fullermd> Yeah, I remember that one...
<fullermd> bug 198646 maybe?
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646
 * vila was thinking about putting fullermd inside ubottu seconds ago :)
<fullermd> > This was fixed in the 2.6.STABLE19 release [...]
<vila> fullermd: yeah ! Well done
<fullermd> It's always one version more than you have   ;)
<vila> Ng: as fullermd said ^
 * fullermd has validated his oxygen consumption for the day!
<vila> Ng: upgrade your squid and you should be fine
<Ng> vila: ok thanks very much
<fullermd> Or if you have access to use sftp/bzr+ssh, so you don't hit squid.
<Ng> fullermd: thanks too :)
<vila> Ng: have a look at the bug report anyway as there are some more explanations
<Ng> yep, am reading it :)
<fullermd> I think I'll celebrate by dredging up a sandwich, and then getting back to the eternal joy of writing documentation...
<some3kksf> hi all
<Peng_> some3kksf: Hi?
<ace> tell me, does "bazar" means something in english?
<Jc2k> ace: http://www.thefreedictionary.com/bazar
<ace> funny
<Odd_Bloke> ace: It stems from "The Cathedral and the Bazaar" by esr.
<ace> ah ok
<ace> it has sense
<james_w> do directory services have a way of influencing what directory name is created when you don't specify one to "bzr branch"?
<jelmer> james_w, afaik not
<james_w> it doesn't look like from the code
<james_w> oh well
<NfNitLoop> I'm getting an error:  [Errno 1] Operation not permitted
<NfNitLoop> Is there a way to run bzr in verbose/debug mode?
<NfNitLoop> I tried -v and --verbose with no luck.
<james_w> NfNitLoop: try -Derror
<james_w> NfNitLoop: and "bzr --version" will tell you where your log file is located, that will have more information
<NfNitLoop> actually, a bit of googling found my exact error (and solution):
<NfNitLoop> https://bugs.launchpad.net/bzr/+bug/183948
<ubottu> Ubuntu bug 183948 in bzr "can't PUSH over an sshfs fuse file share" [Undecided,Won't fix]
<NfNitLoop> it's an issue with sshfs, not bzr.
<james_w> -orename?
<matkor> Hi ? Is it possible to get from bzr only conflictin file names ?
<james_w> matkor: bzr conflicts?
<james_w> vim $(bzr conflicts --text)
<matkor> james: Great ! Thanks a lot that's what I am looking for
<Pieter> https://bugs.launchpad.net/bzr-fastimport/+bug/287785 is there a way to assign that bug to me or so?
<ubottu> Ubuntu bug 287785 in bzr-fastimport "bzr-fastexport crashed in git-bzr -- broken pipe" [Undecided,New]
<Pieter> I'm not really sure how launchpad works
<james_w> Pieter: yeah, there is
<Pieter> oh, I found the drop down thingie
<james_w> yup
<evarlast> i was working bound to a repo, did a few local commits, then when I was back online, I did a bzr update, and it deleted a bunch of files. How can I get back my files that were in my local commits?
<Spaz> evarlast, bzr help revert
<evarlast> but revert to what?
<Spaz> also, does bzr work ok with rbash instead of regular bash?
<evarlast> bzr log shows only server revs, not my local commits.
<Spaz> evarlast, i don't know, hence why i said use bzr help revert
<Spaz> i'm not psychic
<Spaz> i do not know what revisions had the files that got deleted
<Spaz> o_O
<fullermd> If you install the heads plugin, you can use it to find the revid of your old local commit head.
<Spaz> ooh
<evarlast> ok, so new question driven by spaz, how can I revert to a local commit or see them in logs.
<Spaz> see fullermd's comment ^
<fullermd> Then you can merge it in.
<evarlast> wow, so I need the heads plugin to see local commits in the log?
<fullermd> That's...   too narrow and too broad to answer.
<evarlast> seems like I should be able to bzr log --local or something.
<fullermd> When you update with local commits, they should be turned into pending merges.  Various things you can do from that point (including revert) can lead to them being off in never-never land.
<fullermd> No, 'local' doesn't really mean anything special in this case.
<fullermd> There's only log, and log works backward from a head.  Those revisions aren't in the history of your current head.
<evarlast> it did when I bzr commit --local, didn't it?
<fullermd> Not exactly, no.
<evarlast> oh, so I should move my current head?
<fullermd> But the revs are still in your repository.  The heads plugin lets you find unreferenced revs in the repo, so once you find the revid, you can force your head to change to that, or merge it in, or whatever is appropriate.
<fullermd> Sorry I can't do details; I'm way overdue to be off elsewhere   :|
<evarlast> ok, I have heads, but the guy with the real problem doesn't :(
<fullermd> Local commits are a treacherous corner.  When you do them, you're working in a distributed fashion, with a layout that works in a centralized fashion.  There are a lot of dragons in a setup like that.
<evarlast> strangely, he did commit local, then he did bzr up, and I would expect them to be pending merges, but bzr status  doesnt' show them as such
<evarlast> so how to restore the old dead head?
<evarlast> i've got a dead head, but I want files out of it.
<evarlast> ah, the nastly long revid: from the heads list.
<evarlast> thanks.
<evarlast> special thanks to Spaz and fullermd
<Spaz> np
<abentley> fullermd: heads is part of bzrtools nowadays.
<AnMaster> Hi, what command does bzr smart server run?
<AnMaster> I can't figure out what force command to set in sshd_config
<AnMaster> to disallow anything except bzr
<luks> it runs `bzr server --inet ...`
<AnMaster> luks, and what extra parameters after that?
<luks> um, I don't know
<Spaz> AnMaster, probably whatever command the client asked is my guess
<luks> there is a wrapper script which might be easier to use for this
<luks> Spaz: no
<AnMaster> luks, oh? got a link?
<AnMaster> luks, I guess it would need repo path
<luks> `bzr serve --inet --allow-writes --directory=/` would be my guess
<luks> AnMaster: it's in contrib/ in the tarball
<luks> contrib/bzr_access
<AnMaster> hm, installed from ports on freebsd so that means *looks at launchpad branch*
<Spaz> AnMaster, no
<luks> you can have per-repository permissions
<Spaz> AnMaster, cd /usr/ports/devel/bzr; make fetch; make extract; cd work/
<AnMaster> Spaz, more complex
<Spaz> though i suppose that's like killing a bird with a boulder
<AnMaster> also build tree not same as ports tree
<AnMaster> aye it is
<AnMaster> but would be faster ;P
<AnMaster> launchpad is slow atm
<AnMaster> "Sorry, there was a problem connecting to the Launchpad server."
<AnMaster> at http://bazaar.launchpad.net/~mbp/bzr/bzr.1.8/files
<Spaz> someone forgot to feed the hamsters powering the server
 * AnMaster sighs
<AnMaster> ah works now
<RaceCondition> is the main difference between branches and repositories that repositories are branches without a working tree?
<jfroy|work> RaceCondition: repositories are containers for branches, nothing more
<jfroy|work> they allow for efficient data sharing for related branches
<RaceCondition> can repositories be worked in, i.e. do they have a working tree?
<jfroy|work> (e.g. branches with a common ancestor)
<RaceCondition> and does the data sharing efficiency only come into play when all branches in the repository are on the same machine/disk?
<jfroy|work> no, again, repositories store branches, period
<jfroy|work> branches have working trees
<RaceCondition> yes, I know that
<RaceCondition> I'm trying to draw parallels to other VCS's
<jfroy|work> And yes, the savings are realized for the branches stored in a particular repository
<RaceCondition> so in which real life situations I would use a repository?
<jfroy|work> You should always use one!
<jfroy|work> You should use many in fact, typically one per project
<jfroy|work> to store your local branches for said projects
<RaceCondition> why not just use branches?
<jfroy|work> anytime you plan on storing related branches, you should put them in a repository, to gain the efficient storage benefits
<RaceCondition> I mean, what's the benefit of having branches in a repository as opposed to having them stand alone?
<jfroy|work> storage efficiency
<RaceCondition> other than that
<jfroy|work> none that I am aware of
<jfroy|work> by efficiency, I mean mostly disk space
<RaceCondition> yeah
<jfroy|work> which could potentially significantly improve speed, because disk access is slow
<RaceCondition> I'm not aware of what format bazaar uses for repositories though.. I know git stores everything in files so it can simply use hardlinks when cloning a repository
<awilkins> RaceCondition: Bazaar uses packs
<jfroy|work> indeed
<jfroy|work> and hard links are support as well
<jfroy|work> but not used by default, I believe
<RaceCondition> are packs modified or are they immutable?
<awilkins> RaceCondition: But using repositories in Bazaar is more that all the branches inside it use the same packs, not that the packs are copied as hardlinks
<RaceCondition> but if hardlinks are possible, why are repositories used? sorry for so many questions, I'm just trying to get the picture here
<awilkins> RaceCondition: Bazaar objects are immutable, just like git objects - packs are not immutable in either Bazaar or git
<RaceCondition> are packs stored as multiple files then or as a single file?
<awilkins> RaceCondition: Packs are stored as one or more files
<awilkins> And may be repacked
<RaceCondition> I see
<awilkins> The main advantage of a shared repo in Bazaar is that branches do not copy the entire repository when you make a new one
<RaceCondition> so basically achieving the same thing git does with hardlinks using a different approach
<jfroy|work> indeed, creating a branch stored in a repository inside the same repository is nearly instantaneous; it's great :)
<awilkins> git is also pretty instant because a branch starts off as one 40 byte file
<RaceCondition> why are most commands kinda slowish though? Python environment start up overhead?
<awilkins> RaceCondition: Which version and platform are you using?
<jfroy|work> and how many plugins
<jfroy|work> (and which)
<awilkins> Yes, also relevant
<RaceCondition> awilkins: I'm actually the most confortable using darcs but I've lately started using git because of it's speed and large community/tool support
<RaceCondition> but I really hate that it's unintuitive and is very hard to learn
<RaceCondition> I'm a programmer and consider myself a good learner, but git really gets me by the balls sometimes
<jfroy|work> Ah, I've been there as well. I could never figure out git entirely, bzr was very easy to pick up in comparison.
<awilkins> Here, "bzr st" takes less than a second in a reasonable size tree (870 items) (win32, core2duo 2gb, vista, bzr 1.8)
<jfroy|work> There are other advantages. Being in Python makes it easily hackable and readable (something shared by Mercurial).
<RaceCondition> well most commands are instantaneous  in git :)
<RaceCondition> which I really enjoy
<jfroy|work> And I work on Mac OS X mostly, so directory versioning is critical.
<awilkins> I think you are right in thinking a lot of that is down to VM setup
<awilkins> Try "bzr shell" and see if that makes an appreciable difference to you
<RaceCondition> jfroy|work: I work on OS X, too, but why is directory versioning critical on OS X?
<jfroy|work> I think so too. Python takes a while to being up.
<jfroy|work> Because of bundles, executable ones or otherwise.
<jfroy|work> Frameworks, applications, document formats, plugins, are all directories on Mac OS X, and I appreciate that bzr handles them properly.
<awilkins> The advantages of Bazaar for me are  i) It was easy to learn ii) It's fast (was faster than SVN, now is very fast)
<awilkins> iii) OK for my _users_ to learn
<awilkins> iv) Written in a language that I could be productive in without a major learning effort
<jfroy|work> indeed, the small learning curve makes it really easy to switch to.
<RaceCondition> so back to repositories -- when doing distributed development, should each developer have a repository or should there be one or more central/main repositories per project and developers just branch remotely from that (or from each other)?
<RaceCondition> jfroy|work: you are an OS X developer?
<awilkins> RaceCondition: You should have a central repo, and your own repo
<jfroy|work> I presume you did read it, but the bazaar guide presents a number of use case scenarios that are really great starting points.
<jfroy|work> RaceCondition: I work for Apple, so yeah :p
<RaceCondition> awilkins: so multiple repos and multiple branches per repo?
<jfroy|work> RaceCondition: more like, a project is going to have a set of branches
<awilkins> RaceCondition: Since you can push a branch to any repo (that has the same rich-root-ness!), yes
<jfroy|work> Some of those branches you will want to share, some will be private (each developer can have their own set of branches)
<RaceCondition> jfroy|work: cool, I like your products :P and now I know who to ask from when I can't figure out the directory layout of OS X :)
<jfroy|work> All of those branches will, likely, have common ancestors.
<awilkins> Yes, I find the combo of a no-trees repo and lightweight or heavyweight checkouts, plus switching, to be the most productive
<jfroy|work> So, you will want to setup one, or more, repositories on networked machines to share branches among developers.
<RaceCondition> ah, yeah, there are checkouts, too :P
<jfroy|work> And each developer will want one, or more, repositories to store branches they are working on on their own machines.
<jfroy|work> Does that make sense?
<jfroy|work> Checkouts are branches, with some convenience tossed on top of it.
<RaceCondition> so basically all developers have repositories plus central ones and all repositories contain all public branches of all developers + private branches?
<jfroy|work> Not necessarily.
<RaceCondition> well more or less
<jfroy|work> Repositories contain the branches that have been created in them or pushed to them.
<awilkins> Central repo doesn't have to have developer branches
<RaceCondition> repository is a (partial) map of the world (development status) of a single project
<jfroy|work> Correct, it will be a sub-set of all the branches.
<RaceCondition> yeah, I see
<jfroy|work> In almost all cases.
<RaceCondition> so in most cases, branches are never stored outside of repositories?
<jfroy|work> There will usually be a "mainline" or "trunk" branch, as well as "release" branches, in one, designated, central repository.
<RaceCondition> yeah
<jfroy|work> That central repository is not special in any ways, it is simply "designated" or "marked with a post-it note" as being the central repository.
<awilkins> RaceCondition: I end up with standalone branches where I'm just using Bazaar as a deployment mechanism :-)
<RaceCondition> yeah, good point
<awilkins> e.g. on user machines.
<RaceCondition> but, in theory, one could only use branches and never use repositories?
<RaceCondition> for development, that is
<jfroy|work> Yeah, I have a bunch of standalone branches for small stuff.
<jfroy|work> Correct
<jfroy|work> Branches can live on their own.
<awilkins> Yes, but certain things are more resource-consumy and certain other things are not possible (like switch)
<jfroy|work> yeah
<awilkins> Actually, you can still switch without shared repos, ignore me
<RaceCondition> now I'm thinking why bazaar doesn't handle this disk space sharing thing in the background and not force the programmer to think about branches AND repositories :)
<awilkins> Heh, sometimes I think it could take a leaf out of gits book and have a branch format that includes the option to have multiple heads in the repo and be able to switch without external directories
<RaceCondition> even though, now I realize git does this in a similar manner
<RaceCondition> what about that checkout thing? is it similar to a central SVN like approach?
<awilkins> Checkouts come in 2 flavours - lightweight and heavy
<awilkins> lightweight commits to it's bound branch
<RaceCondition> because this is what I really like about Bazaar -- my designer guy really never understands the distributed nature of DVCS'es but SVN sucks, but Bazaar has both
<awilkins> heavy commits to it's local branch - AND it's bound branch
<awilkins> So lightweight is the closest you get to SVN in Bazaar
<jfroy|work> ayep
<awilkins> Heavy is similar but you also retain the ability to work offline
<RaceCondition> so heavy checkout is like an SVN checkout but "replicates" the bound branch (repository in SVN terms) locally
<awilkins> And more performance at the expense of local disk space
<RaceCondition> yeah
<RaceCondition> that's cool
<jfroy|work> a heavy checkout is a full branch
<RaceCondition> just that it has hooks to always commit to the bound branch, too
<awilkins> I go for heavy under most circumstances where the bound branch is across a network
<jfroy|work> With the convenience that a commit to it will automatically mean a commit to the parent, bound branch.
<awilkins> On the grounds that the server may fail and it also provides distributed backup
<jfroy|work> You can, in fact, unbind a heavy checkout, and it will be a regular, plain old branch.
<awilkins> Or occasionally "bzr commit --local" when you are offline
<RaceCondition> and of course it's possible to mix the central and distributed approaches so one developer could be using a distributed approach and dumb-users such as designers and project managers could be using a central approach?
<jfroy|work> Lightweight checkouts will *not* work without the parent branch
<RaceCondition> within the same project
<awilkins> RaceCondition:
<awilkins> Yes
<jfroy|work> In fact, I'm not sure lightweight checkouts are relevant anymore now that we have stacked branches
<awilkins> I've not tried stacked branches
<RaceCondition> what are stacked branches?
<jfroy|work> RaceCondition: happiness :)
<jfroy|work> Essentially, a stacked branch has a *partial* set of the parent branch's history.
<RaceCondition> so stacked branches is the same thing as sex and alcohol and going to Hawaii?
<awilkins> A branch where a lot of the history is a pointer that says "look here"
<jfroy|work> It has the recent history, but requires access to the parent branch for anything older.
<RaceCondition> yeah
<jfroy|work> So it makes branching zippy.
<awilkins> So you can have your cake and eat it - have a quick checkout over limited bandwidth and get hacking fast
<jfroy|work> yep :)
<jfroy|work> Hence, happiness.
<awilkins> Can stacked branches move back their history horizon? (e.g. download older history if it becomes apparent they need it?)
<RaceCondition> does Bazaar make it possible to selectively choose which changes to commit in a file in the working tree like darcs and git do?
<jfroy|work> No idea
<jfroy|work> asak|:
<jfroy|work> ...
<jfroy|work> awilkins:
<jfroy|work> RaceCondition: you want to look at the looms plugin for that
<jfroy|work> I believe
<RaceCondition> so no built-in support?
<awilkins> RaceCondition: Yes ; you can list the files manually at the command, or use qcommit or gcommit
<LarstiQ> jfroy|work: hmm, I'm not sure how well they'd go with switch
<jfroy|work> LarstiQ: good point
<LarstiQ> RaceCondition: I'd use shelve for that
<RaceCondition> awilkins: I often have changes in a single file that should be committed separately, in 2 or more commits
<jfroy|work> Ah yes, shelve is good too
<awilkins> RaceCondition: shelve
<awilkins> Not tried looms
<RaceCondition> awilkins: will check it out, thanks
<jfroy|work> You can commit individual files, but if you want a specific change in a specific file, you'll have to use shelve or looms
<jfroy|work> (or a set of specific changes)
<LarstiQ> RaceCondition: or you could use the 'interactive' plugin, but I personally don't like that workflow
<RaceCondition> I see
<RaceCondition> git even has an option to interactively edit diffs that will be committed which I really like
<awilkins> Yes, the "index"
<RaceCondition> because sometimes even a single line contains changes of multiple potential commits
<RaceCondition> no, not the index.. I can edit diffs that will go into the index
<awilkins> That part of git really seems confusing to me (not having used it in anger)
<Pieter> who is the bzr-fastimport maintainer?
<RaceCondition> it's actually one of the less confusing parts of git :)
<RaceCondition> the most confusing part of git is that I cannot push changes to remote repositories/branches and actually have those changes applied on the remote working tree
<awilkins> It's counterintuitive to me.. I'm used to my VCS committing all my current changes by default, not having to be told which ones to commit
<RaceCondition> (without manual hacking)
<awilkins> RaceCondition: That's true of Bazaar too unless you run certain hooks
<RaceCondition> damn
<awilkins> RaceCondition: Well, across the smart network transports
<evarlast> we run without a remote working tree, so when others pull/branch from the remote tree, they do get latest changes.
<RaceCondition> how time consuming it is to set up those hooks? a single command? a script?
<RaceCondition> since I'm normally developing alone, I need a way to "deploy" changes to remote installations
<RaceCondition> without actually logging in remotely and doing a pull/update/merge
<RaceCondition> btw what's the different between pull, update and merge? does update pull AND merge?
<awilkins> Well... I'm not totally familiar. The one I know just uses SSH to make the remote box do a "bzr update" on the branch you just pushed
<awilkins> pull pulls revisions and updates the tree if you have one. If your branches have diverged, pull instead tells you to merge
<awilkins> You need a working tree to merge
<jfroy|work> a pull is a merge + commit in one operation
<RaceCondition> what is an update then?
<awilkins> a "fast forward" in git terms
<jfroy|work> A merge requires a working tree because it will modify a working tree, not commit for you.
<awilkins> update updates your working tree to the latest revision (and pulls it if you are a heavy checkout)
<awilkins> Pull also updates
<awilkins> (if you have a tree)
<jfroy|work> so does merge
<RaceCondition> wtf
<RaceCondition> this is confusing
<jfroy|work> I'm not sure what the distinction between update and merge are
<jfroy|work> :p
<LarstiQ> RaceCondition: git doesn't care about ordering of parents, so it conflates pulling and merging
<jfroy|work> Beyond that update will essentially be a merge from the parent branch (the one you are bound to), and merge can operate on any branch with (or without) a common ancestor.
<awilkins> pull is a special case of merge where the pulling branch has no revisions that are not in the pulled branch
<LarstiQ> RaceCondition: for your updating a remote tree, to me that seems like you are trying to do deployment, which I'd do with bzr-upload
<LarstiQ> RaceCondition: but if you really do want a branch there, you could use the push-and-update plugin
<jfroy|work> right
<jfroy|work> The most correct understanding of "update" is that it updates a working tree.
<RaceCondition> does bzr-upload basically do a selective upload to save bandwidth and not store revision information remotely?
<LarstiQ> right, brings it up to date with the branch
<LarstiQ> RaceCondition: yes
<RaceCondition> does update ever pull stuff from another branch/repository?
<LarstiQ> RaceCondition: no/yes
<awilkins> update pulls revisions to a heavy checkout
<jfroy|work> When you have a bound branch however (e.g. the result of a heavy checkout), update will do a merge with the parent branch as well.
<LarstiQ> RaceCondition: the case where that happens is if you are using a checkout, when it needs to sync the local branch to the master branch
<jfroy|work> Or a pull, I should say.
<RaceCondition> but if I have a regular branch not a checkout? what does update do then?
<awilkins> Updates to the most recent LOCAL revision
<LarstiQ> RaceCondition: make sure the working tree files are the same as the tip of the branch
<jfroy|work> Updates the *working tree* to the branch's most recent revision.
<RaceCondition> I thought revert makes sure the working tree files are the same as the tip :P
<LarstiQ> RaceCondition: say, when you bzr push remotely, the working tree will not be updated, you could do that with a `bzr update` remotely (which is what push-and-update does)
<LarstiQ> RaceCondition: right, I should be more precise
<awilkins> RaceCondition: You're right ; update does NOT do this esp if you reverted to an older revision
<LarstiQ> RaceCondition: update will merge local changes, revert will not
<LarstiQ> (local uncommitted changes, to be precise)
<jfroy|work> right, revert will clobber the working tree with what
<jfroy|work> *with what's in the branch
<RaceCondition> in which situations I might have newer revisions locally that are not applied to the working directory files yet?
<LarstiQ> RaceCondition: no?
<LarstiQ> oh, yes
<LarstiQ> RaceCondition: is that a question or a statement?
<RaceCondition> question
<jfroy|work> I'm confused too :p
<awilkins> RaceCondition: If you are in a working tree that was pushed to using a smart protocol but has not been updated
<LarstiQ> RaceCondition: ok, which situation do you mean then?
<RaceCondition> awilkins' answer satisfied me :P
<LarstiQ> good :)
<jfroy|work> Ah, awilkins is exactly right
<awilkins> RaceCondition: Most of these cases, you receive a warning when pushing
<jfroy|work> Say developer B pushed to developer A's shared branch.
<LarstiQ> RaceCondition: the main reason not to update working trees remotely is that you can't detect conflicts without being horribly wasteful to bandwidth
<RaceCondition> is pull the exact reverse/opposite of push? I mean, to push from A to B is to pull to B from A? are the effects on B the same?
<jfroy|work> Developer A will have to "bzr update" before he sees developer B's changes in his working tree.
<LarstiQ> RaceCondition: almost, yes
<LarstiQ> jfroy|work: right, imo it's a horrible idea to do that to someone :)
<awilkins> RaceCondition: pull always updates working trees because it assumes they are local
<RaceCondition> what about merge? does merge touch the working tree?
<LarstiQ> RaceCondition: yes, it often needs to
<jfroy|work> merge *only* touches the working tree
<jfroy|work> it doesn't actually commit
<awilkins> RaceCondition: merge touches the working tree as much as the revisions you are merging
<jfroy|work> although a branch does keep track of pending merges
<awilkins> And leaves a merge state pending
<LarstiQ> RaceCondition: what jfroy|work said is important, it doesn't commit
<RaceCondition> but is there a command that gets patches from branch A to branch B but doesn't touch the working tree just like push?
<jfroy|work> pull probably as a flag for not updating the working tree
<RaceCondition> I see
<jfroy|work> flag -> option
<RaceCondition> so running pull with that flag + update = regular pull?
<jfroy|work> yes
<awilkins> I don't think pull does have that flag
<jfroy|work> actually, damn, no such option
<jfroy|work> :|
<RaceCondition> doesn't matter, I'm just trying to get a picture :P
<awilkins> You can pull and then revert back to the tip revision you pulled on top of though :-)
<RaceCondition> it's like complex numbers -- the imaginary part really doesnt exist like that pull flag but it makes the equation simpler :)
<LarstiQ> RaceCondition: pull does make a working tree
<LarstiQ> RaceCondition: so if your branch doesn't have one, it doesn't update it
<LarstiQ> argh
<LarstiQ> pull does _not_ make a working tree
<awilkins> Yes, a no-tree branch doesn't have a working tree to write to :-)
<RaceCondition> make? you mean touch the working tree?
<RaceCondition> oh
<LarstiQ> RaceCondition: hmm, I believe there used to be a `fetch` command that did just the revision pulling logic
<awilkins> But if you pull to an empty branch (zero revisions) you will get the working tree also
<RaceCondition> I wish there was a set of underlying elementary commands that made up all user level commands that the user level commands could be explained with/expanded to :P
<RaceCondition> LarstiQ: exactly! fetch was what I was thinking of
<LarstiQ> RaceCondition: well, a lot of that understanding you get from understanding the 3 main domain concepts
<LarstiQ> RaceCondition: being, Branch, WorkingTree, Repository
 * awilkins wonders if Bazaar supports hardlinks on NTFS6
<jfroy|work> Would the fetch-ghosts in bzrtools do what RaceCondition is talking about? I'm not sure what "ghosts" are?
<LarstiQ> RaceCondition: you can have all 3 in the same location, or just one of them, or any two
<LarstiQ> jfroy|work: no
<jfroy|work> Good to know :)
<awilkins> jfroy|work: "ghosts" are revisions that do not exist within a branch
<jfroy|work> Ah
<LarstiQ> jfroy|work: ghosts are references to revisions where you don't have the actual revision object
<awilkins> Oops
<LarstiQ> but you do know the position in the revision dag
<awilkins> I was thinking of something else
<LarstiQ> jfroy|work: if stacked branches didn't point somewhere else to get older history, you'd have a branch with tons of ghosts
<awilkins> Maybe we should have a feature based on that for Halloween
<awilkins> Something that goes "WOO!" every time it encounters a ghost, but only on October 31st :-P
<LarstiQ> jfroy|work: Arch branches used to be similar to stacked branches, except they always pointed somewhere else
<LarstiQ> jfroy|work: so that introduced lots of ghosts when the pointees would disappear
<unenough> what are the highlights of the major changes since version 1.0? i've blinked and we're at 1.8 already
 * LarstiQ looks at NEWS
<jfroy|work> sky is now green, grass blue, and let's not even mention the oceans
<jfroy|work> Or look at NEWS :p
<awilkins> Lots of features, lots of speed.
<LarstiQ> unenough: stacked branches is a major one
<unenough> if NEWS is what i think you're referring to: error, too much information
<jfroy|work> Speed has seen huge progress as well
<jfroy|work> Like, probably an order of magnitude since the early days
<awilkins> In short No Reason Not To Upgrade (tm)
<awilkins> I've been using since 0.9 and never regretted an upgrade (even to random revisions in bzr.dev)
<LarstiQ> unenough: I don't hold the diff in my head, so I'm looking at NEWS too
<unenough> ok
<unenough> :)
<LarstiQ> unenough: an easier question would be if you had specific things in mind
<awilkins> Bazaar is a real poster-boy for test driven development
<jfroy|work> And that is why It Is Awesomeâ¢
<unenough> svn has a "feature" that merges are automatic if there is no "conflict" (which are defined as changes on a single line of text) - can anyone explain what can possibly justify such a destructive "feature"?
<unenough> or am I missing something
<awilkins> I still think you need to commit a merge from SVN after you've done it
<unenough> that's right
<unenough> and yet, what's the sense
<awilkins> Because you should review it to make sure it didn't destroy the universe?
<LarstiQ> unenough: what does "automatic" mean in this context?
<unenough> it means that if svn's diff algorithm decides that two changes are non conflicting, then it merges them (if two changes are in two different lines, it puts in the new versions of both lines)
<lifeless> unenough: generally I don't try to justify things bzr doesn't do :P
<unenough> lifeless, I would gladly use bzr, but i need this for a company that's currently using VSS and the replacement must have Visual studio integration
<unenough> and svn has AnkhSVN
<unenough> and bzr doesn't have it
<unenough> EOF
<awilkins> Hmm, "must have VS integration" sounds like a management-generated requirement
<unenough> awilkins, they are working with VS. that's what they are paying me for..to find an alternative to VSS
<awilkins> And merging two seperate single line changes without conflict is pretty universally normal....
<awilkins> Is this VSS 6 they are using?
<unenough> i think so
<awilkins> Godawful piece of trash
<LarstiQ> unenough: welll
<unenough> awilkins no it isn't normal. what if line 1 was changed to ptr = NULL and line 2 was changed to *ptr = 1?
<LarstiQ> unenough: depending on how much work you want to do, you could continue the VS integration work that currently exists
<unenough> LarstiQ not that much :)
<evarlast> VS integration is pretty damn important.
<evarlast> especially when you figure in things like refactoring tools.
<awilkins> unenough: Adjacent lines are usually thought of as conflicts
<awilkins> unenough: I thought you meant line 1 and line 100
<evarlast> you rename a class, it renames the file for you, these changes need to be done properly in source control
<unenough> awilkins, ok, you can put a ton of lines in the middle, but the logical meaning could be the same
<evarlast> you can do it manually, but it is painful.
<LarstiQ> unenough, evarlast: https://edge.launchpad.net/bzr-visualstudio
<unenough> LarstiQ seen that, it looks premature
<LarstiQ> unenough: it's not as mature as svn integration, no
<awilkins> unenough: Which is why it doesn't commit it off the bat - you should test it and review it before you commit (or at least have a staging branch where you do that)
<LarstiQ> unenough: so it needs someone to work on it :)
<unenough> awilkins what it really should do is tell you "you can't update this unless you perform a merge, OR if you want, merge automatically now and review later"
<unenough> isntead, it FORCES you to merge automatically
<awilkins> unenough: Oh, when you update files that you've edited.
<unenough> yes
<unenough> it "succeeds" in the update, btu actually kills all your files that need merges
<lifeless> this is getting quite offtopic
<unenough> ok, so what does bzr do in this case?
<lifeless> bzr merge will not merge without --force if you have uncommitted changes;
<unenough> that's more like it
<LarstiQ> but pull and update will merge file contents of uncommitted changes
<lifeless> merges are between a revision and a working tree, if your branch is out of date the un-updated changes are not brought in by merging an unrelated other branch
<lifeless> LarstiQ: right, but those commands are defined that way; update isn't merging a different line of work, and pull is maintaining a local mirror-with-edits
<LarstiQ> lifeless: yes, I'm just not certain unenough means bzr merge when he says merge
<lifeless> there is an argument for wanting --force on those cases, but I think it would be an unbreakme option
<unenough> LarstiQ, i'm looking into converting ankhsvn to ankhbzr ... if it's nto hard, i'll do it :)
<jelmer> unenough, there's already a visual studio plugin for bzr
<jelmer> never mind, I missed the earlier discussion
<jfroy|work> jelmer: good [morning, afternoon, evening, night]
<jelmer> jfroy|work, hi
<RaceCondition> I've branched and easy_install'ed the bzr-upload plugin, but how do I use it?
<RaceCondition> bzr-upload nor bzr upload seem to work
<beuno> RaceCondition, it's: bzr upload
<beuno> run:  bzr plugins
<RaceCondition> doesn't show bzr-upload
<beuno> and see if it installed properly
<beuno> right, then it didn't install properly
<RaceCondition> how to install it properly?
<RaceCondition> aha, easy_install was incorrect, python setup.py install was needed instead
<RaceCondition> wonder why, though
<lifeless> easy_install doesn't meet the standard behaviour for python modules and packages
<lifeless> you have to do special stuff to make it work and noone has contributed that stuff to bzr's plugin logic
<lifeless> its pretty crufty anyway, I'm not entirely sure it would be a win to add it :)
<beuno> and, bzr-upload is in Ubuntu and Debian now!
<beuno> intrepid and unstable, but it's there
<RaceCondition> what does the ftp:// URL have to be like?
<RaceCondition> I'm getting bzr: ERROR: No such file: '/path/my/to/dir/': 550 Can't create directory: No such file or directory
<RaceCondition> for totally valid paths
<beuno> RaceCondition, what's the exact command?
<RaceCondition> ah, relative to the home directory
<RaceCondition> nevermind :)
<RaceCondition> anyway, this bzr-upload thing really rocks
<RaceCondition> I think I'm switching over from git right away :P
<beuno> RaceCondition, good to hear
<unenough> what does bzr upload do?
<RaceCondition> unenough: push changes over dumb-transports such as FTP
<unenough> hmm so you can use any dumb server for bzr?
<beuno> unenough, you can use a dumb server without the plugin
<beuno> this just uploads your working tree
<beuno> for websites and such
<RaceCondition> I love that I don't have to do a full upload
<RaceCondition> I wonder if I could bind a branch to a specific FTP location so I wouldn't have to enter a remote location every time I use bzr-upload
<beuno> RaceCondition, and it all came out of a nice dinner and a few beers :)
<RaceCondition> beuno: bzr-upload?
<beuno> RaceCondition, yeah
<RaceCondition> so this means I will want beer whenever I use bzr-upload
 * RaceCondition wants beer
 * beuno invests in beer stocks
<RaceCondition> I also want a nice dinner
 * RaceCondition invests in nice dinner stocks
<RaceCondition> now how can I migrate from git to bazaar -- is there a tool for that? :)
<beuno> RaceCondition, take a look at fastimport
<beuno> not sure how advance it is with git
<beuno> maybe lifeless knows
<RaceCondition> OK
<lifeless> yes, its git-fast-export | bzr fast-import
<lifeless> (roughly)
<lifeless> details are on the wiki I believe
<jam> lifeless: I tried calling via skype, didn't get through
<jam> There is a patch for your review which retries at the CombinedGraphIndex layer
<jam> if you are interested
<jam> I'm still looking at retrying for data access
<jam> it gets pretty convoluted. ATM I'm thinking we'll have to do a pretty large retry
<lifeless> jam: what drives the convolution?
<jam> lifeless: NoSuchFile exceptions while iterating over "self._indices"
<lifeless> jam: I was thinking it would just redo the whole operation (minus already returned items)
<jam> lifeless: right
<jam> the data reads are a bit harder to find the right point to retry
<jam> because we end up re-reading the index a few times
<jam> and we use a lot of helper functions, etc
<jam> I think I can do it, I just need to tweeze apart the state-that-needs-to-be-preserved from the state-that-gets-refreshed
<lifeless> CGI is a bad abbreviation :P
<jam> True :)
<jam> so is GI
<jam> oh wait, it was GC
<l3dx> isn't it possible to use tortoiseBzr if tortoiseSVN is already installed? My context menu only contains svn
<jam> l3dx: it should be fine, though I've heard of problems with TBZR and 64-bit windows in case that is relevant
<markh> where "problems" == "doesn't work at all" :)
<l3dx> 32-bit here
<markh> l3dx: is a bzr taskbar icon created?
<markh> and are you checkin on a local disk (ie, not a network or removable disk)?
<markh> checking (ie, testing)
<l3dx> no taskbar icon, and it's a local env
<markh> I'm not sure what could be going wrong, but the tortoise readme has some info for collecting diagnostic information.
<lifeless> jam: I'm not in front of the skype machine; if you want voice let me know I'll switch rooms
<jam> lifeless: nah, I just skyped for the standup, I'm done for now
#bzr 2008-10-24
<Verterok> -DartifactId=maven-emma-plugin
<vila> hi all
<phoku> hi there
<matkor> Hi ! What does conflict mean "Contents conflict in foo" ? I see only foo.BASE and foo.OTHER ?
<matkor> Why no partially merged foo ?
<lifeless> probably a binary file
<lifeless> or a parallel add
<matkor> mhmmm ... its py file so popably parallel add ... thanks lifeless
<lifeless> if bzr st shows both as versioned
<lifeless> then its parallel add
<lifeless> pick one and bzr mv it to the right name
<fullermd> If there's only a .BASE and .OTHER (no .THIS), wouldn't that mean you had deleted it, and OTHER had changed it?
<lifeless> fullermd: no, it warns clearly on that case
<lifeless> I think
<fullermd> No, it just says 'Contents conflict, with foo.OTHER add'd and foo.BASE unknown.
<Odd_Bloke> jelmer: I'm getting a "SubversionException: ("Can't get entries of non-directory", 160016)", what might be causing that?
<Odd_Bloke> jelmer: This is when doing a "$ bzr branch svn://svn.debian.org/svn/pkg-voip/freepbx/trunk freepbx" BTW.
<james_w> lifeless, spiv: tdflanders is a tricky customer, I think it's best to just leave him be for a bit. I'm dealing with him on several other bugs as well.
<matkor> I had file in rev_A, I did bzr update to rev_B and file is missing ... How can I get latest revision when file existed in branch ?
<awilkins> matkor: Get the file-id from a revision where you knew it existed, and do a verbose log with file-id grepping for it
<awilkins> matkor: It's also fairly trivial to hack in a "log on file-id" option to the log command (not this is the 4th time that's come up in the channel, I think I may submit a patch for it)
<jelmer> Odd_Bloke, please file a bug
<Odd_Bloke> jelmer: Will do.
<matkor> awilkins: Thanks !
<awilkins> matkor: You're welcome ; the problem with logging on file-id is that because of the way inventories work, you can't actually pin down which revision it was deleted in.
<awilkins> matkor: But the last revision it was _changed_ in should be good enough if you just want the file back
<awilkins> matkor: for the deletion revision, you have to run the full log
<Pieter> I made a fix on my old fastimport branch yesterday. But someone had introduced a new bug in the fastimport-dev version. So I merged in fastimport-dev and now want to refer to the commit that introduced the bug. But that commit has another commit number in my branch than in fastimport.dev. how should I refer to it?
<Pieter> use --show-ids?
<Kinnison> If I want to refer to a rev on a moving branch then I use the revid
<Kinnison> they're a bit longer, but they're stable
<Pieter> Hmm, I made changes to my working tree before merging, and now they're added to the merge commit :(
<Kinnison> if you've not pushed that, uncommit, pick them out, revert and start again
<Pieter> yeah.. I wish bazaar would auto-commit on merge
<Kinnison> but the merge might not be right
<Kinnison> E.g. you might want to fix a semantic error caused by the line-by-line merge
<Pieter> yeah, in that case you can just amend the commit
<Kinnison> It'd be trivial for you to write yourself a script which did merge, check-for-conflicts, commit-if-okay
<Kinnison> If you really want that
<Pieter> hmm..? http://pastie.org/299587
<Kinnison> You can't push to launchpad over http
<Pieter> but why is it a saved location then?
<Kinnison> It's probably where you pulled from?
<Kinnison> use bzr push --remember URL-TO-RIGHT-PLACE
<Pieter> right
<Pieter> http://pastie.org/299589
<Pieter> nice :)
<Peng_> Pieter: The bad URL being given by break-lock is known (bug 250451).
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed] https://launchpad.net/bugs/250451
<mwhudson> so the launchpad plugin doesn't seem to cope with random network suckage all that well
<mwhudson> gar
<mwhudson> when will ~ work in bzr+ssh urls?
<awilkins> When a developer gets annoyed enough by it to patch it, I suspect
<mwhudson> it's too easy to work around i guess
<awilkins> It's a one-time annoyance for most branches
<awilkins> So I suppose it doesn't pee you off on a daily basis
<RedLizard> is it possible to synchonize working copies using bazaar without committing the changes?
<fullermd> It annoys me on a semi-regular basis.  Probably would a lot more often it it weren't for bookmarks...
<fullermd> RedLizard: You can use merge --uncommitted on a [local] branch to bring across uncommitted changes.  But it's not really a synchonization tool.
<HippySurfer> Hi, bzr newbie here. Is it safe to copy a branch onto a CD from a Linux box, then back onto a Windows box? Ignoring anything that that might happen to the filenames in the working copy, will the bzr files be OK?
<awilkins> HippySurfer: That should work, AFAIK
<HippySurfer> thanks.
<awilkins> HippySurfer: Do a remove-tree on the folder first and save yourself the space (unless there are unsaved changes)
<RedLizard> fullermd: that should work I think, thanks :)
<HippySurfer> good point.
<RedLizard> fullermd: is it possible to merge your changes into the external branch, rather than the other way around?
<awilkins> RedLizard: You can merge the changes from the external branch, then push to it, but merging needs a working tree because you may have to resolve conflicts
<fullermd> Well, merge has a -d option to do the merge in another directory.  But that's of limited use; it's usually a lot easier to just cd $wherever; bzr merge $other
<fullermd> (and anyway, you'd have to poke around $wherever to verify the changes and commit them anyway)
<RedLizard> awilkins: but can you push uncomitted changes?
<fullermd> No.  Push pushes revisions; it there's no revision, it can't be pushed (pash?)
<RedLizard> can i merge --uncommited -d to a remote (as in, not on the local filesystem) branch?
<fullermd> No, working trees can only be accessed locally.
<fullermd> Realize, you could always commit the changes, push it somewhere, and then use uncommit or pull to 'step back' your branch and not include that commit.
<RedLizard> i don't think that's going to help me
<RedLizard> i'm trying to keep a working copy synchonized over several machines, while retaining the proper merging bazaar provides
<RedLizard> without abusing commits just to synchonize
<RedLizard> any ideas on how to accomplish this?
<fullermd> Well, as a general rule, if you're moving between machines more than once without a commit, You're Doing Something Wrong(tm).
<RedLizard> why?
<RedLizard> what's wrong with what i'm trying to do?
<fullermd> Well, it's not like there's a RULE about how often you have to commit.  But if it takes so long between commits that you're moving where you're working, that tends to suggest that you're doing a whole lot between commits.
<RedLizard> i work both at home (on my home computer) and at the university (on my laptop). Therefore, i need to synchonize twice a day, regardless of how much work I accomplish.
<RedLizard> In particular, i often need to synchonize something that isn't a logical atomic change, and therefore shouldn't be a commit
<fullermd> Well, but commits ARE the item that bzr synchronizes.  You can fake it with 'temporary' commits that you push around and uncommit, but...
<fullermd> merge --uncommitted is a tool to handle the case of "Whoops, I should be making that change in _this_ branch instead"; it won't (and isn't intended to) handle syncing back and forth.
<fullermd> That's what revisions are for after all.
<RedLizard> well, it's true that the problem I'm trying to solve is outside the scope of bazaar, but I don't think there's a different way to do it
<RedLizard> in particular, I can't just rsync working copies around and merge those, because that would mean i would be merging .bzr directories, which will undoubtedly screw things up
<fullermd> It could be done without screwing things up, but yes, it would take a bit of rather careful (which means 'fragile') handwork.
<fullermd> It may help to just scale back the meaning you assign to a commit.  While every commit I make [ideally of course; I fall short in practice sometimes] is of a _single_ thing, that thing isn't necessarily _complete_.  Often isn't, in fact.
<fullermd> 's why I have a lot of side branches; I don't stand for half-done things sitting on a 'main' branch, but in topic branches it's far and away the common state.
<RedLizard> that could work, but there's a requirement that complicates things:
<RedLizard> i don't want any of those synchonization-commits to show up in the public logs
<RedLizard> [of the main repository]
<RedLizard> since they often contain testing files containing passwords etc.
<fullermd> Well, I never add those sort of temp things anyway; if they exist, they're individual and tiny files, and don't change much, so I just scp 'em around manually if necessary.
<Odd_Bloke> I'd like to email a series of patches (i.e. one for each commit) to someone.  What's a good way to do this?
<semslie> does anyone know if the trac-bzr plugin supports remote repositories?
<semslie> currently my bzr repository is hosted on a different server to my trac install
<jelmer> semslie, In theory I think it should, but it would be unworkably slow.
<semslie> jelmer: well, thats a pretty convincing argument against. I'll try to set things up more sensibly instead.
<mdmkolbe> Every time I revert a file, bzr leaves behind a *.~1~ file, is that default or is that something that has to be set per repository?  Also how do I disable that?
<fullermd> Well, you could use --no-backup to make it not create a backup file.
<jelmer> mdmkolbe, it's the default
<mdmkolbe> ok, then is there an easy way to get to or check if I have a pristine code tree.  e.g. "bzr st" doesn't show *.~1~ by default and I need it to
<fullermd> .~whatever files are ignored.
<mdmkolbe> fullermd: yes, but is there a way to (temporarily) make them not ignored?
<fullermd> No.  You could just whack 'em with find, or finger your way through bzr ignored.
<mdmkolbe> fullermd: it looks like bzr ignored will do just what I need, thx
<jdo> bug #288751
<ubottu> Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Undecided,New] https://launchpad.net/bugs/288751
<jdo> just got that using 1.9dev
<jdo> Using saved push location: bzr+ssh://jdobrien@bazaar.launchpad.net/~jdobrien/ubunet/subscription-payments
<jdo>  bzr: ERROR: Revision {jdo@canonical.com-20081006141744-k8myay8ls316o14y} not present in "purchase.py-20080823031523-leymwbfdmocqr4fp-4".
<RaceCondition> I think I might have asked this yesterday, but how do I convert a git repository to a Bazaar one?
<RaceCondition> was it fastimport?
<Odd_Bloke> RaceCondition: Yes.
<RaceCondition> so bzr init mybranch; cd mybranch; bzr fastimport ../mygitrepo/?
<RaceCondition> hmm, I branched bzr-fastimport, but python setup.py install not easy_install . do not work
<RaceCondition> python setup.py install gives no ouput, easy_install complains
<RaceCondition> No eggs found in /Users/erik/bzr/fastimport/egg-dist-tmp-uIh1Oe (setup script problem?)
<james_w> RaceCondition: it's a bzr plugin, drop it in ~/.bazaar/plugins
<james_w> named as "fastimport"
<RaceCondition> oh
<RaceCondition> the fastimport module, right? not the whole branch
<RaceCondition> hmm, there is no fastimport module
<james_w> no, the whole branch
<RaceCondition> got it
<RaceCondition> nice, it worked
<RaceCondition> although it went crazy when I accidentially did git fast-export -all instead of --all
<RaceCondition> does bzr-upload also upload files that are not under version control?
<beuno> RaceCondition, no
<RaceCondition> beuno: weird, it did upload a file that was NOT under version control
<RaceCondition> but that was the initial upload, following ones might be different
<fynn> Hi. How do I get all patches committed by user foo?
<fynn> including a summary, a patch name, and possibly the full diff as well?
<fynn> OK, I'm encountering a weird issue.
<fynn> when I run bzr (no arguments) in a directory that contains a .pyc file, that .pyc file is executed.
<fynn> OK, this isn't just a .pyc file: it works if the directory contains a .py file.
<fynn> i.e. same problem.
<fynn> anyone knows why that is?
<fynn> the problem seems to be caused by a file called parser.py
<jam> fynn: I'm guessing you are on windows?
<fynn> jam: nope, Ubuntu Hardy.
<jam> hmm... we *do* "import parser" in 'bzrlib.tests.test_source' because 'parser' is a module that is part of the standard library
<jam> so you naming a file the same as a standard lib isn't a great thing to do
<jam> however, '.' shouldn't be on our search path
<jam> by default it isn't
<jam> there were some problems with /usr/lib/python2.x/site.py
<jam> which was accidentally including '' into the default search path
<jam> but IIRC that was only on win32
<jam> fynn: can you try: "python -c 'import sys, pprint; pprint.pprint(sys.path)" and paste the output?
<fynn> jam: here's a simple, straightforward reproduction of the problem:
<fynn> http://dpaste.com/86633/
<jam> fynn: right, that doesn't happen here, and I believe it is because your site.py is setting up a bad python module search path
<fynn> jam: http://dpaste.com/86634/
<jam> fynn: notice the '' as the first entry
<fynn> jam: I suspect the problem is ... right
<fynn> I thought that was normal for PYTHONPATH?
<jam> fynn: you have "PYTHONPATH=''" ?
<jam> or do you have it something like "PYTHONPATH='something:'"
<jam> with a trailing ':'
<jam> anyway, you could hack the bzr startup script with
<jam> import sys
<jam> if '' in sys.path:
<jam>   sys.path.remove('')
<jam> but you may want to try and debug how '' is being put into your path
<fynn> jam: no, I'm not changing PYTHONPATH at all.
<fynn> s/changing/setting/
<jam> fynn: ah wait a sec, part of the issue is that 'python -c' is running in the local working directory
<jam> so yeah, it adds ''
<jam> can you try adding the 'pprint' stuff to your 'bzr' script?
<fynn> where is that?
<jam> fynn: probably /usr/bin/bzr
<jam> you can just copy it somewhere else if you don't want to modify it there
<jam> cp /usr/bin/bzr ~/bzr
<jam> and then test it with ~/bzr
<fynn> jam: it adds the CWD as the first entry.
<jam> fynn: it should add the directory of the 'bzr' script, but not CWD
<jam> you are seeing "CWD" always be added?
<jam> well, CWD not the literal 3-letter string :)
<fynn> jam: yes.
<fynn> the first entry on the sys.path seems to consistently be CWD.
<jam> fynn: just to cover all bases, here is a test script
<jam> http://dpaste.com/86640/
<jam> can you copy that into a file like "test.py"
<jam> and then run it as
<jam> cd ..
<jam> python directory/test.py
<jam> and see if it has CWD or only CWD/directory in the search path
<jam> and assuming that fails like the rest
<jam> then it is something with your python installation
<jam> and that takes a bit more to debug
<fynn> jam: $ cat bar.py
<fynn> import sys, pprint
<fynn> pprint.pprint(sys.path)
<Odd_Bloke> loggerhead just made it into unstable. \o/
<Odd_Bloke> 20:26:03 < BTS> loggerhead (NEW) 1.6-1 uploaded by Jelmer Vernooij <jelmer@samba.org> (Closes: #492477) http://packages.qa.debian.org/loggerhead
<fynn> jam: $ python bar.py
<fynn> ['/home/xif',
<fynn> ...
<jam> fynn: that is expected. And if you run it from another directory?
<fynn> jam: same behavior:
<fynn> ['/home/xif/foo',
<jam> fynn: '/home/xif' is also in the path, right?
<fynn> jam: if I run it from a different directory?  no, it's not.
<jam> (the directory containing the script should always be added, and CWD should not. Unless, of course, the script is *in* CWD)
<fynn> ah, one second then.
<fynn> jam: OK, I checked
<fynn> 1) the CWD is always added
<fynn> (as the first entry in sys.path)
<fynn> 2) the script directory is added as well, but not as the first entry.
<jam> fynn: ok, so part (1) is a bad python installation setting, which we can try to debug, but isn't specifically a bzr problem
<jam> fynn: you can try editing /usr/lib/python2.5/site.py
<jam> for example, there is a function "removeduppaths"
<jam> my guess is that it will end up having a '' in sys.path
<jam> which gets expanded to CWD
<jam> just before line 95 or so there is "sys.path[:] = L"
<jam> you could add
<jam> import pprint; pprint.pprint(sys.path); pprint.pprint(L)
<jam> and then paste that
<jam> that will tell us what paths remove dup paths is getting, and what it is setting it to
<jam> fynn: it *could* be that you have a rogue 'foo.pth' file in your path, causing python to get confused about the correct paths
<fynn> jam: you want me to add that debugging line before or after "sys.path[:] = L"?
<fynn> (that's not it: I tried it from several newly-created directories)
<jam> fynn: *before* that line
<jam> fynn: the foo.pth is in some /usr/lib/* location
<jam> well, a "rogue foo.pth" would be there
<fynn> OK, line 100-101 now looks like this:
<fynn> (100-101 in my site.py)
<fynn>     import pprint; pprint.pprint(sys.path); pprint.pprint(L)
<fynn>     sys.path[:] = L
<jam> fynn: right
<jam> now try running bar.py or bzr
<fynn> hm, running 'python -c "pass"' doesn't do a thing.
<fynn> I would have expected a printout.
<fynn> jam: possibly stdout for site.py is suppressed.
<jam> fynn: well looking here if I add "print testing" to site.py it shows up
<jam> it may be that 'removeduppaths' isn't getting called
<jam> fynn: you might try looking at the 'def main()' function
<jam> and adding some debugging there
<jam> fynn: also are you editing 'site.py' in place, or in a local copy?
<fynn> jam: OK, thanks. I guess I should try that.
<jam> A local copy won't be run
<fynn> editing it in place, of course :)
<fynn> jam: this is a fairly vanilla Hardy installation, so I'd suspect I'm not the only one seeing this.
<jam> fynn: the first *I've* seen :)
<jam> and as all python programs would suffer similar issues...
<fynn> hm, I guess it _could_ be my setup.
<fynn> would debug this a bit more when I have the time.
#bzr 2008-10-25
<alester> is there anything more verbose about running my own server than http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server ?
<Peng_> alester: It's not very complicated, so probably not.
<Peng_> alester: The docs for an HTTP smart server are elsewhere in that page.
<alester> it's basically "you have a dir and everything goes thru bzr+ssh"
<alester> I've already got a /bzr/drizzle/trunk set up
<alester> I'll just need to init-repo at /bzr/newproject ?
<alester> I guess what I don't get is what init-repo is actually doin'
<alester> And, the diff between bzr branch and bzr checkout.
<alester> That's the one that's always stumped me.  Can you explain, Peng_?
<Peng_> Err.
 * Peng_ vaguely gestures to the docs.
<alester> Yeah, I have indeed read them.
<alester> oh ewll.
<Peng_> Sorry, but I'm bad at explaining things.
<alester> One is bound, the other isn't
<alester> but that doesn't help me. :-)
<alester> oooh, now it does.
<pickscrape> alester: if a branch is bound it means when you commit to it, the commit also goes to the branch it is bound to
<alester> and you have to be online to do so?
<pickscrape> And update gets revisions from the upstream branch.
<pickscrape> If the upstream branch is online, yes.
<pickscrape> Though you can unbind and make it into a normal branch.
<alester> so I can't use a checkout repo in airplane mode
<alester> which is my key need here on this one.
<pickscrape> Yes, just unbind it
<alester> ok
<alester> so in a checkout, you can only commit to one place
<pickscrape> Say you have upstream branch A, and you do bzr checkout A B to create checkout B.
<pickscrape> This is the same as doing bzr branch A B, except that the new branch is bound to A
<pickscrape> This means that when you commit in B, the commit also goes to A.
<pickscrape> You could get the same effect by doing bzr branch A B, and then doing bzr bind A from within B
<alester> Mine is going to be central, just me.
<alester> but what you're saying is switching between bind and unbind is the diff between a checkout and a branch
<alester> and I can switch between them as necessary
<pickscrape> Checkouts basically give you a centralised workflow, svn style. With the added flexibility that you can unbind it at will.
<pickscrape> Yes
<alester> oK, thank you
<pickscrape> Best thing for you to do really is to experiment checking out a local branch. Doesn't have to be over a network.
<alester> I've been using bzr for a while on launchpad, but have not set up my own projects utnil now
<pickscrape> Just use bzr init A anywhere, create a file in it, commit, then bzr  checkout A B and start experimenting etc.
<alester> I need to get bzr-svn not looking in my home directory.
<Skellus> It might sound not entirely legible (as for all these repository kind of things I am total newbie) but how can a repository be unpacked?
<Peng_> What's your goal and what do you mean?
<Skellus> I mean
<Skellus> that there is a OGG Vorbis "codec" for Actionscript
<Skellus> and it can be
<Skellus> supposedly
<Skellus> downlaoded from
<Skellus> http://people.xiph.org/~arek/bzr/fogg.dev
<Skellus> which is Bazaar repository
<Skellus> the guy says I have to use a command set like this
<Skellus> bzr branch http://people.xiph.org/~arek/bzr/fogg.dev fogg
<Skellus> but inside there iss no source files
<Skellus> some odd files which seem to be logs
<Skellus> and one ~450 kb file which has extension .PACK
<Skellus> which I suppose has to be the source
<Skellus> but I have less than no idea what to do with that thing
<Skellus> But due to my limited knowledge about it
<Skellus> the problem might be as well lying somewhere else
<Peng_> Skellus: "bzr co"?
<Peng_> Skellus: That is, cd to fogg and run "bzr co"/
<Peng_> Err, without the slash. :P
<Skellus> You mean
<Peng_> Wait, what are we talking about?
<Skellus> I should go into
<Skellus> cmd
<Skellus> I mean
<Skellus> command line
<Peng_> Skellus: Have you run "bzr branch http://people.xiph.org/~arek/bzr/fogg.dev"?
<Skellus> nope
<Skellus> yes
<Peng_> Oh.
<Skellus> yes
<Peng_> What?
<Skellus> (got confused here for a second)
<Skellus> Yes, I run
<Skellus> bzr branch http://people.xiph.org/~arek/bzr/fogg.dev fogg
<Skellus> this to be precise
<Peng_> OK.
<Peng_> What's in "fogg"?
<Skellus> hidden .bzr directory
<Skellus> and nothing else
<Peng_> Skellus: Locally? After you branched it?
<Peng_> Skellus: If so, run "bzr co" inside it.
<Peng_> But...I don't get it. That shouldn't happen.
<Peng_> Working trees are created by default.
<Skellus> so you mean in command line I should get to that directory and run "Bzr co", right?
<Skellus> I did it
<Skellus> and it told me
<Skellus> File exists
<Skellus> can't open file
<Skellus> not open
<Skellus> create*
<Skellus> Ah, nevermind
<Skellus> I've used
<Skellus> bzr co "" bla
<Skellus> and now it tells me
<Skellus> Unable to create symlink 'test.swf' on this platform
<Skellus> but I guess that's not the cause of Bazaar this time
<Skellus> Peng_: But thanks either way :)
<bhy> Hi, why bazaar always tend to consume all my memory?
<bhy> I just did a commit with removal of serveral files, but got a MemoryError
<stbuehler> can please someone tell me how to merge a branch in rich-root format back to a launchpad repo?
<fullermd> Well, there's nothing special about being on launchpad.  But you can't merge from rich-root to non-rich-root.
<stbuehler> and let me guess: i cannot update the launchpad branch to rich-root?
<fullermd> As far as I know, you can.
<stbuehler> i tried: bzr upgrade --rich-root lp:~lighttpd/lighttpd/sandbox
<fullermd> Well, you almost certainly want --rich-root-pack rather than --rich-root.  But that's peripheral.
<stbuehler> tried that one too...
<fullermd> At one time you had to do upgrade over sftp for LP; I THOUGHT that was taken care of some time ago, but I don't know.
<stbuehler> "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
<LarstiQ> what does bzr info say it is?
<stbuehler> i see nothing helpful in the output... "Standalone branch (format: unnamed)"
<LarstiQ> unnamed?
<stbuehler> launchpad says it is "Packs containing knits without subtree support"
 * LarstiQ blinks
<fullermd> Using lp: will do that since it walks over the SS which doesn't reveal format info.
<fullermd> It's pack-0.92.
<LarstiQ> stbuehler: it is pack-0.92
<stbuehler> so what is right way to access lp branches, if lp:... is not?
<fullermd> lp: is.  But going over the SS has certain side effects, and one of them is that you can't directly see the remote format.
<fullermd> Format:
<fullermd>        control: bzr remote bzrdir
<fullermd>         branch: Remote BZR Branch
<fullermd>     repository: bzr remote repository
<fullermd> Switching to sftp, it shows the real formats.
<LarstiQ> stbuehler: for upgrading, you could try sftp://bazaar.launchpad.net/~lighttpd/lighttpd/sandbox instead
<mwhudson> (also nosmart+bzr+ssh...)
<fullermd> Also WHAT?
<fullermd> That's the most ridiculous sounding thing I've read in at least 2 hours.
 * mwhudson bows
<stbuehler> thx for your help, it looks like it at least does something now. but i don't think i will use bzr or launchpad for new projects - such problems are not really acceptable.
<Peng_> Ouch.
<fullermd> Our mother dresses us funny too.
<LarstiQ> stbuehler: one of the remote transports launchpad offers doesn't work for upgrading is an unacceptable problem for using bzr?
<stbuehler> unacceptable is: a) that there is an incompability (and no warning for it) b) i didn't find anything helpful in manuals+google
<LarstiQ> feh
<Peng_> What does nosmart+bzr+ssh do exactly?
<Peng_> Oh, SFTP.
<Peng_> That's awesome.
 * fullermd boggles.
<fullermd> It broke my brain enough when I thought it was a _joke_...
<Peng_> :)
<fullermd> Anyway, I have a hard time feeling too disgusted with a guy pissed about tripping over an incompatibility from the default format that we've been discussing round and round doing away with for a year and a half now.
<Peng_> upgrade doesn't work over lp:?
<Peng_> fullermd: Well, he doesn't know that.
<fullermd> *I* do.
<beuno> there's the plan to be able to upgrade branches via launchpad UI
<beuno> so, that doesn't completely solve anything
<fullermd> There's the lots of plans to do the lots of things that aren't.
<beuno> but it's a start
<fullermd> For the human-friendly VCS with the easy UI, we've got a lot of half-wired panels hanging out with sharp edges on the UI.
<beuno> yeah, I agree
<Peng_> jam: FWIW, with the attribute lookup thing on the mailing list, I get similar results on Linux.
<Peng_> (Only it's all twice as slow for me. What kind of computer do you have?!)
 * Peng_ gets depressed
<fullermd> Oh, you haven't seen depressed 'till you've used a PPro to pull updates to bzr.dev in weaves.
<Peng_> Heh.
<Peng_> (My other computer is twice as slow again!)
<fullermd> On a good day, there weren't any changes, so it only took a couple minutes.
<fullermd> If there were any...  well, half hour would be the absolute minimum.
<abentley> Peng_: nosmart+bzr+ssh is similar to sftp, but will work on systems that don't support sftp.
<Peng_> abentley: ...How does that work? It does VFS operations over bzr+ssh?
<abentley> Peng_: Yes.  bzr+ssh has a VFS layer it can use when there's no corresponding "smart" operation.
<Peng_> Yeah, I know. Interesting.
<Peng_> Was supporting nosmart+bzr+ssh intentional?
<abentley> Peng_: I have no reason to think it wasn't intentional.
<Peng_> What's the point? Debugging RPC/smart method/whatever-they're-called issues?
<abentley> Peng_: Not having to switch protocols when a smart operation doesn't do what you want.
<epsy> hi, how do I disable a plugin?
<Peng_> abentley: What do you mean?
<Peng_> (Are we talking about the VFS in general or nosmart+bzr+ssh specifically?)
<abentley> nosmart+bzr+ssh.
<Peng_> When would a smart operation not do what you want?
 * Peng_ is confused.
<abentley> Peng_: bzr info doesn't report useful format information when bzr+ssh is used.
<abentley> Peng_: I have occasionally worked around other bugs using nosmart.
<abentley> epsy: move it into a different directory.
<Peng_> Would sftp be faster than nosmart+bzr+ssh? I mean, OpenSSH is C...
<epsy> hm, then i got a problem..: http://pastebin.com/m7a70f89e
<Peng_> You can disable all plugins temporarily by running with --no-plugins.
<abentley> Peng_: C or not C is pretty irrelevant if you're using the internet.  I would expect bzr+ssh to have a high startup cost, and sftp to be less efficient overall.
<Peng_> bzr's VFS is more efficient than sftp?
<Peng_> Neat. :)
<abentley> Peng: I believe so.  There isn't a 1:1 mapping of VFS operations to SFTP operations.  So some VFS operations require more than one SFTP operation.
<beuno> Peng_, ping
<beuno> tell me about https://code.edge.launchpad.net/~mnordhoff/loggerhead/valid-html when you havee time  :0
<beuno> :)
<beuno> seems like something I'd want to merge
<Peng_> beuno: I ran a couple pages through the HTML validator and fixed some of the simplest things. There's no reason not to merge it, but it's nothing major.
<beuno> Peng_, cool, I'll merge
<Peng_> :)
<beuno> I didn't want you to think I was code-stalking you
<beuno> just happened to see it
<strk> how do I produce a diff which includes file renames and new files and all ?
<strk> if I can at all...
<strk> I received a "merge-diff" once, even contained commit logs
<Verterok> strk: bzr send -o <output-file.patch>
<Verterok> strk: also, check bzr help send for more options
<strk> Verterok: thanks!
<Verterok> np
#bzr 2008-10-26
<pdf23ds> Is there a way to import files from one bzr branch into another with history?
<tetha> hi
<jml> hi
<tetha> currently, I am collecting some of my basic data structures into some sort of private library (which is versioned using bazaar). Differing subsets of this library will be used in different projects, which are going to be versioned in bazaar again. I s there a neat way to nest checkouts, so I can have something like std/ co'd rom repository 1 and everything else to repository 2?
<tetha> on the other hand, thinking this further: I need apt for source modules
<Odd_Bloke> tetha: Yeah, I think you'd be better off structuring the private library such that you can check all of it out for every project.
<Odd_Bloke> Furthermore, there's not really a good way to do it.  Nested trees might help, once they land.
<Odd_Bloke> I'll subtly ping LarstiQ, who's working on them.
<tetha> Yeah, that's what I didjust now
<Odd_Bloke> tetha: Cool. :)
<tetha> if it grows large enough to be a problem, I will either try to abuse apt directly, look if someone wrote something like it for software or write my own ;)
<Odd_Bloke> tetha: What exactly are you looking to do?
<tetha> Odd_Bloke: the ideal tool would be able to contain a bunch of modules (that is, code and test-files). Each module has a name and a description and dependencies on different modules.
<Odd_Bloke> tetha: Have you considered just packaging them?
<tetha> given that, I am able to say "get module A" to that tool and it will get module A and transitive dependencies
<tetha> furhtermore, some unified "update egverything" would be nice
<tetha> I didnt dig much into that topic yet, so no
<Odd_Bloke> Right.
<Odd_Bloke> That would certainly solve this problem. :)
<tetha> I guess so :)
<LarstiQ> Odd_Bloke: 'working on them' is a bit too big a word
<Odd_Bloke> LarstiQ: 'meant to be working on them'? ;)
<LarstiQ> 'slowly plodding through'
<unenough> how can i view a version tree of a file and graphically select revisions to diff?
<LarstiQ> unenough: that sounds like work for viz from bzr-gtk or qlog from qbzr
<mwhudson> unenough: 'bzr viz'
<unenough> ok
<ramvi> I'm looking for a revision control system for web pages. I need the source code to be able to run as well, meaning if you go to a url, you're actually running the last revision. Can bazaar do this or should I look at something else?
<thumper> ramvi: I'm not entirely sure what you are asking
<thumper> ramvi: there is a bzr plug-in called bzr-upload that may do what you are after
 * thumper goes back to hacking
<ramvi> thumper: that's because I didnt explain myself very well
<ramvi> :)
<ramvi> My idea is that I've got some guys working on a webpage. php. And when I go to thewebpage.com/bzr I see the code running, not the source of the php
<ramvi> thumper:  so that you can test if it's working or not
<beuno> I still don't understand what you mean
<ramvi> jeez, I suck. i'm sorry. launchpad is a place where you the view the branch source, right?
<thumper> ramvi: launchpad has a branch viewer
<thumper> ramvi: but the branch has to be in launchpad in order to see it
<beuno> ramvi, so, you want loggerhead to view source
<beuno> ramvi, loggerhead is a bzr web viewer
<ramvi> thanks
<fullermd> Heh.
<fullermd> http://thread.gmane.org/gmane.os.dragonfly-bsd.kernel/12079/focus=12144
<fynn> in Bazaar, what's the proper way to get all patches committed by a certain username?
<beuno> fynn, bzr whoami 'Name Lastname <your@email>'
<Pieter> beuno: I think he means something along the lines of bzr log --author="Name Lastname"
<fynn> indeed I do.
<beuno> :)
<fynn> I want "display all patches committed by James Hacker"
<fynn> in SVN, the way to do it is dump an XML log and parse it.
<fynn> Doesn't bzr have an xml log?
<beuno> fynn, bzr log --short | grep 'James Hacker'
<beuno> ?
<beuno> yes
<beuno> there's a plugin calles bzr-xmloutput
<beuno> http://launchpad.net/bzr-xmloutput
<fynn> beuno: yeah, my problem is with grepping a short common string like "sam"
<beuno> fynn, you can do it with xml
<beuno> or, do bzrlib hackery
<Pieter> or use git-bzr and git log --author="sam" ;)
 * beuno hits Pieter on the head
<poolie> hello
<mwhudson> hi poolie
<poolie> hi
<poolie> are you back home now?
<mwhudson> no, still epic-ing
<lifeless> just found the git book; for folk interested in tracking what they do
<lifeless> http://book.git-scm.com/7_the_packfile.html
<beuno> that's a very nice explanation
<beuno> I'm jealous of their webpage
<beuno> http://git-scm.com/about
#bzr 2009-10-19
<lifeless> james_w: whats the plugins/builder symlink for in 'lp:bzr-builder'
<james_w> tests
<james_w> see the top of __init__.py
<lifeless> that seems awfully complex
<lifeless> why not just 'bzr selftest builder'
<james_w> because the directory you are in may not be in bzr's plugin path
<lifeless> oh right
<lifeless> I really need to get back to that
<lifeless> sigh. ETIME>
<lifeless> james_w: still up?
<lifeless> james_w: for daily debs, how do you manage uploading to each ppa suite?
<ScottK> If you find him, please ask him about uploading the updated qbzr too.
<lifeless> ScottK: to debian or ubuntu?
<lifeless> Debian has a maintenance team, and we're always happy for more uploaders :) JFDI :)
<ScottK> lifeless: Ubuntu, AFAIK it's not in Debian (although it ought to be)
<lifeless> ScottK: any reason you can't just upload it then? [Ubuntu]
<ScottK> lifeless: It's not packaged and I'm not familiar with the package.
<lifeless> oh, thats surprising
<lifeless> is there a bug ?
 * ScottK is just looking at the OMG, Kittens bugs being thrown at motu-release.
<ScottK> Yes.
<ScottK> lifeless: 455051 is the bug asking for the upgrade
<garyvdm> Hi ScottK
<ScottK> lifeless: 447214 is the reason it's important
<ScottK> Hi garyvdm
<lifeless> bug 455051
<ubottu> Launchpad bug 455051 in qbzr "Update qbzr to 0.14.4" [Undecided,New] https://launchpad.net/bugs/455051
<lifeless> bug 447214
<ubottu> Launchpad bug 447214 in qbzr/trunk "Segmentation fault during startup" [Critical,Fix released] https://launchpad.net/bugs/447214
<lifeless> ScottK: so it is packaged, just needs an update?
<ScottK> lifeless: Yes.
<ScottK> james_w TIL, but it's fair game for anyone that wants it.
<lifeless> ScottK: it should be straight forward
<lifeless> debcheckout etc
<ScottK> lifeless: I would guess so, but I've got about 7 other things on my personal list that would come first.
<lifeless> I doubt I'll get to it today, was sick for a week, so backlogged
<ScottK> Yuck.  Hope you're feeling better.
<lifeless> over the hump
<lifeless> not well yet
<ScottK> Good luck.
 * ScottK is off to put kids to bed.
 * igc doctor appointment & lunch - bbl
<mwhudson> jelmer: btw i tried bzr-svn on pypy again and got this:
<mwhudson> bzr: ERROR: exceptions.AssertionError: Tried registering <CachingRevisionMetadata for revision 39426, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'> as parent while <CachingRevisionMetadata for revision 39456, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'> already was parent for <CachingRevisionMetadata for revision 39481, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'>
<mwhudson> looks like https://bugs.edge.launchpad.net/bzr-svn/+bug/343382, which is fix released though
<ubottu> Launchpad bug 343382 in bzr-svn "svn-import fails: âTried registering %r as parent while %r already was parent for %râ" [High,Fix released]
<lifeless> james_w: how do you tie bzr-builder <-> PPA's.
<jkakar> lifeless: I'm writing a command to run bzrlib.upgrade.upgrade on all the branches in a project on Launchpad, like you suggested a few days ago.
<jkakar> lifeless: Can I just get a list of branches and upgrade them all in whatever order I get them, or do I need to upgrade the stacked-on branch first (or last)...?
<jkakar> I guess I could try it on staging.lp.net and see what happens...
<lifeless> jkakar: the order shouldn't matter
<jkakar> lifeless: Awesome, thanks.
<igc> bbiab
<vila> hi all
<bialix> hello all
<Kamping_Kaiser> hi all. can someone look at http://pastebin.ca/1629067 ? Its bzr exploding after trying to branch a bzr repo thats been moved. I ntoe an svn error on oline 2, and wondering if its involved
<bialix> Kamping_Kaiser: you have very old bzr-svn plugin
<bialix> maybe your bug was already fixed
<bialix> any reason why you don't upgrade?
<Kamping_Kaiser> bialix: I've just installed this (debian-stable based) distro. Hadn't thought to find updated bzr repos
<bialix> bzr v.1.5 is almost 1.5 years old
<Kamping_Kaiser> blink. the websites changed.
<Kamping_Kaiser> i'll have a look for the updated version, thanks.
 * igc dinner
<jelmer> mwhudson: There's an open bug about that error, I havent had time to look into it yet.
<mwhudson> jelmer: oh, i only found a closed one
<mwhudson> nm for now
<gioele> hello
<bialix> ask
<gioele> is there a guide to bzr-git? Something that describe how to contribute to a project that uses git using bzr-git?
<gioele> bialix: sometimes I just say hallo and idle :)
<bialix> gioele: I don't jnow any guide
<bialix> gioele: I don't know is there any guide
<bialix> but you can use guide for bzr-svn to get idea how to work with foreign branches
<bialix> and of course you can try to ping jelmer who is one of main authors of bzr-git for specific questions
<bialix> so, basically you need to get HEAD of git repo locally, then branch from it to work and commit, then either send patch to core devs or use merge+dpush command to push your patch into git repo
<bialix> it's a basic workflow as I know
<gioele> bialix: but I fear that dpush is not working with bzr-git (the site states that push is not supported, I think this includes dpush)
<bialix> no, push and dpush is two different beasts
<luks> dpush works
<luks> (it's significantly simpler to implement)
<bialix> hi luks
<luks> hi
<jam> morning vila, I hope you had a good weekend
<vila> jam: pretty good thanks, I hope yours was fine too and good morning !
<vila> jam: any ID what a DuplicateID conflict is ?
<jam> vila: offhand I would say it is trying to create 2 paths with the same file-id
<vila> The doc string says: two files want the same file_id but the code creates the conflict with trans_ids instead...
<vila> How can you create two paths with the same file_id ?
<vila> If the two paths comes from different branches with the same file_id.... I hope it's a rename...
<vila> ...but that they are indeed referring to the *same* file
<jam> vila: I don't know the internals of how to get there, but something like telling TreeTransform.add(path, file_id) 2 times would probably trigger it
<vila> jam: that would be  a bug to me, not something the user may encounter
<jam> vila: I think you are tracking down something that was generated via bugs
<jam> however, we have it (apparently)...
<jam> generally any given tree should only have a file-id 1 time
<jam> if that isn't true, there is a bug
<vila> hmm, ok, punting for now then :-/
<jam> dirstate can certainly hold multiple file-ids accidentally
<jam> Inventory cannot, since it uses a dict of file_id => entry
<jam> CHKInventory similarly keys off of file_id so can't really have that
<jam> though I suppose if InventoryDirectory pointed to children that weren't in the _by_id dict, you could have trouble...
<vila> jam: I can see it occurring under weird nested trees configs... with files trying to cross the nest boundary, but I'm not going to think more about it for now
<jam> vila: no prob, though I'm wondering what made you ask in the first place
<vila> jam: working on resolve --interactive and writing tests for each kind of conflict, I came across that one and was wondering if it was legitimate or not (which is always harder than recognizing a known pattern :)
<vila> jam: also, it's not documented in conflicts.txt unlike the orther ones...
<jam> ah, k
<moldy> hi
<moldy> can i merge changes by file?
<jam> moldy: you *can* do 'bzr merge ../branch/single/file'
<jam> however, it shows up as a 'cherrypick' and thus isn't recorded as a 'full merge'.
<jam> jelmer: are you around? I'm trying to figure out if we need a new bzr-svn for the 2.1.0* series.
<moldy> jam: sounds ok, thank you
<bialix> hello jam
<jam> hi bialix
<bialix> Gary and me prefer to have qbzr 0.15 bundled into both windows installers, pretty please
<jelmer> jam: hi
<jelmer> jam: I haven't seen any particular changes that would require a new release
<jam> jelmer: we bumped 'api_minimum_version' wouldn't that be an issue?
<jam> bialix: I thought 0.14.4 was the stable release?
<jam> we certainly can, but I'd like to be conservative if possible
<jelmer> jam: ah, hadn't seen that
<bialix> jam: yes, 0.14.4 is stable and fine for bzr 2.0.1
<bialix> jam: but qbzr 0.15 uses new improvements from 2.1.0b1
<jam> sure
<bialix> jam: if you prefer to bundle different versions in different installers it's ok
<bialix> jam: because I've built and uploaded windows installer for 0.15
<bialix> so in the end your choice will be final one
<bialix> but AIUI, Gary want to see 0.15 in 2.1.0b1
 * bialix hopes Gary on vacations somewhere near warm sea or ocean, because he appears in i-net very sporadically
<jam> bialix: well, he is in South Africa, and as I understand it, his internet connection is pretty spotty. I know he's ran into issues with upload caps, etc.
<jam> I forget what he said exactly, but something like. "For large downloads, it is cheaper to fly to AU, download, and then fly back."
<bialix> in his last e-mail he wrote:  Sorry - computer access is a bit of a problem for me at the moment (I feel like I'm in the dark ages....) I'm currently borrowing someone laptop (luckily I had previously installed ubuntu for this person...) Once again - sorry for my inactivity.
<vila> Can PQM run on windows ?
<bialix> I dunno what it means exactly but it seems he's away from his personal computer
<bialix> vila: I dunno
<vila> bialix: thanks
<vila> Any other ?
<bialix> last time I've heard it's non-trivial to install and setup it even on Linux, so I have big doubts that anybody managed to run it on Windows
<mathepic> Nothing "really" works on Windows.
<bialix> scary
<jam> vila: I would guess that it can, as it is written in python. I'm not sure about the setup difficulties as bialix mentioned.
<jam> However, I think it is configured to "run this command", which should be pretty platform agnostic
<vila> jam, bialix: thanks, nothing urgent, I just wanted some feeling
<jam> I would guess you'd run into problem with "C:\Program Files\Foo\foo.exe" having a space in it versus wanting to run "make check"
<jam> (arg parsing versus executable path is often an issue on Windows)
<jam> and needs explicit support, etc.
<abgalphabet> is there any gitk equivalent in bzr?
<dash> what's gitk do? :)
<jam> abgalphabet: 'bzr qlog'
<jam> or 'bzr viz'
<dash> ah.
<jam> dash: gitk is actually the adaptation of 'bzr viz' if I remember the timelines correctly
<dash> heh
<jam> qlog is now nicer, IMO
<abgalphabet> i tried bzr viz or bzr vis..it's quite good
<abgalphabet> but it doesn't show relationship btn branches
<abgalphabet> qlog?
<abgalphabet> bzr qlog?
<dash> So. I've got a project in a bzr branch, and a separate project that chose to copy the contents of the working tree at some revision into its branch. both projects have made a lot of changes to the once-shared code.
<jam> abgalphabet: you need to supply multiple branches, or the base of a shared repo, iirc
<jam> 'bzr qlog' is from the qbzr plugin
<dash> I'm trying to undo this and merge both variants.
<abgalphabet> i tried bzr vis branch1 branch2. but it only show branch2
<dash> I'm wondering if there's a better way than shuttling diffs back and forth; some way to replay the revisions from the second project into the first?
<abgalphabet> oh. it actually shows in the message/text description. but not visually intuitvie than gitk
<abgalphabet> how to use the bzr to interact with cvs?
<abgalphabet> gitk cvsimport seems working in synchronize changes in cvs into the git mirror by git cvsimport
<Milo-> sooo.. 'bzr server' has no password protection?
<abgalphabet> any ideas in bzr cvs workflow?
<jam> vila: how about another 200MB memory savings? https://code.edge.launchpad.net/~jameinel/bzr/2.1-peak-mem-tweak/+merge/13582
<jam> I'm still not at 50% though... :(
<vila> jam: that's already very good news, don't be too hard with yourself :)
 * fullermd wonders what the chances are vila will say "No thanks"...
<jam> vila: my biggest concern right now is the 'dark memory'.... I haven't figured out how I'm going to find that yet
<fullermd> Be all like, "No, sorry, thanks, but now I have too much memory to run bzr..."
<jam> finding the zlib stuff was a fluke
<jam> fullermd: well he does have a 16GB machine :)
<vila> 12GB.... don't exagerate
<fullermd> Oh, really?  Hm.  You get his arms, I'll go for the kneecaps...
<jam> vila: you went cheap on me... :)
<jam> anyway, I've set myself a goal of getting to 2:1 memory size for 2.1.0b2, so I'm trying hard to get there
 * fullermd hopes you mean "1:2"  ;>
<vila> hmm, fullermd will tell you that it will not work for 2.2....
<jam> fullermd: old:new
<fullermd> Pfft, ruin all my fun, why doncha...
<vila> . o 0 (Why did I have to give "him" credit for a joke I found myself.... See how grateful "he" is now...)
<Milo-> is there any future planning for password protected smart server over bzr-protocol?
<fullermd> Milo-: In the vague sense that "someday we should".
<fullermd> It punts on AAA pretty much completely now.
<Milo-> last time I used sftp for centralized repo purposes, bzr messed up all permissions in the repo for some reason
<Milo-> and friend can't connect using bzr+ssh, his windows fails for some reason.
<LarstiQ> Milo-: you could try ClueBzrServer
<Milo-> heh
 * Tak commit ChangeLog in the conservatory, with the candlestick
<vila> jam: I'm about to EOD so I won't review your patch today (just so you don't wait for me)
<dash> Hmm
<dash> is there a way to exclude files from the current view?
<dash> or create a view that excludes stuff. all I see is inclusion
<beuno> dash, I know there's filtered views
<beuno> but I don't know any specifics
<mfer> Pilky: ping
 * rotty has a problem with repo corruption: http://pastebin.com/m5f16cba1
<rotty> this repository used to work fine, but fails with newer bzr:s. I assume it was borked from the beginning (Arch import several years ago), but bzr started to notice just now.
<rotty> I've googled quite a bit, but couldn't turn up a solution
<beuno> rotty, have you tried "bzr reconcile"?
<rotty> beuno: "revision history ok", the what seems to be the same error.
<rotty> s/the what/then what/
<beuno> hrm
<beuno> jfroy|work,
<beuno> jam may know
<rotty> beuno: btw, the branch is publically available: "bzr branch lp:~rotty/g-wrap/dev"
<beuno> abentley, hi!
<rotty> it's fine to branch, but "bzr check" and e.g. "bzr log" fail
<abentley> beuno: hi
<beuno> maybe you would know how (or id) it can be fixed ^
<rotty> that would be awesome...
<abentley> beuno, rotty: I don't know of an automatic way to fix that.
<beuno> rotty, otherwise, try the mailing list, where all devs can walk you through it
<rotty> abentley: I've seen some scripts floating in several bugs, but they seem only tangentially related
<abentley> rotty: It looks like corruption at a pretty low level.
<rotty> abentley, beuno: I'll drop a mail on the bazaar list
<mfer> anyone familiar with the status of BazaarX?
<Pilky> mfer: you rang?
<mfer> Pilky: hey. I was wondering what's going on with BazaarX
<mfer> Pilky: I have hope for a usable OS X ui. there isn't anything at the moment and I think that's a big deal
<Pilky> mfer: well I've reset it and when I finally get round to it I'll be releasing 0.1
<Pilky> which is basically just packaging it up, what is in the repo atm is basically 0.1
<mfer> Pilky: what is in the 0.1?
<Pilky> basically it will show all the branches in a repo, the status of a branch and let you add, remove and commit
<Pilky> but only locally
<mfer> ok
<Pilky> the next two versions are going to be log and then mv/push/pull
<Pilky> though I'm not sure which will be 0.2 or 0.3 and have no time frame for when I'll work on them
<mfer> Pilky: how much work will it take to bring these in? what kind of time table are you looking at?
<mfer> ah
<mfer> Pilky: are you thinking in terms of weeks or months?
<Pilky> months
 * mfer hopes its not years :)
<mfer> ok
<mfer> Pilky: are you working this alone?
<Pilky> BazaarX is more a part time project really that I work on as and when I need it
<Pilky> almost
<Pilky> one or two people contribute a few bits of code, but mostly knowledge
<mfer> are you looking for others to help with it?
<mfer> The lack of a good mac gui is going to stop bazaar from getting into a lot of places and one that i'm interested in.
<Pilky> sure if you're interested in helping out
<mfer> Pilky: i can't garuntee anything but i'll see if there's anything i can do or anyone i can ralley
<mfer> thanks for the update
<Pilky> do you have much Cocoa experience?
<mfer> Pilky: nope. but, i'm a quick learner. :)
<Pilky> heh, well BazaarX is 100% Cocoa/Obj-C and Objective-bzr (the API that BazaarX uses which is being developed along with it) is about 80% Cocoa/Obj-C and 20% Python
<mfer> ok
<Pilky> but yeah, even if it's only putting forward ideas for how a feature should work or filing bugs it'd help a lot
<mfer> I'd rather start by getting some others in on it. Like a UX person for the gui/features, some Cocoa codes to help there, etc
<mfer> that's better than me picking it up and having at it
<Pilky> well sure, I mean I've quite good at UX stuff but I have been struggling with BazaarX so any help in that area would be great
<Pilky> but like I say, for me it is currently a side project I work on in my free time
<Pilky> I might try to get 0.1 packaged up this week
<Pilky> but at the moment my commercial software is taking precedent
<mfer> Pilky: paying the bills is important. I understand that
<Berge> Cheers! I've got a bzr repository which suddenly grew from a couple of GB. It's supposed to contain relativly small XML files.
<Berge> I'd like to find out when and where this happened. The last diffs are all quite small.
<Berge> Can bzr show me the size of a given revision, for instance?
<Berge> This is bzr 1.5 from Debian lenny, using python 2.5.2.
<Berge> Uhm, the repository grew from a couple of hundred KB to about 7GB.
<lifeless> Berge: ouch
<lifeless> Berge: there is a 'repository-details' plugin, but it doesn't have the ability to query by revision
<lifeless> Berge: you could try:
<lifeless> bzr push /tmp/measure -r 1
<lifeless> du -sh /tmp/measure
<lifeless> bzr push /tmp/measure -r 2
<lifeless> du -sh /tmp/measure
<lifeless> repeat
<Berge> Hm, yes.
<Berge> I'll try and see.
<Berge> Aha. Somebody actually commited a few GB in a given revision, and managed to hide it in a large diff.
<Berge> lifeless: Cheers, found it.
<lifeless> Berge: 'ouch'
<Berge> lifeless: Indeed.
<Berge> But I'll happily nudge someone. Glad to find out.
<Berge> Have a wonderful evening!
<dash> Hmm
<dash> in a lightweight checkout, how do I do something like svn's "svn up -r 123"?
<LarstiQ> bzr revert -r 123 ?
<dash> that registers as a change to the working copy though
<dash> rather than just sucking in the revisions
<dash> I was able to use "bzr co --lightweight -r 100" to create the checkout
<dash> I could just delete it and do it again
<LarstiQ> ah like so
<dash> but i thought there might be a thing
<LarstiQ> that would be `bzr up -r`, when implemented
<dash> "when implemented". Right. :)
<dash> okay then, guess i'll just repeat
<bialix> hi garyvdm
<lifeless> dash: hi
<garyvdm> Hi bialix
<lifeless> dash: update -r 123 is available in a patch in the bugtracker
<dash> ok
<dash> it's not a big deal
<bialix> garyvdm: about your mail: about 1/3 of changes in 0.15 is good for me
<bialix> garyvdm: some performance improvements, many bugfixes
<garyvdm> bialix: You don't want to use bzr 2.1?
<bialix> no
<bialix> it's beta, right?
<garyvdm> bialix: 2.0.0 release with 0.14. And the idea for 2.0 it is ment to only have bug fixes. If bzr 2.0.1 has qbzr 0.15, then it has new features...
<garyvdm> That dose not stop someone from using bzr 2.0.1 with qbzr 0.15.
<bialix> how long we have to support 0.14 then?
<garyvdm> As long as bzr 2.0.x is supported (I think 6 months)
<garyvdm> bialix: We don't have to, but I think it would be good.
<bialix> I'm a bit confused
<bialix> see my answer
<garyvdm> bialix: Yes - bug fixes should be in 0.14
<bialix> if you so strong about supporting 0.14 then I'll better to switch to it as my main qbzr version and will start to backport fixes
<jfroy|work> jelmer: ping?
<mwhudson> hm
<mwhudson> so on launchpad we have a branch that won't branch
<mwhudson> but check is fine
<mwhudson> and if i copy it using lftp locally, it's ok too
<mwhudson> http://pastebin.ubuntu.com/297156/
<james_w> mwhudson: bug 437626 has the same error message
<ubottu> Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,New] https://launchpad.net/bugs/437626
<james_w> probably not helpful though
<james_w> though it does have some dupes
<james_w> so it may not be just an error you hit in various situations
<mwhudson> james_w: looks like the same problem indeed
<mwhudson> spiv: i can help you reproduce 437626 right now
<mwhudson> spiv: are you awake yet?
<jelmer> jfroy|work: hi
<jfroy|work> jelmer: hey. so I think I solved my problem, but I can ask anyways.
<jfroy|work> As a best practice, how do you initialize a new Subversion repository from a Bazaar branch?
<jfroy|work> What I did this particular time is use svn to mkdir trunk, branches and tags.
<jelmer> jfroy|work: I don't mkdir trunk, I just push to trunk
<jfroy|work> Then used push --overwrite from the bazaar branch to push to trunk.
<dash> jfroy: don't you use bzr svn-serve instead? :)
<jfroy|work> Just pushing correctly complained that the branches had diverged.
<lifeless> mwhudson: spiv is usually another 40 minutes away or so
<mwhudson> lifeless: ok
<jelmer> jfroy|work: creating a branch with mkdir is the eqiuvalent of creating a branch with a single commit it in
<lifeless> mornings<--------------------------->spiv
<jelmer> jfroy|work: so it is correct that you get an error about diverged branches
<jfroy|work> dash: eh, no, the source does need to go in that svn server, it's backed up offsite and integrated into the build system, etc etc.
<jelmer> moin lifeless
<lifeless> hi jelmer
<jfroy|work> jelmer: ah, I didn't you know you just push to a non-existing directory.
<lifeless> your ignore patch - you'll need to explain more about it I think
<jfroy|work> Particularly since the branch has several tags which I wanted to appear in /tags
<jfroy|work> push --overwrite seemed to work pretty well though.
<mwhudson> lifeless: yeah, i knew that much :)
<jelmer> lifeless: did you see my email about supporting .hgignore,.gitignore and .bzrignore files?
<jelmer> (an RFC to the list a couple of months ago)
<lifeless> jelmer: i think I saw it go past
<jelmer> lifeless: Basically I'd like to add a mechanism to support the use of .hgignore and .gitignore files in native bazaar working trees
<lifeless> jelmer: would you want to support .hg files in Git trees?
<jelmer> lifeless: sure, why not (if there is no .gitignore file)
<lifeless> jelmer: do you mean to union these things together, or support one at a time?
<lifeless> jelmer: and what about globals? do you mean to union all the git hg bzr global/default ignores, or take each systems one?
<jelmer> lifeless: support one at a time
<lifeless> jelmer: so, putting aside whether this sounds nice to me or not
<lifeless> structurally
<jelmer> lifeless: it seems to make most sense to use the matching global one (global hg ignore file if using .gignore)
<lifeless> we have an existing interface on tree
<lifeless> if you want to make that do indirection, select an implementation etc, then that would be ok
<lifeless> I don't think a separate 'ignores' module is very discoverable, and having different bits of the code base talk to that rather than tree would allow skew and confusion
<lifeless> plus there is important state - the compiled matching rules - that tree maintains
<lifeless> so for all those reasons, I really think that the interfaces to work with ignores should be on MutableTree
<lifeless> and you can dispatch behind that layer to a registry or whatever.
<jelmer> lifeless: having those interfaces on MutableTree seems to make sense to me
<jelmer> lifeless: What value does get_ignore_files() have though? Its return value is highly dependent on the underlying .*ignore file that is being used
<jfroy|work> Urg, I think I self.shoot(self.foot)
<jfroy|work> I have A -> B -> C (A is parent of B, is parent of C)
<jfroy|work> oh, they're branches
<jfroy|work> Unfortunately, C has nothing to do with B
<jfroy|work> C should have been a child of A.
<jfroy|work> Is there a way to rebase (I guess that's what I want?) C unto A at the point C was branched from B?
<jfroy|work> My ultimate goal is to land C on A.
<jfroy|work> (but only C)
<spiv> mwhudson: hey
<lifeless> jelmer: well, 'are the ignore files versioned', for instance
<mwhudson> spiv: hello
<spiv> mwhudson: please capture a tarball of the repo if you haven't already
<lifeless> jelmer: I'm not trying to defend that particular interface; but I think we need the patches to be clearer about how they fit into the overall structure.
<mwhudson> spiv: which end?
<spiv> mwhudson: local is probably more important
<spiv> mwhudson: but both if you don't mind! :)
<lifeless> jfroy|work: rebase yes
<lifeless> jfroy|work: or a cherrypick merge
<spiv> mwhudson: but it seems to be pretty easy lose the ability to reproduce by doing other things to your local repo, so taking a copy is good start
<mwhudson> well i don't have a local repo so that part is easy
<spiv> mwhudson: huh!
<mwhudson> spiv: can you access devpad https urls?
<spiv> I think so
<mwhudson> spiv: https://devpad.canonical.com/~mwh/uk1.tgz is what i end up with in my local repo
<mwhudson> (about 97 megs)
<spiv> ok
<jelmer> lifeless: hmm
<jelmer> lifeless:  I was trying to avoid making this too broad
<mwhudson> currently trying to grab the branch over sftp tpp
<mwhudson> too
<spiv> mwhudson: thanks
<mwhudson> seems to be getting further, at a guess
<lifeless> jelmer: because from your description of the patch I got 'move a function from wt to the ignore module because its implementation specific'
<lifeless> jelmer: and as wt's *represent implementations* that doesn't make sense.
<mwhudson> spiv: yeah, branch over sftp worked fine
<lifeless> jelmer: on the tastefulness of this side, I think it will make debugging ignores harder
<lifeless> jelmer: so I think you need to spend some time thinking about how this polymorphism will be shown in the UI, - and all the docs that will need to be updated to tell people about it
<igc> morning
<jelmer> lifeless: hmm
<igc> hi spiv, lifeless, mwhudson, jelmer
<mwhudson> hello igc
<jelmer> hi Ian, Michael, Andrew
<garyvdm> Hi igc
<igc> hi garyvdm
#bzr 2009-10-20
<jelmer> lifeless: anyway, thanks for the comments. I'll give it some thought
<lifeless> kk
<igc> jelmer: on another topic, what's your timeline for subvertpy 0.7 being released?
<jelmer> igc: Nothing in particular at the moment; if it would be useful for you I could do a release right now
<igc> jlemer: I'm not reconsidering where best you new fast-import script lives
<igc> s/not/now/
<igc> jelmer: my worry is that 0.6.9 is in karmic
<igc> jelmer: does subvertpy end up in our PPA?
<jelmer> igc: there is a separate subverpty PPA but it doesn't have very recent versions at the moment
<jelmer> igc: that's fixable though
<igc> jelmer: maybe my wrapper script - fast-export-from-svn - ought to look for your script and use it if found
<igc> otherwise, fall back to the current one
<igc> your script could live in subvertpy
<igc> and be called something like "subvertpy-fast-export" ...
<igc> or subversion-fast-export even
<igc> jelmer: ^^^
<jelmer> igc: that'd be fine with me
<igc> jelmer: ok, let's do that
<jelmer> ok
<igc> jelmer: so the next step is for you to release 0.7.0 with that script included and point me to a PPA
<igc> I'll them tweak fast-export-from-svn to go looking for it
<igc> then
<jelmer> igc: ok
<igc> jelmer: cool
 * igc out for medical stuff - bbl
<jelmer> igc: I've uploaded 0.7.0
<jelmer> lifeless: so, there are two implementations that should be distinct imho: the ignore file implementation and the working tree implementation, the two aren't necessarily coupled
<igc> thanks jelmer
<jelmer> lifeless: I'd rather see them in separate source files as we for clarity's sake
<lifeless> jelmer: we don't really have a private module concept though
<jelmer> from the working tree's pov it shouldn't matter what format ignore file is used
<lifeless> and it is odd to have a module thats all private
<lifeless> jelmer: actually it matters a lot
<lifeless> jelmer: wt4 on all bzr versions that support wt4 should be able to process the ignores
<jelmer> lifeless: I haven't mentioned privateness anywhere
<jelmer> lifeless: is that really necessary? That would imply .gitignore support in bzrlib or no support for .gitignore in bzr working trees at all
<lifeless> jelmer: bzr checkout <project> foo; cd foo; (build); bzr st
<lifeless> should be clean
<lifeless> if the authors have made it clean using ignores
<lifeless> shouldn't it?
<jelmer> lifeless: yes
<jelmer> lifeless: but would it be ok if that required bzr-git if the original branch was imported from git?
<jelmer> lifeless: I agree it's not ideal but I don't see anything significantly better without storing ignores as tree metadata rather than inside the tree
<lifeless> jelmer: igc has a 'needed plugins' concept that is worth exploring more
<lifeless> Personally, I'd hesitate to add this indirection to existing tree formats
<lifeless> but I only say hesitate because clearly all imports can't work today, so its not really a regression
<jelmer> lifeless: what's the problem with adding this to existing formats compared to adding it to new formats?
<lifeless> none of the existing bzr versions - e.g. 2.0.0 - know how to handle it
<jelmer> lifeless: I do see your point, though it's hard to come up with anything else that allows the use of foreign ignores in the short-o to mid-term
<lifeless> jelmer: we have 5 months before the next stable release
<lifeless> jelmer: and as I say, *I* would hesitate, thats not to say it shouldn't be done.
<lifeless> I would worry that it will confuse folk on 2.0.0 to have someone say 'wow x works' and not have it work for them.
<lifeless> particularly with e.g. NFS home dirs
<spiv> mwhudson: so, did you capture any other tarballs?  What was the command you ran?
<jfroy|work> whoa
<jfroy|work> I think I've found a serious bug.
<jfroy|work> or there's something very weird going on.
<jfroy|work> I removed a file I am certain is under version control from a checkout, and bzr st is reporting nothing
<jfroy|work> I change that file from the base, and bzr st reports nothing.
<jfroy|work> And I moved aside .bzrignore
<jfroy|work> I'm scared :|
<spiv> .bzrignore won't affect files that are already versioned.
<bob2> is it shown by 'bzr inventory'?
<bjp> will loggerhead work with the new 2.0 formats?
<spiv> bjp: yes, although you probably need a recent version.
<bjp> i'm pretty sure i have the latest
<bjp> just wanted to make sure before converting my repos
<jfroy|work> yes, bzr inventory shows the file
<mwhudson> spiv: just bzr get lp:~ubuntu-core-doc/gnome-user-docs/ubuntu-karmic
<mwhudson> spiv: but i access the copy of the branch in the hosted area
<lifeless> jfroy|work: details
<jfroy|work> what do you need to know?
<lifeless> jfroy|work: is the file in 'bzr inventory -r -1'
<mwhudson> spiv: let me faff for a moment
<lifeless> or if inventory barfs on that, can you do 'bzr cat -r -1 PATH'
<jfroy|work> lifeless: yes
<lifeless> and you have deleted it now
<lifeless> but 'bzr st' doesn't reflect that?
<jfroy|work> one sec, more weirdness
<jfroy|work> tes
<jfroy|work> *yes
<lifeless> is the file in 'bzr inventory'
<jfroy|work> it is
<jfroy|work> this is very odd
<lifeless> so, if its in bzr inventory its not 'removed' but it could be missing
<lifeless> its odd for 'bzr st' not to show it
<lifeless> what bzr version?
<jfroy|work> 2.0.1
<jfroy|work> there's more going on here
<jfroy|work> I think my system has gone nuts :p
<mwhudson> strange, mkdir in lftp always fails against codehosting
<jfroy|work> AH!
<lifeless> yes, codehosting isn't quite sftp anymore
 * jfroy|work hides in shame
<spiv> mwhudson: maybe it tries to emulate 'mkdir -p' but gets confused about the topmost directories not actually existing?
<lifeless> pwd != pwd ?
<jfroy|work> I was operating on a different directory in the GUI than the shell
<mwhudson> spiv: hm, maybe
<jfroy|work> I apologize.
<fullermd> Guuuh.  Stupid stat begging for WT...
<lifeless> jfroy|work: no worries
<spiv> mwhudson: how goes the faff?
<spiv> mwhudson: that branch command worked for me, btw
<mwhudson> spiv: progress, i think
<mwhudson> spiv: i'm not entirely surprised
 * spiv nods
<mwhudson> spiv: try bzr get lp:~spiv/+junk/u-k
<spiv> mwhudson: curiously, my fetch retrieved an identical number of revisions, inventories and texts as your tarball
<spiv> heh
<spiv> That reminds me I should make some noise on the bug for 'should not be able to make random stuff owned (and thus implicitly attributed to) people w/o their permission'
<mwhudson> spiv: i can only do that because i'm a bazaar-expert
<spiv> Ah, that's good.
<mwhudson> spiv: a copy of the branch made with lftp's
<mwhudson> 'mirror' command is at https://devpad.canonical.com/~mwh/mirror.tgz
 * spiv encoffees
<spiv> mwhudson: that reproduces, thank you!
<mwhudson> spiv: yay
<spiv> Hmm, I should probably grab a mirror of the stacked-on branch too, just in case.
<mwhudson> yes i guess so
<spiv> if nothing else, being able to reproduce without consuming my adsl bandwidth would be plus :)
<mwhudson> heh yes
<spiv> mwhudson: I have some sort-of good news for you
<spiv> mwhudson: it's almost certainly a client-side bug, which means no cherrypick when I do fix it ;)
<mwhudson> spiv: yay
<igc> mwhudson: re bug 441125 ...
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125
<igc> I used lftp to grab the branch
<igc> but it doesn't report being a branch once I grab it
<igc> should I use 'mirror' instead?
<mwhudson> igc: how did you grab it?
<igc> mwhudson: or maybe it was just lftp user error on my side?
<mwhudson> igc: also if it's stacked, the stacked on branch will be relative
<mwhudson> igc: so you'll need to fix that
<igc> hmm
 * igc looks
<igc> mwhudson: I don''t think it's stacked looking through the .bzr directory
<igc> mwhuson: bzr info -v reports it as being an unshared repository, even though .bzr/branch and all the files seem to be there
<mwhudson> igc: what is in .bzr/branch/branch.conf ?
<igc> ah, me wrong ...
<igc> parent_location = lp-hosted:///%7Escott/upstart/trunk/
<igc> stacked_on_location = /~scott/upstart/trunk
<igc> that's all
 * mwhudson gets out his "practical bzr debugging" badge
<igc> spiv: ping
<igc> spiv: any chance you could be second reviewer on some simple patches in the queue?
<igc> https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380
<igc> https://code.edge.launchpad.net/~joke/bzr/bugfix353370/+merge/13404
<igc> https://code.edge.launchpad.net/~mathepic/bzr/remove-tree-multi/+merge/13451
<igc> spiv: all are just a few lines long and pretty straight forward imo
<spiv> igc: ok
<igc> spiv: also, is https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-chk-map/+merge/13082 ready to land?
<igc> for some reason, I'm not allow to change it to "Approved'
<igc> spiv: maybe because you claimed the reivew?
<spiv> igc: because the target is not a branch you have rights to
<igc> spiv: ah - fair enough
<spiv> igc: this is the downside to the way jam found to get LP reviews to do incremental diffs
<igc> spiv: right
 * igc pick up kids - bbiab
<igc> back
<bialix> hello all
<bialix> hi garyvdm, thanks for such detailed mails.
<garyvdm> Hi bialix - Sure - Sorry I did not do it earlier.
<bialix> yep
<bialix> I suppose your i-net and/or free time is problematic. no problem.
<garyvdm> Yes - I hope to get that sorted out soon.
<bialix> will be nice
<bialix> I'm glad you're back on board :-)
<otu> hi! i am trying out bazaar and i am trying to settle on a workflow for using it with django. anybody have any tips?
<igc> hi bialix, garyvdm
<garyvdm> Hi Igc
 * igc dinner
<bialix> hi igc
<garyvdm> Hi vila
<garyvdm> vila: I want to make a test that requires user interaction. For this reason, I'm not going to incude it in the test suit.
<garyvdm> vila: I'm trying to work out the easiest way to do this.
<garyvdm> Can you give me any pointer.
<vila> garyvdm: phone call
<garyvdm> Ok
<vila> garyvdm: ping.... if you read logs somewhere...
<vila> garyvdm: automated tests assumes no user is there. If a user is required, that's not automated anymore, so I'd like to understand better why you want to write such a test...
<bialix> vila: perhaps because writing automated tests for PyQt4 is a hard job
<bialix> garyvdm: I think custom launcher for non-automated tests should be enough?
<vila> GUI automated tests are always hard, but you have to start somewhere...
<garyvdm> Hi vila, bialix.
<vila> garyvdm: hi
<vila> garyvdm: automated tests assumes no user is there. If a user is required, that's not automated anymore, so I'd like to understand better why you want to write such a test...
<bialix> hi Gary (again)
<garyvdm> I was disconnected for a while. It seems I missed some dicussion. I'll take a look in the logs.
<bialix> garyvdm: you don't miss anything yet
<bialix> vila just repeated his question to you
<garyvdm> Ok
<garyvdm> This is what I started on: http://pastebin.ubuntu.com/297350/
<garyvdm> vila, bialix: That should give you a good Idea of what I want to do.
<garyvdm> My problem is getting a TestCase to run, that is not apart of the test suite.
<bialix> hmmm
<vila> garyvdm: oh, ok, so while I still think that's not the right way to go :-) What you want is a test loader and a test runner
<vila> garyvdm: look into bzrlib.tests.TestUtil.py
<garyvdm> vila: Thanks - That is what I was looking for.
<vila> hmm, only the loader is defined here, let me see for the runner
<bialix> the runner in bzr;lib/tests/__init__.py
<vila> garyvdm: hmm, for the runner it's more controversial, but you can use .. yeah like bialix said
<bialix> garyvdm: any reason why you want to use unittest-like interface?
<garyvdm> To be able to reuse assertRaises
<bialix> then you have to write custom TestRunner
<bialix> IMO
<lifeless> I'm about to go crash
<lifeless> but if you were to mail the list with a broad "i want to achieve x' I'd be delighted to reply tomorrow
<garyvdm> lifeless: Ok - I'll do that.
<jml> hi
<garyvdm> Hi jml
<jml> there's a bug with a branch at https://bugs.edge.launchpad.net/bzr/+bug/84659 that has been approved
<ubottu> Launchpad bug 84659 in bzr ""serve --allow-writes" allows more than you might think" [Medium,In progress]
<jam> morning all
<Meths> I'm being sent to a 404 (http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings) from http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html
<Meths> Can anyone tell me where the proper bug tracker settings page can be found please?
<Meths> Is there a bzr documentation project or should I just post a bug in bzr?
<bialix> hello jam
<bialix> jam: we discussed with garyvdm qbzr versions re bzr versions, perhaps you saw that thread in qbzr ml. resume: 0.14.4 is for bzr 2.0.1, 0.15 for bzr 2.1.0b1
<jam> morning bialix
<jam> Meths: bug in bzr is fine
<bialix> :-D
<jam> bialix: sure
<Meths> jam: okay.
<Tak> is there a way to cache my svn credentials with bzr-svn?
<jam> Tak: IIRC you can use svn to cache the credentials, and then bzr-svn will use the cached values
<jam> but it doesn't have a way to cache them itself
<jam> alternatively, I think you can set up authentication.conf, but I'm not sure how to set that up w/ svn
 * Tak try that
<Tak> hah - svn co doesn't ask me, but bzr pull from an existing branch does
<jam> Tak: what versions are you using?
<vila> morning jam
<Tak> bzr 2.0.1, svn 1.6.5, bzr-svn 1.0.0
<Tak> wow @ bazaar-vcs.org makeover
<jml> btw, I just found a bug with a branch at https://bugs.edge.launchpad.net/bzr/+bug/84659 that has been approved but not merged.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/84659/+text)
<Tak> aha - if I set up authentication.conf, I can get: http://paste2.org/p/476652
<Meths> Is there an ETA for 2.0.1 .exes?
<jam> Meths: approximately today, it just depends on how many hiccups I run into while trying to build them
<Meths> jam: cool, thanks.  Do they always cause lots of headaches compared to the other packages?
<jam> Meths: yeah, generally. It is the only place where we bundle everything in one package
<jam> so skew means rebuilding the whole thnig
<jam> thing
<jam> so you need the right version of bzr-svn, bzr-rewrite, qbzr, tortoisebzr, ...
<jam> by contrast on Linux, each of those is a separate package, so if there is a problem *that* package gets updated
<jam> also, by there are some bad designs in the windows packaging
<jam> namely, the code that defines plugin dependencies is *in* bzr's setup.py
<jam> which means that plugins have to match bzr, which is a bit wonky
<Tak> aha, bug 452121
<ubottu> Launchpad bug 452121 in bzr-svn "Putting svn password in authentication.conf doesn't work" [Undecided,New] https://launchpad.net/bugs/452121
<jam> Meths: also, the shared machine we use to make the windows builds is 'remote', and has a bug with DNS so you have to manually add hosts to the 'hosts' file. Which generally is ok, but can be annoying
<jam> being hosted in AU doesn't help *my* ping times, though :)
<bialix> jam: there is desire to factor out plugins dependencies from bzr's setup.py
<jam> bialix: absolutely, but we need people to actually... do it
<jam> which is non trivial
<bialix> yep
<jam> and since *I'm* the one that pays the primary burden, I would be the one to fix it
<bialix> I don't think it's non trivial
<jam> but I'm also the one working on new features, etc.
<bialix> it's just need some time
<jam> bialix: you think it would be a trivial change?
<bialix> I mean I understand the way where we should go to achieve this
<bialix> but it require lot of work
<bialix> I have proof of concept of moving such data to plugin's setup.py
<bialix> you said in the past that this is almost impossible
<bialix> I have proof of concept that it very possible
<bialix> but then you did not answer
<bialix> I suppose you have distracted by other more important things
<bialix> and vila too
<bialix> so, it's not "trivial" as 5-minutes fix
<jam> bialix: so I see it as possible, but getting 10 plugins to all switch to the format, and getting bzr's setup.py cleaned up is at least a couple of days to a weeks worth of work
<bialix> but it's not "non-trivial" as you need many weeks to experiment first before writing actual code
<jam> to a week
<bialix> here I'm agreed
<bialix> couple of days
<bialix> and push all these improvements back to each component upstream
<bialix> IIUC there is only 2 components affected: tbzr and qbzr
<jam> bialix: and bzr-svn
<jam> I think, not positive
 * bialix looks
<jam> but certainly tbzr is the one that has caused the most dependency problems
<jam> bzr-svn has caused the most 'rebuild a new installer' problems
<bialix> you as core dev can voluntary working on transferring dependency codes
<bialix> I'd like to have clear agreement about approach first
<bialix> at my job we always writing mini specs first before coding
<bialix> for bzr-svn the dependency is simple, but indeed present
<bialix> def get_svn_py2exe_info(includes, excludes, packages):
<bialix>     packages.append('subvertpy')
<bialix> jam: while I'm here. This is my proof of concept to load required data from plugin's setup.py lp:~bialix/+junk/plugins-setups
<bialix> jam: to really start working on it somebody should extend plugins API definition as in http://doc.bazaar-vcs.org/bzr.dev/developers/plugin-api.html#plugin-metadata-before-installation
<bialix> for me this is 2 mandatory dependencies
<jam>  \o/ finally the build completed... now to get people to poke at it :)
<bialix> cool
<jam> I probably can't build 2.1.0b1 yet, because bzr-svn at least needs updating
<jam> but at least 2.0.1 will be done
<bialix> all hail jam!
<jam> bialix: thanks for the encouragement
 * jam does not like doing the installers, but seems to be the only one doing it...
<bialix> building tbzr is still the corner of entire installer process
<bialix> because of full MSVC 2008 required
<jam> bialix: yeah, supposedly naoki had it working without the full compiler
<jam> using specific versions of SDKs, etc
<jam> I haven't seen his setup, yet
<jam> but he mentioned not needing it for his work
<bialix> I'm not sure
<jam> bialix: just to check, we should be using qzbr 0.14.4  and bzr-explorer 0.8.3, right?
<jam> bialix: he mentioned it in the bug about tbzr not compiling with the lite version
<jam> I don't have it off-hand
<jam> and IIRC, he didn't give specific steps to reproduce
<bialix> qbzr 0.14.4 and explorer 0.8.3, correct
<jam> vila: how is babune looking lately?
<vila> pfff
<jam> bialix: also at some point we'll want to start bundling svn 1.6.*
<vila> leopard is back, I had to fight with tiger to avoid a log file filling my boot disk (which is quite painful as it's the host for the guest I'm using for IRC and mail riht now :-/)
<vila> so OSX suffers from a latent bug related to leaking tests but the bug stop manifesting itself on leopard
<vila> and tiger failed this morning but without filling my OSX /
<vila> jam: which more or less confirms that I'm right about the cause of the bug, but gives no idea on where to start to fix it... (I have some ideas but none are trivial so I let them mature a bit)
<jam> vila: sounds like about as much fun as I've been having with the installers :)
<vila> jam: so I'm back working on resolve --interactive.... and realizes there are many conflicts than need more love, to the point I may want to define a new format :-/
<vila> jam: yeah ! Lots of fun ! :-D
<vila> well many is too strong, but at least 3 or 4 :-/
<jam> vila: yeah for conflicts we sort of have the 'minimal set' right now. We could use clearer definitions for 'directory already exists' versus 'parent directory deleted' etc.
<jam> Which I had looked at a while back
<jam> when we were debugging what was going on w/ mysql
<vila> there is also the fact that sometimes we create several conflicts and I'm not sure we really need that...
<vila> So my basic concern is about how to change conflicts definition with regard to compatibility,
<vila> can we consider that upgrading while having conflicts in a tree is rare enough that we can say:
<jam> vila: do it in 2.1.0* and don't overly concern yourself :)
<vila> Oh, no luck, I can't read your conflicts anymore, please redo your merge
<jam> vila: I would say, if it is a problem, refuse to upgrade if there are conflicts
<jam> so let them sort it out how they want
<jam> revert, resolve, whatever
<vila> hmm, no the code has to be changed, so the data and the code should stay in sync :-/
<jam> so when working on old format working trees, I think you need to interpret the conflicts file the same as old clients
<jam> there are people that share workingtrees across NFS
<jam> (which I don't recommend in any fashion, but it happens)
<vila> jam: right, so I need to address the backward compatibility issue at least :-/.
<vila> jam: and since I don't want to do that right now, I think I will restrict implementing --interactive for some conflicts only instead
<vila> that way I will move forward instead of backward at each step :-/
<jam> vila: usually a preferred direction :)
<vila> :)
<jam> vila: so I'd like to check the current memory status on 64-bit python. Would it be okay if I bring down a copy of the launchpad code base onto 'saw' ?
<jam> I think it is ~100-200MB of data
<vila> hmm, what size ?
<vila> ok, be aware you're on an SSD, so don't burn it too fast :)
<vila> jam: if you need HDD instead I can create some dir somewhere you can symlink from your home
<vila> but up to 1GB, go for the SSD
<jam> vila: I certainly don't need to use the SSD, but if it means you don't have to do more work, I'm happy to use it :)
<vila> jam: still 33GB free there, as long as the tmp files for selftest are not on it, SSD ftw !
<jam> vila: I'm shocked, I'm only getting 16kB/s downloading launchpad's code from lp
<jam> I wonder what is going on...
<jam> maybe codehosting is overloaded?
<jam> going via http, I'm peaking at around 2MB/s
<jam> though it is pretty choppy
<vila> jam: don't know what you tried, I get 2MB/s right now
<vila> oh, you too
<jam> vila: first attempt was 'bzr branch lp:launchpad' which would go via bzr+ssh
<jam> And I'm wondering if that wasn't slow because of the bzr:// server side
<jam> for example, if codehosting is thrashing into swap
<vila> jam: my observations so far are that the rate is highly variable (and different from what a perfmeter will report)
<vila> but the difference is due to our processing so not worth fixing IMHO
<jam> vila: well we could do better on the filtering
<jam> such as using "a = a + b*cur"
<jam> (first order filter)
<jam> rather than just "a = cur / time"
<vila> jam: well we can't satisfy everybody, I think the actual figures are quite representative, if people want more detailed bandwith usage, that's outside bzr (still IMHO :)
<vila> right now you're using between 0 and 1MB/s, what did bzr report ?
<jam> vila: I think we tend to under-report
<jam> because a long download followed by a quick short one
<jam> will get overrwritten
<vila> jam: nope, I've seen both under and over reports
<vila> that's why I didn't report myself :-D
<jam> vila: right now it reports ~.5M
<jam> so sure
<jam> my point is that it is unstable because we mix big reads with short reads
<jam> and don't average across them
<vila> from the perfmeter that's quite correct, you had peaks at 2MB/s
<vila> jam: well, I'd prefer we fix the code so that we always max the bandwith :)
<vila> you're flag now
<vila> for the last 30 secs
<vila> s/flag/flat/
<jam> yeah, it is on the 'missing keys' portion
<jam> so almost done
<vila> peak at 2
<vila> flat
 * vila cries
<vila> what on earth is an 'overwrite' conflict !
<fullermd> The thing that conceals an underwrite conflict.
 * vila send some anti-bits on fullermd disks just so he too can have his share of fun :)]
<fullermd> Anti-bits take up negative space, so it's like getting larger disks for free!
<vila> fullermd: you wish !
<fullermd> It seems logical.
<vila> no, anti-bits erase real bits and disapear, the net result can be smaller sectors for example
<vila> so you have your regular 512 bytes sectors and then some at 511 or 510 see
<vila> Actually, I *encountered* such behavior in real life... at leasts it looked like that, we found part of files that had shrinked
<fullermd> Man, how prejudiced can you be?  anti-bits are just as 'real' as regular bits.  Don't be such a baryogenetic racist.
<vila> shrinked in the *middle* of fixed size records...
<vila> ..in the end it was an hardware bug, but boy did we wonder...
<fullermd> That's why I run ZFS   :p
<fullermd> jam: BTW, can you weigh in on the DWIM "looks like a revno but isn't" fallthru thingy?  It's kinda mixed...
<jam> jelmer: btw, subvertpy 0.7.0 breaks the build...
<jam> subvertpy\repos.c:24:21: apr_md5.h
<jam> No such file or directory
<jam> perhaps this is a svn 1.6ism?
<fullermd> That's part of APR, actually.
<jelmer> jam: I've just merged a fix for that
<jelmer> jam: will update bzr-windows-installer
<jam> fullermd: sure it is apr, but my assumption was that subvertpy was using something from a newer apr which is bundled with a newer svn
<jam> jelmer: so a subvertpy 0.7.1 ?
<fullermd> Oh.  I didn't know svn bundled APR.
<jelmer> jam: there was an incorrect include path in setup.py that for some reason wasn't a problem before now
<jam> fullermd: so... the revspec dwim is basically someone doing "bzr branch -r 1.2.3" and there isn't a revno 1.2.3 but there is a *tag* 1.2.3
<jam> fullermd: well, it depends on it, and exposes the pools etc as part of svn's pai
<jam> api
<jam> jelmer: let me know when you've pushed the updates
<jam> also is 0.7.0 reasonable to include in 2.0.x series?
<jam> (aka, bugfix only?)
<fullermd> Or any of the other laters specs tried, but tag is overwhelmingly the most likely to have a hit, yah.
<jelmer> jam: no, 0.7.0 is not bug fix only - it contains new bindings as well
<jelmer> jam: (enough to make subvertpy-fast-export work)
<jelmer> jam: shouldn't have an influence on the stability of the existing bindings that bzr-svn depends on though
<jam> jelmer: so I would probably rather do 0.7.0 in the 2.1.0b1 release, and stick with 0.6.9 in the 2.0.x series
<jam> I'll probably split of a separate bzr-windows-installer branch for the 2.0.* series
<jam> since we also have stuff like qbzr 0.15 vs 0.14 series, etc.
<jam> jelmer: at least IMO, if it is different enough to break the build, it is different enough to not include in 'stable' :)
<jelmer> jam: sounds ok to me :-)
<jelmer> jam: can you create a 2.1 branch for the intsallers?
<jelmer> *installers
<jam> yeah
<jam> well, I was thinking to just use the standard trunk for the 2.1 series
<jam> and branch off 2.0 stable series
<jelmer> the only reason I added 0.7.0 was because I had probmised to keep bzr-windows-installers up to date on new releases :-)
<jam> sure
<jam> please do so
<jam> i'll branch of a 2.0.x now
<jam> ideally this wouldn't be separate branches (because that is a pain to administer)
<jam> but instead it would be "make 2.0" vs "make 2.1"
<jam> however, separate branches is easier *today*
<jam> jelmer: and yes, thank you for keeping bzr-windows-installer up to date
<jam> still working through the issues for a 2.0.* stable series versus 2.1.0* dev series
<jam> jelmer: do you have an updated bzr-svn release for the 2.1 series ?
<jam> igc: when you get a chance, did bzr-explorer 0.9.0 actually get a release? or should I just bundle 0.8.3 w/ 2.1.0b1
<jam> abentley: I don't see a tag for 2.1.0b1 in the bzrtools trunk
<jam> am I just missing it
<jam> ?
<abentley> jam: I see it, but perhaps it's not in the mirrored copy of the branch...
<jam> abentley: can you tell me the revno?
<abentley> jam: No, it's in the mirrored copy too.
<abentley> jam: revno 732
<jam> abentley: 'bzr pull lp:bzrtools' gives me: 730 Aaron Bentley     2009-09-26 {release-2.0.1}
<jam>     revision-id:aaron@aaronbentley.com-20090926174001-f1kpi0tqgizyx5g5
<jam>     Release 2.0.1
<jam> should I be pulling: lp:~abentley/bzrtools/trunk instead ?
<jam> note that dev focus is ~abentley/bzrtools/bzrtools.dev
<abentley> jam: yeah, for now.
<jam> :'( so much pain
<jam> not just you, but about 5 plugins need to be hand crafted for the release seires
<jam> series
<jam> and running "make" is ~ 30 min as buildout checks all the dependencies, etc...
<jam> I'm glad I caught it before uploading at least...
<abentley> jam: I've pushed to bzrtools.dev.
<abentley> jam: I'll be deleting trunk.
<jam> k
<vds> anyone have some hints on how to solve this: bzr: ERROR: Connection error: curl connection error (Problem with the SSL CA cert (path? access rights?)) ?
<vds> ok solved ca-certificate wasn't installed...
<ToyKeeper> Hmm, that was odd.
<ToyKeeper> bzr-rebase pulled instead of rebasing, and wiped out all the changes I wanted to rebase.
<ToyKeeper> I'm glad I was working on a copy.
<jelmer> jam: 1.0.1 will be compatible with 2.1
<jam> jelmer: thanks for the heads up. Let me know when subvertpy 0.7.1 and bzr-svn 1.0.1 are out
<jelmer> jam: *nod*
<jelmer> jam: subvertpy 0.7.1 is out, bzr-svn 1.0.1 on the way
<igc> jam: there's no explorer 0.90 release yet - I'm targeting 2.1.0b2 for that
<jam> igc: yeah, I noticed
<jam> I just saw you mention some work that went into the 0.9 series
<jam> and thought that meant you were releasing it
<lifeless> moin
<thumper> lifeless: morning
<thumper> if I have a branch with no tree, what is the easiest way of getting the size of the repo?
<thumper> can I get that through bzrlib?
<thumper> or just do a du of the .bzr dir?
<lifeless> what are you trying to estimate
<lifeless> size on disk of a checkout?
<thumper> the size on disk
<lifeless> size of tree?
<thumper> branch size
<thumper> it is one of the metrics that we want to store
<thumper> for us
<thumper> size in the hosting facility
<lifeless> ok
<lifeless> size in the hosting facility - du -sh .
<thumper> kk
<lifeless> will include backup.bzr if it exists
<lifeless> and thats good, IMO
<thumper> hmm...
<thumper> I hadn't thought of that bit
<thumper> lifeless: is there a python way to do that without shelling out?
<lifeless> and naturally for stacked branches this should be a very small number
<thumper> exactly
<lifeless> thumper: yes, there is. recursive walk statting everything. can do it via the transport interface even
<lifeless> should be fast even on huge branches because we don't create many files
<lifeless> if we ignore 'dir size', which I think is safe to do:
<lifeless> sum(map(lambda p:b.bzrdir.root_transport.stat(p).st_size, b.bzrdir.root_transport.iter_files_recursive())
 * thumper tries the mystic map
<thumper> lifeless: what is the unit for st_size?
<fullermd> stat(2) gives it in bytes; I presume python passes the same through.
<lifeless> yes
<lifeless> this will give 'content size' not 'allocated size'
<lifeless> we have that too if you need it, but you need st_nblocks * blocksize, or something like that
<fullermd> Yah.  But in this case, the lions share will be in a few giant .packs, so the different is probably ignorable.
 * igc food
<lifeless> fullermd: it generally only matters for us on the small incremental packs; there are 5 files per push, so the overhead can be non trivial on 64KB allocation units fs's
<fullermd> Oh, perhaps.  I was just thinking that it could be in the noise.  I mean, if we have 20 packs, and waste a full 64k (say having N*64k+1 bytes in each), that's still only 6 megs, when we may have 500 or so in the packs.
<lifeless> right
<fullermd> Depends on what you're doing with the numbers, I guess.
<lifeless> but consider a stacked branch
<lifeless> may only be a few hundred k data in total
<spiv> And maybe LP still has lots of knit format branches ;)
<fullermd> Yeah, I heard about 'em every time I multi-pull in my ~/.bazaar/plugins/   :p
<mwhudson> there are ~700 knit branches on lp it seems
<mwhudson> that have had updates in about, uh, 18 months
<PsyberS> what does this error mean and how do i fix it:
<PsyberS> $ bzr unshelve
<PsyberS> Unshelving changes with id "2".
<PsyberS> bzr: ERROR: The file id "weather-20091020223948-b5odfh732rtw2uvz-1" is not present in the tree <DirStateRevisionTree of chris@szikszoy.com-20091020003650-ytlugguaozazh0u6 in DirState(u'/home/rdyer/branches/docky/.bzr/checkout/dirstate')>.
<PsyberS> i shelved a bunch of changes, did a 'bzr pull' (there was nothing new to pull) and then got that when i unshelved
<jelmer> PsyberS: did the pull remove a file that you had shelved changes in perhaps?
<PsyberS> the pull didnt do anything, i was on the latest revision (apparently)
<PsyberS> rdyer@narmada:~/branches/docky/Docky.StandardPlugins$ bzr pull
<PsyberS> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~docky-core/docky/trunk/
<PsyberS> No revisions to pull.
<PsyberS> to think i was just bragging to some people about how nice bzr was =o
<PsyberS> oh well, cest la vie
#bzr 2009-10-21
<igc> emmajane: ping
<KhaZ_> Hello!  I apologize if this is the wrong place to ask this, but does anyone here use the bzr-p4 plugin?  I'm trying to understand just what it does but the documentation on it appears to be rather minimal.
<lifeless> you can try bzr help p4 (if thats what the directory for the plugin is called)
<lifeless> I don't know how complete it is
<KhaZ_> Ah, OK.  I supopse I'll isntall it.  Just trying to  read more of it before I install it - not sure if it will solve my problems or not.
<lifeless> but most foreign VCS plugins allow 'bzr pull' 'bzr branch' etc to Just Work with urls/locations in those systems
<KhaZ_> Ah, neat.  Maybe that is something similar to what I want.  Is bzr push normally facilitated as well, or is it usually up to the client to use the other VCS' tool for that?
<lifeless> depends on how complete the plugin is :)
<KhaZ_> Ah, but it's not out of the qeustion then at least.
<lifeless> but yes, certainly for bzr-svn and bzr-git the whole gamut of push/pull/branch/merge commands work
<KhaZ_> Swank.  I will have to dabble with this.  Perforce is getting on my nerves.
<KhaZ_> ALright, dumb question.  How can I see what plugin directory bzr is scanning for?  I'm running cygwin on vista, and I've tried $APPDATA/bazaar/2.0/plugins and ~/.bazaar/plugins, and yet bzr plugins doesn't return me any of my nifty plugins.  Is there an easy way to get it to spit out the path it's looking up?
<fullermd> Not directly, I don't think.  But it should be a 'plugins/' subdir under the 'Bazaar configuration' dir that `bzr version` spits out, I think.
<KhaZ_> Genius, that works.  Thanks fullermd.
<KhaZ_> Ah, right.  I had reset my BZR_HOME in order to try and keep my linux/windows configurations the same.  D'oh, should've checked the env. variables. :/
<fullermd> Maybe there should be an arg to 'plugins' to list the search path.
<KhaZ_> I was hoping --verbose would show it
<KhaZ_> fullermd: Might be a nice add.
<fullermd> Nah, that just shows where the existing plugins are from.
<jdub> i'm getting the following error after attempting to bzr co with http basic auth against loggerhead:
<jdub> bzr: ERROR: exceptions.KeyError: 'user'
<jdub> (interactive or provided in the url)
<KhaZ_> fullermd: Right.  I guess my assumption was it woudl say, "Found the following plugins from scanning these paths [searchpath1,searchpath2,searchpath3]: plugin1 [plugin1path], etc."
<KhaZ_> Not that it matters, but that was where my intuition took me.
<fullermd> It's a reasonable intuition.  You should file a bug on it.
<spiv> jdub: hmm, sounds crummy.  pastebin a full traceback?
<jdub> spiv: http://www.gnome.org/~jdub/2009/bzr-20091021002215-9259.crash
<KhaZ_> fullermd: Good idea.  Done: https://bugs.launchpad.net/bzr/+bug/456834
<ubottu> Launchpad bug 456834 in bzr "Command "bzr plugins" - would be nice to output searchpaths somehow." [Undecided,New]
<lifeless> jdub: is loggerhead doing the auth, or some front-end web server?
<jdub> lifeless: front end
<lifeless> how are you passing the user details to the backend then ? :)
<jdub> lifeless: not sure i am; if anything, i don't want to
<mwhudson> jdub: i'm suspicious of the bzr-svn in that traceback
<jdub> mwhudson: you think bzr-svn on the client might be screwing with it?
<mwhudson> it's possible
<jdub> ah, you know, yes
<jdub> it might be trying to use bzr svn on the http url?
<jdub> jdub@sliver:/tmp$ bzr co bzr+http://whitlam.crikey.com.au/code/live/bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://whitlam.crikey.com.au/code/live/.bzr/smart: Unknown response code 403
<lifeless> I think you should:
<lifeless> file a bug
<lifeless> remove bzr-svn if you don't need it
<lifeless> see if that helps
<lifeless> there is a bug, thats for sure.
<mwhudson> jdub: that seems like a more plausible problem in some ways
<lifeless> jdub: note that bzr+http shouldn't be needed - http:// will probe for .smart anyway.
<jdub> yeah
<jdub> jdub@sliver:/tmp$ bzr co http://whitlam.crikey.com.au/code/live/
<jdub> bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://whitlam.crikey.com.au/code/live/.bzr/branch-format
<jdub> ^ without bzr-svn installed
<jdub> ooh, what a lovely little mess :-)
<lifeless> jdub: 403 sounds like you aren't passing POST to the backend, to me.
<jdub> that interactive password request dudie did seem a little svn-riffic
<jdub> lifeless: naw, looks like i'm not serving static files at all :_)
<lifeless> jdub: yes but that doesn't matter
<lifeless> jdub: there should be a 'smart' POST attempt in the log
<lifeless> if that is passed through to loggerhead properly, bzr will talk to that, not to static files.
<jdub> right
<jdub> the smart post hits the frontend with a 403
<RenatoSilva> how to  bzr pull --preview merge-directive.patch?
<RenatoSilva> or bzr mssing it
<jdub> lifeless: does the smart check attempt to auth before posting?
<lifeless> jdub: auth is on-demand, when the server gives 401
<lifeless> RenatoSilva: I'm not sure missing works with merge diectives
<lifeless> RenatoSilva: pull --preview should just work
<jdub> lifeless: aaaaaaaahhhhhhhhh
<jdub> lifeless: *lightbulb*
<jdub> lifeless: i should not bar access to .bzr on this host :)
<lifeless> you want .bzr/smart to work
<lifeless> not the rest
<lifeless> [or at least, you *shouldn't need* the rest]
<jdub> right
<lifeless> and you want it auth protected.
<jdub> yeah
<james_w> does loggerhead work as a smart server with no extra configuration?
<jdub> lifeless: oh man... new issue
<jdub> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-46030224:///"')
<jdub> james_w: recent versions, yeah
<lifeless> jdub: ah, shared repo ?
<jdub> lifeless: yeah :|
<lifeless> jdub: there is a bug, Peng will know more
<james_w> that's neat
<lifeless> basically it needs to make the chroot in the backend higher up.
<lifeless> so I know what needs to be done, I haven't gone and looked at it
<lifeless> jdub: look for Chroot in the loggerhead code, you can probably figure it out
<lifeless> jdub: rather than branch.base, it will be branch.repository.bzrdir.root_transport, for the chroot root path
<jdub> lifeless: looks like that might be a bzrlib thing
<lifeless> jdub: nope
<lifeless> smart server handles this fine ;)
<jdub> there's no Chroot in loggerhead
<lifeless> ugh
<lifeless> look for smart then
<jdub> can i /msg for a moment?
<lifeless> of course
<spiv>             wsgi_app = wsgi.SmartWSGIApp(self.transport)
<spiv> that's in loggerhead/apps/transport.py, line 85
<lifeless> so self.transport needs to be adjusted
<lifeless> you'll need to find the actual root you want
<lifeless> and probably need to pass in some adjuster - spiv knwos this much better than I :)
<spiv> which in turn gets transport from make_app_for_config_and_path, which gets it from the config
<spiv> Which apparently defaults to '.', unless you pass a command line arg?
<spiv> I don't really know my way around the loggerhead codebase very well.
<jdub> yeah
<lifeless> spiv: yes, but you know the wsgi helpers in bzrlib
<lifeless> spiv: you see the problem, right?
<RenatoSilva> lifeless: pull --preview didn't work
<spiv> lifeless: not really, it's calling the right wsgi helper, I would expect that so long as it feeds the right path to it is all good.
<RenatoSilva> lifeless: iirc someone here noted that pull doesn't have --preview as expected
<spiv> lifeless: but I don't know enough about how self.transport is created to know where loggerhead is going wrong
<spiv> or where jdub's configuration of loggerhead is going wrong, perhaps?
<jdub> spiv: i'm just passing it a path (to the repo)
<jdub> spiv: then attempting to co the branch under it
<jdub> loggerhead autoserves branches under a repo
<lifeless> spiv: its the transport of the branch, not the repo
<spiv> lifeless: oh, right, yes, I got that bit :)
<lifeless> spiv: it needs to be shifted up to the repo; but requests at that path need to be shifted down to the branches relative path
<spiv> lifeless: I don't know why; the code I've read suggests it shouldn't be
<spiv> lifeless: i.e. the code I've seen so far looks like it is doing things correctly
<lifeless> spiv: if you're not bogged down with critical stuff, I think this is actually well worth treating as high and digging into
<jdub> spiv: 0.17 or beyond?
<spiv> Hmm, the UserBranchesFromTransportRoot looks a bit suspicious
<spiv> jdub: I'm reading the code in trunk
<spiv> Not sure how that relates to version numbers ;)
<spiv> lifeless: I'm certainly happy to dig for a while
<spiv> lifeless: I just posted a patch for that "second push failed to complete" bug
<jdub> thanks dudes :-)
<lifeless> spiv: awesome; I saw it, but got distracted just as I hit the diff
<lifeless> Lynne has the lurgy now too
<spiv> Urgh, lucky Lynne :(
<spiv> mary and I think we've been fighting off something this week, so far not so bad but not quite feeling 100% either.
<spiv> Ah, found it I think.
<lifeless> spiv: vitamin C!
<thumper> can anyone with windows experience comment on https://bugs.launchpad.net/bugs/455636 to say where to put the ssh key that bzr will use?
<ubottu> Launchpad bug 455636 in launchpad-code "r/o code download with lp: prefix asks for ssh key" [Undecided,Incomplete]
<lifeless> thumper: there isn't a place AIUI
<lifeless> thumper: you run a gui - pageant - and tell it to add the key
<thumper> lifeless: hmm, that's about as much as I know too
<SamB_XP> that really ought to be in the help file :-(
 * igc lunch
<SpamapS> Hi.. in perforce if I see a change #, I can say 'p4 describe ######' and it shows me al the changes associated with that.. does bzr have something similar? Right now I have to find the previous revision and use bzr diff..
<spiv> jdub, lifeless: so I have a fix for your bug, but now I'm hitting https://bugs.edge.launchpad.net/bzr/+bug/348308
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308)
<jdub> spiv: boh!
<spiv> jdub, lifeless: will keep poking after lunch, that bug was going to bubble to the top of my list sooner or later
<fullermd> SpamapS: You don't have to find the previous revision, you can use '-c'.
<SpamapS> fullermd: ahh thats what I get for only paying attention to the examples and not reading the whole manual. ;)
<fullermd> SpamapS: (and technically you don't need it with -r either, -c is just less typing  ;)
<fullermd> SpamapS: "bzr diff -c$REV" == "bzr diff -rbefore:$REV..$REV"
<lifeless> spiv: sweet
<lifeless> spiv: that is the bug isn't it :)
<mwhudson> oh _that_ bug!
<SpamapS> fullermd: thank you.. :)
<fullets> I've been using a workflow like: bzr init-repo repo; bzr branch svn-trunk bzr-trunk; bzr branch bzr-trunk bzr-feature; hack on bzr feature; cd bzr-trunk; bzr merge ../bzr-feature; bzr push
<fullets> Trying to bzr diff -c a merge commit from a branch outside that repository causes bzr to crash. Are there any workarounds for this?
<dash> huh. what version of bzr?
<fullets> 2.0.1 from the jaunty ppa
<dash> huh, dang.
<dash> I've never seen that happen
<lifeless> what crash
<fullets> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository(path) has no revision
<lifeless> interesting
<lifeless> can you try -r before:X..X PATH/TO/BRANCH
<lifeless> as in 'bzr diff -r before .....
<fullets> Sorry, what should the X's be? The revision number of the merge commit?
<fullets> If so, the same crash happens
<lifeless> fullets: yes, exactly.
<fullets> Also -r m..n that cross the merge commit give the same crash
<lifeless> fullets: if you cd to that branhc
<lifeless> and then run the command, does it work?
<fullets> It crashes whether the branch, repo, or the repo's parent dir are my cwd
<lifeless> does 'bzr log' work when the branch is your cwd
<fullets> Yes, both displaying the whole log and the log for the merge commit work. Trying to show the merged revisions with --include-merges shows none of the merges
<lifeless> log -n0 will do that
<lifeless> I think you should file a bug
<lifeless> if log works but diff -c doesn't, there is something very strange going on.
<fullets> I shall file a bug once I finish putting steps to reproduce together :)
<lifeless> fullets: please file the bug earlier
<lifeless> fullets: as you may need our help to diagnose it, and bugs provide a place to track the conversation
<fullets> Very good
<thumper> how do I create a branch with the LCA of two other branches?
<lifeless> thumper: cd two; bzr revision-info -r ancestor:one
<lifeless> then bzr branch -r revid:.... one
<fullets> lifeless: https://bugs.launchpad.net/bzr/+bug/456908
<lifeless> thanks
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456908)
<lifeless> bug 456908
<ubottu> Launchpad bug 456908 in bzr "Merge commits in branch of subversion repository crash on diffing" [Undecided,New] https://launchpad.net/bugs/456908
<thumper> lifeless: ta
<spiv> jdub: http://bzr.pastebin.com/m5e6d6205
<spiv> jdub: there's a couple of minor debug droppings in that (the print statement and the commented out pdb line), but that makes serve-branches work for me with a shared repo
<spiv> jdub: I'm working on a proper fix for the bzr bug that works around
<jdub> spiv: rocking -- thanks! :-)
<lifeless> spiv: nice
<jdub> spiv: beautiful :-)
<jdub> spiv: what are the chances that will work with --allow-write? :-)
<spiv> jdub: I don't see why it wouldn't :)
<spiv> thumper: btw, https://answers.edge.launchpad.net/bzr/+questions?field.search_text=ssh+windows&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status=ANSWERED&field.status=SOLVED&field.status-empty-marker=1 has some info about ssh and windows if you're prepared to dig a bit
<jdub> spiv: it does, btw :-)
<Peng_> spiv: You rock! Thanks for working on this! :)
<lifeless> james_w: is there a PPA with bzr builder in it?
<Peng_> mwhudson: ping
<bialix> hello all
<Peng_> Hi. :)
<spiv> Ah good, I have what seems to be a working fix for the bzr+http bug and a draft of a reasonable test.
 * spiv heads to yoga class feeling satisfied
<Peng_> spiv: I love you. :)
<Kamping_Kaiser> sigh. dependancy hell for the win.
 * igc dinner
<alex_morelli> hello all
<alex_morelli> long time ago, I found a plugin for bzr that implemented a "make-log" command a la tla
<alex_morelli> Now I can't find it anymore... anyone ever heard of it?
<bob2> what did make-log do?
<alex_morelli> It created a log file, to which you appended what you were doing until commit
<alex_morelli> and you couldn't commit without that log file
<bob2> what does it do different to 'touch x ; edit x ; bzr ci -F x'
<alex_morelli> not much, but you can commit anyway this way
<alex_morelli> and make-log sort of forced you to behave
<Kamping_Kaiser> Is `bzr svn-import` supposed to work from a client checkout of an svn repo?
<Peng_> Kamping_Kaiser: Not sure. It's not hard to get the URL, though.
<Kamping_Kaiser> I gen an error "bzr: ERROR: No Repository found at gns/builder-clean. For individual branches, use 'bzr branch'." when trying to run it against an svn checkout (I don't hae access to the svn repo)
<Kamping_Kaiser> Peng_: ah, i'm supposed to run it on the url?
 * Kamping_Kaiser tries
<Kamping_Kaiser> aaah. *yay*
<Kamping_Kaiser> Peng_: thanks :)
<Peng_> Kamping_Kaiser: :)
<Peng_> Kamping_Kaiser: FYI, if you *did* have a copy of the repo locally, you could run it against the directory path too.
<Peng_> Probably.
<Kamping_Kaiser> good to know, thanks.
<james_w> lifeless: https://edge.launchpad.net/~dailydebs-team/+archive/bzr-builder
<Kamping_Kaiser> perhaps a strange question: having vampired out of the svn repo, i have a 34mb .bzr directory, and the builder/ directory is empty. is there a non-obvious step involved in making the repository useful?
<Peng_> Kamping_Kaiser: svn-import doesn't create working trees by default. cd to a branch and run "bzr checkout".
<Kamping_Kaiser> ah.
<Kamping_Kaiser> Peng_: would it be worth noting that somehow on the help (bzr help svn-import)? (sorry if it is, in newer versions)
<Peng_> Kamping_Kaiser: I'm running the bzr-svn trunk, and it does mention it.
<Kamping_Kaiser> Peng_: no worries then. thanks for checking!
<Kamping_Kaiser> caw. its there
<Kamping_Kaiser> thanks so much\o/
<Peng_> jam: StaticTuple.as_tuple() doesn't recursively convert other StaticTuples inside the StaticTuple to tuples. Do you think it should?
<Peng_> jam: In other words, is that a bug or a feature? :)
<Peng_> beuno: ping
<bialix> ÑÐ¿ÑÐ Ð·ÑÑÐ¿
<bialix> igc: ping
<igc> hi bialix
<bialix> I want to convert cvs repo of FTE to bzr
<bialix> I've managed to rsync entire repo from sf.net
<bialix> can you point me where to start?
<bialix> should I use instructions from here: http://cvs2svn.tigris.org/cvs2bzr.html
<igc> bialix: start with http://doc.bazaar-vcs.org/migration/en/data-migration/index.html
<bialix> or your plugin has inside something else?
<igc> bialix: if the instructions aren't clear, we need to improve them
<bialix> ok, I'll read
<bialix> will ask questions tomorrow
<igc> bialix: fast-export-from-cvs calls cvs2bzr to do the export
<bialix> aha
<bialix> cvs2bzr page mentions some options.file
<igc> bialix: hopefully you don't need a custom options file. If you do, I think fast-export-from-cvs allows you to provide one
<bialix> igc: I have installed TortoiseCVS
<bialix> I hope it will be enough to use cvs2svn
<bialix> as I know it can work with RCS co utility or cvs executable
<bialix> do you control this aspect somehow?
<bialix> igc: ok, help for fast-export-from-cvs is clear, I'll start experimenting and will report all issues I'll encounter
<igc> bialix: thanks. we need to get the process *clearly* documented
<spiv> Peng_: test added, patch up for review
<spiv> Peng_: feel free to sneak it into your deployment right now and get rid of your monkey patch ;)
<bialix> igc: my mileage as typical windows/tortoisecvs user will vary
<spiv> Peng_: Btw I discovered that doing that fix was exactly as painful and confusing as I thought it would be, so I feel less bad about not doing it sooner now :P
<bialix> igc: and btw, I found gnuwin32.sf.net project is better than unxutils.sf.net
<spiv> Peng_: (even though the eventual patch is actually quite clear I think, but fully analysing this stuff is always makes me go a bit cross-eyed)
<bialix> igc: unxutils.sf.net is no more maintained and I'm unable to download sort there
<Peng_> spiv: Heh, that makes me feel better about not trying to figure it out myself.
<Peng_> spiv: I just confirmed that your fix works. I love you! :)
<spiv> Peng_: great, thanks for testing :)
<spiv> Peng_: yeah, it's not so much that it's hard exactly.  Just that there are just enough confusingly similar variables involved that it's hard to keep track of what's going on.
<Peng_> spiv: Not to rush you, but you're working on a fix for Loggerhead too, right? What's the status of that?
<spiv> All the various path the user sees/path the http request is delivered to/path in the hpss request/path adjusted relative to server backing transport/path relative to request handler etc
<spiv> Oh yeah, good point.
<spiv> I've even tested that it works (with my fix for bzrlib)
<spiv> So I'll file that merge directive now
<spiv> Peng_: https://code.edge.launchpad.net/~spiv/loggerhead/shared-repo-fix/+merge/13701
<Peng_> spiv: Great. :)
<Peng_> This is missing the point, but testing with "bzr revno" is clever. I always use "bzr log -r -1 -n 1", which takes a while
<spiv> Peng_: :)
<spiv> Peng_: a while to type if nothing else!
<Peng_> Yeah, that too.
<igc> night all
<spiv> g'night
<beuno> Peng_, hi
<Peng_> beuno: I just wanted to say that lp:~beuno/loggerhead/yui3-0-0 is redundant. I pushed a similar branch to lp:~mnordhoff/loggerhead/yui-3.0.0 and lp:~loggerhead-team/loggerhead/yui-3.0.0, which also handles a couple of renamed files better.
<beuno> Peng_, did you get it working?
<Peng_> beuno: No. I didn't do anything more than update the copy of YUI.
<beuno> Peng_, gotcha. I will see if I can spend an afternoon fixing it. I have some idea of what needs to be tweaked
<Peng_> Oh, good. :)
<beuno> Peng_, did you get the LP tshirt?
<Peng_> beuno: Not yet.
<beuno> mrevell-lunch, do you know anything  ^
 * beuno has delegated the problem to a smarter person
<nil1> Hi!
<nil1> Is bzr able to handle concurrent commits on a "dumb" server (like FTP)?
<beuno> nil1, yes
<nil1> thanks!
<Peng_> There are very brief windows where the repo will be write-locked, though, no?
<nil1> Does it require a reliable locking mechanism?
<nil1> (locking in the sense of a .lock file being written)
<Peng_> nil1: Yes. Bazaar implements said reliable locking mechanism itself. It works fine over FTP.
<beuno> yes, it locks the repo for brief moments
<beuno> I guess that would limit how concurrent it can be
<nil1> I use the FTP interface of the Tahoe storage grid, where the latency is probably higher than on a normal FTP server
<nil1> I'll ask them if writes are reasonably atomic
<nil1> (them = Tahoe devs)
<beuno> nil1, let is know  :)
<nil1> will do!
<Peng_> Using StaticTuple in Loggerhead is fun. There are currently fewer tuples than lists in memory. :D
<beuno> Peng_, did it have an impact in memory usage?
<Peng_> beuno: It's way too dynamic to be sure.
<mrevell> Peng_ Your t-shirt'll be in the post today.
<Peng_> mrevell: Yay!
<beuno> thanks mrevell
<mrevell> Peng_ I've just been told that it has now been sent.
<beuno> Peng_, spiv's branch looks good to land now, want to merge it yourself or want me to?
<Peng_> beuno: You can if you want to.
<Peng_> mrevell: Thanks! :)
<Peng_> beuno: But I don't mind doing it.
<spiv> Peng_: woo
 * spiv -> zzz
<beuno> spiv, thanks
<beuno> Peng_, go for it
<Peng_> beuno: 'kay
<Peng_> Pushing now
<beuno> woo!
<Peng_> (Pushed again, cuz I forgot to mention bug #348308 in NEWS.)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308)
<Peng_> I can never merge something in just one revision. :P
<beuno> heh
<Peng_> jam: ping
<pickscrape> Could someone explain to me what the --incremental option of bzr svn-import does?
<Peng_> pickscrape: "bzr svn-import --incremental" is to "bzr svn-import" as "bzr pull" is to "bzr branch".
<pickscrape> Peng_: Ah, so if I have an import that I have to kill due to it using 13G of ram, using that option will allow it to carry on from where it left off?
<Peng_> pickscrape: ...Probably.
<pickscrape> Peng_: thanks, I'll try that the next time I have to kill it
<Peng_> pickscrape: I'm not sure how much of the import will have been saved if you kill it, but it probably will include most of the repo.
<jam> morning all
<jam> spiv: thanks for the reviews, sleep well
<jam> Peng_: wave
<jam> jelmer: it looks like we need an updated bzr-rewrite as wel
<Peng_> jam: First of all, I'm sorry about pestering you to keep adding features to StaticTuple. Thanks to all of your work, I finally got the Loggerhead branch working. :)
<jam> Peng_: good to hear. Did you see my recent patch to support more object types?
<jam> That should land in bzr.dev today
<Peng_> jam: Yeah, I'm using it.
<jam> it will change slightly, but not dramatically
<Peng_> jam: Anyway, on to the continued pestering: The only other things I could want are these, but they're not necessary: Pickle support, and the ability to pass a generator to from_sequence.
<Peng_> jam: What do you think? Like I said, they're not necessary, but they would be nice.
<jam> Peng_: from_sequence(tuple(generator)) should work fine :)
<jam> and essentially give the same results
<jam> I have to iterate the generator because ST is a fixed-width object
<Peng_> jam: OK.
<jam> given that, from_sequence(list(generator)) might be better
<jam> I'm not clear on the tuple internals wrt a generator
<Peng_> from_sequence(list(generator)) might be better than from_sequence(tuple(generator))? Why?
<jam> Peng_: because tuple() is also fixed width, so it has to somehow stage the whole generator result somewhere
<jam> and then create a tuple
<jam> *list* can grow
<jam> so it can stage the contents into itself
<Peng_> jam: Ahh, interesting. ...It probably doesn't matter much, though.
<jam> Peng_: looking at the internals of PySequence_Tuple() it re-allocates the internal tuple
<jam> holding a size of 10, and then reallocating over and over as it grows
<jam> so I guess ~ the same as List does
<jam> Pickle support... I really don't know what it takes to tell pickle about a custom type
<Peng_> I think these tuples are only like 1 or 2 items long, so it shouldn't matter much.
<jam> http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types
<Peng_> Oh, I hadn't scrolled down that far in the docs.
<Peng_> jam: BTW, your merge proposal got the LP equivalent of bb:tweak, more or less. Have you seen it yet?
<jam> Peng_: yeah, I'm cleaning it up now
<Peng_> jam: ok :)
<jam> Peng_: so if pickling is important to you, I'm happy to look over a patch, give suggestions, etc. I'm probably not going to worry about it myself, though.
<jam> In general, I think it wouldn't be too hard
<jam> you just have to implement __reduce__() and __setstate__()
<jam> except __setstate__() sounds like it happens *after* the class has been instantiated
<Peng_> Step 1: Learn C. :P
<jam> Peng_: if you wrote it sufficiently in Python, translating it to C wouldn't be hard (for someone)
<jam> you could try doing it on the pure python StaticTuple type to start with
<jam> or if it 'just gets' it from 'tuple', check what to do there
<jam> they also mention that you can do this 'after-the-fact' by registering with the 'copy_reg' module
<jam> http://docs.python.org/library/copy_reg.html#module-copy_reg
<jam> that may work better, as it can
<jam> 1) probably be done in pure python
<jam> 2) you can be more sure that you don't have to construct an object and then call __setstate__ on it
<jam> hmm.. maybe no nee
<jam> need
<jam> given the callable you pass takes a tuple of arguments for the callable
<Peng_> I just tested a copy_reg one-liner. It whined about __builtin__.StaticTuple not existing.
<jam> Peng_: did you have _static_tuple_c imported before you did the unpickle?
<Peng_> jam: I had "from bzrlib.static_tuple import StaticTuple".
<jam> so potentially that is the pure python class, though not if everything is working correctly
<Peng_> jam: It's the C version.
<Peng_> I note that the C StaticTuple has no __module__ attribute.
<jam> interesting, given that 'tuple' itself does
<jam> Peng_: actually *instances* of tuple do not have the __module__ attribute, but t.__class__.__module__ does
<jam> and
<jam> >>> _static_tuple_c.StaticTuple.__module__
<jam> '__builtin__'
<jam> I don't specifically know how to change that
<jam> as I don't see where it is set
<jam> it seems to be in 'typeobject.c' a function called type_module()
<jam> and it looks like if you set "tp_name" to "bzrlib._static_tuple_c.StaticTuple" then it will get a module
<jam> otherwise it defaults to __builtins__
<jam> Peng_: give this a shot: http://paste.ubuntu.com/298325/
<Peng_> Are you supposed to hardcode the module like that? Obviously, it isn't necessary when writing Python code.
<jam> Peng_: that seems to be why Type.__module__ expects
<jam> we aren't creating a heap type, so we can't just set "Type.__module__" directly
<jam> and if it isn't a heap type, it checks 		s = strrchr(type->tp_name, '.');
<jam> and if not found returns __builtin__
<jam> so I think so
<Peng_> jam: This fixes it, but you'll have to adjust __repr__, as it now includes the module too.
<Peng_> jam: Or, don't adjust repr, but adjust any tests where it's still hardcoded (if there are any).
<jam> well, seeing the full format in print '%r' also isn't very nice
<jam> and I think we have the flag set so you can't subclass StaticTuple
<jam> so it is safe to just hard-code it there
<Peng_> jam: With that patch, pickling works with this one-liner: copy_reg.pickle(StaticTuple, lambda st: (StaticTuple, st.as_tuple()))
<Peng_> jam: Although it will probably die horribly if you enable or disable the C extensions in between pickling and unpickling.
<jam> Peng_: it won't work because the module is hard-coded in the pickle stream
<jam> now if we wanted to be 'evil'
<jam> we would make the module name "bzrlib.static_tuple"
<jam> and then set
<jam> bzrlib._static_tuple_py.StaticTuple.__module__ == 'bzrlib.static_tuple'
<jam> at that point
<jam> I think you could switch between them
<jam> i'm not positive
<Peng_> Probably.
<jam> but I think the unpickler just tries to grab a class at the given path
<jam> and passes it the args
<Peng_> IMO doing that is nice, but unacceptably evil.
<Peng_> Boy. I'm running bzr.dev with 2 unmerged branches + a patch. Fun!
<Peng_> jam: So... what do you want to do? About tp_name, and about __reduce__? I could probably do it all, but it would take me a while, since I've written about 4 lines of C, none of them involving Python's C API.
<jam> Peng_: I can probably put it on my "get to it eventually" list, as the actual amount of work is pretty small
<jam> did you try the 'nice but evil' hack and see if it worked?
<Peng_> jam: What, to make switching between C and Python work? No.
<Peng_> jam: Are you going to land the tp_name patch? I'm going to work on pickling -- though I might give up -- so I can make it a part of that. But I don't know what, if anything, to do about repr.
<jam> Peng_: just change the part that formats to hard-coding it
<jam> I would land them all together
<Peng_> jam: Alright.
<jam> static tuple type support is in pqm now
<jam> Peng_: what other unmerged branch are you running?
<Peng_> jam: lp:~spiv/bzr/bzr-http-jailbreak-bug-348308
<Peng_> Uh-oh. Applying the tp_name patch to another branch, it doesn't work. :\
<Peng_> And no, I'm not making some mistake like importing the wrong file.
<awilkins> Thought of the day : a fast-import frontend you can use for benchmarking
<awilkins> ie - it replays revisions by making changes to the filesystem and driving the porcelain of your chosen VCS
<awilkins> So you could take a git-fast-export of say.. the kernel tree... and pipe it through this thing to see how various things performed on real-world data
<jfroy> verterok: ping
<verterok> jfroy: pong
<verterok> jfroy: hi
<verterok> jfroy: I wasn't able to get a spare minute and reboot into OS X, so no push yet :(
<jfroy> alright, just ping me when you do
<verterok> jfroy: sure, let me try to get the changes from the HFS+ disk ;)
<verterok> jfroy: pushed revno 13 to lp:~verterok/+junk/OSX-package
<verterok> jfroy: I remove the -desktop pmdoc, as it was quite outdated
<verterok> *removed
<jfroy> verterok: so what's the process for the desktop installer?
<verterok> jfroy: there isn't a desktop installer :)
<verterok> jfroy: I just builded a PyQt.pkg and included it in the DMG
<verterok> jfroy: as I'm still using my old script to build the 10.5 installer
<verterok> jfroy: basically, I think we need a new pmdoc (-desktop) for 10.6
<jfroy|work> I see
<jfroy|work> well that should be easy enough
<jfroy|work> I don't see a switch to have fetch-external grab PyQt and Sip, am I missing something?
<Tak> yay, subvertpy crash fixed!
<verterok> jfroy: it should fetch all the deps
<jfroy|work> Ah, so it did
<jfroy|work> hum
<jfroy|work> why did you modify the config for sip and pyqt that much?
<jfroy|work> ah I see, the default paths are bogus
<verterok> jfroy: yeap
<jfroy|work> anyways, it needs to be done that way too because there's no prefix or root option
<jfroy|work> was the -q option necessary for pyqt?
<jfroy|work> it should find the default just fine I would think
<jfroy|work> oh, did you include Qt in your dmg?
<verterok> jfroy: no, QT  needs to be installed
<verterok> jfroy|work: ^
<verterok> jfroy|work: I'm still trying to build a standalone bundle with qt and pyqt
<Peng_> jam: I just sent a merge request for pickling. Peng_ wrote C, ha! (Well, Peng_ copy-and-pasted C.)
<jam> Peng_: \o/ for you
<jam> Peng_: https://code.launchpad.net/~mnordhoff/bzr/statictuple-pickling/+merge/13720 doesn't have anything with pickling
<jam> it only has the repr and tp_name changes
<Peng_> jam: I know. Launchpad's mirror is out-of-date; see my message.
<Peng_> I didn't want to wait another 4 hours to submit the proposal, or figure out how to trigger a mirror again.
<Peng_> Sorry for making it confusing.
<abli> Hi! If I do a bzr merge of certain revisions (i.e. with from_rev..to_rev) why doesn't it get noted that I have pending merges when I do a "bzr st"? And why dont the merged versions's comments get added when I check in the merge? Any ideas?
<abli> (using bzr 1.16.1)
<dash> abli: that's a cherry-pick and bzr doesn't treat it like a 'normal' merge
<dash> it just applies the changes and doesn't track history
<jam> Peng_: you could have always hosted the branch... :)
<abli> and is there some way  to make bzr treat it like a normal merge? To get the merged comments in the checkin comment?
<jam> Peng_: reviewed. I think you need one more Py_INCREF but otherwise it looks good.
<jam> abli: use "bzr merge -r to_rev"
<jam> and if you really need to
<abli> For example, bzr will know that those revisions were merged, right? I.e. won't show them when I run "bzr missing" later?
<jam> bzr merge --force -r from_rev..ancestor:../other
<jam> abli: it will show them as missing
<jam> as said earlier, we don't track the history of cherrypicks
<Peng_> jam: How's that fun? If I had originally pushed to LP, it would have been very quick, instead of 8 minutes of streaming data to the out-of-date repo on my server. :D
<dash> abli: what's your situation?
<abli> Btw why isn't cherry-picking treated like a normal merge? (I.e. why is the workaround you guys mentioned needed?)
<jam> Peng_: well at least your server is up to date now :)
<abli> trying to merge "half" of a branch to trunk. I.e. I have a branch with commits that implement  two features, and I want to merge those belonging to one of the features to trunk
<abli> jam: how should I read that from_rev..ancestor:../other part? I assume I am to run "bzr merge" from the branch I am merging to, right? So running "bzr merge -r from_rev..to_rev other_branch" is a normal cherry-picking, right? so how do I run this non-cherry-pick-but-only-some-revisions merge? Or is it even possible?
<Peng_> jam: Thanks for the review. :)
<Peng_> Writing (a little bit of) C is kind of fun. Python is so easy that it's boring. :P
<jam> abli: we don't have a way to internally represent "i'm merging some of the ancestry but not all of it"
<jam> so there are some options
<jam> but they all 'break' for some use cases
<jam> abli: for example you can do
<jam> bzr merge ../other -r from_rev
<jam> bzr revert .
<jam> bzr commit -m "Explicitly remove the initial changes"
<jam> bzr merge ../other -r ../to_rev
<jam> however, in that case the initial changes 'won't' land
<jam> though you can then do the reverse sync
<jam> with cd ../other
<jam> bzr merge ../trunk
<jam> bzr revert .
<jam> bzr commit -m "Revert the removal from trunk"
<jam> or something along those lines
<jam> caveat that merging trunk probably does more than just bring in the feature you just did
<jam> abli: alternatively, you can look at something like: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
<jam> for how to take a branch that has multiple features developed on it
<abli> and then merge to to_rev, and commit, right? But that will show the revisions up to from_rev as merged, won't it? I will want to merge those at some later point
<jam> and split it into independent branches
<abli> Ok, thanks, I'll try out that refactoring thing.
<emmajane> igc, pong (belated)
<igc> hi emmajane, how are you?
<beuno> mwhudson, Peng_, I think I have LH working with 3.0.0
<emmajane> igc, hey :)
<beuno> just need to iron out a few errors with the search js
<mwhudson> beuno: cool
<thumper> beuno: 3.0.0 what?
<lifeless> moin
<lifeless> YUI I imagine
<igc> hi lifeless, thumper
<beuno> thumper, lifeless, yes
<beuno> I'm pretending this is research for the lazr-js sprint in dallas
<lifeless> beuno: 'it is'
<jml> I've recently been motivated to care about this bug: https://bugs.launchpad.net/bzr/+bug/152008
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/152008)
<jml> lifeless, you now have commit rights to testtools.
<lifeless> cool
<lifeless> [what prompted this?]
<jml> I'm yak shaving :)
<jml> I want to release txsshserver
<jml> to do this, I need to make sure the tests pass
<jml> right now, running the tests in trial makes them all skip
<jml> I have NFI why that's the case, but suspect a bug in testtools (or maybe in trial)
<lifeless> awesome
<jml> you've been keeping up to date with python test development much more than I, so I feel that you are in a much better position to get stuff landed.
<jml> and I feel I'll be less of a blocker if I don't have sole commit rights.
<lifeless> what was your previous 'policy' about reviews of committer's code
<lifeless> and how do you want me to behave
<lifeless> e.g. 2 +1s, then land, or 'if you think it is right just land', or 2 +1s with a timeout?
<lifeless> jml: ^
<jml> lifeless, my policy has been patches get reviewed, and I land patches without review. but I was the sole controller.
<jml> lifeless, I just got on a call w/ thumper, will actually think about policy when I'm off :)
<lifeless> jml: indeed, but you can see why I ask :)
<jml> yes :)
<lifeless> jml: if you're to be less of a blocker we need committing to be quorate without needing you
<jml> lifeless, that's right.
<lifeless> enjoy the call
<jml> :)
<jam> jelmer: ping (still need a newer bzr-rewrite for 2.1.0b1 release...)
<jam> morning lifeless
<lifeless> hi jam
<igc> hi jam, jml
<jml> igc, hi
<igc> emmajane: my email from last week? Did I miss your reply or is it still coming?
<emmajane> igc, email from last week?
<emmajane> igc, on-list?
<igc> emmajane: no, just to you
 * emmajane checks the backlog of lsit email.
<emmajane> oh. hrm.
<jam> morning igc
<emmajane> igc, can you resend?
<igc> emmajane: it was the one about templating, etc - shall do
<GaryvdM> Hi jam - Thanks for the bzr-beta-ppa approval.
<emmajane> igc, thanks. I don't remember getting one to me about templating. :/
<igc> emmajane: just re-forwarded it now - date was 12/Oct; title was "Next steps ..."
<jam> GaryvdM: no problem
<jam> easier than having you request a copy every month :)
<GaryvdM> :-)
<emmajane> igc, got it this time. I'm not sure where the other one went. :/
 * emmajane reads
<igc> jam, lifeless: OOo fast-imports now with latest trunk and cache of inventories cut down to 5 (was 100)
<igc> jam, lifeless: I'm just trying qt now with a few different cache sizes to see memory and speed impact
<emmajane> igc, Good list. I'll send a response back tonight with a plan.
<igc> emmajane: thanks
<emmajane> no problem! thanks for pinging me about it.
<jam> igc: you're saying that it succeeds at importing w/ a cache of only 5?
<jam> (and cache of what?)
 * ToyKeeper ponders how to rebase a series of merges on top of a new upstream tarball...  bzr-rebase seems to think the source branch (with new tarball) is a descendent of the target branch (with merges), and pulls instead of rebasing.
<jam> btw, it *might* be reasonable to handle a hunk stream by copying everything into the chk store, and then extracting it from there.
<jam> though 'pack' won't gc those extra objects.
<ToyKeeper> Hmm, I bet a null commit before the merges would un-confuse it.
<himanshu__> Hi, I am getting following error :bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
<himanshu__> Not sure why?
<ToyKeeper> himanshu__: It sounds like your version of bzr is too old to read the repository.
<himanshu__> bzr server is running on remote repository  with version 2.0.1
<himanshu__> my client machine is ubuntu with bzr version 1.6.1
<ToyKeeper> It's because your client is old, then.
<himanshu__> so new bzr version is not backward compatible with any bzr version?
<ToyKeeper> It is if you're using a backward-compatible format.  Format 2a is compatible back to bzr 1.16...
<fullermd> (though you really would rather not use it with <2.0.0)
<fullermd> _bzr_ is compatible; that _repo_ isn't.
<ToyKeeper> Ah, okay.
<ToyKeeper> himanshu__: Upgrading your client would probably be the best option, but you could also rebuilt the repo with an old format, like 1.6.1-rich-root.
<ToyKeeper> s/rebuilt/rebuild/
<himanshu__> so what do you suggest..Shoudl I rebuilt repo with old format  or upgrade client
<fullermd> Upgrade the client, definitely.
<fullermd> 2a is a better format in a lot of ways, and unrelated to that 2.0.1 will be a lot faster etc. than 1.6.1 as well.
<himanshu__> what is the quickest way to upgrade client on ubuntu?
<himanshu__> I have installed using apt-get install bzr
<fullermd> Older format mirrors are for when (for whatever reason) clients _can't_ be upgraded.
<fullermd> That probably involves PPA's, but I don't know any details about it.
<himanshu__> ohk so I need to build it from source ?
<ToyKeeper> Ubuntu backports may have it.
<himanshu__> what is backports?
<ToyKeeper> https://help.ubuntu.com/community/UbuntuBackports
<igc> jam: fastimport caches inventories
<himanshu__> ok cool let me check
<himanshu__> Also, 1 more question
<GaryvdM> himanshu__: New versions can also be found in the ppa: https://launchpad.net/~bzr/+archive/ppa/
<himanshu__> ok cool let me check
<lifeless> jam: inventory cache
<lifeless> jam: fast import has a huge one
<ToyKeeper> BTW, know of any tools to modify fast-import files?  It would be nice sometimes to remove files, revisions, and other stuff from history.
<himanshu__> I have 1 question related to supporting bzr repositor
<ToyKeeper> It can be done by hand, but it's a lot of work.
<himanshu__> say if I have 10 users acess to bzr repository but I want to ensure that no user can have read/write access in other user's project
<himanshu__> how can that be possible?
<jam> ToyKeeper: you may want to look at 'bzr replay' versus 'bzr rebase'
<fullermd> himanshu__: Why do you need it in one repository?  Or do you?
<ToyKeeper> jam: Ooh, sounds promising.  Thanks.  :)
<himanshu__> so it possible to start bzr server with each user repository?
<jam> igc: so you might be extra interested in the patch I'm about to propose again (chk_map changes). Providing you are caching chk inventories.
<rockstar> ToyKeeper, I'm actually rather surprised you hadn't heard about bzr replay.
<fullermd> himanshu__: The server and 'repositories' are almost completely decoupled.  You serve a directory tree, which may have one, two, or six hundred repositories under it.
<fullermd> himanshu__: Now, the bzr server doesn't itself do any AAA.  You'd have to do that in a high level, via the web server for bzr+http, or the ssh daemon for bzr+ssh.
<himanshu__> what is AAA?
<fullermd> himanshu__: I've never messed with bzr+http; I use bzr+ssh everywhere.
<fullermd> himanshu__: Authentication, Authorization, Accounting.
<himanshu__> ok here is what i am doing rite now: I have created 1 bzr repository  and executed following command
<himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
<himanshu__> nohup serve-branches /home/bzradmin/repository >> /home/bzradmin/logs/bzr_loggerhead.log &
<himanshu__> but this way I am giving everyone read-write access
<igc> jam: cool
<fullermd> Right.
 * igc breakfast - bbl
<himanshu__> but I just want to limit it to each user group
<himanshu__> I mean each user group should not have any read-write access of other usergroup
<himanshu__> not even on http
<fullermd> I'd do it all via bzr+ssh (the writing, anyway).
<fullermd> And use FS permissions.
<ToyKeeper> rockstar: It was a hidden command...  :(
<rockstar> ToyKeeper, those are the ones you find first usually.
<rockstar> :)
<fullermd> Really, there's no way to provide meaningful security differentiation within a repository; if you can write into it, you can change anything.  So you'd need one repo per slice of the auth domain.
<himanshu__> how do you use bzr+ssh?
<fullermd> Oh, I just use regular system accounts.
<fullermd> You COULD do it with a ssh daemon that uses PAM or some other auth, and refers to an external database rather than using regular system accounts.
<fullermd> But that would be rather more complicated.
<himanshu__> so this way each usergroup will be having their own repository?
<ToyKeeper> I haven't checked in a while, but if bzr-access ever got developed to a usable point, it might help.
<fullermd> bzr-access can't provide control at a sub-repository level.
<ToyKeeper> No, it can't.
<fullermd> Nothing can, without bzr moving a ways.
<lifeless> if you need privacy or integrity, use separate repos
<lifeless> thats a design statement, not a feature statement
<fullermd> himanshu__: You may be assigning more meaning to 'repository' than bzr does.  It's not like cvs/svn, where the 'repository' is an important semantic unit.
<lifeless> we can and will remove the VFS eventually, or at least make pushing with it disabled work [modulo plugins this is the case already]
<lifeless> and with the VFS removed many middling hostile attacks are prevented
<fullermd> Yah, VFS is a hole you can drive a 11-dimensional multiverse through.
<fullermd> I didn't know we have all the core actions moved off it.  That's pretty neat.
<himanshu__> I am getting little confure here: say I need to support 10 usergroup over same bzr server completly isolated from one another
<lifeless> fullermd: 2.0.0. baby
<fullermd> (well, aside from having to longcut to it to find out the !@&$ format of a remote branch...)
<lifeless> himanshu__: then you have 10 repositories
<lifeless> himanshu__: or more if you like :)
<himanshu__> then I should create 10 different respository setting read-write access according to group
<fullermd> himanshu__: Remember, your users will [practically] never be interacting with repositories; they'll be dealing with branches.  So think in terms of a directory hierarchy of branches, slicing that up how access control needs to be.
<fullermd> Then you can see where it's worth creating repositories within that.
<himanshu__> then each user group can access their resporitory over the bzr+ssh
<himanshu__> I agree that users will always interact with branches but I need a way to make sure that set of branches are accesible to only 1 particular user group
<fullermd> Yah, having those branches have all their data be 775/664 works well for that.
<himanshu__> ok  cool
<himanshu__> so it seems 1 repository, within that I create sub directory fo reach user group
<fullermd> No, that's a step backward, since they all have to write into the repository.
<fullermd> Step back and forget about [explicit] repositories; just arrange a bunch of individual standalone branches.
<himanshu__> ok
<fullermd> So you end up with $ROOT/team1/ and $ROOT/team2/ and $ROOT/team3/ etc. dirs, each full of branches.
<himanshu__> ok
<fullermd> With everything under teamX set with that group having write access, and everybody else just read (or no access, if that's what you want)
<fullermd> So, you can run with just that, and not create any repositories.
<fullermd> That has its shortcomings, but it's functionally equivalent.
<himanshu__> what is the shortcoming here?
<fullermd> Every branch has a full copy of the history, so (assuming that some/many/most/all of the branches are of the same project), you'll have a giant pile of copies of the same data.
<fullermd> Which eats up disk space, and also means the users can end up having to push up more data to get their work done.
<fullermd> But, ignoring space and time, everything acts just like it would with repos.
<fullermd> Now, if we assume that most/all of these branches are of the same project, just creating a repo in each teamX/ branch means we have 10 copies of the history (one for each team), but that's not so bad probably.
<himanshu__> i want branches of same project in teamX directory only
<fullermd> You could have a repo for teamX/ even if all the branches in it were of different projects of course, but it wouldn't gain anything in that case (since there's no common history to store only 1 copy of)
<fullermd> So, it sounds like you want a tree sorta like that, with a repo per teams and its perms set as appropriate.
<himanshu__> so requirement is that if there is some projectX, then that projectX is just limited to TeamX, cannot be read/write by any other Team
<himanshu__> thanks a lot fullermd, i got your suggestions
<himanshu__> From my requirement, it makes sense to maintain 1 respoitory for each Team as they have nothing in common, I mean no project, no read-write access
<fullermd> Sounds like a perfect fit then   :)
<himanshu__> so when I start bzr server, this would be wrong choice"	
<himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
<himanshu__> "
<himanshu__> so how should I start server?
<himanshu__> assume I have multiple respository
<himanshu__> should I give path of top level common directory maintaningg all user repos as underlying sub directory
<fullermd> You don't 'start' the server.  The users use bzr+ssh, which ssh's in and spawns bzr itself behind the scenes.
<fullermd> So you just have bzr installed and in $PATH, and them able to login.
<himanshu__> ok cool
<fullermd> Then they give whatever path they want.  Even a path to one of the other teams if they want, but since the filesystem permissions won't let them write...
<jml> lifeless, how's this: all patches need reviews from a committer who is not the author. If the author is a committer, there is a 24hr timeout on this rule.
<himanshu__> ok cool
<fullermd> So they'd do something like "bzr branch bzr+ssh://me@server/bzr/team5/mainbranch mylocalbranch"
<himanshu__> ok cool~
<lifeless> jml: sounds fine to me
<himanshu__> Also, is it possible if I can expose this kind of view over http using loggerhead?
<jml> lifeless, cool.
<jml> lifeless, let's do that then.
<fullermd> himanshu__: Well, since you've moved the devs to bzr+ssh, you don't need writes over the web (or over a 'bzr serve' bzr:// server, if you still want to run one), so that just needs read access.
<fullermd> If you wanted write over bzr+http, you'd have to do access control via Apache (well, or whatever other httpd you have).
<himanshu__> ok cool
<lamalex> is there a way to only get part of a branch?
<beuno> mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744
<beuno> in case you have a little while
<beuno> notifying oopsed
<beuno> so I'm doing it manually  :)
<beuno> Peng_, ^
<lamalex> im trying to set up bzrbuilder, but our debian package branch is in a subdir of the branch
<lamalex> is there a way to just get the debian dir of the branch or should i just use run to do an mv
<beuno> lamalex, there's no way to get a specific dir with bzr at the moment
<lamalex> so i guess run mv is the way for now
<lamalex> thanks
<lifeless> jml: is the new team subscribed for reviews to trunk ?
<jml> lifeless, is now.
<lifeless> :)
<jml> g'night.
<lifeless> night
#bzr 2009-10-22
<awilkins> Hmm... when I view the output of building the "survival" docs locally all I get is a blue page
<awilkins> Title headers are there but the content seems to be missing
<awilkins> Same for the other pages so I know it's not just me
<fullermd> awilkins: Sorry, that means you don't get to survive   :(
<awilkins> Bah, pushed it up anyway, the text is still PURE GOLD, I tell you.
<awilkins> Only someone who hates VSS as much as I do could document how it differs from decent version control systems at all thoroughly.
<awilkins> Because by definition, anyone who knows a lot about how VSS works, hates it.
 * mwhudson hasn't used VSS for 9 years, didn't use it much then and still hates it
 * fullermd never used VSS, and still hates it   :p
<awilkins> I used to have to run the "analyze.exe" tool
<fullermd> I figured the document would look something like "unlike VSS, bzr actually stores your history and can retrieve it later"
<awilkins> I tried to stay away from making it a "why Bazaar is just Soooooooo much better than VSS" document and stuck to "Why you may find Bazaar, or indeed, any decent VCS, a bit confusing after using VSS"
<awilkins> But it's far from complete and I need sleep. But slashdot beckons
<awilkins> Bah
<awilkins> Is Karmic going to have GNOME Shell?
<SamB_XP_> awilkins: why do you care? rxvt-unicode, man!
<fullermd> Oh, is that what people use who don't have xterm?  :p
<awilkins> Yeah, but it's nice to have a window manager to move your terminals around
<awilkins> You can fit more on the screen with overlapping windows
<fullermd> Pfft.  Who wants to waste CPU cycles on frills?
<SamB_XP_> awilkins: oh, wait, I'm confused with GNOME Terminal
<SamB_XP_> I guess I may have been using Windows too much lately?
<SamB_XP_> also, some people are liking Xmonad, though it's configuration file be written in a most arcane script ...
<awilkins> This was prompted by the announcement that Fedora 12 has a preview of it in the distro
<dash> gnome-shell is available in karmic
<dash> it's slightly neat
<SamB_XP_> who needs a desktop?
<dash> SamB_XP_: who needs a computer?
<awilkins> Who needs a computer?
 * dash hgh fives awilkins 
<awilkins> :-D
<fullermd> How else would I heat my house?
<SamB_XP_> dash: well, the desktop is a lot less necessary than the WM
<SamB_XP_> if you'd seen my homedir, you would understand ;-)
<awilkins> They replaced my machine at work with one that only drives one monitor
<fullermd> That sounds like it should be a country song.
<awilkins> What the *hell* are they smoking in ICT
<awilkins> I'll just have to get one of those USB graphics adapters
<SamB_XP_> huh, my school's ITS is really crappy and I don't think we *have* any computers that can only drive one monitor ...
<awilkins> Or work at home a lot more... I neeeeeed my dual 22" widescreens
<awilkins> It's painful enough being trapped in tiny resolutions like 1280x1024 at work...
<SamB_XP_> ... of course, none of them are really set up to take advantage of the second output, except some of the ones hooked up to projectors :-(
<awilkins> Blimey, gnome-shell is going all "Mac" in terms of menu
<Peng_> I'm being pushy here, but: could someone send my branch to PQM? :D https://code.edge.launchpad.net/~mnordhoff/bzr/statictuple-pickling
<fullermd> Let's just agree too assume I've found the perfect time for the 'sounds like a real pickle' joke, and save me the trouble of coming up with it, and you the trouble of hearing it.
<spiv> Peng_: hmm, I don't see your name on the list people that have signed contributor agreements... would you mind doing so?  http://www.canonical.com/contributors
<Peng_> spiv: Yeah, I never did, cuz I don't like copyright assignment. :P I liked being in the grey area of "hasn't written enough code for it to be copyrightable".
<Peng_> spiv: Anyway, I'll do it now.
<Peng_> Crap, it's a PDF?
<Peng_> Google cache++
<spiv> Oh, that's a problem?  I could have sworn this was 2009, not 1999 ;)
<fullermd> No way.  Then I'd have to stop partying like this.
<spiv> Haha
<Peng_> spiv: Or...I'll do it soonish. My brain isn't up to deciphering legal documents rightn ow.
<Peng_> spiv: Who do you want me to CC it to, you or poolie?
<spiv> Peng_: poolie
<Peng_> spiv: 'kay
<Peng_> spiv: Is it supposed to be GPG-signed?
<spiv> Peng_: I don't think it's required (whatever that link says is the rule), but it wouldn't hurt.
<spiv> Peng_: and I know if I was the sender it would make me feel better ;)
<jdub> hrm, where do i install plugins such that loggerhead will run them on writes?
<lifeless> the bzr plugins dir
<lifeless> how are you running loggerhead?
<jdub> lifeless: the init script... runs as loggerhead user
<jdub> lifeless: so ~loggerhead/.bzr/plugins ?
 * jdub doesn't like the loggerhead package
<lifeless> you may also need to be sure you are running 'bzr serve --http', not 'serve-branches'
<lifeless> the former will load all plugins, the latter *may*, and I'd need to check to be sure.
<jdub> s/bzr/bazaar/ <- oops ;)
<jdub> lifeless: hrm, then using loggerhead as a plugin?
<spiv> lifeless: serve-branches does load plugins
<lifeless> spiv: good to know
<lifeless> jdub: I hope to convince beuno to delete serve-branches soon
<lifeless> only need one 'serve' command.
<jdub> spiv: so my expectation that it'd load them from ~/.bazaar/plugins of whatever user loggerhead is running as would be right?
<lifeless> yes
<lifeless> or the global python install dir
<lifeless> and you can add paths via BZR_PLUGINS_PATH
<jdub> whihc makes the loggerhead package SPECIAL
<Peng_> It does?
<jdub> jdub@whitlam:~$ getent passwd loggerhead
<jdub> loggerhead:x:109:117::/:/bin/false
<lifeless> \o/
<lifeless> jdub: put them in e.g. /var/lib/loggerhead/plugins
<lifeless> and export BZR_PLUGINS_PATH=/var/lib/loggerhead/plugins
<jdub> perhaps the best thing to do would be BZR_PLUGINS_PATH=/var/lib/loggerhead or whatever in the init script
<jdub> ha ha
<jdub> we are FHS TO THE MAX, man
<lifeless> submit a package patch to do that ;)
<jdub> yeah, but now i'm looking more closely at bzr serve
<jdub> does --http only work when bzr finds loggerhead?
<lifeless> yes
<lifeless> loggerhead provides --http
<jdub> right
<lifeless> svn should provide --svn, but I don't know if its glued in yet
<jdub> will other parameters be passed through automagically? ie --use-cdn
<spiv> It would perhaps be nice to have something simple builtin for --http, but if loggerhead is easy enough to install then it's probably not a big deal.
<lifeless> spiv: I'm very keen on not building in a non-loggerhead http
<lifeless> spiv: I think discussions about doing that have been missing the point :)
<AfC> lifeless: that wold be nice
<Peng_> jdub: No.
<lifeless> AfC: --svn?
<Peng_> jdub: That's basically the reason to still keep serve-branches around for now.
<AfC> lifeless: non loggerhead --http
<AfC> [battery change
<lifeless> AfC: why?
<jdub> Peng_: particularly since the use of libjs-yui doesn't actually work ;-)
<jdub> Peng_: ah, plus, no way to provide a prefix
<jdub> jdub@whitlam:~$ bzr serve --http --allow-writes --port 8000 --directory /srv/whitlam.crikey.com.au/code/
<jdub> ...
<jdub>   File "/usr/lib/python2.5/site-packages/bzrlib/registry.py", line 183, in get_prefix
<cszikszoy> Hi, I was wondering if someone could help me with a small bzr problem.  I merged 2 branches.  There was a conflict in 1 file.  I bzr rm'd the folder that contained that file, and now I can't commit (bzr says conflicts still exist).
<jdub>     if fullname.startswith(key):
<jdub> AttributeError: 'LocalTransport' object has no attribute 'startswith'
<lifeless> jdub: please file a bug on that
<cszikszoy> bzr resolve gives an error saying: "bzr: ERROR: The file id "....." is not present in the tree <WorkingTree4 of ...."
<lifeless> cszikszoy: bzr resolve --all
<jdub> lifeless: will do
<lifeless> cszikszoy: and file a bug please
<jdub> lifeless: against?
<jdub> bzr itself
<lifeless> jdub: loggerhead, for now.
<jdub> ok
<cszikszoy> lifeless, great, thanks very much!
<spiv> lifeless: yeah, I'm certainly not keen on bringing yet another underpowered, buggy HTTP server into the world :)
<spiv> lifeless: I can see how it might be convenient from time to time... but I think I'd rather put effort into making loggerhead smoother.
<lifeless> same
<mlh> http://code.google.com/p/magnum-py/ ?
<lifeless> god no
<jdub> -1 point, terrible pun name
<mlh> oh, liux specific :-(, not really embeddable
<mlh> (I'll get my coat)
<lifeless> for starters, python 2.6 minimum
<lifeless> and multiprocessing is *slow*
<lifeless> (the module)
<mlh> is it?  I was curious about that
<lifeless> we already have http servers in the code base too, for testing
<lifeless> there is a tolerable http server in the standard library
<jdub> lifeless: looked at unicorn?
<lifeless> nope
<jdub> lifeless: http://unicorn.bogomips.org/ (ruby, but interesting to read)
 * mwhudson keeps meaning to investigate spawning seriously for loggerhead
<lifeless> mwhudson: please don't, I've seen one have lots of fallout from spawning
<spiv> lifeless: btw, here's something a bit amusing
<jdub> yeah, spawning sucks. looking at you, spiv.
<lifeless> jdub: 'serve fast clients on low-latency, high-bandwidth connections'
<spiv> lifeless: we recently pointed out an error in the way our mortgage interest was being calculated by our bank (they weren't applying an offset account the way we had asked them to)
<lifeless> jdub: e.g. 'unsuitable for use on the internet'
<jdub> lifeless: it also says that. :-)
<lifeless> spiv: nice catch
<spiv> lifeless: the bank checked their records and agreed, so they had to fix the history of our account
<jdub> lifeless: unicorn is designed to sit behind nginx
<spiv> lifeless: it turns out they don't rebase ;)
<jdub> (or something else, but they're close cousins)
<lifeless> spiv: so you got a single adjustment ?
<spiv> lifeless: so the statement for the mortgage now has all the original interest and payment transactions, plus a bajillion new transactions, backdated, that undo those individually, and individually reapply the right amounts
<lifeless> jdub: squid won't [without a rather ugly hack I don't think I landed in trunk] buffer full responses
<spiv> lifeless: on top of the existing history
<lifeless> jdub: unless they are tiny
<spiv> lifeless: which certainly makes for a confusing read, but the original history is intact ;)
<lifeless> spiv: nice
<lifeless> spiv: they can't rebase, its the law :)
<spiv> Right.
<spiv> Still, it would be nice to have a view of the history "as it should be" as well as "how it ended up being recorded"
<spiv> But they don't provide the tools for that.
<lifeless> true
<spiv> jdub: spawning is certainly slow~!
<lifeless> [=======     ]   download in progress
<lifeless> there is a maternity t-shirt with that on it
<spiv> lifeless: from thinkgeek, yeah :)
<jdub> spiv: yeah, i think about starting, but "want! now!" impatience gets in the way
<lifeless> it would rock if they sold three or four versions
<lifeless> jdub: and thus, Po
<jdub> lifeless: or a little extendy piece of fabric
<jdub> hmm.
<jdub> probably going to have shirt size problems.
<jdub> separate shirts == better.
<piem> howdy. i'm trying to "bzr svn-import https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd", but it crashes bzr
<lifeless> yes
<jdub> lifeless: adult size, puppy brain!
<jdub> he's 23kg now
<jdub> 6 when we got him
<lifeless> jdub: nice
<spiv> piem: with a memory error, or something else?
<lifeless> piem: details are needed, my telepathy is broken
<piem> ok, i'll reproduce again. got than on osx, now back on debian unstable, and got the same
<jdub> he's currently chasing horse flies in the loungeroom... chaos.
<piem> $ dpkg -l bzr | tail -1 | awk '{print $3}'
<piem> 2.0.1-1
<piem> $ dpkg -l bzr-svn | tail -1 | awk '{print $3}'
<piem> 1.0.0-1
<piem> now running the import, it will take a while...
<spiv> piem: a pastebin of the error would be helpful
<piem> spiv: yep, preparing that...
<Peng_> jdub: Waitwaitwait, I just fixed that LocalTransport bug in the trunk a couple days ago.
<jdub> Peng_: oh! loggerhead trunk?
<Peng_> jdub: Yah.
<jdub> Peng_: win! :-)
<spiv> jdub: also, loggerhead trunk has my fix from yesterday I think
<jdub> looks like i'll have to start running loggerhead trunk ;)
<jdub> yayayay
<spiv> jdub: (and bzr trunk now has the fix for the other issue I bumped into too)
<lifeless> spiv: whats a test that will run only_raises
<Peng_> spiv: Yes, it does.
<jdub> not quite so interested in running bzr trunk ;)
<piem> http://pastebin.com/d47582967
<Peng_> jdub: Why not?
<jdub> (it appears this loggerhead adventure has been fruitful!)
<spiv> lifeless: test_decorators has unit tests for it
<jdub> Peng_: happy to run 2.0 on production machine via ppa, but not quite so keen on bothering with trunk ;)
<Peng_> jdub: Bazaar's trunk is just as reliable as the releases.
<lifeless> piem: either a sf operation issue, or a bzr-svn bug; start by filing a bug on bzr-svn please
<Peng_> jdub: Plus, there's a nightly PPA, so you don't even have to build it yourself.
<spiv> lifeless: or if you mean indirectly, any test that invokes unlock on a Repository or Branch
<spiv> Peng_: mmm, our trunk is pretty damn good
<spiv> Peng_: but even so it's not *quite* as reliable as releases
<piem> lifeless: https://bugs.launchpad.net/bzr-svn/+filebug ?
<Peng_> spiv: The only major breakage I remember is all of the fallout back when packs were added, and that made it into the releases. :P
<spiv> piem: yep
<Peng_> spiv: But you're right. Still, it's pretty damn close.
<Peng_> spiv: I sent the contributor agreement email, btw
<spiv> Peng_: there have been a few regressions in trunk from time to time that we've been careful to catch and fix before releases
<Peng_> spiv: Hmm. The 2a fallout?
<spiv> Peng_: and occasionally stuff like hpss verbs in one revision of trunk incompatible with an earlier revision of trunk
<Peng_> spiv: Oh, that's a good point. That did bite me once.
<Peng_> The main problem with running bzr.dev is keeping all of your plugins compatible.
<Peng_> piem: The "bzr init" is pointless.
<fullermd> All the majorest hiccups I remember ended up happening with releases too.
<piem> Peng_: why?
<fullermd> So maybe it's safer to avoid them and stick with .dev   ;)
<spiv> Yeah, plugins are really the main practical issue, much more so than our rare regressions.
<piem> Peng_: import does init too/
<piem> ?
<jdub> Peng_: i use bzr-svn quite a bit (working with wordpress stuff)
<piem> just submitted a bug
<piem> https://bugs.launchpad.net/bzr-svn/+bug/457813
<ubottu> Launchpad bug 457813 in bzr-svn "bzr svn import crashes" [Undecided,New]
<Peng_> piem: Well, first of all, teh command you were looking for was "bzr init-repo", not "bzr init". And yes, it does create its own repo.
<Peng_> jdub: You only have to keep a copy of bzr.dev's bzrlib around for Loggerhead. You don't need to install it globally. Well, you'd have to hack get it into sys.path somehow, but...
<Peng_> Just sayin'.
<jdub> Peng_: wait, loggerhead trunk requires it?
<Peng_> jdub: Err, no, not what I meant. I meant that if you wanted to run Loggerhead against bzr.dev, you don't need to install bzr.dev globally.
<Peng_> jdub: Loggerhead trunk is supposed to be compatible back to...1.13, I think?
<Peng_> jdub: I don't know if anyone tests it regularly, but...
<jdub> right
<jdub> yeah, if i don't need to run bzr.dev, i'm not going to bother :)
<piem> Peng_: right. reproduced, the right way :-)
<spiv> piem: exact same error?  Or does the SVN revision number change?
<piem> and bug report updated
<piem> spiv: exact same error it seems
<Peng_> jdub: If you want .bzr/smart to work with shared repos, you'll need bzr.dev. Or to backport the patch.
<spiv> Or use the monkeypatch I gave him yesterday
<jdub> yeah
<Peng_> Or that!
<Peng_> Heh.
<Peng_> I don't want to add the monkeypatch to Loggerhead; there's not a good way to test if the version of bzr.dev being used has the bug or not.
<spiv> Peng_: version < 2.1.0b2 would be approximately right
<mwhudson> lifeless: one as in u1?
<mwhudson> in any case, good to know
<Peng_> spiv: Eh.
<spiv> Peng_: I'm not for or against adding the monkeypatch to loggerhead anyhow
<spiv> Peng_: just saying :)
<Peng_> spiv: :)
<Peng_> I don't _want_ to add it, but I also want Loggerhead to seem less buggy. I'm going with the lazy choice for now. :P
<spiv> +1 lazy
<spiv> piem: not that it matters a lot, but I don't see your update to the bug report?
<Peng_> Stupid question: does interning objects keep them around forever or can they still be GCed?
<mwhudson> interning strings doesn't keep them around forever
<piem> spiv: editing the first entry actually failed, resubmitted now
<Peng_> ISTM _static_tuple_py's interning makes them immortal, though. It just does "adict.setdefault(self, self)"
<spiv> Peng_: hmm, perhaps that should be a weakref dict of some sort.
<Peng_> _static_tuple_c OTOH uses a SimpleSet, and does a decref and has a comment about making sure they're not immortal, so I guess it doesn't?
<mwhudson> static tuple's aren't weakrefable
<mwhudson> though maybe the python version is
<spiv> mwhudson: the pure python one is a non __slot__ted subclass of tuple, so it probably is
<spiv> (Hmm, adding __slots__ to that is probably a good idea though)
<mwhudson> spiv: i don't think it is actually
<mwhudson> because you can't weakref subclasses of variable sized types i think
<mwhudson> (i tried to fix this once)
<spiv> mwhudson: apparently you're right
<spiv> That seems like an odd restriction.
<mwhudson> spiv: it's because the location of the weakref list is stored as an offset into the structure
<mwhudson> in something like tuples you'd have to interpret a negative offset as an index from the end of the object
<spiv> Ah, hmm.
<mwhudson> (which is how dict is done)
<mwhudson> i can't remember why i didn't fix this, i guess i just ran out of steam
<spiv> Another reason perhaps to make the pure python StaticTuple not inherit from tuple
<mwhudson> or make interning a noop
<spiv> (the other is that you can't make tuple + StaticTuple give you a StaticTuple)
<spiv> (which is an unfortunate difference in behaviour from the C version)
<spiv> I don't think it's hugely likely that we'll right code that accidentally depends on "foo = (prefix,) + a_static_tuple; foo = foo.intern()"
<Peng_> There are probably other subtle differences, features that tuple doesn't implement but StaticTupleC does.
<spiv> s/right/write/
<lifeless> mwhudson: yes, u1
<spiv> (I'm sure if wrote it we'd right it sooner or later ;)
<mwhudson> lifeless: ugh :(
<mwhudson> lifeless: oh well, i'm glad i can take advantage of their pain
<lifeless> mwhudson: they may have gotten all the glitches out by now
<lifeless> but its got a tonne of too-much-magic in it
<lifeless> such as watching sys.modules contents, which is a terrible idea (apt-get dist-upgrade FAIL)
<Peng_> E.g., StaticTuplePy.from_sequence supports arbitrary iterables; C requires sequences.
<Peng_> StaticTuplePy can be subclassed, C cannot . .
<Peng_> The very basic issubclass(StaticTuple, tuple).
<lifeless> AfC: why?
<AfC> lifeless: you talking about aspiration for a loggerhead-less embedded web server?
<lifeless> yes
<lifeless> I said 'we don't want it' and you piped up with 'it would be desirable'...
<lifeless> so why is it desirable?
<AfC> lifeless: well (and this is just my subjective experience, but) LoggerHead has been unbearably slow.
<AfC> lifeless: It's user interface is ghetto.
<AfC> lifeless: It is almost impossible to find the revisions [and their detailed commit messages] that actually contributed changes as instead presents almost exclusively to the useless left hand edge merges.
<lifeless> AfC: so, an embedded http server in bzr core would be likely be slower and even more primitive
<AfC> lifeless: and I am quite embarrassed that my code is presented by it on the branches that launchpad mirrors.
<AfC> lifeless: as may be
<lifeless> AfC: these are 'things wrong with loggerhead' not 'why there should be an embedded http server in bzr core'
<lifeless> AfC: For the former, I encourage bug filing!
<AfC> lifeless: I've been hacking on a kludgy workaround just using GNU source-highlight locally and then rsyncing up
<lifeless> for the latter, I'm still at a loss
<AfC> lifeless: but a straight forward [a la darcsweb, gitweb] branch navigator would have been lovely.
<lifeless> I _loath_ gitweb
<lifeless> its terrible
<AfC> lifeless: or whatever they're running on git.gnome.org â people can effortlessly refer to a branch + revision + file + line number combination.
<mwhudson> a Transport should expect to get paths that are utf-8 plain strings and urlencoded, right?
<lifeless> mwhudson: yes
<lifeless> mwhudson: or rather no
<lifeless> mwhudson: urls and relative urls
<mwhudson> lifeless: i mean a transport method like "rename"
<lifeless> mwhudson: url encoding is not uf8; its a specific defined encoding itself.
<jfroy> verterok: I got things building, I'll try to package tomorrow
<lifeless> utf8 is outside the permitted codepoints for urls
<mwhudson> lifeless: yes, it's a succession of things: unicode --(utf-8)--> str --(urlencode)--> ascii-only str
<lifeless> AfC: you can do that in loggerhead too
<lifeless> mwhudson: urls don't imply unicode or utf8 at all
<lifeless> mwhudson: std66 is sadly clear about it being useless this way.
<spiv> AfC: I honestly don't see any of that being harder with loggerhead than with what git.gnome.org is running
<mwhudson> lifeless: i'm not talking about urls, i'm talking about bzrlib.transport.Transport methods
<lifeless> mwhudson: the generator of a url is responsible for getting it into url form, and noone else is permitted to try to decode it.
<lifeless> mwhudson: so am I
<spiv> except *perhaps* the browsing for branches part
<lifeless> mwhudson: they take relative url references
<AfC> spiv: I couldn't say why, to be honest. I'm just giving you the result of my experience working with both that cgit is a) not slow and b) way easier to use.
<spiv> But certainly once you're looking at a branch it's essentially the same, except it takes me one less click with loggerhead
<lifeless> AfC: its fast, I'll give you that. Thats something loggerhead can improve at - it should be faster with 2a branches anyhow.
<lifeless> AfC: can you describe /how/ cgit it easier to use?
<lifeless> I know I find 'blob' links a bit of a mindfuck
<mwhudson> lifeless: the concrete problem i have is that "bzr push bzr+ssh://bazaar.launchpad.dev/~mark/+junk/bÃ©" causes a server side exception
<mwhudson> (that was a utf-8 string if irc's unhelpfulness on this topic defeated things)
<lifeless> mwhudson: ok. So the client should be encoding that, and here is where std66 fucks us, we guess at utf8 for the native encoding of the far end
<mwhudson> lifeless: right
<lifeless> so you'll have argv[2].decode(console_encoding).encode('utf8').urlencode()
<lifeless> and then pushed over the wire
<lifeless> whats the server side exception? is there a bug?
<mwhudson> lifeless: the bug is https://bugs.edge.launchpad.net/launchpad-code/+bug/449528
<ubottu> Launchpad bug 449528 in launchpad-code "lp: resolution for non-ASCII name oopses" [High,Triaged]
<mwhudson> well, ish
<spiv> AfC: hmm.  Well, if you figure out why it feels nicer to you at some point then please do file a bug or post about it.  From what I can see loggerhead's UI actually is simpler for this, but I realise UI issues can be pretty subtle.
<mwhudson> the exception in that report is in the lp-resolution
<lifeless> mwhudson: is there a stock test double for launchpad, for using in code that wants to talk to launchpad
<mwhudson> lifeless: no
<mwhudson> it would be hard to make a generically useful test double that was much less complicated than launchpad i think...
<lifeless> a fixed definition of apis would allow that to be programmtically generated
<mwhudson> lifeless: the exception is actually in the implementation of the xml-rpc method that we call to interpret paths
<AfC> spiv: I don't know. I've just spent the last 5 minutes trying to find loggerhead of bzr on launchpad. I really don't have any more time, so I'm sure you'll dismiss this feedback as whinging. Pity I can't be more specific. At least my objection to Bazaar Explorer is simpler to articulate.
<lifeless> mwhudson: it would help to have a backtrace in the bug
<mwhudson> lifeless: basically, i think there's a lack of understanding of unicode paths all through the code, so i want to figure things out starting at the beginning
<spiv> AfC: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
<lifeless> mwhudson: we try for crunchy shell there
<AfC> spiv: [thanks; that wasn't anywhere obvious on the bling new website]
<spiv> AfC: now, if your problem is with Launchpad's UI for browsing branches rather than loggerheads, that makes more sense to me :)
<AfC> spiv: aren't they the same?
<lifeless> AfC: bzr lp-open lp:bzr, and click on 'view the branch content'
<mwhudson> lifeless: i'm implementing a transport, i'm part of the shell, surely?
<lifeless> AfC: god no.
<spiv> AfC: I mean, for browsing through the set of branches that are available
<lifeless> mwhudson: gimme a backtrace, I'll try to help :)
<AfC> really? Well, launchpad is what everyone I talk to thinks loggerhead is
<AfC> s/launchpad/launchpad's pathetic attempt at branch, revision, and code browsing/
<lifeless> AfC: the url spiv gave you is loggerhead
<mwhudson> lifeless: you've already answered my question enough i think
<spiv> AfC: as opposed to what loggerhead provides to Launchpad, which I just gave you a link to
<spiv> AfC: (And is where the "browse the source code" link on https://code.launchpad.net/bzr will take you)
<lifeless> mwhudson: ok, well I'm happy to look more closely if you like.
<lifeless> it would be a pleasant distraction from deciding how untested I can bear this ppa watcher to be
<mwhudson> lifeless: thanks, i'll come back if i have more questions
<Peng_> Crap, I just let a traceback get word-wrapped by my email client. :( Should I resend a fixed version, or do you guys usually just suffer through mangled tracebacks?
<spiv> AfC: so if the difficulty you have is with finding a branch in the first place, that's purely Launchpad.
<AfC> So here I am, trying to find the revisions that led to revno 4753. Click on the expander, and all I get is more details about some guy named "Canonical.com Patch Queue Manager" who write some code
<spiv> Peng_: they are generally decipherable anyway
<mwhudson> oooh
<mwhudson> bleeping xmlrpclib strikes again
<mwhudson> i expect
<spiv> AfC: ah, fair enough.  The link "(4752.2.1 integration)" with the crossed arrows icon takes you to the other parent revision
<AfC> Four pages later I finally find my way to a page that has a link that turns out to be http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4752.1.1 that finally has the commit message that Vincent wrote.
<spiv> AfC: but I think a way to see all the revisions that were merged into mainline at that point is lacking
<emmajane> abentley, I see you're away and stuff... but I'll be in Toronto this weekend for OLF. We're going out for dinner on Friday if you're interested.
<AfC> in little itty bitty type
 * spiv takes some notes
<emmajane> (Everyone else is invited too... if you can make it up to Canada)
<AfC> spiv: yeah, you know, like, say, `bzr viz`
<mwhudson> aaaaaaaaaaa
 * spiv nods
<AfC> oh, that's brilliant... from that page, click on "view branch changes" which is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/4752.1.1?start_revid=4752.1.1 and then get another useless left hand edge history. Squint hard, and we'll see our revision at the top.
 * emmajane chuckles.
<AfC> spiv: so... here I am, having spent about 4 times longer on evaluating this than most people, [and lord knows I'm predisposed to at least try and figure it out] only to be frustrated, puzzled, and then ultimately profoundly depressed.
<AfC> spiv: maybe this makes perfect sense to someone who understands the Zen Of LoggerHead
<spiv> AfC: Thanks, this is useful feedback.
<spiv> So, I think Loggerhead currently does a very good job with the left-hand history.
<AfC> spiv: but I've got to admit as someone who has a reasonably sophisticated (if outsider) knowledge of Bazaar and it's culture [and more to the point, basis] that I have absolutely no idea what that tool is presenting, other than knowing that it's
<AfC> not giving me anything I can readily show to a new developer saying "yeah, here! that's the code"
<spiv> And a pretty weak job with the rest.
<AfC> [and yes, I've tried this extensively on [mirrors of] my branches]
<jdub> spiv: you would have received more points if you started that with, "so, on the one hand..."
<AfC> spiv: which, actually, is my primary interest: people toddle along to one of my projects, ask a question,
<AfC> spiv: and I want to show them a {file snippet | branch that is working on that feature} in as seemless and impressive a way as possible.
<AfC> spiv: in order to suck them in, have them think that Bazaar is smoking hot & sexy cool
<AfC> spiv: while being blown away and in need of CPR to get over how impressed they are at my code :)
<spiv> So I think loggerhead does a pretty good job of that.  Wanting to interrogate the non-lefthand history isn't usually something I'd want to do with a project I'm new to.
<spiv> It would be good to make it easy to do so, of course.
<AfC> spiv: in the projects I'm working on, the left hand edge is almost meaningless. It's the people who contributed the actual work in the [non merge] revisions & their commit messages that I'm interested in. That's where the credit needs to be focused.
<AfC> spiv: and that's what the left hand edge bias comprehensively works against.
<AfC> [as I write about frequently]
<spiv> Sure.  There are multiple use cases here.
<AfC> spiv: (and, just to close the topic, annotate does NOT show left hand edges. It shows the revisions that change things. Merges are transparent there, as they should be)
<spiv> And some of them aren't being well catered for.  I just wanted to point out that some are, and I think actually fixing the presentation non-lefthand history is not fundamentally that hard.
<spiv> ...and, to bring the conversation back to the start: I'd rather fix this in loggerhead than try to do it from scratch in some sort of minimal serve --http :)
<mwhudson> spiv: do you have any good tips for running pdb inside a smart server process?
<spiv> mwhudson: "import pdb; pdb.set_trace()" works well in a TCP server
<spiv> Other than that, not really.
<AfC> spiv: not sure; as I've just alluded to, those of you who work to the patch queue manager and have it committing your left hand edge seem awfully happy with that workflow,
<mwhudson> hm, i can probably get a TCP server to work
<AfC> spiv: but certainly no one else I know is using that model, and thus the culture expressed by the bzr tool (and its left hand edge loving ecosystem) doesn't seem to be that well suited to "their" needs. [using that sloppily, of course]...
<AfC> spiv: and since I have a somewhat vested interest in Bazaar looking appealing to [new contributors] people, this is a very exposed issue for me.
<AfC> spiv: back to start... fair enough
<spiv> AfC: well, I think for heavy lifting you really want something richer than a web UI (which is not an argument for neglecting the web UI)
<AfC> spiv: perhaps, but at this point anyone coming from another system has glorious [pun intended] web experiences, and we look lame & cumbersome in comparison.
<spiv> AfC: but "when did this line of this file change", and "show me what's been happening lately" the sorts of things a casual users tend to want and loggerhead already caters for quite well.
<mwhudson> huh, pushing to bzr://localhost/<non ascii path> says "bzr: ERROR: Unsupported protocol for url "bzr://localhost/~mark/+junk/bÃ©""
<spiv> mwhudson: weird
<spiv> AfC: I'll file some bugs with this feedback, it's good to have some concrete "user tried to do X, got lost" stories.
<mwhudson> oh hang onnnnnnnnnnn
<spiv> AfC: oh, and I'll note we keep getting git users in this channel wanting to rebase because they don't want to deal with non-linear history in any VCS ;)
<mwhudson> the unicode characters in my test case are getting past the checks in get_transport because of the directory service?
<mwhudson> well sort of
<spiv> mwhudson: whee?
 * spiv -> late lunch
<mwhudson> the directory service is accidentally quoting them
<lifeless> 'accidentally' ?
<mwhudson> well maybe not that
<mwhudson> but it is
<AfC> spiv: yeah, well, there is that :)
<AfC> spiv: I have a suspicion that if we did a concerted push on making the workflow [that I don't have a cunning handle for, but that John blogged about at http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html ]
<AfC> spiv: be *ultra* smooth and sexy
<mwhudson> lifeless: basically you can say bzr push lp:<unicode> and it will go off and talk to the server
<AfC> spiv: [ie, the use of revert there, and the need to not unrevert a second time]
<mwhudson> lifeless: but the client will barf on bzr push sftp://<unicode>
<mwhudson> (actually you can't say the former, the directory service will oops)
<AfC> [when "revert" as in blow away is NOT what you're actually doing overall, even if in that branch at that instantaneous moment it is indeed the operation you are performing]
<AfC> spiv: cross product
<AfC> spiv: somehow making the `bzr diff -r submit:` UI a bit more first class
<AfC> would suddenly make the outward goal that people are trying to achieve ["here's my patch, here are the revisions (sic) that led to it" be Ã¼ber clean]
<AfC> and suddenly merge vs rebase would go away entirely (with bzr winning, because the workflow would be easy, and the history would be preserved... TRANSPARENTLY
<AfC> anyway, that's what I'm ultimately after. There's no doubt in my mind that Bazaar's infrastructure is a better foundation, but equally the ... effect ... that people are presently rebasing to achieve isn't going to go away.
<AfC> It is, indeed, [IMHO] the primary open source workflow, and we don't support it very well.
<AfC> ... which was the point that Havoc & Martin made all those years ago when contemplating what a next gen distributed version control system ought to be if it was going to be of value to open source communities.
<Peng_> Ohh! I left out my name in the contributor agreement email. Oops.
<mwhudson> lifeless: fwiw, i think i found the (or a, at least) problem in codehosting: in say def get(relpath) going self.base + relpath isn't valid
<mwhudson> because the escaping is different on the two sides
<lifeless> mwhudson: thats correct
<lifeless> mwhudson: don't you wish we used haskell/erlang/ocaml?
<mwhudson> lifeless: heck, python3k would be a lot better for this
<lifeless> mwhudson: I don't think it would catch this as they are both going to be bytestrings
<lifeless> unless relpath is unicode, in which case your caller is broken
<mwhudson> lifeless: although launchpad implemented in haskell would be an interesting idea
<mwhudson> lifeless: yeah, true in this case, but it would be better for other things
<jelmer> moin
<lifeless> hi jelmer
<jdub> lifeless: writing post commit stuff is kinda hard for a sysadmin not familiar with the bazaar codebase
<lifeless> jdub: I'd like to have a library of common needs
<lifeless> jdub: the svn stuff is also strange
<jdub> lifeless: ever thought of a runparts adapter?
<lifeless> jdub: mmmm, not having stuff on disk ...
<jdub> lifeless: hmm?
<lifeless> I may be confused
<jdub> lifeless: i was just thinking of a bazaar plugin which let you throw shell scripts into runparts style directories
<jdub> and passed useful parameters
<lifeless> jdub: see jelmers shell hooks plugin
 * jdub currently trying to figure out params, as passed to post_change_branch_tip
<jdub> lifeless: ooer, wher eis this?
<lifeless> jdub: somewhere around
<lifeless> anyhow, write the hook, and import pdb;pdb.set_trace() as teh first line of it
<lifeless> you can explore very effectively
<lifeless> what do you want your hook to check
<jdub> first thing appears to be "is this the branch i should be running this hook on?"
<jdub> ahr: http://people.samba.org/bzr/jelmer/bzr-shell-hooks/trunk
<lifeless> right, you can use the branch.get_config() to read a config key
<lifeless> johnf has done some stuff for finding the public url too, for similar reasons
<abentley> emmajane: I'm rock-climbing on Friday after work, but maybe I can meet up later?
<emmajane> oooooo
<emmajane> jealous
<emmajane> I havne't been climbing in ages.
<spiv> jdub: http://doc.bazaar-vcs.org/latest/en/user-reference/index.html#post-change-branch-tip http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.branch.ChangeBranchTipParams.html
<emmajane> abentley, we'll be up at the end of the world for the pre-party. it'd be great if you could make it.
<jdub> spiv: aha, it's that second url i have been looking for -- thanks!
<jdub> hrm, suspect i can't really use the shell hooks stuff... not sure i want something in .bzr/branch/branch.conf -> i only want server-side hooks
<lifeless> jdub: that should be referenced (as ChangeBranchTipParams) from the hook docs
<lifeless> and pydoc bzrlib.branch.ChangeBranchTipParams
<lifeless> will work
<abentley> emmajane: Sure, can you mail me details? aaron@aaronbentley.com
<emmajane> abentley, sure.
<lifeless> jdub: .bzr/branch/branch.conf is fine for configuring a plugin that is only installed on the server :)
<lifeless> jdub: as for the shell hooks - yes, security and containment are big reasons we didn't include them in core
<jdub> lifeless: but if someone has the plugin on their client, won't it attempt to run the shell script?
<lifeless> "jdub: as for the shell hooks - yes, security and containment are big reasons we didn't include them in core"
<lifeless> :P
<jdub> heh
<jdub> lifeless: pdb during commit = win ;)
<jdub> well
<jdub> post commit ;)
<lifeless> james_w: please upgrade bzr-builder to 2a
<bialix> hi bzr universe
<jdub> can't quite seem to get loggerhead to run a commit hook plugin
<jdub> i've got a py file in /var/lib/loggerhead/plugins
<jdub> set the BZR_PLUGIN_PATH env var in the init script (both exported and ahead of the daemon just in case)
<jdub> BZR_PLUGIN_PATH=/var/lib/loggerhead/plugins bzr plugins
<jdub> lists the plugin
<jdub> it's world readable
<jdub> i've set up a non-interactive way to see if it runs
<jdub> (touch /tmp/touchable ;)
<spiv> jdub: your plugin touches when loaded, or when the hook is run?
<jdub> spiv: oh, within the hook
<jdub> spiv: good point, check if it's loaded at all
<spiv> Yeah
<jdub> aha
<spiv> It might be nice if loggerhead had an option to turn on a magic diagnostic URL, e.g. /plugins to list plugins.
<jdub> loaded and running
<jdub> maybe one of my checks is bad...
<jdub> (also, must remember to restart loggerhead on plugin changes)
<vila> hi all
<vila> spiv: revno 4762 put babune in the red, 16 errors about TypeError: __init__() takes exactly 5 arguments (4 given)
<bialix> hi vila
<vila> hi bialix !
<bialix> :-)
<bialix> babune -- what is funny name. what it means? a monkey?
<vila> spiv: certainly trivial, but I'm worried that PQM let it pass...
<vila> spiv: http://paste.ubuntu.com/298840/
<vila> spiv: I need to apply updates all  over the place so babune (and  I :) may well be unreachable in the coming hour, see the paste above for the various call sites
<jdub> spiv: *lightbulb* ... plugins run in bzr serve's handy chroot
<lifeless> jdub: :)
<jdub> spiv: well, no, more that branch locations have special chroot names
<jdub> (params.branch.base)
<lifeless> this is why I mentioned johnf's work
<igc> hi vila, bialix
<bialix> hi igc
 * igc back online after a day nursing my 6 year old
<mneptok> igc: you've started lactating?!
<igc> mneptok: no, that's well beyond my talents!
<mneptok> igc: damn. it's always been a secret desire of mine, and i was going to ask about your current pharmaceutical regimen.
<igc> mneptok: :-)
<lifeless> mneptok: I hear simple stimulation can be enough
 * spiv puzzles over the test failures that PQM didn't catch
<spiv> lifeless: Oh!!
<spiv> lifeless: selftest --subunit gives exit code 0 even when a test fails.
 * spiv fixes the immediate failures first.
<mneptok> lifeless: if you're going to be at UDS, i'll take you up on that offer
 * vila back after rebootS
<vila> spiv: ping
<spiv> vila: so
<spiv> vila: 1) fix for the test failures is with PQM
<spiv> vila: 2) selftest --subunit has exit code of 0 even when test fail
<vila> argh, I ws so afraid about 2) :-(
<vila> spiv: is that related to the progress reportting ?
<spiv> vila: well, in bzr.dev make check uses --subunit now
<spiv> To give the progress reporting
<spiv> But it looks like subunit's TestProtocolClient has a bug in wasSuccessful
<spiv> In certainly doesn't have a unit test for it...
<vila> spiv: ok, thanks for checking that so quickly
<spiv> vila: this explains both recent cases of buildbot breakage I think
<vila> I was about to say that :)
<vila> It certainly sounds like jam's breakage that we attributed to some extension building related problem wasn't related to extensions :)
<vila> It's a good thing I don't use 'make check' in babune (as I considered at one point, but I think lifeless disagree :)
<vila> disagreed
<lifeless> spiv: subunit command gives non-0 though
<lifeless> spiv: oh, you've found the bug?
<spiv> lifeless: yes
<lifeless> cool
<spiv> lifeless: here's a failing unit test for you http://pastebin.com/m72a5a3bf
<spiv> lifeless: feel like writing the fix? :)
<spiv> lifeless: (I need to go to the shops and grab some dinner stuff)
<lifeless> spiv: not tnoight; can you file a bug with that?
<spiv> lifeless: sure
<spiv> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/457952
<ubottu> Launchpad bug 457952 in bzr "TestProtocolClient.wasSuccessful is always True" [Critical,Confirmed]
<spiv> Pfft, I filed that on subunit originally, but somehow the bzr task seems to have taken precedence.
<spiv> Anyway, food.
<Peng_> Crapcrapcrap, jailbreak errors.
<Peng_> Ah, I accidentally reverted the fix.
<lifeless> spiv: thats not the bug
<garyvdm> Hi bialix
<garyvdm> I don't often get annoyed, but I'm realy piss now... </vent>
<bialix> Hi Gary
<bialix> garyvdm: I don't understand
<bialix> am I say something wrong (again)?
<garyvdm> No not you
<garyvdm> Craig
<vila> garyvdm: me ? I said nothing ! Maybe I should have ? :-D
<garyvdm> lol
 * vila is always happy when he can make an angry people laughs :)
<bialix> garyvdm: that custom rendering was always issue for me
<bialix> garyvdm: take easy, Craig is not python developer as I know
<garyvdm> bialix: Me to. The qt api is not very good, it that it does not allow you to reuses the bits that you need.
<bialix> heh
<Peng_> jam: ping
<vila> Peng_: Don't wake up the beast yet...
<vila> Peng: it's 3:00AM in Chicago...
<Peng_> vila: A real beast never sleeps anyway!
<vila> Peng: oh, you're talking about fullermd now...
<Peng_> jam: There's a little oddness in StaticTuple_New: if (size < 0), it throws a TypeError with PyErr_BadInternalCall(). Then it has a check, if (size < 0 || size > 255), it throws a ValueError.
<Peng_> I should probably file a bug or something instead of IRC-poking.
<vila> Peng: exactly, throw a mail to the ML or better, file a bug
<Peng_> vila: Then I have to think of a title and stuff. I hate that. :P
<Peng_> (Will do.)
<vila> Peng: title == 'little oddness in StaticTuple_New'
<Peng_> vila: I hate undescriptive bug tiles like that, or "bzr crash" or whatever.
<spiv> lifeless: oh?
<spiv> lifeless: hmm
<spiv> lifeless: so, in that case, I still think you want a test for the behaviour of wasSuccessful :)
<vila> Peng: that one should be short-lived so it doesn't matter that much, what you want is catch jam attention, if you don't want to file a bug, send a mail :)
<Peng_> vila & jam: Well, I filed https://bugs.edge.launchpad.net/bzr/+bug/457979 about it.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457979)
<Peng_> C'mon, ubottu, you can do it! ...Darn.
<vila> Peng: hmm, looks like today will be a good day for you :)
<Peng_> I just edited the bug description right after filing it. I *always* do that.
<igc> vila: do you have time today to look at the review queue? There's a few small changes there from community folk that I'd like to get a second reviewer on
<vila> igc: not really, but I'm tweaking the terminal_width one right now
<vila> igc: also I'd really like if we can do *something* about the dwim revspec one to get it moving forward
<vila> lifeless: would you be really sad if we land it as is ? I agree we want *something* to be done for svn:, git:, thread:, etc, but we don't have that today so I think it's  not a valid reason to block the landing... thoughts ?
<vila> spiv: babune starting its comeback in green (jaunty almost there, I'll start the others now), thanks
<igc> vila: ok. Thanks for working on the terminal width one. I think we need to help pilot a few of these patches through rather than let them sit there in semi-limbo for weeks/months
<vila> igc: you're preaching the choir :)
<igc> vila: ? as in you agree?
<vila> igc: as in: I fully agree for years :-D
<vila> igc: as in: I'm a dog more than a owl (at least that's what everybody is telling me :) bark bark
<igc> vila: I've been flat out on 2.0-related stuff like packaging and docs for a few months now but ...
<igc> vila: I'd *love* to get back to the BundleBuggy days of just a few patches in the queue - not 20
<vila> igc: sure, I think we have more submissions right now though...
<igc> vila: we probably do. It will only increase though if we're successful :-)
<vila> igc: hehe, I think the actual increase *is* already a sign of success :)
<igc> vila: and I want the community folk to enjoy the experience of submitting patches (again) rather than being frustrated as some have been lately
<igc> vila: anyhow, enough philosophy. Here are the simple patches I'm looking for a reviewer on ...
<igc> https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380
<igc> https://code.edge.launchpad.net/~mathepic/bzr/remove-tree-multi/+merge/13451
<igc> plus the terminal one
<lifeless> vila: I think that landing the proposed patch makes things less clear/obvious for someone wanting to work inthat area
<lifeless> vila: that fails the 'dont make things worse' tenant
<lifeless> bah, spelling.
<lifeless> vila: I'm not -1 on it, but I'm certainly not for it.
<vila> lifeless: worse ? It *adds* new semantics for unqualified rev specs. It *doesn't* provides an easy way to add *more* dwim semantics, but there wasn't any before that. What is worse ?
<vila> lifeless: I'm really trying to understand here, I've looked at addressing [y]our concerns but didn't find a trivial way in less than an hour, hence my desire to land as is
<spiv> I'm inclined to agree with vila.  I haven't looked at the patch closely, but I don't see that adding that extensibility later is going to be hard enough that it justifies landing the incremental improvement.  It doesn't feel like a step backwards to me.
<spiv> Er,
<spiv> That is justifies *not* landing.
<spiv> memo to self: long run on sentences with double negatives on irc are a bad idea :)
 * igc dinner
<Kamping_Kaiser> suppose I bugger up a commit without noticing and want to fix it. is the best thing to branch at that point, fix and merge?
<Kamping_Kaiser> I have commited since the change in question
<Peng_> Kamping_Kaiser: Daggy Fixes are really cool (IMO), but not necessary. You can just "bzr commit" a fix.
<Peng_> Kamping_Kaiser: Daggy Fixes are useful if you want to do something like merge it into a release branch, though.
<Kamping_Kaiser> Peng_: ok, thanks.
<lifeless> spiv: vila: it adds a long case statement which needs to be teased apart and put back into the existing registry
<vila> lifeless: right, looking at the code, I think we don't want to inherit from RevisionSpec but put the code back into a static method, and from there, right (apart from rewriting the tests), there should be a way to come back to a registry but I'm not sure we want to reuse the existing one or create a new one
<vila> but that isn't indeed trivial
<vila> pff, not even ! the dwim revspec is used to delay the _match_on call so that the actual revspec can be created lazily from the dwim_revspec created in from_string :-/
<vila> hmm, jam just walked on his laptop that he mistakenly left near his bed...
<RenatoSilva> Is there a way to unmerge an ancient merge?
<garyvdm> Any opions on Bug 444862?
<ubottu> Launchpad bug 444862 in qbzr ""bzr qlog" displays revision when searching in revids, but not when searching in messages" [Undecided,New] https://launchpad.net/bugs/444862
<vila> garyvdm: you mean apart from the fact that 52 clicks is too much ? :)
<vila> garyvdm: oh wait, you ask that question before guilhem replied tight ?
<guilhembi> vila: garyvdm:
<guilhembi> hello, yes I just replied, and it has to do with 52 clicks indeed (more details in my reply).
<guilhembi> and I attached a screenshot to clarify more.
<garyvdm> guilhembi: Ok - so you want it to expand to the found revision.
<garyvdm> *revisions
<guilhembi> garyvdm: yes, 52 clicks is tedious. On the other hand, there is not one found revision, all found revisions are interesting,
<guilhembi> so I guess it could expand to all found revisions. On the yet other hand, if the search found 10000 revisions,
<guilhembi> this expanding will kill qlog I guess.
<guilhembi> Which is why I thought - don't expand, but offer an "expand all" button (if user sees 1000 unexpanded revisions he may not click on the button). Just an idea.
<garyvdm> Yes - if you start typing 'apple' and you just get to 'a'  - it will show lots.
<garyvdm> hmm - intresting problem
<igc> night
<jam> night igc
<jam> morning vila, did you see my response to your 'isatty' change
<jam> I think you 'broke' the original intent with your update
<vila> jam: not yet, :-/
<vila> jam: morning
<jam> basically, you now set the terminal width based on whether there is an 'isatty' attribute
<jam> rather than whether isatty() returns True/False
<jam> and doing "bzr log | less" has an object with 'isatty' but it returns False
<vila> oh, I see, you mean I should *add* 'and not sys.stdout.isatty()' ?
<vila> rhaaaa 'or not sys.stdout.isatty()'
<vila> jam: ^
<vila> jam: ok, found your mail finally, I agree (as said above...) and will fix
<vila> jam: did you read the IRC logs, especially the part about PQM not failing on errors ? (for bzr.dev, not 2.0.x)
<jam> vila: I did not see the irc logs, I did see Andrew's post about it.
<vila> jam: good, I didn;t see your comment on the bug until now
<jam> Peng_: btw, I replied to the bug and the merge proposal
<jam> wow GaryvdM is going banaza on the bugtracker...
<fullermd> vila: I warned you that registrifying the DWIM wasn't trivial   :p
<vila> fullermd: I have a working patch except it fails one test that seems so unrelated I'm a bit puzzled...
<fullermd> 's either a lot of grumpy hand-fitting so it works with The Way Things Are, or a lot of grumpy work changing The Way Things Are...
<vila> fullermd: not that much, let me push that so you can see
<fullermd> Oh, my eyes won't help you.  I hit my capability limit just writing it as-is.
<vila> fullermd: pff :)
<fullermd> And I'm in crunch, so I won't have time to do more than glance at much for weeks...
<fullermd> And actually, if the concensus is toward stopping on non-revno revno-looking things, that adds more magic in registrification, unless that check is left out of the reg, and...
<maxb> igc: Hi! What's your initial reaction to the idea of having bzr-fastimport store git refs as bzr branch nicks?
<vila> fullermd: look at lp:~bzr/bzr/revspec-dwim if/when you can
<vila> fullermd: that's not as bad as many tought
<fullermd> vila: What's with the pulling of wants_revision_history in 4586?
<vila> fullermd: nobody uses that since we create new revspecs objects
<fullermd> Are you sure?  I needed it so that it didn't try to build the history when it looked into revnos, but DID for other stuff.
<vila> fullermd: no I'm not sure :)
<larsemil> i have created a project for wich i am the maintainer on launchpad. but i dont understand how to upload my code there?
<fullermd> (and without at least setting it False, it ended up building the history just for revnos, which is a big regression)
<vila> fullermd: you rock !
<vila> setting to false is enough
<vila> Indeed, I deleted that after running only -s bt.test_revisio, but the failing one was not there...
<vila> I need to EOD just now, but I'll update the submission probably later tonight ~21h00 my time (it's 18h10)
<fullermd> I recall that I needed to reset it for later because something failed if I didn't, but that may be faulty memory.
<jam> larsemil: you may want to create a group for the project
<jam> otherwise just "bzr push lp:~USERNAME/PROJECT/trunk" or some similar branch name.
<jam> you can then edit your project settings to declare that location as the 'development focus'
<jam> so that people doing "bzr branch lp:PROJECT" will get the code from that branch.
<jam> Peng_: if you could help me understand the issue with 'merge' it would be appreciated
<jam> testing it locally doesn't seem to trigger the problem
<larsemil> so now the project came under USERNAME/PROJECT so noone else will be able to commit to it+
<jam> larsemil: so anyone can push their own branch to "~myuser/project/branch-name", however yes, if you don't create a group for the project
<jam> only you will be able to push to the trunk branch
<jam> note that you can create a group later
<jam> and move the development focus to that branch later, etc.
<larsemil> jam: i did a push but still it says no revision?
<larsemil> jam: and with group you mean team=
<larsemil> ?
<jam> larsemil: yeah, probably team
<larsemil> thanks
<jam> larsemil: did you commit locally before pushing?
<larsemil> jam	maybe not?
<larsemil> before pushing i did bzr init
<jam> larsemil: 'bzr init; bzr add; bzr commit; bzr push' is the general steps
<jam> note that you may want "bzr init; bzr st; bzr ignore; bzr add" etc
<larsemil> jam: thanks i got the files now
<jam> Peng_: for example, are you sure that you recompiled all extensions before doing the 'bzr merge' ?
<RenatoSilva> I want your feedback about the following workflow. I have trunk and feature branches. I focus on testing all of them together, so I have a branch all-features that basically is a merge of trunk and the otehr branches.
<RenatoSilva> Hi.
<RenatoSilva> I want your feedback about the following workflow. I have trunk and feature branches. I focus on testing all of them   together, so I have a branch all-features that basically is a merge of trunk and the other branches.
<dash> RenatoSilva: why do you do that?
<break_> hey. I was hoping someone could help me. I need to import the files from just the latest revision of an svn repo into a newly created bzr branch. I don't need any of the revision information, just the files themselves. how do i do this?
<vila> fullermd: so, we were both half-right, wants_revision_history should be set to False at the class level BUT there is no need to set it to True after that.
<vila> fullermd: presumably you needed it in some intermediate implementation ?
<fullermd> Possible.
<fullermd> Remember, I don't know python or bzrlib, so my patches are all just shotgunned until they work   :p
<fullermd> You can def. see the performance impact of not False'ifying it.
<Tak> break_: svn export, then bzr add?
<vila> fullermd: EPARSE(can def. see)
<fullermd> Goes from ~.21s to ~.60s for 'stat -c-1' without it, since it builds the full tree before it gets to trying the revno.
<fullermd> "can definitely see"
<vila> ha, funny you say that, the failing tests was a effort one :-)
<vila> bzrlib.tests.blackbox.test_pull.TestPull.test_pull_smart_stacked_streaming_acceptance
 * fullermd blinks.
<fullermd> Wow, that must be some WEIRD indirect kinda effect   :p
<fullermd> But I guess it did its job, in a roundabout way.
<vila> the test checks how many calls are done to the remote server, getting the rev history add calls
<fullermd> I can only imagine the performance impact it would have on trees with more history than bzr.dev, but I knew if I submitted a patch that made -r123 more expensive, I'd get lynched...
<vila> the good thing is that the test was well tought and caught a related bug, the bad thing is that it was the only test to catch it
<fullermd> Yeah, but who expects something like that to be doing a -rSOMETHING?  Wacky.
<vila> fullermd: look at it now that you know it fails and why, you'll see it's obivous
<vila> even more when knowing that replacing '-r 1' by '-r revno:1' made it pass
<fullermd> Probably.  I never looked at it before I kniew it failed   :p
<fullermd> ('cuz it never failed for ME.  I can't help it if YOU break my perfect code  ;)
<sjamaan> Is there any sane documentation for scmproj? The official docs are thoroughly confusing
<vila> fullermd: me neither, but it prompted me to ask for your fresh eye 5 mins before my EOD :)
<vila> sjamaan: your input will certainly help, the main autho native language is not english
<vila> s/autho/author/
<break_> Tak: thank you, that looks like just what i need
<sjamaan> vila: sure, but in order to be able to provide input I have to understand it first :)
<sjamaan> I was able to initialize a project, but I can't find docs on how to actually start adding subprojects to the project
<vila> I don't use it myself so I can't answer that
<vila> fullermd: so, should I propose merging lp:~bzr/bzr/revspec-dwim or do you want to pull that in your branch and press the resubmit button ?
<vila> I think the later will provide a better tracking,,,
<fullermd> Either way.
<vila> then pull/push/resubmit , I'll aprove, add some comments
<vila> s/approve,/approve and/
<vila> fullermd: the 'resubmit proposal' button is in the upper right area
 * fullermd waits in LP to update it.
<vila> ok
<fullermd> I don't see a...    oh, on the merge page, not the branch.
<fullermd> 'k, wending its way around.
<vila> fullermd: did you explicitly request reviews from Ian and Robert or did lp did that on its own ?
<fullermd> I didn't do anything to add them, so I guess LP slapped 'em on.
<vila> wow, I thought I approved that one.... but I'm not even in the comments 8-)
<fullermd> You answered the email I sent on to the list, not the MP mail.
 * fullermd goes on another epic bitch session about the two being divorced.
<vila> hmm, yeah, both arrive in the same mailbox here so I may have been confused, especially if you used the same subject...
<fullermd> jelmer and spiv also commented, but on the list, so they didn't make it into the tracker either.
<vila> I think we are progressing anyway :-)
<phoenixz> Hi all, Im new on Bazaar... Long time SVK / SVN user, but since SVK effectively is dead, I need to switch to something new.. Could anybody here tell me if bazaar has these options? - Offline working, automated merges (not needed to track which changes where, etc, just plain merge and it works)...
<vila> We have nearly all the needed pieces in place: 1) You put an url to the merge proposal in the commit mesage when you land on trunk, 2) You put url to the mailing list archive in your merge proposal, 3) You teach qbzr/bzr-gtk to open urls in commit messages....
<fullermd> phoenixz: Both of those are pretty much inherent qualities in DVCS's, so bzr does them naturally.
<phoenixz> fullermd: well, I'd think so too, but AFAIK, SVN doesn't.. :) which was the reason for me to use SVK, which does..
<fullermd> That's 'cuz SVN isn't a _D_VCS  ;)
<phoenixz> fullermd: sounds good.. is it possible to for BZR to connect to an SVN repository?
<nyu> hi
<phoenixz> fullermd: Just for the record, I'm just walking out on SVK / SVN here.. :) I know VCS, but what is a DVCS?
<fullermd> phoenixz: Yes, there's a bzr-svn plugin for that.
<nyu> I notice branching from svn (via bzr-svn plugin) is awfully slow.  is this because of the branching or because of the svn->bzr conversion?
<fullermd> phoenixz: 'Distributed'
<dash> phoenixz: yes, i use bzr with several svn repos
<nyu> I guess it's downloading the whole thing?
 * fullermd has to dash off and take care of some things.
<dash> phoenixz: I hear it can even read SVK merge data but I haven't tried that :)
<dash> nyu: yes, the first time it has to download the whole thing
<phoenixz> dash: so it makes a complete local mirror of a repository, like SVK does?
<dash> right
<nyu> dash: once I created the first branch, will I be able to create further branches from it quickly?
<dash> yes
<nyu> I mean, remotely
<dash> a shared repo can also help with that
<phoenixz> fullermd: another question.. svn has the very FRIGGIN nasty habbit of dumping .svn directories all over the place.. bzr doesnt do this either?
<dash> phoenixz: nope, just one .bzr dir at the top level of your branch
<nyu> dash: so even if the repo is huge, I can branch a remote bzr URL into another remote bzr URL with small cost?
<phoenixz> dash: mmm, I think I can live with that..
<nyu> i.e. without downloading the whole thing
<dash> nyu: right, because it will use the revisions stored locally before downloading any
<dash> if you use a shared repo then the branches will use it for the revisions they have in common
<nyu> in that case I guess I should setup a bzr mirror of svn trunk, then branch off it, rather than branching directly from svn?
<nyu> I need branching to be cheap
<dash> nyu: that's what we did
<nyu> ok, thanks
<phoenixz> fullermd: so, it also tracks all changes and merges? So, say if I have tree B, with subdirectory lib in there.. I copy tree A to B, I make changes in some files in A/lib and some changes in similar and other files in B/lib.. then can I easily merge the changes from A/lib to B/lib and also vice-versa?
<phoenixz> fullermd: I realize, I may be asking if ice is cold here, but with SVK.. well, it worked, but thats about all.. I have a migraine from using it and I need something that just plainly works..
<fullermd> phoenixz: Sorta.  There'll be some realigning of your thinking to fit with bzr, though.
<phoenixz> fullermd: howso?
<fullermd> phoenixz: You don't work with repositories in bzr, you don't work with branches.  And they're real branches, not 'copies'.
<phoenixz> fullermd: okay.. trying to fit that in...
<fullermd> phoenixz: And revisions are the first-class entities you ship around.  So when you merge, you're merging one set of revisions with another.  Your history has all the revisions you've ever pulled in, so it tracks based on that.
<fullermd> phoenixz: I really need to run off right now, but I'll be back in an hour or so.  Or somebody else can help you fill that in.
<sjamaan> fullermd: Is there a way to fetch an entire repository with bzr? Or can you only fetch branches?
<fullermd> sjamaan: Only branches, currently.  There may never be a way to fetch a _repository_ per se, but there will probably be ways to fetch a _group of branches_.
<sjamaan> (I'm a little concerned that if I have two very big branches and I clone both, they won't share data on my machine)
<phoenixz> fullermd: okay, thanks for all the info anyway! Im going to give this one a good try
<sjamaan> Having repositories be second-class citizens as it were, you undermine the distributed nature of bzr, no?
<dash> sjamaan: create a repo, fetch branches into it, they'll share revisions
<sjamaan> dash: Ah, that works?
<dash> sjamaan: yep
<sjamaan> cool!
<sjamaan> I take it it picks up the sha1 hashes and uses that to determine two files are the same?
<dash> sjamaan: this is why they're second class citizens, they're mostly an optimization rather than something affecting the contents of your branch :)
<dash> sjamaan: revision IDs
<sjamaan> Ah, I understand now
<sjamaan> It does make sense
<asac> how can i configure bzr branches so that noone can push merges that make the bzr revision move backward?
<sjamaan> Is there a way to create repositories later on, after you checked out a branch?
<sjamaan> (say I have branch a as a regular branch, but then decide I also want branch b, and want them to share data)
<dash> sjamaan: sure. just do the same thing :)
<dash> create a repo, create a branch in it from your existing non-repo branch
<sjamaan> I need to re-clone the branch?
<sjamaan> Or can I just move the existing branch into the repo dir?
<dash> the former
 * sjamaan nods
<sjamaan> I could probably clone it locally and then make it point at the original upstream branch, right?
<sjamaan> (to avoid downloading a lot of data)
<lifeless> asac: bzr help configuration, look for append_only
<lifeless> moin
<sjamaan> Where can I find more info on nested branches?
<nyu> dash: uhm, the "bzr push" part of the mirroring just takes 5 steps in progress bar, is this normal?
<nyu> it looks scaringly fast in comparison ;-)
<nyu> I hope it *does* indeed upload the whole thing
<Solarion> is there an easy-to-read guide to using bzr in emacs?
<dash> Solarion: well, both vc (builtin to emacs) and DVC (available separately) support it
<dash> DVC does more
<sjamaan> dvc is fancy
<dash> yeah and its bzr support is pretty good these days
<Solarion> vc is (hopefully) fine for now
<dash> Solarion: well, i'd just look at the manual for that
<Solarion> I may be stupid, but I'm having trouble figuring out how to do a basic pull and update the buffers
<dash> vc doesn't support pull
<Solarion> ah, well, that'd explain it. :)
<dash> vc was written when CVS was the hot new thing :)
<Solarion> yeah
<Solarion> it seems to quasi-support bzr, though, so it had me fooled
<Solarion> is there an ubuntu package?
<dash> sure
<sjamaan> Solarion: I guess it would work if you only use bound branches?
<dash> the operations that vc _does_ support, it supports on bzr
<dash> (where they make sense)
<sjamaan> (ie "centralised mode")
<Solarion> sjamaan: I don't think so
<Solarion> maybe I fail to distinguish between bound and checkout
<sjamaan> no, that's the same
<Solarion> then no. :)
<Solarion> at least, not that I can tell
<sjamaan> clone creates an unbound copy, checkout creates a bound copy of a branch
<sjamaan> VC has all the main concepts then, no?  commit, update, log
<sjamaan> Those work when operating on a bound branch
<sjamaan> (not that I've tried this though :) )
<Solarion> C-x v m?
<Solarion> to just "Picku p any recent changes from the repository without trying to commit your own chagnes"
<Solarion> "Sorry, merge-news is not implemented on Bzr"
<sjamaan> ic
<sjamaan> Well, too bad :)
<Solarion> y8eah
<Solarion> DVC it is
 * Solarion doesn't want to manually update all the buffers
<sjamaan> yeah, that sucks too
<nyu> is it possible to organize repositories using a directory structure?
<sjamaan> I always hated that about vc-mode
<nyu> bzr seems to want them all in the top dir
<sjamaan> Even with svn I use psvn or dsvn
<sjamaan> (but vc-mode is a nice way to do a "quick commit")
<sjamaan> (and then afterwards finding out you forgot to commit the other file and need to do it all again)
<sjamaan> :P
<LarstiQ> nyu: euh? you can use directory hierarchies just fine
<nyu> it complains that "parent of foo does not exist".  and --create-prefix doesn't seem to be accepted in branch command
<nyu> maybe I should branch locally, then push with --create-prefix ?
<LarstiQ> what is it you are trying to do?
<nyu> or perhaps just create the directory by hand
<nyu> LarstiQ: branch from . to a remote location
<nyu> . is a pull from svn, which I just pushed
<nyu> (to a remote bzr location)
<LarstiQ> nyu: `bzr push --create-prefix remote/location`
<nyu> LarstiQ: but then it's not a branch?
<nyu> or is it
<LarstiQ> it is
 * LarstiQ goes to bed
<nyu> but this uploads the whole thing?
<lifeless> if the branch is new, yes
<nyu> but I'm branching from something which is already in the server
<lifeless> server?
<nyu> I guess "branch <remote URL 1> <remote URL 2>" is what I'd like to do, but it complains about missing directory
<nyu> may I create that dir by hand?
<lifeless> nyu: is this an svn server?
<lifeless> or a bzr server?
 * lifeless is totally without context
<nyu> bzr
<lifeless> then branching locally and push --overwrite newoath is equivalent
<lifeless> uhm
<lifeless> if you're worried that it will upload a lot of data - it won't (unless you don't have a shared repo)
<lifeless> and if you don't have a shared repo, branching on the server would still have to do the same amount of work
<nyu> I was using the local tree I use for the svn->bzr transition, is that ok?
<lifeless> thats fine
<nyu> do I have a shared repo? ;-)
<lifeless> do you have any branches on the server yet?
<nyu> well, I'm trying to create the first one.  then I interrupted it mid-way because it seemed like it was uploading the whole thing
<lifeless> it has to :)
<nyu> but why?
<nyu> it's already there
<lifeless> you just said you don't have any branches on the server...
<nyu> oh, sorry
<nyu> I have something I would've called a 'trunk'
<lifeless> and its a bzr branch ?
<nyu> it's the result of bzr pull from svn && bzr push to bzr
<lifeless> ok
<lifeless> 'bzr info <url to trunk>'
<lifeless> pastebin that somewhere, and I can show you if you have a shared repo
<nyu> it says that's the "branch root".  svn one is in "related branches"
<lifeless> It should have provided several lines of output
<lifeless> you can anonymise the urls if you like, but I need to see the otuput
<nyu> nah, just these two
<nyu> wait
<nyu> lifeless: http://pastebin.com/m3a9c5661
<phoenixz> Hi, just started to test a little with BZR.. made a project, pushed it to a remote place, branched it to another computer.. Now I have the same project on 2 locations, I made changes on both places, now I want to merge the changes from both locations so that both locations have the same changes but how do I do that? bzr send seems to support only email?!  cant I send the changes directly?
<lifeless> phoenixz: bzr merge OTHER_URL; bzr commit
<lifeless> nyu: 'Standalone branch ' is the bit that matters
<lifeless> nyu: it means you don't have a shared repo
<lifeless> nyu: if you do this:
<lifeless> 'bzr init-repo --rich-root-pack sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub/trunk'
<lifeless> then you'll have a shared repo
<lifeless> you'll need to push up the contents once more, because the previous push is in a standalone branhc
<lifeless> so
<lifeless> bzr push sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub/temp
<lifeless> and after that pushing new branches will be fast
<fullermd> You probably don't want to actually init-repo at trunk/...
<lifeless> oh yes, bad cp
<lifeless> 'bzr init-repo --rich-root-pack sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub'
<lifeless> I'll note that sftp is fairly slow compared to our dedicated server, but savannah still see to be confused/limited
<lifeless> kfogel: ^
<asac> thx
<nyu> lifeless: ok, now I need to push again?  the old tree is still there
<kfogel> lifeless: reding
<kfogel> lifeless: savannah problem?
<lifeless> nyu: you need to push to a branch that isn't trunk, within the shared repo, to seed it with the content.
<lifeless> kfogel: last I heard they only support sftp for bzr
<lifeless> kfogel: which is really really inefficient compared to a client-server protocol
<nyu> lifeless: ok.  how do I replace the old trunk afterwards?
<lifeless> delete it, e.g. with lftp
<lifeless> then push to it again
<nyu> ah.  can't I just delete trunk already?
<lifeless> sure
<kfogel> lifeless: https://savannah.gnu.org/support/?106612#comment10 indicates they have smart server
<lifeless> they need a root signed ssl cert too
<lifeless> or we should ship their root cert
<nyu> lifeless: btw, when setting up a svn mirror, am I supposed to checkout or branch from it?
<nyu> I guess commits aren't going to be pushed back, so branch would be the way?
<lifeless> nyu: its up to you
<lifeless> nyu: if you want a mirror, I'd use checkout + update myself
<lifeless> as you shouldn't be committing in a mirror
<lifeless> kfogel: "Using the latest version of bzr with a ssh + smart server access requires a change in the current installation and a migration of existing bzr projects. This looks like the way to go in the long run but this will take more time than using the existing infrastructure. "
<lifeless> kfogel: I think you got the sense inverted
<nyu> lifeless: yeah, I don't want anyone to commit in the mirror.  they should branch instead
<kfogel> lifeless: oh, no I just read the first line.  but they are doing commit emails with inotify
<lifeless> nyu: exactly
<lifeless> nyu: what I'd do is maintaint he mirror as a checkout+update; and branch from the mirror to do work
<phoenixz> bzr does not support file copy?
<fullermd> phoenixz: Not as something that makes any notations in history, no.
<phoenixz> fullermd: so basically, a copied file is just a new file, as far as bzr is concerned?
<fullermd> Right.
<phoenixz> fullermd: okay... and just so that I get it.. I created tree A, added some files and dirs, committed, then pushed that to another server.. on the same computer in another directory, I bzr branch "serverpushurl", and had a branch of A, which I called B.. so far, so good, right?
<phoenixz> fullermd: then I made changes in A and in B, and to merge them, I basically would have to do cd A, merge ../B, correct?
<fullermd> Right.  So now you [technically] have 3 branches; one at A, one at B, one at SERVER.
<phoenixz> and then cd ../B, bzr merge ../A
<phoenixz> fullermd: ah, so bzr push also branches?
<fullermd> (note that you could have done 'cd .. ; bzr branch A B' instead of routing through SERVER there too)
<phoenixz> fullermd: but so, technically, how could I merge my changes back to the pushed branch? because that didnt work, somehow..
<fullermd> Well, you'll have to quantify "didn't work" a little more   ;)
<fullermd> Because that looks reasonably correct.
<phoenixz> fullermd: heheh, well, so I had A, pushed it to server (which is branching too, right?), lets call that C, then I bzr branch C on another location in my laptop, called that B
 * fullermd glares at his ringing phone.
<phoenixz> fullermd: so I have A, B and C (on the server)
<nyu> lifeless: btw, the example in http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html recommends --default-rich-root rather than --rich-root-pack.  I guess it needs updating?
<lifeless> nyu: no
<phoenixz> yeah, take that call :) I'll keep on writing..
<lifeless> nyu: you did the conversion with an older bzr
<nyu> lifeless: ah, ok
<phoenixz> fullermd: now, I make changes to A and B.. I can merge changes from A to B and from B to A.. but how do I send those changes to C??
<lifeless> nyu: I used the exact matching format that 'bzr info' told me you have your trunk in
<nyu> lifeless++
<lifeless> nyu: otherwise bzr would have had to do data conversion - and while converting to 2a (which is what default-rich-root is now) is a good thing, I sense you're just getting started
<nyu> pretty obvious that I am ;-)
<fullermd> phoenixz: 'k, sorry.  You'd use 'push' to push them up.
<fullermd> push is almost the complement to pull, except that (as in your first steps) push also creates the target branch if it doesn't already exist.
<phoenixz> fullermd: and if I Im in B and I send changes from A to C and I want to receive those changes in B.. ? how would I do that then?
<lifeless> vila: jam: spiv: - on tripit?
<phoenixz> fullermd: sorry for all the bothering :) just trying to gettit
<fullermd> phoenixz: Grr.  You people are going to make me actually dig all that up...
<fullermd> phoenixz: Lemme dig through my logs.  I had a long discussion about roughly that with another guy some weeks ago...   I've been threatening to put it up somewhere for reference.
<phoenixz> fullermd: Hehehe, sorry.. Its just that bzr does seem to do things a bit different than SVN.. its not hard to grasp, its hard to change learnt stuff...
<fullermd> Yeah, the basic units you work with are a bit different.
<phoenixz> fullermd: exactly, thats my difficulty now, Im looking though pink svn glasses...
<fullermd> phoenixz: Editing...   will take me some minutes.
<phoenixz> fullermd: sure, thanks!
<fullermd> phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutPushPullMerge
<fullermd> phoenixz: There was followup discussion to that about Repositories.  I'm editing that now.
<nyu> lifeless: ok, finished with the re-push.  still complains about non-existant parent dir though
<nyu> I guess I can mkdir it by hand?
<nyu> (within the shared-repo directory, of course)
<sven_oostenbrink> fullermd: thanks for the document, reading it now!
<sven_oostenbrink> fullermd: sorry for the late reply, had some network problems here
<fullermd> Hey!  No nick changing on me!  10 minutes in the penalty box!
<RenatoSilva> my question : http://pastie.org/665423
<RenatoSilva> sorry http://pastie.org/665941
<sven_oostenbrink> fullermd: just a question... the .bzr directory basically is the repository? and then the files  along side it the working tree?
<fullermd> The .bzr/ directory is all the bzr meta-data.  Any given .bzr/ dir may have a Repository, or a Branch, or [the internal tracking files for] a Working Tree.
<fullermd> Or any combination of the above.
<fullermd> In SVN terms, it can be the repo, or the equivalent of the stuff in .svn/ dirs in a checkout, or both.
<sven_oostenbrink> fullermd: gottit..
<sven_oostenbrink> fullermd: other question..
<sven_oostenbrink> fullermd: There is A, pushed to B, branched to C
<sven_oostenbrink> fullermd: So I could say.. B is the trunk, A is my working copy, C is working copy for person C..
<sven_oostenbrink> now, A makes changes, C makes changes..
<sven_oostenbrink> fullermd: to move those changes to B, A does bzr push
<sven_oostenbrink> When C does a push, A's changes will NOT be overwritten, right?
<rockstar> sven_oostenbrink, no.  In fact, C can't commit unless they are up to date.
<sven_oostenbrink> fullermd: thats to say... when I push to a location, All revisions (each revision being a collection of changes) will be pushed to that location.. If that location contains nothing yet, it will practically be a copy of my local stuff, right?
<fullermd> rockstar: No, they're branches, not checkouts.
<fullermd> sven_oostenbrink: When C tries to push, it will tell him he's out of date.  And he'd have to merge before he could push.
<rockstar> fullermd, yeah, I think there's some confusion there.
<sven_oostenbrink> fullermd: so C first would have to do a pull, right?
<fullermd> (this also then leads into a discussion about how you'd actually probably NOT wnat to work that way, since it destroys the mainline.  But let me edit ONE big thread at once!)
<rockstar> fullermd, sven_oostenbrink, he won't be able to just push if A has pushed already.
<sven_oostenbrink> fullermd: C would have to do bzr pull or bzr merge?
<rockstar> He'll have to do a merge -> push, because the branches are diverged.
<fullermd> sven_oostenbrink: No, he'd have to merge.  He couldn't pull since he has changes the far side doesn't.  See the merge discussion about halfway down that page.
<fullermd> You can imagine that instead of that guy working on both Linux and Windows, there are just two people, one on each.
<sven_oostenbrink> fullermd: so if C would do either push or pull, he'd get a message he'd have to merge first..
<rockstar> sven_oostenbrink, yes.
<sven_oostenbrink> ok, perfect..
<sven_oostenbrink> fullermd: rockstar: another question.. I did a push to another server over sftp:// I checked the destination, and it was a directory with a .bzr directory in it. This means that, bzr push basically sends all revisions to the remote location that the remote location doesn't have yet, and if the remote location has nothing yet, it will just send all revisions I have.. is this correct?
<rockstar> sven_oostenbrink, correct.
<sven_oostenbrink> ok, and when I have changes to merge, I can also send them by email (bzr send) and then another person receiving htat mail, can apply then with bzr patch ?
<fullermd> 'bzr merge' more like.
<fullermd> You could also just put your branch somewhere they can see, and they can merge directly from it.
<sven_oostenbrink> ah, gottit..
<sven_oostenbrink> fullermd: now just one other thing.. What, in bzr, is the difference between a checkout and a branch? I mean, in SVN / SVK, a branch basically is a copy. period. A checkout is creating a working tree.. but here, I bzr branch or bzr checkout, both create a WT..
<sven_oostenbrink> fullermd: if I get it correctly
<sven_oostenbrink> fullermd: then if I have A in bzr, I push that to B.. Then if I work on location C, if I bzr branch it, I have branch C.. if I just checkout it, I will be on location C but working on branch B... ? irght?
<mwhudson> argh
<dash> sven_oostenbrink: the difference is just that a checkout is bound to a remote branch
<fullermd> sven_oostenbrink: Roughly the same, actually.  Just think of 'branch' as making a branch and then checking it out.
<mwhudson> lifeless: hi
 * fullermd stabs dash until he stops saying 'bound branch'.
<dash> sven_oostenbrink: meaning that checkins will first make sure the changes can be applied to the remote branch before applying them locally
<dash> fullermd: I didn't say "bound branch"!
<fullermd> You said half of it.  That's at least 75% as bad  :p
<sven_oostenbrink> fullermd: understood..  but then, if I checkout from a branch on another computer.. when committing, I then MUST have network access to that computer, no? while bzr branch would just place everything locally on my computer.. right?
<dash> sven_oostenbrink: if you don't have network access you can do 'bzr commit --local'
<fullermd> Right.
<dash> and then push/merge later
<fullermd> And never commit --local.  'cuz then we'll have another giant fooforah when it screws you.
<dash> fullermd: What
<dash> fullermd: Where is this documented
 * sven_oostenbrink hates deez pink SVN glasses.. its easy, but so hard to get it..
<dash> sven_oostenbrink: the third mode is a lightweight checkout, you get one via "bzr co --lightweight"
<dash> sven_oostenbrink: this doesn't store any local revisions, it's like an svn checkout in that regard
<fullermd> dash: In a whole lot of mailing list threads and long IRC discussions.
<dash> fullermd: so what's wrong with it
<sven_oostenbrink> dash: Id prefer just bzr branch.. just work on my own branch, all alone, nobody bothering me.. when I'm finished,  I merge my changes to a trunk
<dash> sven_oostenbrink: that works
<fullermd> For one thing, various bugs cause it to totally hork you when you have local commits and uncommited changes and update.
<fullermd> sven_oostenbrink: It's very common to use checkouts for the trunk.
<dash> fullermd: Oh. :(
<dash> yeah I switched to a checkout for my local copy of trunk
<fullermd> In a broader sense, local commits in a _checkout_ make no sense.  That's more a 'bound branch' thing.
<dash> fullermd: what's the difference
<dash> I never knew those were distinct
<fullermd> sven_oostenbrink: So instead of merging trunk and pushing your branch over, you merge your branch into trunk and commit.  That way you don't disturb the mainline.
<fullermd> Well, they're not, in bzr.  That's kinda the problem   :p
<dash> fullermd: I am utterly confused
<dash> fullermd: what is the problem?
<fullermd> The difference is that in a _checkout_, you have one branch, and a WT for it.  In a _bound branch_, you have TWO branches, that you generally want to keep in sync.
<dash> Er
<fullermd> The desired semantics of the two cases are subtly different in many ways.
<dash> i thought that's what a lightweight checkout was?
<sven_oostenbrink> fullermd: sorry, didn't get that last one.. merging trunk and pushing branch over, or merge branch into trunk.. whats the difference?
<fullermd> Right now, bzr has _neither_.  It has a chimera that's some of both.
<dash> Okay
<sven_oostenbrink> fullermd: probably totally logical, but not seeing it for a second here.. :)
<fullermd> sven_oostenbrink: It has to do with the way revisions are arranged in history.  Ask me later.
<sven_oostenbrink> ok
<dash> I think I'm going to stop thinking about this and go back to being ignorant
 * sven_oostenbrink welcomes dash...
<fullermd> Light and heavy checkouts _should_ act exactly the same, just with heavies having a local cache.  Bound branches should act differently from either.
<fullermd> But as-is, we have heavy checkouts sometimes acting like bound branches (and sometimes acting in ways more like a checkout)
<fullermd> The two cases are so MUCH alike, that it's easy and natural (and what happened) to conflate them.  But it's troublesome because they're not really the same thing.
<lifeless> nyu: push --create-prefix
<lifeless> mwhudson: hi
<lifeless> mwhudson: are you on tripit?
<mwhudson> lifeless: i don't think i know what tripit is, so probably not
<lifeless> mwhudson: social flight tracking
<spiv> lifeless: I'm not on it
 * mwhudson is once again horrifically confused by non-ascii characters in urls
<lifeless> spiv: does your -suffix@puzzling.org work dynamically?
<lifeless> or do you need to set them up?
<sven_oostenbrink> dash: another one, does bzr also do binary files, like (small) images
<sven_oostenbrink> ?
<fullermd> sven_oostenbrink: http://bazaar-vcs.org/MatthewFuller/AboutUsingRepositories   is a followon to that previous discussion, talking about using shared repos (and some other stuff mixed in I didn't bother cleaning out)
<dash> sven_oostenbrink: sure, files are files :)
<fullermd> It's hard to get a diff of them, of course   ;)
<lifeless> fullermd: I don't really get the differences you postulate for bound/heave
<fullermd> lifeless: Yeah, I'm gonna make a wiki page of it in, like, 20 years when I recover from making them today   :p
<lifeless> spiv: mwhudson: you should both have tripit invites
<mwhudson> it seems if i do bzr push bzr://localhost/b%C3%A9 the server raises an exception and the client blows up translating it :(
<lifeless> mwhudson: would you like to go through whats happening in more detail?
<fullermd> lifeless: Bound branches can have different nicks, checkouts can't (doesn't make sense).  Bound branches can diverge, checkouts can't (doesn't make sense).  Checkouts should be sync'd to the remote with update, bound branches should use pull.  etc etc etc.
<lifeless> fullermd: are you listing bugs or conceptual expectations?
<fullermd> Well, the latter, which means them showing up is the former   ;)
<lifeless> fullermd: I wouldn't expect pull on a bound branch to sync it to the master
<lifeless> fullermd: I'd expect that to change the master
<mwhudson> oops, now i have two tripit accounts it seems...
<lifeless> mwhudson: heh, you can combine them I think
<mwhudson> yeah, i'm sure
<fullermd> sven_oostenbrink: (that discussion of usage of repositories may be good for you coming from svn)
<mwhudson> lifeless: yes i would like to talk about what's going on, but first i think i'm going to have lunch
<mwhudson> lifeless: talk to you in a bit?
<spiv> lifeless: yes, the suffix is automatic, although I prefer @bemusement.org these days.
<fullermd> lifeless: Maybe.  But 'update' shouldn't updating the local branch to the other branch.  Update is for WT<-Branch, not Branch<-OtherBranch.
<lifeless> mwhudson: ok
<lifeless> spiv: puzzling/bemusement :P
<lifeless> fullermd: as the author of update, I take some exception to your definition
#bzr 2009-10-23
<lifeless> fullermd: there is one particular vicious bug, which abentley suggested a great fix for
<lifeless> but noone has executed it
<fullermd> I take exception to commands doing totally different things.  Special cases are bad.
<lifeless> fullermd: I agree with you
<fullermd> Especially when every other VCS has an 'update' command that goes between a WT and its Branch (or whatever equivalent that VCS has)
<lifeless> fullermd: well, git doesn't, hg doesn't do wt <-> branch (it does something different again), svn and cvs's updates are behaviourally identical to bzr's
<lifeless> (modulo the 'check out new files' aspect.
<fullermd> Well, git re-abuses 'checkout' for that.
<fullermd> And hg's update DOES update the WT to something based on the branch.
<fullermd> Anyway.  I totally don't have the time or the energy for the whole co/bb discussion.
<lifeless> it changes the working copy to  a revision
<lifeless> fullermd: ok
<lifeless> fullermd: I want to get to the bottom of it some day
<fullermd> sven_oostenbrink: Are you going to be around for a while yet?
<lifeless> I think we should fix the polish bugs we have first
<fullermd> Oh, totally.  I wouldn't keep grumping about it if I didn't want to get it dealt with eventually   :)
<lifeless> :P
<fullermd> I certainly agree that some of the behaviors (like that two-merge-update) are flat-out bugs, and need to be fixed irregardless of other issues.
<fullermd> sven_oostenbrink: I have some discussions of 'mainline' I can put together and post up, but it's 18:00 and I reallyseriouslydesperately wanna go have lunch.  So it'll be a while.
<lifeless> mwhudson: so at this point you forward your confirmation mail to plans@tripit.com and magic happens
<phoenixz> fullermd: another thing.. since this is a DVCS.. if I want to have a backup of my work, I only need to have a copy of the .bzr directory, right?
<fullermd> phoenixz: Yeah.  Though realize that every branch (or at least, every shared repo) is a 'backup' too.  We commonly back up branches via 'push'   ;)
<fullermd> phoenixz: See above about mainline.
<dash> phoenixz: to emphasize this fact, note that pushing to a remote branch does not create or modify the remote branch's working tree. :)
<phoenixz> gottit, get some food, don't want you to starve to death, who else will help me out here? :)
<fullermd> Somebody else, who won't get into an argument with lifeless in the middle of it?   8-}
<phoenixz> dash: yeah, I was basically talking about branches with WT that would not contain changes..
<phoenixz> heheh
<fullermd> phoenixz: BTW, you say that AboutUsingRepositories link as well, yse?
<phoenixz> fullermd: yeah, saw it, will give it a read in a moment
<Peng_> jam: I might not have recompiled all of the extensions before the "merge" error. I'll see if I can reproduce it.
<Peng_> jam: Ehh, I'll follow up in an email.
<Peng_> jam: Short answer: I can't reproduce the errors. Looks like I did forget to recompile.
<lifeless> james_w: around?
<jfroy|work> jelmer: is there a way to push to a local (e.g. file) svn repository with bzr-svn?
<jfroy|work> is seems there's no way to separate the branch name / path from the repository URL / path
<wgrant> jfroy|work: WFM with file:// URLs.
<jfroy|work> WFM?
<wgrant> Works for me.
<jfroy|work> mmm
<wgrant> And it also seems to work with just a normal absolue path.
<jfroy|work> well yeah, if you want to push to another bazaar branch
<jfroy|work> I'm trying to push from bzr to a local svn repositoru
<jfroy|work> *repository
<wgrant> How does it complain when you try? It works fine for me.
<jfroy|work> not a branch or directory already exists
<jfroy|work> Ahh
<wgrant> That's from 'bzr push /path/to/repo/path/to/subpath'?
<jfroy|work> dpush fails, push works
<jfroy|work> (I was trying to use dpush)
<wgrant> Ahh.
<jfroy|work> Ok, that's a new one
<jfroy|work> bzr: ERROR: [Errno 24] Transaction cleanup failed
<wgrant> New to me also.
<mwhudson> lifeless: i wonder if tripit is going to understand the air nz itinerary in pdf i just mailed it...
<lifeless> possibly :P
<mwhudson> hm, it seems like it did, but now i can't find it online
<mwhudson> ah, just took a while
<lifeless> 'magic'
<jfroy|work> so I just don't see how to use dpush
<jfroy|work> (I really don't want the metadata)
<lifeless> jfroy|work: file a bug :)
<jfroy|work> it won't create the branch if it doesn't exists, and when it does, its error message stating I should pass --overwrite ends in failure because it doesn't have an overwrite option!
<lifeless> mwhudson: indeed, it did better than for me; it thinks I stay in chch :P
<lifeless> I guess I should tell them somehow
<lifeless> which is odd vause their detailed view is right
<mwhudson> it even coped with the hotel confirmation
<mwhudson> lifeless: i think they might be using memcache or something a bit much
<mwhudson> taking the "eventually consistent" to extremes
<lifeless> mwhudson: we have longer lag than you saw, I think
<jfroy|work> well, having more luck pushing to a svnserve-ed repository
<igc> maxb: re storing git refs in bzr nicks, I'd like to explore the idea. Storing the value exactly probably isn't the best choice but having a deterministic mapping is a great idea
<lifeless> igc: do you mean the object sha, or the human reflog name?
<igc> lifeless: human name
<Peng_> Either something odd has happened, or lp:~jameinel/bzr/2.1-static-tuple-chk-map has really helped Loggerhead's memory usage.
 * igc food
 * fullermd wouldn't rule out 'both', just on GP   :p
<jfroy|work> so I don't understand fast-export :|
<jfroy|work> no matter what bzr branch I export, it always seems to re-import it as trunk
<jfroy|work> ahhh, 0b
<jfroy|work> *-b
<jfroy|work> magic
<jfroy|work> do I need to re-export marks (whatever those are) if I have more than 2 branches to export and import?
<jfroy|work> or do I need --export-marks only for the first export-import, and only need to use --import-marks for all subsequent export-imports?
<mwhudson> spiv, lifeless: so i think the smart server doesn't handle unicode paths very well
<lifeless> mwhudson: backtraces, details, please.
<mwhudson> lifeless: run bzr serve --allow-write somewhere
<mwhudson> bzr push bzr://localhost/b%C3%A9
<mwhudson> --> http://pastebin.ubuntu.com/299462/
<mwhudson> on the server side, Transport.__init__ is seeing a 'base' of filtered-41598608:///b\xc3\xa9/
<lifeless> yup thats wrong
<mwhudson> sigh
<mwhudson> i think sftp has different bugs like this :(
<mwhudson> is there some way i can see what's going over the wire easily?
<mwhudson> huh nosmart+bzr:// works finer
<mwhudson> -r
<lifeless> tcpdump
<fullermd> phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutMainline
<mwhudson> the path is sent across the wire unescaped
<mwhudson> http://pastebin.ubuntu.com/299476/ fixes things, maybe
<Peng_> This "pretend the screen is 65,536 columns wide" thing is causing problems. :\
<Peng_> Including test failures. :D
<spiv> mwhudson: hmm
<Peng_> (And yes I'll file bugs, once I verify that that's what's responsible.)
<spiv> mwhudson: seems plausible I guess
<lifeless> mwhudson: in fact u1 have rolled back to paste, spawning was too much fail :)
<spiv> mwhudson: I wonder about paths sent in responses, but one problem at a time...
<Peng_> "u1"?
<lifeless> Peng_: ubuntuone
<mwhudson> lifeless: ugh
<mwhudson> lifeless: oh well, my business with other things saved me some pain there i guess
<mwhudson> spiv: uh yes i guess so
<Peng_> How should environment variables be handled in tests? If you change one, will it be automagically fixed when the test ends?
<mwhudson> spiv: which smart verbs respond with paths?
<mwhudson> Peng_: there is certainly some support in testcase for that
<lifeless> Peng_: many common ones are automatically saved and restored
<Peng_> "common ones"?
<lifeless> plugins path, email, HOME, editor etc
<lifeless> see bzrlib.tests
<Peng_> Ah.
<Peng_> They're fixed after every test? So it's okay to mess with them?
<lifeless> the set that are isolated, yes
<lifeless> those that aren't, you should call the isolation helper on first
<arjenAU> ahoy my beloved bzr magicians
<lifeless> ahrr
<arjenAU> i come to you in search of enlightenment.
<arjenAU> lifeless: stay put you, i'm a happy user!
<lifeless> I was doing pirate
<arjenAU> I need something akin to a hardlink in a branch
 * fullermd is a couple doves short of a sixpack.
<lifeless> in the ahoy theme
<arjenAU> oh righty
<arjenAU> lifeless: ideas?
<arjenAU> so I need a file in 2 or 3 directories, and keep 'em in sync. no risk of divergence. a straight link would do it, if bzr can grok that.
<lifeless> arjenAU: bzr can version symlinks
<arjenAU> ok so I'd have a main and secondary... that would do. just not hardlinks? and I presume the symlinks break on windows or did you use the magic API to use it on NTFS?
<arjenAU> i don't need win, just curious ;-)  NTFS supports symlinks but win doesn't use 'em
<lifeless> we degrade on windows
<lifeless> there is a plugin
<lifeless> to do something more than we do
<arjenAU> lifeless: no worries. ok so symlinks. ok out of the box or do I need to set anything to make this jive?
<lifeless> ln -s foo bar
<lifeless> bzr add
<arjenAU> sounds sane as usual. ok
<arjenAU> then, can I get conflicts on a bzr pull if I didn't have any local changes that weren't pushed?
<lifeless> sorry, rephrase that wont
<lifeless> s/wont/one/
<arjenAU> euh?
<lifeless> I don't understand the question :)
<arjenAU> I do a bzr pull and I get conflicts, even though I have no local divergence afaik
<lifeless> you may have local changes
<lifeless> such as files that are ignored in a subdirectory
<arjenAU> not on those files.
<lifeless> or uncommitted edits to a file
<arjenAU> i've seen this a few times ove rlast week or so. using 2.0
<arjenAU> well jaunty ppa
<arjenAU> it's honestly files I have not touched.
<lifeless> could you, for a while, do 'bzr st; bzr pull'
<lifeless> and when it happens file a bug with the output of those two commands - the order matters ;)
<spiv> mwhudson: lots of them
<arjenAU> lifeless: rigthy. can I nicely back out of the current state totry that again. revert?
<jam> lifeless: I don't remember it happening for files, but if you delete a directory, then you can get a conflict if there are temp files lying around
<jam> Peng_: I would like to think 'static-tuple-chk-map' helps mem, but I wouldn't have expected it to effect loggerhead
<lifeless> jam: yes, thats why I mentoned ignored iles in subdirs
<Peng_> jam: Hi. :)
<lifeless> arjenAU: no, because we don't have the exact state any more
<jam> lifeless: I'm currently trying to get meliae to perform 'compute_referrers' on a 500MB dump file w/ 5.6M objects.
<spiv> mwhudson: list_dir obviously, but also I think various opening verbs can e.g. BzrDir.find_repositoryV3 and Branch.get_config_file and probably several others.
<jam> The problem is that a dict holding 5.6M entries is 200MB by itself...
<Peng_> jam: Well, Loggerhead does read data that comes through bzrlib.chk_map.
<jam> Peng_: for iter_changes?
<arjenAU> lifeless: ehm. so to get rid of the mess, I did bzr revert then bzr clean-treeto be sure I didn't have build leftovers. then bzr pull says no rvisions to pull.... so it's just the local checkout that's the issue now, right? what command? or did I go foul somewhere
<Peng_> jam: No clue. I know it hits iter_ancestry, but I forget how.
<lifeless> arjenAU: well, thats the thing, we don't have the state that caused the conflicts
<lifeless> arjenAU: so we need to wait for it to happen again
<lifeless> arjenAU: thus my asking you to do 'bzr st; bzr pull' from here on in, to capture more detail when it happens again.
<mwhudson> spiv: list_dir agrees on the encoding with that via a local transport fwiw
<jam> arjenAU: so if you get conflicts, 'bzr revert' should restore you to the pristine state, however, as lifeless says, determining what got you there in the first place would be useful
<arjenAU> yes I get that, but I don't understand the situation I now have in my tree.
<mwhudson> >>> get_transport('bzr://localhost').list_dir('.') == get_transport('/home/mwh/tmp').list_dir('.')
<mwhudson> True
<spiv> That's good.
<Peng_> jam: Loggerhead caches a copy of the revision graph. . .
<jam> mwhudson: yeah, I would use list_dir() as a guideline for how paths should be encoded
<jam> Peng_: revision graph comes from the indices
<jam> I thought it also cached the per-revision deltas
<mwhudson> yeah, it does
<jam> and that could certainly come from chk_map
<mwhudson> though not in ram very much i think
<arjenAU> jam: if you need graph magic, look at http://openquery.com/blog latest entry, you may find useful.
<spiv> mwhudson: oh, and of course the various error responses that contain paths
<spiv> mwhudson: e.g FileExists
<Peng_> jam: FYI, I just ran "bzr selftest" on bzr.dev + 2.1-static-tuple-chk-map + statictuple-pickling, and there were no failures (related to ST, anyway)
<mwhudson> argh
<mwhudson> now get_transport('bzr://localhost').mkdir('b%C3%A9bbb') creates a directory with the escaped path :(
<spiv> mwhudson: :(
<spiv> mwhudson: so clients today are sometimes sending utf-8 bytes and sometimes sending urlutils.escape'd?
<mwhudson> spiv: it seems that way
<mwhudson> spiv: at a guess bzrlib.remote and bzrlib.transport.remote are different
<spiv> mwhudson: is it varying by verb only?
<mwhudson> spiv: not sure
<mwhudson> spiv: actually
<spiv> If it's just a difference between VFS verbs and not, that's not too bad
<mwhudson> spiv: what do you mean by that question? :)
<spiv> I mean, for every verb X, do clients consistently send paths a particular way?
<mwhudson> spiv: i don't think there are cases where the same verb is called with varying levels of escaped-ness
<igc> lifeless, jam: any hints on where I should look to solve bug 441125?
<spiv> Right
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125
<mwhudson> spiv: right, yes, afaik
<spiv> That's what I'd expect (and hope)
<lifeless> igc: isn't it a dupe?
<spiv> If so, that's not insurmountable.
<igc> lifeless: not sure. It's well beyond my knowledge area
<spiv> Especially if the split is exactly VfsRequest/everything-else
<spiv> mwhudson: so bzrlib.remote calls something that seems to intentionally unquote the url before transmission
<mwhudson> spiv: if you say so, i've become a bit lost among the various objects & methods
<jam> lifeless: so if I understand the exception, it is triggering because an inventory is referring to a file key  (file_id, revision) which is *not* present in the repository
<jam> sorry igc^^
<jam> which is certainly bad-mojo
<jam> is this a stacked branch?
<igc> jam: yes
<lifeless> spiv was fixing a bug like this yesterday
<lifeless> or so
<jam> and does reconcile fail on the base?
<igc> jam: reconcile on the trunk works ok
<spiv> mwhudson: specifically RemoteBzrDir._path_for_remote_call invokes _SmartClient.remote_path_from_transport invokes the medium's remote_path_from_transport
<igc> jam: it's only on the stacked branch it fails
<spiv> mwhudson: both implementions of that make a urlutil.relative_url and urlutils.unquote it.
<igc> jam: branching from there gives a branch on which reconcile works
<jam> igc: so one possibility is to probe through all of the inventories to find one that references this text key
<igc> jam: can comparing the log -v -p on the orginal branch and the created branch gives the same results
<jam> it is certainly possible that this inventory is 'unreferenced'
<spiv> mwhudson: where bzrlib.transport.remote uses RemoteTransport._remote_path which appears to rely on whatever Transport._combine_paths does
<jam> (or, not in the ancestry)
<mwhudson> spiv: ah right
<jam> _text_refs is built up by walking *all* chk pages, IIRC
<jam> not  just chaining from revisions => inventories => chk_pages
<mwhudson> spiv: so a cheap hack would be to have VfsRequest override translate_client_path to unescape again?
<jam> hold on... maybe not. Maybe only ones that are referenced via an inventory
<spiv> lifeless, jam, igc: The bug lifeless is thinking of that I fixed is bug 437626, I think
<ubottu> Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix committed] https://launchpad.net/bugs/437626
<jam> it looks like unreferenced ones are just streamed out directly, without being parsed.
<mwhudson> spiv: https://code.edge.launchpad.net/~mwhudson/bzr/escape-smart-server-requested-paths fwiw
<spiv> lifeless, jam, igc: which didn't affect 2a repos, if that helps
<igc> spiv: thanks
<jam> however, that doesn't mean we have the *revision* for that inventory
<igc> (it does)
<lifeless> jam: unrefed ones shouldn't be copied though
<lifeless> jam: except for the adjacent ones, and those we don't want the texts for
<spiv> mwhudson: I think so
<igc> jam, lifeless: so does that imply reconcile is looking at extra data it doesn't need to?
<spiv> mwhudson: or not apply your escaping
<spiv> mwhudson: whatever works is fine by me, though :)
<lifeless> igc: possibly yes
<mwhudson> spiv: is it sane to have vfs requests have different rules than the others?
<spiv> mwhudson: we'll need tests, obviously, and I should add some text about this to network-protocol.txt
<jam> igc: it is possible to have inventories in the repository that aren't referenced by the branch. it is further possible for those to be borked.
<spiv> mwhudson: well, they already do AIUI?
<jam> hence why I suggested you walk all inventories and find out which one thinks it knows something about the given file_key
<mwhudson> spiv: i guess
<mwhudson> fixing it would require defining a whole new tranche of verbs
<spiv> mwhudson: the long term plan is to remove the vfs requests anyway, so if there's cruft that's restricted to just them I'm fairly comfortable with that
<jam> for inv in b.repository.iter_inventories([k[0] for k in b.repository.inventories.keys()]):
<spiv> mwhudson: and as far as cruft goes this is pretty minor, happily.
<jam>   if file_key in inv:
<mwhudson> spiv: true enough
<jam>     print inv.revision_id
<mwhudson> spiv: where are the vfs verbs tested?
<mwhudson> just in the generic transport tests applied to RemoteTransport?
<spiv> mwhudson: mainly those, yeah
<spiv> mwhudson: there's also a little bit SmartServerRequestHandlerTests in test_smart_transport
<spiv> mwhudson: most of the newer verbs are more rigorously tested in test_smart
<mwhudson> spiv: i guess an appropriate test for this is to have a RemoteTransport onto a directory, mkdir('%C3%A9'), and then check list_dir via a LocalTransport matches?
<mwhudson> spiv: can i get you to write that? :-)
<igc> jam: thanks for the code snippet. That saved me ages I'm sure ...
<igc> jam: I get 202 matches on that file-id and the rev-id is one of them
<igc> i.e. rev-id failing in the KeyError exception
<igc> jam: make that 280 matches sorry
<spiv> mwhudson: I suppose so, although it's not my ideal way to spend a Friday afternoon ;)
<mwhudson> argh
 * mwhudson is all confused again :(
<spiv> mwhudson: but yes, that sounds like a good test to have
<spiv> mwhudson: oh, except I'd back it onto a MemoryTransport :)
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/458762
<ubottu> Launchpad bug 458762 in bzr "smart client inconsistent about escaping of paths to the surprise of the smart server" [Undecided,New]
<mwhudson> spiv: can i assign that to you?
<spiv> mwhudson: no
<spiv> mwhudson: because I just did :)
<mwhudson> spiv: ok :)
<spiv> mwhudson: thankks
<mwhudson> spiv: np
<mwhudson> spiv: i'm glad the problem turned out to be fairly simple in the end
<jkakar> lifeless: I've written a command to upgrade Bazaar branches on Launchpad.  I'm not sure it's working.  Do the formats here make sense: http://pastebin.ubuntu.com/299569/
<lifeless> jkakar: lp has a bug where it doesn't update the reported format
<lifeless> jkakar: bzr info nosmart+<url>
<jkakar> lifeless: Ah ha, I was wondering about that.
<jkakar> lifeless: Woot: http://pastebin.ubuntu.com/299574/
<lifeless> its been upgraded :)
<jkakar> It's probably a good time to make the first release of AutoLP.
<lifeless> autolp ?
<jkakar> I want a place to collect Launchpad commands.  I already have several scattered about.
<lifeless> lptools
<lifeless> https://code.edge.launchpad.net/lptools
<lifeless> and there is another one as well that the lp folk made
<lifeless> (that meaning rockstar/jml/abentley I think, though I'm hazy)
<jkakar> I didn't know about lptools, will check it out, thanks.
<lifeless> it has a review-notifier which is nifty
<lifeless> on my TODO to package it
<wgrant> Might want to add lptools to the lpx project group.
<lifeless> lpx?
<lifeless> surely launchpad ?
<wgrant> A new officially-sanctioned project group for launchpadlib-using applications.
<jkakar> Launchpad Extensions, similar to the tx project group for Twisted.
<lifeless> mmm
<lifeless> seems totally weird to me to not use the launchpad group
<wgrant> They are not part of LP.
<lifeless> so?
<wgrant> To they should not be part of LP.
<wgrant> s/To/So/
<lifeless> you're repeatin yourself but not making a case
<wgrant> They are not part of LP in the real world, so why should they be part of LP on LP?
<lifeless> the launchpad project group isn't just launchpad.net
<jkakar> I like having a way to separate "Launchpad the moving parts of the service" from "The set of tools that work with Launchpad".
<lifeless> it needs to be shrunk if thats what its meant to be an exact match for
<lifeless> jkakar: I can see that
<lifeless> project tags FTW
<jkakar> Yeah. :)
<wgrant> Right. lpx is brand new, and things haven't been sorted out yet.
 * lifeless sighs over data models
<lifeless> so limiting
<igc> lifeless: the reconcile problem seems to come down to parent_map(text_refs) not finding all parents
<igc> lifeless: so maybe we aren't collecting things correctly for a stacked branch?
<lifeless> igc: reconcile runs in unstacked mode
<lifeless> igc: because it has to enforce 'this repo is internally consistent'
<igc> groupcompress_repo.py, line 1289
<igc> text_refs has 5024 items
<lifeless> igc: do you perhaps mean 'reconcile is not fully up to date with the setup of stacked repositories'
<igc> parent_map returns a dict with 4875 keys
<igc> I may mean that, still fumbling my way through
<igc> lifeless:^^^
<lifeless> :)
<lifeless> I'm done for the day btw
<lifeless> should have been, oh, 3 hours back. But I'm bad at 8 hour days
<igc> lifeless: sorry. not great timing I know
<igc> lifeless: I'll update the bug report and look more on Monday
<lifeless> kk
<lifeless> win 32
<vila> hi all
<vila> lifeless: win 32... 2000 ? XP ? Vista ? :-P
<igc> hi vila
<lifeless> wgrant: its a shame that bzr, and various things with lp support won't ever be able to be in lpx :P
<bialix> privet
<wgrant> lifeless: This is why we need project tags.
<bialix> oh! my favorite subject: project tags
 * bialix looks at irclogs
<lifeless> wgrant: I know :)
<lifeless> hi vila
<igc> lifeless: I'm seeing *much* better memory usage having dropped the cache size down to 1 by default, along with the latest bzr trunk with jam's improvements
<igc> lifeless: you may want to retry a netbeans import when you get a chance
<lifeless> igc: I'll teach you the cache mantra eventually ;)
<igc> it helped at the time :-)
<igc> but I'm really pleased it's mostly not needed now
<lifeless> hows the performance?
<igc> better!
<lifeless> good
<lifeless> gc costs a lot :)
<igc> well, better or medium to large projects
<igc> on
<igc> it's slower on smaller projects but not by a big amount
<spiv> igc: nice
<igc> spiv: well, turning off a cache is simple - jam and you guys did the hard yards making the core fast enough that it wasn't helpful!
<igc> spiv: but thanks :-)
 * igc dinner
<lifeless> vila: forward your trip booking mail to plans@tripit.com, should create an itinery :)
<vila> lifeless: yup, I'm trying to sort out the email used first, but thanks for the t[r]ip :)
<vila> lifeless: next time, treat me as spiv but with a '+' instead of '-' !
<loxs_wrk> what do I need to do in order to revert some file to the state from the previous revision
<lifeless> vila: I wasn't sure if they were magic oryou had to configure it
<lifeless> loxs_wrk: bzr revert -r -2 FILE
<vila> lifeless: '+' is the "standard" magic char, spiv cheats :-P
<vila> bah, I can't find the merge accounts anymore, will just delete the othr
<vila> bug 353370 upsets babune a lot, do you I need to submit a proposal to revert revnos 4766 and 4764 or can I just go ahead  ?
<ubottu> Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,In progress] https://launchpad.net/bugs/353370
<lifeless> james_w: you has bugs
<james_w> lifeless: you has responses to bugs
<lifeless> james_w: also a merge request on -builder; would love to have a todo-to-merge for it for Monday
<lifeless> james_w: thanks
<lifeless> james_w: did you only just comment? I don't see bugmail..
<james_w> about an hour ago
<james_w> for "needs -sa" I said "eh?"
<james_w> bzr-builder currently builds native packages to sidestep tarball issues
<james_w> so you shouldn't have an issue
<james_w> for "invalid email address" I said that I couldn't see how it happened given the code
<james_w> though I didn't look that closely
<james_w> knowing what $DEBEMAIL $DEBFULLNAME $MAIL $NAME $EMAIL were in your environment
<lifeless> dch -a gets something more 'sane' (though still not great)
<james_w> this uses a port of dch's algorithm, so it should give the same behaviour
<james_w> I can believe that we made a mistake in porting though
<lifeless> I saw, it doesn't.
<lifeless> $ echo a $DEBEMAIL b $DEBFULLNAME c $MAIL d $NAME e $EMAIL
<lifeless> a b c /var/mail/bobthebuilder d e
<james_w> $MAIL looks wrong to me
<james_w> or not
<james_w> I wonder where Javier got MAIL from, dch doesn't seem to use it
<lifeless> looks fine to me
<lifeless> its the maildir for the user
<lifeless> I can't imagine it ever being useful for email address detection
<lifeless> bzr has a pretty complete heuristic itself, built in
<james_w> ok
<james_w> yeah, I wanted the same as dch though
<james_w> I thought that would be less surprising
<lifeless> so the mail thing was a distraction
<james_w> using bzr stuff as a fallback before the "guess based on socket.fqdn" though
<lifeless> took me a bit of time to realise that it wasn't lp api's giving me grief :)
<lifeless> the merge proposal is more interesting to me than the bug now [as I has workaround]
<lifeless> its lightly tested as there doesn't seem to be any test support for lp apis
<lifeless> [and cody gave me a chunk of the code in one hit]
<james_w> yeah, I'm reviewing that now
<james_w> lifeless: if you could respond to the other bug I would appreciate it
 * james_w doesn't like incomplete bugs
<lifeless> james_w: I thought I replied to both
<james_w> ok
<james_w> hanks
<lifeless> yeah, I did
<lifeless> just bugmail slowness
<lifeless> really, smtp==www, should be instant :)
<james_w> lifeless: review done
<james_w> thanks for working on this
<bialix> bzr guru I have a question about bzrdir.sprout
<bialix> Bug 458914
<ubottu> Launchpad bug 458914 in bzr-scmproj "pget clone all revisions from shared repository instead of revisions belong to .scmproj branch" [High,Confirmed] https://launchpad.net/bugs/458914
<bialix> I have following code in scmproj to clone control branch
<bialix> http://pastebin.com/d5939252d
<bialix> this code using sprout
<bialix> as result it does not filter out unrelated revisions when cloning branch
<bialix> but get entire shared repo
<bialix> what I'm doing wrong?
<vila> bialix: why don't you use branch.fetch() instead ? And why does your comment talks about creating a working tree for force_new_repo ?
<bialix> I dunno, that code was written by amanica
<bialix> I don't understand how sprout works
<vila> :-/
<bialix> that code invoked this way: http://pastebin.com/d41766d3d
<bialix> wait
<bialix> are you asking about comment after force_new_repo=True ?
<bialix> vila: ^
<vila> yes
<bialix> the idea was is to create standalone branch always, regardless of presence of shared repo
<vila> bialix: especially when sprout has a _create_tree_if_local parameter...
<vila> ha
<bialix> _create_tree has leading underscore, therefore it's private API
<bialix> last time you was very hard that gary using private api in qbzr
<vila> meh, no underscore, sorry typo
<bialix> that code was written last winter, perhaps bzrlib evolved since then
<vila> rhaa, I wasn't hard at all ! You misunderstood my intent, but nm
<vila> bialix: you may want to use the revision_id parameter too
<vila>         if revision_id is not None, then the clone operation may tune
<vila>             itself to download less data.
<vila> bialix: your caller certainly can get that from br_from.last_revision_info
<bialix> vila: hmmm
<bialix> strange
<bialix> vila: so I need to change my clone fuinction?
<vila> I'd say so...
<bialix> :-/
<bialix> so I need to make function as     def _clone_to_local_url(br_from, revisions_id, to_url, accelerator_tree=None):
<bialix> vila: ^, right?
<bialix> and pass revision_id to sprout?
<vila> revision_id, no 's' , but yes, I'd try that
<vila> bialix: do you have any evidence that this bug is recent or was it always there but unnoticed ?
<bialix> my coworker just today discovered this
<bialix> I think it was there always
<bialix> but he has non-standard scmproj project clone
<bialix> .scmproj should be standalone tree, we forcing this
<bialix> but he made by hands this branch using shared repo
<bialix> so it's not very critical but I'd like to fix it
 * bialix trying what vila suggested
<vila> Peng: ping !
<bialix> Ping: peng
<vila> Peng: just noticed bug #458743 and bug #458741
<ubottu> Launchpad bug 458743 in bzr "terminal_width fix causes progress bar hideousness when piped to "less"" [Undecided,New] https://launchpad.net/bugs/458743
<ubottu> Launchpad bug 458741 in bzr "terminal_width fix causes test failures with subunit" [Undecided,New] https://launchpad.net/bugs/458741
<vila> Peng: I've been bitten by the problem in another way and I just proposed lp:~vila/bzr/353370-notty-no-term-width
<vila> Peng: your feedback will be highly welcome
<vila> Peng: oh, and more info at bug #353370
<ubottu> Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/353370
<bialix> vila: branch.py suggests that I can obtain rev_id tip by br_from.last_revision() call. ok?
<vila> bialix: yup
<bialix> cool
<bialix> vila: many many thanks
<bialix> merci
<bialix> it working
<vila> bialix: \o/
<bialix> all hail vila!
<vila> :-D
 * bialix mutters: that's new ajax lp made me crazy
<Peng_> vila: AIUI (skimming things) your patch drops the no-TTY width from 65,536 to 256. My terminal is ~130 columns wide, so it should still get spammed, just a lot less.
<Peng_> vila: Is that correct?
<vila> Peng: not only, it changes the way is obtained in more cases
<vila> Peng: not only, it changes the way the width is obtained in more cases
<vila> Peng: can you try it ?
<vila> err, which Peng are you ? Peng or Peng_ ? :)
<Peng_> Oh look, I have $COLUMNS. 183? Didn't remember it was that high.
<Peng_> vila: Both.
<Peng> vila: ...And neither!
<vila> lol
<vila> Right, so if you set COLUMNS, it's obeyed. Period.
<Peng_> OK, both of my computers have $COLUMNS. If it works, I don't really care about the details. :P
<Peng_> vila: I'll grab a copy of your branch.
<vila> ok, I'll grab some food then :-)
 * SamB_XP still wishes bzr paid attention to SIGWINCH
<vila> SamB_XP: patches welcome !
<SamB_XP> heck, I'm not even sure I made sure there was a bug about it!
<vila> SamB_XP: see.... :-D
<bialix> vila: thanks again, you my hero
<Peng_> That brings it to 4 branches I have merged to my bzr.dev. :D
<Peng_> vila: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.
<Peng_> vila: when piped to less, anyway
<Peng_> vila: This is an improvement, obviously, but it's still worse than the old code.
<vila> Peng: with or without COLUMN being set ?
<vila> COLUMNS
<Peng_> vila: with
<vila> Peng: and is the value coherent with your terminal ?
<vila> i.e. <=
<Peng_> vila: Yes.
<vila> Peng: you said earlier that COLUMNS was set to 183 and your terminal ~130, right ?
<vila> anyway, try to either *not* set COLUMNS or set it to a value that is *less* than your terminal width
<vila> Peng: regarding #458741, can you tell me how to reproduce that ?
<Peng_> vila: I just sent an email. All I did was "bzr selftest --parallel subprocess".
<Peng_> vila: Well, to be exact I did "bzr selftest --parallel subprocess pending".
 * Peng_ runs off to watch TV. I'll check in at ad breaks, though.
<vila> ok, I can reproduce now, that's fixed with my patch
<Peng_> Ohh, why is there always an ad break right when I get up?
<vila> Peng: at your next break, can you precisely tell me what width your terminal is, what COLUMNS value you use and if you still experience a problem
<Peng_> vila: 183, 183, and which problem? The selftest one? I'll check.
<vila> the selftest one is fixed, just checkd it
<Peng_> vila: Yeah, I can confirm it.
<Peng_> vila: Which problem do you want me to check?
<vila> You said: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.
<vila> I can't reproduce that
<Peng_> vila: Oh. ...Show's back.
<Peng_> vila: Anyway, that's with latest-everything, including your branch. And 3 others, but they shouldn't break this.
<vila> ghaaa, I want a recipe to reproduce !!! :D
<vila> ha, got it, if COLUMNS >> terminal_width I can see that, but if I use COLUMNS==terminal_width it's not the case, please double check
<vila> and if COLUMNS >> terminal_width, well, it's kind of expected, if the terminal issue a linefeed, there is no way bzr can uses carriage returns to erase the current line (since it has become the previous line...)
<vila> hmm, so, to be pedantically precise, the bug occurs if you set COLUMNS=terminal_width+2, so there probably is a off-by-one error somewhere
<vila> Peng: but it also very probably means COLUMNS is not set the way you think it is :)
<Peng_> Hmm.
<Peng_> vila: $COLUMNS is right.
<Peng_> vila: Also, like I said, it only happens when I pipe to less.
<Peng_> vila: ....Now I can't reproduce it.
<vila> Peng: haaaaa, I prefer that :-) THanks !
<Peng_> vila: Sorry, I was wrong. I can reproduce it.
<Peng_> vila: It works fine if I do "COLUMNS=183 bzr pull -v | less -F", but fails if I just do "bzr pull -v | less -F". Even though $COLUMNS is 183 anyway.
<vila> >-/
<Peng_> Sorry. :P
<vila> env | grep COLUMNS
<vila> vila:~/src/bzr/releases/2.0 :( $ echo $COLUMNS
<vila> 80
<vila> meh....
<vila> Peng: Can you try COLUMNS=182
<Peng_> vila: "export COLUMNS=182; bzr pull -v | less -F" works.
<vila> Peng: amazing isn't it ?
<vila> so it's *another* off-by-one error somewhere else
<Peng_> vila: Bu I told you, 183 works. Sometimes.
<Peng_> But*
<Peng_> vila: "export COLUMNS=183; bzr pull -v | less -F" works too. Augh!
<Peng_> vila: Ah-ha! "echo $COLUMNS" works, but "env" doesn't list COLUMNS.
<vila> seems related to 'shopt -s checkwinsize' in my .bashrc
<Peng_> vila: $TERMCAP does include the columns, though.
<Peng_> Although I only have $TERMCAP inside of screen, but that's mostly where I run bzr anyway, so it's not a big deal.
<vila> Peng: I'm pretty sure we are chasing a different bug here...
<Peng_> vila: I dunno. What are we talking about?
<vila> off-by-one errors bewtween terminal width and COLUMNS
<vila> before my patch COLUMNS wasn't obeyed, so you didn't see these bugs
<Peng_> So, um, hmm. Since it turns out I don't actually have $COLUMNS ("echo" lies), where does that put me?
<Peng_> It's using the default of 156?
<Peng_> 256*
<vila> echo doesn't lie, try 'shopt' and search for checkwinsize
<vila> if you do echo $COLUMNS and get something, so does bzr
<Peng_> vila: echo really does lie. $COLUMNS is not listed in "env", or Python's os.environ.
<Peng_> ...I hate computers. :P
 * vila kills some more chickens
<nyu> lifeless: thanks!
<phoenixz> fullermd: Good morning!
<phoenixz> fullermd: Just finished reading the other document you wrote
<phoenixz> fullermd: I have to say, still not sure on how the init-repo thing works, though it seems cool..
<dlee> Trying to use Bzr against an svn repo at http://opensource.adobe.com/svn/opensource/flex/sdk:  flex/sdk is the path in it, and it's from there laid out in "trunk" layout.  Read-only access requires no password, and this works with svn; but bzr insists on asking for one.
<dlee> I gather that this is because bzr tries to determine layout by examining the root, but I must not have read access that far up.  Is there a solution to this?
<jelmer> dlee: specify the layout manually
<dlee> I've tried messing with ~/.bazaar/subversion.conf but it didn't help.  I may not have done that correctly.
<jelmer> and disa ble the cache
<dlee> Can I use bzr co/branch or do I need bzr svn-import?
<dlee> The latter has a layout parameter; the former two don't I think
<jelmer> you can set the layout in subversion.conf
<jelmer> e.g. layout = trunk0
<dlee> The 0 is new to me :) tried without.
<jelmer> it shouldn't be necessray
<dlee> My subversion.conf is just the [uid] line, layout=trunk (with or without 0), and locations = http://opensource.adobe.com/svn/opensource
<jelmer> dlee: you'll also need to disable the cache
<jelmer> dlee: 'use-cache = False'
<dlee> in subversion.conf?
<jelmer> yeah, in the uuid section
<dlee> Hmm...still wants a user name.
<dlee> tried co and svn-import, trying to check out both trunk and just flex/sdk
<jelmer> can you send it ia sigquit and see what code path is tryuoing to access the repo root
<jelmer> (apologies for my spelling today)
<dlee> In the debugger, but I haven't been here before... what do you want from here?
<cellofellow> I need to install bzr on a Mac that I don't have admin rights too. Is there some way I can do that?
<Peng_> cellofellow: Worst case, run from source.
<jelmer> dlee: 'bt' will print a backtrace
<Peng_> cellofellow: You've tried the installer, and it failed without admin rights? http://bazaar-vcs.org/MacOSXDownloads
<cellofellow> Peng_: it asked for them but I didn't just click cancel and see what happened.
<cellofellow> if I click cancel it doesn't continue to the install
<cellofellow> source it is I guess
<dlee> Trying to sift out what matters... should I be suspicious at seeing "self._cached_revnum = self.transport.get_latest_revnum()"?
<cellofellow> or just don't use it, I can commit from my laptop.
<dlee> Looks like it happens when bzr tries to get the latest revnum.  Iirc, pasting large text chunks isn't appreciated in here, or I could paste some of the backtrace.
<Peng_> dlee: Use a pastebin.
<james_w> is there a way to do a backwards merge?
<james_w> use case:
<james_w> shared trunk with disconnected workflow
<james_w> if there is a collision in pushing to the trunk then I get told the branches have diverged
<james_w> if I merge trunk then it changes the left hand history of trunk
<Tak> rebase?
<james_w> the "correct" way to do it is to get another copy of trunk, update it, and then merge in
<james_w> but that's a faf
<james_w> if I could do "bzr merge", but just put the revision parents the other way around then I could do it in one directory couldn't I?
<james_w> Tak: there's no need to rebase, and in fact I don't want to
<dlee> Peng_ / Jelmer: I made a pastebin - never done that before either.
<Peng_> dlee: What's the URL?
<dlee> http://pastebin.com/m4e19701d
<jelmer> dlee: looks like we try to open the repository root at the moment when we try to figure out the last revision number
<jelmer> dlee: that's not really necessary, please file a bug
<jelmer> sorry, gtg - breakfast
<dlee> np and thanks
<phoenixz> I have varios SVN repositories containing various implementations of one and the same inhouse developed framework. Simplified, I have repo A with the framework itself, as trunk, branches and tags, from there copied (using SVK), in repo B project B1, B2 and B3, and I have repo C with projects C1 and C2... When making updates to the framework while working in repo C, project 1, I merge those changes back to the framework in Repo A. When I have updates to the
<phoenixz>  framework in repo A, I merge those changes to all projects in repos B and C.. I want to change from SVN / SVK to BZR. How can I import all these works from SVN / SVK to BRZ, keeping all the histories but also keeping the abilities to merge in between the various projects?
<phoenixz> I know, SVN cannot copy cross-repository, but SVK can. Which is one of the reasons why I used SVK in the first place. Now, SVK is pretty much a dead project, and I want to jump ship, BZR seems like the perfect choice for me, but I would not want to loose the ability to merge in between projects..
<jelmer> phoenixz: hi
<phoenixz> jelmer: hi
<jelmer> phoenixz: yes, if I understand your situation correctl bzr-svn should be able to handle that
<jelmer> phoenixz: please note that you shouldn't be using the 'bzr dpush' command when attempting something like this
<phoenixz> jelmer: I don't even know what dpush is or does, yet.. :)
<jelmer> phoenixz: in that case, don't worry about it :-)
<jelmer> phoenixz: dpush is the bzr-svn equivalent of "push but don't set svk:merge"
<phoenixz> jelmer: haven't found dpush in bzr help commands..
<phoenixz> jelmer: a question here..
<phoenixz> so in subversion, I have varios projects
<phoenixz> each project has a trunk, development branches and tags
<phoenixz> pretty common way to work in SVN
<phoenixz> I use this framework within different companies
<phoenixz> for each company I have multiple projects that use that framework
<phoenixz> for each company I have one SVN repository that contains the projects
<phoenixz> like, /svn/companya/projecta/ (where companya is an SVN repo)
<phoenixz> How do I set this up in BZR?
<phoenixz> Because AFAIK, BZR has each branch being its own thing
<phoenixz> there is a shared repo directory
<phoenixz> where I can keep those branches together
<phoenixz> so I figure, for each company, I would make a shared repository
<phoenixz> and in there I would place directories for each project
<phoenixz> and in those project directories, I would place the branches for each project
<phoenixz> jelmer: does this make sense in BZR? or did I get it totally wrong?
<dlee> Jelmer: Re: getting svn latest revno querying at repo root unnecessarily:  Bug #459187 filed.
<ubottu> Launchpad bug 459187 in bzr "Unnecessary request for userID/password on bzr co/branch/svn-import from svn repo" [Undecided,New] https://launchpad.net/bugs/459187
<Meths> Can bzr import from CVS?
<Meths> nm, found bzr-cvsps-import
<jelmer> dlee: Thanks
<jelmer> Meths: you may also want to check out cvs2svn's fastexport option
<jelmer> phoenixz: yeah, that should work
<jelmer> phoenixz: I would recommend sticking to the standard layout for svn inside of those branch container directories
<jelmer> phoenixz: because bzr-svn will automatically regonize what is a branch in that case
<phoenixz> jelmer: another question.. Does BZR know if different branches are related? I suppose it does, but if I make a branch of a branch of a branch, etc etc.. will the last branch still know its related to the first one
<phoenixz> ?
<phoenixz> I know, noob questions.. :)
<jam> Meths: or use 'cvs2bzr' from the 'cvs2svn' suite. Which will create a 'fast-import' stream, that you can import using 'bzr fast-import'.
<jelmer> phoenixz: yes, it will know if different branches are related
<phoenixz> jelmer: is it also possible to branch a sub directories? like, I have a project A with sub directory lib.. I want a branch of only lib, is that possible too?
<jelmer> phoenixz: partial checkouts are possible but the related history with the partent branch will not be recognized
<Meths> jelmer: jam: thanks.  How does bzr fast-import work?  bzr help fast-import isn't implemented
<jelmer> Meths: you need the bzr-fastimport plugin
<Meths> ah
<jelmer> phoenixz: I'm out for the day. If you have more questions, please mail the list and cc me
<vila> morning jam !
<phoenixz> jelmer: thanks lots for the help so far!
<vila> jam: I could spend a better week-end if I could land https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832
<jam> hey vila
<jam> I'm technically on vacation again today
<jam> though I found a way to shrink mem by another ~50MB or so, so I can't stay away :)
<vila> jam: ach, sorry again, but hey you're here again :)
<jam> I'm not sure about trusting COLUMNS when isatty() is false
<Tak> jelmer: btw, I figured out what the issue was with bzr-svn/subvertpy/md-bzr
<vila> jam: well, the more I dig, the more I see COLUMN being set even when you don't touch it :-)
<jam> certainly under 'less' you probably don't want to truncate
<jam> even though Peng does
<vila> Just try it in a terminal...
<jam> vila: I'm pretty sure the terminal likes to set COLUMN / COLUMNS or whatever
<jam> as a hint
<vila> bash too
<jam> vila: well bash has to get it from the terminal, rigth?
<Tak> I wasn't invoking PyEval_InitThreads
<jam> or perhaps it uses SIGWINCH, or TIO or whatever
<vila> I dunno, surely they talk to each other, but that makes it even more reliable
<jam> vila: right, and my point is if I do "bzr XXX > file"
<jam> should it be paying attention to that?
<jam> also note that for our purposes
<jam> sys.stderr.isatty is probably more relevant
<jam> I don't think we ever truncate stdout
<jam> vila: can you verify that last statement?
<vila> let's not open more cans than necessary....
<vila> log --line is one know truncate case
<jam> (stdout being valuable information that the command is generating, versus 'progress' etc information that can be truncated on a whim)
<jam> vila: so my direct preference is "revert the 'bugfix"
<jam> my second preference is "just set it to 256"
<jam> my third is 'lets have a discussion and actually get this right"
<vila> setting to 256 when using a tty is bad, I know that for sure
<vila> ok, so I'll revert the offending revnos and wait more feeedback on the patch
<Peng_> jam & vila: <3
<jam> vila: but isatty() is False
<jam> Or am I missing something
<vila> jam: ECONTEXT
<jam> (11:16:57 AM) vila: setting to 256 when using a tty is bad, I know that for sure
<jam> You are setting it to 256 when "isatty()" is returning false
<vila> yes
<jam> hence "using a tty" but the system is telling us you aren't
<vila> I was replying to: <my second preference is "just set it to 256">
<jam> vila: I'm saying "set it to 256 when isatty() is False"
<jam> I should have typed it all out, I guess
<vila> ha ok, yes, that's what the patch does
<jam> I was trying to say "change 65536 => 256"
<jam> vila: and a bunch of other stuff
<jam> My point is there is a one line 65536 => 256 change
<jam> that seems to cover what you really need
<vila> haaaa, I started with that, but them I realized there was other problems and that wasn't enough
<vila> s/them/then/
<vila> so, it's either, revert or fix them all
<vila> well, for some values of all...
<jam> vila: which is my point about (3)
<jam> if we are going to spend significant time on it, lets do it the right way
<jam> (and i feel stuff like checking sys.stderr is part of that, possibly handling SIGWINCH, possibly a few things)
<vila> jam: ok, I thought I did that but by all means, let's discuss it widely :)
<jam>  $COLUMNS concerns me, because doing something like:
<vila> wow, wow, wow :)
<jam> bzr log --line > file
<jam> seems like it shouldn't truncate
<jam> should bzr log --line | less?
<jam> should we truncate a progress bar, but not log --line
<jam> ?
<vila> yeah, the truth is I started thinking COLUMNS wasn't set behind my back but *always* by the user, I'm less sure about that now
<jam> vila: well if you resize your window
<jam> COLUMNS is usually updated to match
<jam> it just isn't updated 'on-the-fly' while the program is running
<jam> hence SIGWINCH
<vila> I thought you had to use termios, not COLUMNS for that... It appears I was wrong (still not completely sure, try:)
<vila> try: env| grep COLUMNS
<vila> then echo $COLUMNS
<vila> then under python look at os.environ['COLUMNS']
<jam> vila: I'm currently on Windows, which has fairly fixed column width for cmd.exe
<jam> I can try it, I suppose
<jam> echo "$COLUMNS" is empty for me
<vila> Ach, windows, yeah, I have some pending questions there too... as pointed in some bugs bzr behaves differently wrt redirections on windows and linux...
<jam> vila: well, there you have to also worry about '\r\n' and setmode(binary) etc.
<vila> jam: on OSX: http://paste.ubuntu.com/299876/
<jam> vila: pretty
<jam> I like how it ends in a frown
<vila> hehe
<vila> on jaunty: http://paste.ubuntu.com/299877/
<jam> hmm. same result
<vila> yup
<vila> on FreeBSD: http://paste.ubuntu.com/299879/
<vila> some result too, except when set by the user, COLUMNS is not seen by python...
<vila> I suppose *bash* knows about COLUMNS in some kind of way
<Peng_> Oh, good, my weird results aren't unique.
<jam> vila: go start enjoying your weekend
<jam> :)
<vila> jam: yeah, revert sent to pqm, I'll poke babune later :)
<vila> jam: thanks, enjoy yours too when you decide it :)
<jfroy|work> jelmer: ping-a-pong
<Tak> if I set a command's outf to something other than stdout, will the file be closed automagically when the command is gced or no?
<Tak> hmm, it looks like "no"
<bialix> fullermd: ping
<Kmos> hi
<Kmos> kmos@kmos:~/packages/apport$ bzr push lp:apport
<Kmos> bzr: ERROR: Cannot lock LockDir(lp-46086288:///~apport-hackers/apport/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<RenatoSilva> If I cerate an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and merge all-features into trunk, will only the new commits CONFLICT_N be merged from all-features into trunk?
<Kmos> break-lock doesn't work
<RenatoSilva> * If I create an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and then merge all-features into trunk, then will only these new commits CONFLICT_N be merged from all-features into trunk?
<Kmos> RenatoSilva: don't repeat yourself
<RenatoSilva> Kmos: Strictly speaking, I didn't ;)
<Tak> hmm, if I have something in ~/.bazaar/plugins that I have a different version installed systemwide, will my local plugin override, or will there be a conflict?
<lifeless> local wins
<Tak> thanks
<james_w> hi lifeless
<lifeless> hi
<james_w> thanks for making the changes
<james_w> I haven't reviewed the incremental diff, but I don't foresee any problems
<james_w> I just replied before seeing the mail that you had made them
<lifeless> ok
<lifeless> so I made the bits *I* consider a must given the things the review discussion uncovered
<lifeless> I haven't change print to mutter, or other such things
<james_w> as I said, I'm happy to take over if you are willing to block on me
<lifeless> Well, I'm running from a homedir install now
<lifeless> not going to block regardless
<james_w> but as you are asking me to maintain the code I am wary of merging it with things that I can see being problematic
<lifeless> so, I don't think there are things remaining that are problematic, just differnet
<lifeless> with the sole exception of the oauth file
<lifeless> and I think that all of that should be in launchpadlib *anyway*
<lifeless> its fugly the way the setup stuff is cargo culted around
<james_w> I pointed to the API for that
<james_w> did you take a look at whether it matched?
<lifeless> no, its saturday ;P
<lifeless> and I don't understand enough to know if it matches or not.
<james_w> fair enough
<lifeless> the whole launchpadlib thing is rather opaque to me
<lifeless> the pydoc is epic epic epic fail
<lifeless> and the total inability to work and test with it offline (Without a multi-hundred mb separate download & apache locally) is a real disincentive to learn more
<lifeless> so there is also a bit of passive resistance to learning more:P
<james_w> pydoc launchpadlib.launchpad
<james_w>  /login_with
<james_w> if you are interested
<lifeless> heh
<lifeless> so this is actual code and documented ;)
<lifeless> so, login_with looks fine, but given that I know nothing about the failure modes, internals, required facilities, expected conventions...
<james_w> the only issue with it is that it puts the cache in "launchpadlib_dir"
<lifeless> my approval doesn't mean much
<james_w> and currently the cache is broken with multiple processes
<lifeless> Oh, I really hate the cache
<lifeless> it shouldn't need one.
<james_w> because?
<lifeless> Damn silly idea, HTTP caches are extremely hard to get right.
<lifeless> build the API by introspecting the wsdl and compiling python from it; then ship the resulting static API, which is fully documented and faster
<lifeless> I say HTTP caches are hard to get right after years as squid-core :), its an informed opinion.
<lifeless> also, if you need an HTTP cache for a web services API to work, the API design is broken and will perform problematically [because of cache seeding overhead at a minimum]
<james_w> bug 459418 filed as due dilligence
<lifeless> what else, oh, require write access means you can't use launchpadlib as a very restricted user, or [for instance] to grab backup data during system restore when nothing is mounted writable
<ubottu> Launchpad bug 459418 in launchpadlib "Cache is broken with multiple processes" [Undecided,New] https://launchpad.net/bugs/459418
<lifeless> s/require/requiring/
<james_w> I can now go back to moaning about how login_with is broken with a clear conscience
<lifeless> :)
<james_w> anyhow, I shall make some time to merge your code at some point
<james_w> thanks again
<lifeless> that would be excellent
<lifeless> I'd lke to be running a packaged bzr-builder
<lifeless> the less string the easier to get OSA's to run the service ;)
<jfroy|work> http://trac.webkit.org/changeset/50000
<jfroy|work> uuuuarg oops
 * jfroy|work hides in shame
<jfroy|work> defeated by too many tabs, once agao
<jfroy|work> *again. I apologize.
<jfroy|work> jelmer: ok I have the weirdest problem with bzr-svn
<jfroy|work> well, it seems to me that way. I have a completely clean repository with no bzr: props or revprops and no svn:mergeinfo or svk:merge props.
<jelmer> jfroy|work: are you psychic? I just returned back to my computer after being away for half a day and you ask within a couple of seconds :-)
<jfroy|work> and a straight bzr branch of the trunk branch in that repo yields a bazaar branch with a number of sha1 mismatch errors
<jfroy|work> lol :p
<jfroy|work> no, I'm pretty sure I'm not :p
<jfroy|work> basically, we're migrating a project from a repo with a bunch of projects in it to a brand new repo dedicated to only one project
<jfroy|work> so I 1) branched using bzr the trunk and the current active branches from the old svn repo 2) pushed trunk (with the push merged revision option enabled) to a simulation blank svn repo 3) dumped that 4) ran a filter on the dump to strip every revprop and prop starting with bzr: (as well as svn:mergeinfo and svk:merge) 5) loaded that filtered dump into a new repo and 6) branched the trunk from that repo
<jelmer> did you change the UUID or throw away the cache?
<jfroy|work> that should yield a clean bzr branch, shouldn't it?
<jfroy|work> pretty sure I did
<jfroy|work> ~/.bazaar/svn-cache/ and ~/.bazaar/subversion.conf
<jfroy|work> And I get a "Initialising Subversion metadata cache" message when branching
<jfroy|work> I'm guessing the only thing left that could trip bzr-svn are copy nodes it's trying to interpret
<jfroy|work> I don't think there's anything that can be done about those
<jelmer> can you reproduce the problem on a small repo?
<jfroy|work> I have no idea how to reproduce this
<jfroy|work> oi, wait a second...
<jfroy|work> these are the sha1 mismatches
<jfroy|work> http://paste.ubuntu.com/300096/
<jelmer> can you pastebin the backtrace?
<jfroy|work> no backtrace
<jfroy|work> this is output by bzr check
<jfroy|work> All of those files are symbolic links
<jfroy|work> I think this is the problem
<jelmer> ah, that might make sense
<jelmer> That should be a relatively trivial bzr-svn bug
<jfroy|work> those 4 files are all empty with Property svn:special set to *
<jfroy|work> and the content set to "link Versions/Current/ATF"
<jelmer> we're just filling in a different sha1 in the inventory as we put in the versionedfiles
<jfroy|work> s/ATF/foo
<jelmer> jfroy|work: can you file a bug?
<jelmer> jfroy|work: :-)
<jfroy|work> let me try to repro with a simple repo
<jelmer> jfroy|work: I have some long flights coming up, might give me something to do :-)
<jfroy|work> That would be incredibly awesome :)
<jfroy|work> yup
<jfroy|work> reproduced with a one commit repo
<jfroy|work> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/459440
<ubottu> Launchpad bug 459440 in bzr-svn "bzr-svn sha1 mismatches on symbolic link files" [Undecided,New]
<jelmer> jfroy|work: awesome, thanks
<jfroy|work> jelmer: oh, I've found another minor issue
<jfroy|work> if you create a brand new repo and push a branch to <repo url>/trunk, you won't get any tags (but branches will show up if you have push merged revisions)
<jelmer> jfroy|work: please file a bug for that one as well
<jelmer> jfroy|work: and thanks :-)
<jfroy|work> if, however, you create a revision 1 with svn that creates the standard layout, then push --overwrite, then you'll get tags
<jfroy|work> I'm guessing it doesn't detect that the repo is using the standard layout
<jfroy|work> probably needs a "repo is at revision 0, I should make the standard layout first" special case
<jelmer> I suspect it's because we have a different code for "create this branch" vs "push revisions to this existing branch"
<jfroy|work> https://bugs.launchpad.net/bzr-svn/+bug/459444
<ubottu> Launchpad bug 459444 in bzr-svn "Pushing to a blank repository does not push tags" [Undecided,New]
#bzr 2009-10-24
<cellofellow> how would I check out an svn repository into a subdirectory of my bazaar branch without any ill effects? I want to still pull changes from the svn if needed, and also have the svn be managed by bzr.
<wgrant> cellofellow: Why not use a bzr-svn checkout?
<wgrant> cellofellow: That way you have a bzr branch that can cooperate with the svn repo.
<cellofellow> I just did that, and it seems to work ok.
<fullermd> phoenixz: Hey.  Did you figure out what you needed?
<phoenixz> Hi, yeah, more or less.. Im still toying a bit with it before I will transer all repos.. I need the different ideas of BZR to settle a bit..
<fullermd> Absolutely.  Much fiddling preceeds real work   :)
<phoenixz> Its not so diffuicult I suppose, its like... switching querty to dvorak.. :) it sucks!
<fullermd> Did the mainline stuff make sense?  That's probably a pretty big mental departure.
<phoenixz> It did actually, yes, its just something.. needs to sink in
<phoenixz> I have 2-3 years of SVN / SVK stuff to squeeze out of my brains
<fullermd> Well, don't squeeze it all out.  Otherwise we can't pressgang you into helping run the SVN User Reeducation Camps.
<phoenixz> Heheheh, I doubt it will all sip away
<BUGabundo> morning
<BUGabundo> $ bzr pull .
<BUGabundo> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~exaile-devel/exaile/exaile-0.3.0/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<BUGabundo> can anyone elaborate on this?
<lifeless> you probably have a checkout
<lifeless> over http
<lifeless> and you can't do mutating operations - push/pull/uncommit/commit to a checkout if you can't write to the master
<BUGabundo> thanks lifeless
<BUGabundo> so how can update my checkout?
<luks> bzr update
<luks> (very non-intuitively named command :P)
 * BUGabundo tries
<BUGabundo> Updated to revision 2567.
<BUGabundo> seems to work :)
<BUGabundo> thanks lifeless luks
<lifeless> BUGabundo: the rule to remember is:
<lifeless> if you use it like svn, *use it like svn*
<BUGabundo> I don't :)
<BUGabundo> bzr is my 1st cvs
<lifeless> you do if you use 'checkout'
<lifeless> its centralised-style workflow, which is all that svn does
<BUGabundo> I mean, I don't use it like svn
<lifeless> BUGabundo: I think you mean 'vcs', ''cvs'' is the name of a tool
<BUGabundo> which one is better for single offline keeping?
<luks> if it's your first vcs, you should read the manual
<BUGabundo> bzr branch or checkout ?
<BUGabundo> luks been using it for a while, read the man long ago. much has changed since bazaar started :)
<luks> but not this
<luks> http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/bzr_man.html#concepts
<BUGabundo> which one is better for single offline keeping? bzr branch or checkout ?
<BUGabundo> seems to be CO
<BUGabundo> since I don't need the history :)
<BUGabundo> specially lightweight CO
<lifeless> lightweight CO is very slow over the network
<BUGabundo> :(
 * BUGabundo goes reading more
<GaryvdM> Hi Luks
<GaryvdM> luks: I generated quite a bit of bug mail. So you may have missed my response to bug 421039
<ubottu> Launchpad bug 421039 in qbzr "Diff windows launched from qci are always in the background" [High,Confirmed] https://launchpad.net/bugs/421039
<GaryvdM> luks: Is that still a problem for you?
<luks> GaryvdM: let me check
<luks> GaryvdM: yes, the problem still exists in lp:qbzr
<luks> the commit window is always above the diff window
<GaryvdM> Luks: ok - I'll get hold of that other laptop, and try debug it.
<GaryvdM> As I said, it dose not do it on my computer - And  I have an almost identical setup - so it is very weird.
<GaryvdM> luks: What version of qt and pyqt do you have installed?
<luks> GaryvdM: PyQt 4.4.3 and Qt 4.4.0
<GaryvdM> luks - Ah - I'm running Qt 4.5 - I'll try it with 4.4
<GaryvdM> luks: Asking you this cause you did qconflicts - do you think bug bug 174509 is important?
<ubottu> Launchpad bug 174509 in qbzr "qcommit/qbrowse: Show conflict status in file list and an option to launch a merge tool to resolve them" [High,Confirmed] https://launchpad.net/bugs/174509
<luks> GaryvdM: I wrote qconflicts, but not for myself :)
<luks> I don't really have an opinion on the bug
<luks> I guess it's not 'important'
<luks> maybe just a way to launch qconflicts from qcommit would do it
<nyu> lifeless: you're the author of cia_baz.sh ? this script runs on the server, right?  Savannah admins seem a bit confused about it, and I don't know what to answer them
<dash> Hmm. I am getting an interesting error
<dash> 'bzr info' in my branch says 'bzr: ERROR: No repository present: "<branch url>"'
<dash> pretty sure it never was in a repo, I branched it from a standalone branch on another machine
<fullermd> Every branch always has a repo, otherwise there's no place to store revisions.
<fullermd> Can you access that branch locally, wherever it is?
<dash> oh, of course
<dash> nope, bzr info says that locally, it's a file:/// url
<fullermd> What's in .bzr/ ?
<dash> Hmmmm
<dash> there is indeed no repository directory
<dash> what a curious turn of events!
<dash> oh, there's checkout/
<dash> anyway all i have is:
<fullermd> 'bout the only way you'd ever get bzr to produce that would be if it were in a shared repo, and then moved out somehow.
<dash> branch branch-format branch-lock checkout
<jelmer> fullermd: fwiw, bzr-git now supports dwim revspecs :-)
<fullermd> jelmer: So now all we need is bzr-nongit to do to  ;>
<lifeless> nyu: I'm not the author
<lifeless> nyu: but I'll do what I can to help
<nyu> lifeless: thanks!
<nyu> lifeless: the savannah admin said he thinks this script would have to be run in client side
<nyu> is this correct?
<lifeless> I don't know, I haven't seen it
<nyu> uhm...  "Robert Collins contributed a client for Bazaar, using email delivery: cia_baz.sh."
<lifeless> wow
<nyu> that's you?
<lifeless> must have been a long long time ago
<lifeless> in a galaxy far far away ;)
<nyu> http://cia.vc/doc/clients/ distinguishes between bazaar and bazaar-ng
<nyu> I'm using bazaar-ng, right?
<lifeless> yes
<nyu> this page looks ancient
<lifeless> cia_baz.sh is for 'baz' which was a fork of tla
<nyu> cia_bzr.py instructions say "Copy this file to ~/.bazaar/plugins
<nyu> "
<nyu> looks like client side
<lifeless> I've just dropped micah an email
<lifeless> to update the page
<lifeless> jelmer write the cia plugin for bzr
<nyu> cia-clients - clients scripts for CIA commit notification on IRC
<nyu> heh
<nyu> it's even packaged
<lifeless> as for client/server - all bzr plugins get installed in the same place; whether they work on servers or not depends on whether they need all history or only the most recent commit
<lifeless> I'd expect the CIA plugin to work on a server - but savannah are not running a server at the moment
<lifeless> (sftp:// isn't a server,its a file system :))
<nyu> lifeless: ssh+bzr:// ?
<lifeless> yes
<lifeless> or bzr://
<nyu> they run that too
<lifeless> or http:// with a server configured
<lifeless> nyu: then you should use bzr+ssh!
<lifeless> its much faster than sftp
<nyu> https://savannah.gnu.org/support/index.php?107077
<lifeless> ok good
<nyu> the script now lives in /usr/share/pyshared/bzrlib/plugins/cia/__init__.py
<nyu> as provided by cia-clients package
<nyu> do I still have to copy it to ~/.bzr ?  this one looks like a system-wide plugin repository
<nyu>     config = branch.get_config()
<nyu>     project = config.get_user_option('cia_project')
<nyu> uhm
<nyu> my modest python skills tell me this is a setting I need to feed into bazaar somehow
<lifeless> systemwide is fine
<lifeless> and yes you need to get the cia_project option
<lifeless> either in .bzr/branch/branch.conf
<lifeless> or ~/.bazaar/locations.conf
<lifeless> or ~/.bazaar/bazaar.conf
<lifeless> bzr help configuration for an overview
<nyu> thanks
<syncrondi> Hey all - quick question= Does anyone know what the BZR_SSH environment variable should be set to on win ?
<nyu> uhm any idea what I'm doing wrong?
<nyu> rmh@thorin:/tmp$ bzr co bzr+ssh://robertmh@bzr.savannah.gnu.org/grub/branches/experimental/
<nyu> No handlers could be found for logger "bzr"
<nyu> bzr: ERROR: Repository KnitPackRepository('file:///tmp/experimental/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://robertmh@bzr.savannah.gnu.org/grub/.bzr/)
<GaryvdM> syncrondi: You probably just need to Pageant from Putty
<GaryvdM> nyu: KnitPackRepository is a very old format.
<syncrondi> GaryvdM: I've got that .. but I think I accidentally pointed my env var at plink instead
<GaryvdM> syncrondi: then just set BZR_SSH=
<nyu> GaryvdM: why would bzr want to use it?
<nyu> I didn't tell it to
<GaryvdM> nyu: what version of bzr do you have?
<nyu> should I create a shared-repo locally?
<nyu> 1.5
<GaryvdM> nyu: That won't help (shared-repo)
<GaryvdM> nyu: 1.5 should support packs - so if you run bzr upgrade on the branch it should work.
<lifeless> hang on
<lifeless> nyu: don't do that
<lifeless> GaryvdM: _always_ gather more data before suggesting that
<GaryvdM> nyu: bzr 2.0 is release - I would recommend using that.
<GaryvdM> lifeless: sorry
<lifeless> GaryvdM: you need to check that a) you won't break interop with the users community and b) that you're not going to be accidentically causing a rich-root transition
<lifeless> nyu: bzr info -v nosmart+bzr+ssh://robertmh@bzr.savannah.gnu.org/grub/branches/experimental/
<lifeless> nyu: that will tell use the actual format in use by grub
<GaryvdM> lifeless: I meant that he should upgrade his local branch.
<lifeless> GaryvdM: right, but its a shared repo
<lifeless> GaryvdM: and if he has other projects in that repo
<lifeless> GaryvdM: what will happen to them ? :)
<GaryvdM> I c
<lifeless> exactly, they will become incompatible with their upstreams
<lifeless> its the downside of the waterfall transition that is 2a
<nyu> lifeless: it's odd, I created everything myself using this version :-)
<lifeless> nyu: did you run 'bzr init-repo' at some point ?
<lifeless> nyu: is there anything in your local shared repo?
<nyu> http://pastebin.com/d7c182b58
<nyu> lifeless: am I supposed to have a local shared repo?
<lifeless> nyu: you have one, or you would not have got that error
<nyu> I don't think I have any, just a bunch of checkouts and branches
<nyu> lifeless: but I'm in /tmp
<lifeless> run 'bzr info' please
<nyu> in /tmp?
<lifeless> whereever your cwd was when you got that error
<nyu> $ bzr info
<nyu> bzr: ERROR: Not a branch: "/tmp/".
<lifeless> ok
<lifeless> and /tmp/experimental was an empty dir ?
<nyu> I removed it, then tried a checkout and got the error
<lifeless> ok
<lifeless> what bzr version? this could be a bug..
<nyu> 1.5 (from debian lenny)
<syncrondi> GaryvdM: I cleared BZR_SSH, but I now I get the error saying that it isn't set. I set it to pageant.exe but it didn't like that either
<lifeless> nyu: so, I /really/ recommend you upgrade and use bzr 2a
<lifeless> it will be a lot faster, and I suspect that you have indeed found a bug in checkout
<nyu> I see
<GaryvdM> syncrondi: sorry - I checked the docs - You need set BZR_SSH=paramiko
<syncrondi> ah
<lifeless> nyu: sorry, the version is 2.0.0, the format name is 2a
<GaryvdM> syncrondi: see bzr help env-variables
<lifeless> nyu: you don't need to use the 2a format
<lifeless> but the 2.0.0 client is more than a year newer
<syncrondi> GaryvdM: In my frustration with the command line verison, I installed the full package for win because I've had that running before.. I'll take a look at that doc
<nyu> lifeless: will that switch to a new format?  I don't want to block access to 1.x users
<lifeless> only if you tell it to
<nyu> ok
<lifeless> [or run 'bzr init' or 'bzr init-repo' somewhere - those commands create new projects]
<syncrondi> GaryvdM: So it appears that I can use plink?
<nyu> to create a local shared repo, I should use "bzr init-repo --rich-root-pack" just like i did on the server?
<GaryvdM> syncrondi: Ok - I've never used it myself.
<lifeless> nyu: yes
<syncrondi> GaryvdM: oh, ok. I just saw that it has plink listed in the doc
<nyu> ok
<nyu> oh, in the shared repo the problem doesn't happen anymore
<syncrondi> Well, instead of doing C:\plink.exe I set it to just 'plink' and its progressed a bit ( I think ). Now it says bzr: ERROR: [Error 2] The system cannot find the file specified
<syncrondi> Any ideas on that?
<syncrondi> I'm using bzr branch bzr+ssh://syncrondi@myhost.com:port/path/
<nyu> I have a local tree which is used for the bazaar mirror (pulls from subversion and pushes to bzr).  should I move this into the shared repo as well?
<lifeless> nyu: sure
<nyu> do I need to re-create it?
 * lifeless shrugs
<nyu> I can live with that, it's just 30min ;-)
<GaryvdM> nyu: you can bzr branch form the old bzr standalone branch into the shared-repo, insted of branching from svn
<GaryvdM> nyu - That should be quicker.
<GaryvdM> *from
<GaryvdM> syncrondi: check My Documents\.bzr.log - That should give you more info.
<nyu> GaryvdM: well, in fact it's a checkout rather than a standalone branch
<nyu> which now that I think, seems a bit odd
<GaryvdM> A heavywight checkout, or a lightweight checkout?
<nyu> default is heavy, right?
<GaryvdM> yes
<nyu> then heavyweight.  sounds better now
<GaryvdM> If heavy - it will be the faster from the local bzr branch
<GaryvdM> * checkout
<nyu> but if I branch that checkout, it's not a checkout anymore, right?
<GaryvdM> nyu: I think - a heavyweight checkout == bound branch
<GaryvdM> so you can bzr branch
<GaryvdM> and then bzr bind svn+....
<syncrondi> GaryvdM: Thanks for the tip. I'm looking there now, but nothing appears obvious to me. I see this as the last line before the error:
<syncrondi>   File "C:\Python26\lib\subprocess.py", line 830, in _execute_child
<syncrondi>     startupinfo)
<syncrondi> WindowsError: [Error 2] The system cannot find the file specified
<GaryvdM> syncrondi: please put the last section of the file in http://pastebin.org/
<nyu> GaryvdM: ah, ok
<lifeless> nyu: if you branch the checkout,t he new branch is a branch
<lifeless> nyu: it doesn't alter the checkout to branch *from* it
<nyu> lifeless: but I want a checkout as result
<nyu> it seems that "bzr bind" turned it into one, as GaryvdM said
<nyu> but it still remembers the local dir it originated from as "parent branch"
<nyu> can I make it forget that?
<GaryvdM> nyu: if you do bzr pull svn+... --remember, it will change the parent branch
<GaryvdM> nyu: or edit branch.conf
<lifeless> nyu: then just make a checkout
<lifeless> nyu: I suggest just doing what you wanted
<syncrondi> GaryvdM: http://pastie.org/668389.txt?key=cqmpumyv5bm1lglmhidj7w
<lifeless> ignore all the hints about speed, they add confusion and complexity
<nyu> ok
<nyu> so I rm -rf trunk, and check it out again
<nyu> when removing stuff from a shared-repo, do I need to tell bzr to remove it, or may I do that by hand?
<lifeless> just delete it
<lifeless> the backing database will keep the revisions
<lifeless> we don't currently have a gc command
<GaryvdM> syncrondi: I'm sorry - I don't know how to solve that . Maybe someone else can help you.
<nyu> ok here we go
<nyu> checkout in 1s!!
<syncrondi> Thanks GaryvdM
<syncrondi> Would you recommmend perhaps uninstalling everything and reinstalling the standalone?
<lifeless> no
<lifeless> its trying to run a process
<lifeless> run with BZR_PDB=1
<lifeless> when the error happens you will be put into a debugger and be able to confirm the program its trying to find
<syncrondi> lifeless: Ok, I'm not familiar with how to run with BZR_PDB=1
<syncrondi> Did a google, but nothing substantial came up; any hints? :)
<lifeless> BZR_PDB=1 bzr ....
<lifeless> oh, you're on windows
<lifeless> set BZR_PDB=
<lifeless> set BZR_PDB=1
<lifeless> bzr ...
<syncrondi> > c:\python26\lib\subprocess.py(830)_execute_child()
<syncrondi> -> startupinfo)
<syncrondi> (Pdb)
<lifeless> locals()
<syncrondi> locals() ?
<lifeless> type that in
<lifeless> hit enter
<lifeless> show the result
<syncrondi> http://pastie.org/668398
<lifeless> its trying to run plink
<lifeless> is plink on your path ?
<nyu> if I commit in "trunk" (whose parent branch is in svn), is my commit pushed to svn as well?
<nyu> or should I use svn for commits as usual
<GaryvdM> nyu: In a hw checkout - it will push to trunk when you commit
<GaryvdM> sorry - will push to svn when you commit
<nyu> ah, great
<GaryvdM> nyu: with just a branch - it will push only when you do bzr push
<nyu> and I take it that if I branch trunk foo, then commit in foo, then push in foo, it also goes to svn?
<nyu> (trunk is a bzr checkout of svn)
<lifeless> push foo trunk
<lifeless> yes, that will go to svn as well
<lifeless> however!
<lifeless> because of svn limitations I would not do that
<lifeless> cd trunk
<lifeless> bzr merge ../foo
<lifeless> bzr commit
<lifeless> will behave better
<nyu> you wouldn't use bzr to commit to svn, or you wouldn't use branches?
<nyu> ah I see
<nyu> then I just do it in that tree
<syncrondi> lifeless: Wow, I think that fixed it!
<syncrondi> I figured C: was in my path but I had to add it
#bzr 2009-10-25
<syncrondi> thanks lifeless
<lifeless> nyu: I would use branches
<lifeless> nyu: and when finishing the branch, merge it to trunk and commit
<nyu> ok
<syncrondi> If I've made an init on my server, do I also have to branch it before I can branch on my workstation?
<syncrondi> Anyone know how I can remove a bzr project/repo?
<lifeless> syncrondi: not sure I get the question
<syncrondi> lifeless: I just deleted the .bzr/ and I hope that removes any projects created with init
<syncrondi> But I can't seem to connect to my new project
<syncrondi> I get bzr: ERROR: Not a branch: "C:/Documents and Settings/syncrondi/My Documents/My Webs/project/bzr:ssh:/me@project.org/home/project/htdocs/".
<syncrondi> I'm just running the same command as I was before to connect to a server on another project : >bzr branch bzr:ssh://me@project.org/home/project/htdocs
<spiv> syncrondi: you want "bzr+ssh" not bzr:ssh
<syncrondi> ah..
<syncrondi> I just noticed that myself
<syncrondi> xD
<syncrondi> I hate being pesty, but it seems as though I'm just unable to get this right. When I try branching, I get bzr: ERROR: Connection closed: Unexpected end of message. Please check connectiv
<syncrondi> ity and permissions, and report a bug if problems persist.
<syncrondi> I've got my key imported, host is accepted and now I get this :-\ Any ideas?
<lifeless> syncrondi: check your bzr.log (bzr --version shows where that is)
<lifeless> I suspect you don't have bzr on the server, or some such thing
<syncrondi> lifeless: I'm pretty sure I apt-getted bzr.. What should I be looking for on the log?
<offby1> .oO("apt-got"?)
<lifeless> syncrondi: if you're on linux, ~/.bzr.log
<MTecknology> !logs
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<lifeless> MTecknology: ?
<MTecknology> lifeless: I just needed the link and this channel was the closest w/ ubottu in it - sorry for noise
<lifeless> heh
<lifeless> you can msg ubottu i think
 * kfogel is away: zzz
<syncrondi> lifeless: well, my tail has this http://pastie.org/668618
<lifeless> syncrondi: you've clearly run other commands ;)
<lifeless> syncrondi: is that on the client or the server?
<syncrondi> lifeless: I thought you were asking for the server log. That's what I pasted and I was trying to init my project
<syncrondi> my server is linux, client windows
<lifeless> syncrondi: I was asking for the client log
<lifeless> syncrondi: its going to be someting windows specific I suspect
<syncrondi> ok lemme get that
<syncrondi> http://pastie.org/668643
<lifeless> so that means its not getting a connection via ssh to bzr on the server
<lifeless> you might try BZR_SSH=paramiko
<lifeless> I believe our windows devs think that works better
<syncrondi> I can connect to my other server (that wasn't set up by me) just fine from that client, lifeless
<lifeless> ok
<syncrondi> that's why i thought it was something on the server side
<lifeless> well, the sudden disconnect error like that means we didn't get a handshake
<lifeless> if bzr is installed on the server
<syncrondi> it is
<lifeless> then its almost certainly client ssh issue
<lifeless> e.g. a new host key
<lifeless> plink doesn't prompt when its used in a subprocess
<syncrondi> that could be the problem
<syncrondi> the pw for my key and user are different, so perhaps I messed that up
<MTecknology> How can I uncommit a revision?
<MTecknology> I did bzr uncommit until I got back to where I wanted to be; then bzr push
<MTecknology> but it's still at r5
<bob2> you'll need to push --overwrite, I think
<bob2> (back up remote side first)
<MTecknology> thanks
<Peng_> bob2: There's not really any need to back up. If you screw it up, you can always fix it.
<GaryvdM> MTecknology: If other people allready have that revision, you may want to do bzr revert -r -2 bzr commit
<MTecknology> ooh; it works nice too
<MTecknology> the other guys are sleeping atm
<GaryvdM> MTecknology: Otherwise they will need to do pull --overwrite
<MTecknology> thanks :)
<MTecknology> I like how uncommit kept my local files the same
<MTecknology> that worked out very pretty :D
<MTecknology> awesome stopping point for tonight
<MTecknology> after using cvs, bzr makes me so so so happy
<MTecknology> after dealing with svn servers, bzr makes me so so so happy
<lifeless> we're glad :)
<wgrant> bzr-svn means I don't have to deal with svn when it's mandated at uni.
<wgrant> So no svn for me.
<MTecknology> wgrant: I didn't know that existed.. happy day
<MTecknology> wgrant: drupal.org might move from cvs to svn
<MTecknology> so some more saps will be making bzr work over svn jsut to make the rest of us happy
<Kamping_Kaiser> any step up is a good step *g*
<MTecknology> svn is much better than cvs, but using bzr over svn... nice
 * Kamping_Kaiser wonders how easy it will be to backport bzr-git from sid
<MTecknology> I should try bzr-git.. I've been playing with the ubuntu kernel some
<fullermd> MTecknology: By the way, you may recall we had a discussion a few months ago about mainline and revision numbering...
<MTecknology> but git isn't too bad
<MTecknology> ya?
<MTecknology> I remember that
<Kamping_Kaiser> it'll involve a new bzr, so its probably going to be annoying to backport. mutter. *puts on todo list*
<fullermd> MTecknology: I stole the transcript of that out of my logs the other day and posted it up, to save having to type it again next time the question came up.  Hope you don't mind.
<MTecknology> fnope
<MTecknology> nope*
<wgrant> Kamping_Kaiser: What are you running these days? Still gNewSense?
<MTecknology> hope it helps others too
<MTecknology> I should be sleeping......
<fullermd> That's what you said then too, as I recall   :p
<Kamping_Kaiser> wgrant: yeah, except the version based on Debian stable, not Ubuntu
<MTecknology> I'll get ~5hr if I'm sleeping within the next 17min
<Kamping_Kaiser> wgrant: gday and good evening, by the way.
<wgrant> Kamping_Kaiser: Indeed. Evening!
<Kamping_Kaiser> :)
<MTecknology> fullermd: you have others ask the same thing?
<fullermd> It comes up from time to time.  It's one of those things that's Obvious(tm) once you grok it, but kinda hard to see beforehand.
<fullermd> And it's not necessarily obvious that it's important to understand either, until you run into it headon.
<MTecknology> where's teh link?
<fullermd> http://bazaar-vcs.org/MatthewFuller/AboutMainline
<MTecknology> fullermd: you should s/USER/user/
<MTecknology> just a thought
<MTecknology> Thanks for the bookmark
<MTecknology> I think I'll read it again
<fullermd> I swear, someday I'll actually get time to distill that sorta stuff down into an actual doc...
<fullermd> I expect to get to it shortly after my pony arrives...
<Kamping_Kaiser> hehe
<MTecknology> lol
<MTecknology> if nothing else, the reader can have a laugh
 * Kamping_Kaiser goes to see how fullermd 's discussion of mainline fits with the documentation
<MTecknology> Kamping_Kaiser: I learned A LOT that day
<MTecknology> I was too tired to retain it the first read though. It was almost the afternoon
<MTecknology> that's when I started work at 02:00; I quit. Now I desperately need a new job
<MTecknology> If I don't get one, idk about next tuition
<fullermd> I specialize in blasting information at people too tired to retain it; that way I get to seem brilliant without all the hard work of actually being so  ;)
<Kamping_Kaiser> hehe
<MTecknology> this has been a while....
<MTecknology> sending a process to the background - never do that intentionally
<lifeless> Peng_: testtools is in 2a now
<Peng_> Eh eh?
<lifeless> Peng_: you're subscribed to lp:testtools; there isn't a list, but it just got upgraded to 2a
<lifeless> I presume you're subscribed for some reason ;)
<Peng_> Ah. I was wondering why you had singled me out.
<Peng_> lifeless: Cool. I'll upgrade. :)
<Peng_> Oh, the branch has moved too
<Peng_> Working tree formats that support content filtering have to disable some optimizations, right? Do they even do that when content filtering isn't being used?
<lifeless> Peng_: hardlinking, and yes, and there is a bug open I believe
<Peng_> Ah. I don't use hardlinking, so I guess that's okay.
<bialix> jelmer: ping
<jelmer> bialix: pong
<vadi2> Does bzr eclipse work with launchpad?
<Peng_> What would be Launchpad-specific about bzr-eclipse's workingness?
<vadi2> I think I read something about it not working with certain types of repositories. Anyway it's stuck uploading to a branch at 0% for a good while
<vadi2> Was wondering if anyone knew something
<Peng_> Oh. Well, I don't,
<vadi2> cancelling didn't work either, so my whole eclipse is frozen on it
<vadi2> @_@
<jelmer> bialix: pong
<bialix> hi jelmer
<bialix> I've encounter bug in bzr-svn with russian characters
<jelmer> bialix: that's been fixed :-)
<bialix> today?
<jelmer> 5 minutes ago
<bialix> you're fast!
<bialix> I'll try it
<bialix> jelmer: in which branch?
<bialix> all branches art https://code.launchpad.net/bzr-svn is at least 5 days old
<bialix> jelmer: btw, how's your subvertpy-based fast-export-from-svn?
<bialix> jelmer: are you still here?
<jelmer> bialix: yeah, sorry
<jelmer> bialix: it's in the main branch (launchpad only has mirrors)
<jelmer> bialix: http://people.samba.org/bzr/jelmer/bzr-svn/1.0
<bialix> aha, thanks
<jelmer> bialix: the subvertpy-based fast-export-from-svn should work
<jelmer> bialix: but it's only in the subverpty development branch
<bialix> I'm interested in this, I want to glue together 2 fast-import streams
<bialix> and then produce integrated branch
<jelmer> bialix: you can rebase as well
<jelmer> or import to bzr and then fastexport
<bialix> no, I think I can't
<bialix> I have CVS repo and forked svn repo
<bialix> they are unrelated, because svn repo is not converted from CVS
<bialix> so I need to figure out how to graft svn on CVS history
<bialix> I have success with cvs2bzr though
<bialix> now I think I need to get fast-import stream from svn repo and then join them somehow
<bialix> I'll try svn-import, bzr fast-export
<bialix> your bzr-svn branch is big
<bialix> 3200 revisions... still branching
<jelmer> yes
<bialix> incredible
<bialix> jelmer: does your 1.0 branch is compatible with bzr 2.0.1?
<bialix> or I need cherrypick?
<jelmer> bialix: it's compatible with 2.0.1
<bialix> good
 * bialix trying
<bialix> jelmer: it working, many thanks
<bialix> jelmer: after svn-import I have 2 branches with common history and 2 more branches w/o common history. is it normal?
<jelmer> bialix: it depends on what happened in svn
<jelmer> if there was common history in svn there will be common history in bzr
<bialix> ok, I'll aske the author of that repo
<bialix> jelmer: are you interested in the selftest result of bzr-svn on windows?
<bialix> there is many unicode-related failed tests
<jelmer> bialix: please file a bug
<bialix> and attach test.log there?
<jelmer> yeah
<bialix> ok
<bialix> jelmer: done: https://bugs.launchpad.net/bzr-svn/+bug/460613
<ubottu> Launchpad bug 460613 in bzr-svn "bzr-svn selftest failures on windows" [Undecided,New]
<igc> morning
<jelmer> 'moin igc
<igc> hi jelmer
<jelmer> igc: this is probably a configuration issue on my end, but I wanted to try out bzr-explorer the other day and it seems to segfault when I try to start it
<jelmer> "bzr qlog" segfaults in a similar way
<igc> jelmer: which version of qbzr as you running?
<igc> jelmer: it may me a PyQt thing in karmic which I beliebe bialix or garyvdm recently fixed
<jelmer> r1006
<igc> s/me/be/
<igc> believe
<jelmer> should I update my version of qbzr or my version of pyqt?
<jelmer> Never mind, updating my version of qbzr fixed it - thanks
<igc> jelmer: I'd try the latest qbzr
<igc> jelmer: you on karmic now?
<jelmer> igc: I'm on Debian sid/experimental
<jelmer> igc: but that should have mostly the same (and newer) packages as karmic
<igc> jlemer: right. I think pyqt 4.6 introduced some changes which triggered some issues
<igc> jelmer: when explorer runs, try Help > About to see the version of PyQt you're running
<jelmer> igc: Yeah, I'm indeed running 4.6
<rubbs> Hello all. I'm doing a presentation for my local Linux Users Group on DVCS's and I had a few questions about some things I had trouble finding in the documentation.
<jelmer> hi rubbs
<rubbs> First, I am a little fuzzy on what packing does. My guess is that it makes the storage of the meta data more efficient, but I'm unsure as to how that works.
<rubbs> Hello Jelmer.
<rubbs> Second, if one were to track binary files, and a small change was made (say one line in a .odt file) does the storage double, or can it keep a diff stored similar to text files?
<rubbs> The answers don't have to be bzr specific and any info on the differences about these questions in relation to git and hg would be greatly appreciated as well.
<lifeless> rubbs: packing in bzr < 2.0 just reduces latency
<lifeless> the db format consists of a number of files on disk
<lifeless> packing coalesces these files
<rubbs> ah thank you! That makes sense
<rubbs> does this mean it's safe to delete the packs in the "obsolete packs" directory?
<lifeless> in the 2a format it will recompress as well, as the compression algorithm isn't as fixed as it was
<lifeless> yes
<lifeless> that directory is used because there isn't such a thing as 'write barriers' on e.g. FTP/SFTP servers
<lifeless> and fsync() on ext3 is appallingly slow
<rubbs> Ok that makes sense to me then.
<rubbs> thank you
<rubbs> btw, I'd really like to thank the developers of bzr. I love it. I use it at work all the time.
<lifeless> now, for binary files
<lifeless> odt files are zipped
<lifeless> so the size of a commit of a small change in the doc will be a large [size of .zip] delta
<lifeless> sadly.
<lifeless> however, we'd like to allow unpacking and deltaing the text
<rubbs> That's what I thought, but I wanted to make sure before I said so in my presentation.
<rubbs> The reason I asked about the binaries, was I'm trying to find reasons why a normal Linux user (non-developer and non-admin) would like to know about bzr/git/hg. I'm having trouble coming up with usage ideas for them (if there is any) now that binaries are for sure not saving space for each version, I'm running out of ideas.
<lifeless> so, space isn't a reason
<lifeless> but organisation
<lifeless> backups
<lifeless> logging
<lifeless> 'what did I do yesterday'
<lifeless> etc
<lifeless> a VCS lets you rollback time, in a way that *some* apps allow, but not all - but the VCS lets you do it for all
<rubbs> That's a good point. I'll put that in for sure
<rubbs> Thank you for all your answers. I really appreciate it.
<nyu> rubbs: it also helps with coordination
<nyu> when different people want to modify the same code at the same time
<rubbs> I also had thought of the fact that you could push a "history" of any file to the next maintianer of whatever project you may be working on (even word docs)
<rubbs> got to go eat, but I'll be back. Thanks again.
<Meths> In a pull or update what does a * next to a file mean?
<lifeless> execute bit changed
<Meths> Ah, okay.  Thanks.
<igc> bbl
<jelmer> LOL
<jelmer> having both hg with hg-bzr and bzr with bzr-hg loaded is a bad idea :-)
#bzr 2010-10-25
<spiv> Good morning.
<yann2> is there a good reason why I wouldnt want to have +w for group on .bzr/checkout/dirstate ?
<yann2> I got problems by pushing because that file belongs to another user, although the group is set correctly, the user seems to need to write there
<spiv> yann2: Odd, I wouldn't have thought that push would need to write to that file at all.
<yann2> it might be the update I just added before actually :)
<spiv> yann2: the reason not to set group +w for that is if you don't want to allow other users in that group to tell bzr that files have been added or deleted, or that merges have been made...
<spiv> (Or that renames have happened, or conflicts resolved, etc, i.e. changes to the state of the checkout)
<spiv> Yeah, the update would make sense :)
<yann2> well users in the group can basically remove the .bzr folder :)
<yann2> I think the problem is that I do an automated update before doing a push... mmmmh, I ll look into that, thanks...
<RenatoSilva> how to diff between branches?
<spiv> D'oh, missed RenaotSilva
 * jelmer waves to spiv
<spiv> For the record: "bzr help diff"
<spiv> Hi jelmer
<spiv> Any progress on the bzr-svn/chk issue?
<jelmer> spiv: No, I need to follow up on your email but I haven't had the time to do so yet (travelling at the moment).
<spiv> I was CC'd on part of a thread, but don't know if I'm missing any discussion, and probably the discussion ought to happen on (or at least summarised on) the bug...
<spiv> Ah, ok.
<spiv> To UDS, I guess?
<jelmer> spiv: No, although I am in the US. Google Summer of Code mentor summit and GitTogether
<spiv> Oh, heh.
<spiv> So near and yet so far!
<spiv> (not that I'm at UDS this time either)
<jelmer> spiv: Are you going to the epic?
<spiv> I am
<jelmer> Cool
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | 2.3b2 is officially released, test it! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> hi all !
<GaryvdM> Hi vila
<vila> _o/
<mgz> I see jml has blizted a bunch of testtools things
<mgz> wonder if he'd prefer follow up bugs for continuing issues or reopening the current ones
<lifeless> mgz: new bugs
<mgz> will do, just found a mp for one of them and added a comment too.
<mgz> I guess I could subscribe to testtools somehow.
<mgz> ...might just put up some branches for these test failures, some of them are shallow.
<mgz> hm, Python doesn't expose raise. I guess kill covers it anyway.
<RenatoSilva> bzr qlog shows "Failed to decode using utf8, falling back to latin1", why?
<RenatoSilva> isn't bzr aware of the encoding of the file?
<abentley> RenatoSilva: bzr does not store any information about file encoding.
<abentley> RenatoSilva: Individual commands can guess the current file encoding, if they choose.
<RenatoSilva> if they choose? a command needing to print file content ought to do that, doesnt it?
<RenatoSilva> what's funny is that file is latin1 and diff in bzr qlog shows file as utf8 (drop down in bottom) but the chars are ok
<abentley> RenatoSilva: No, generally just emitting the bytes to the console works quite well.
<abentley> RenatoSilva: And for binaries, it's generally the only thing that can be done.
<RenatoSilva> hmm this is a bug, it tries to decode from utf8 and something defaults to latin1 (msg above), but the drop down is not updated
<RenatoSilva> by emiting the bytes to console you mean relying on python's guessing right
<abentley> RenatoSilva: Actually, it means relying on the console to have an encoding that is compatible with the files' encoding.
<RenatoSilva> where console is the python's stdout object
<abentley> RenatoSilva: The console is written to via python's stdout object, but it is not, itself, anything to do with python.
<RenatoSilva> by console you mean the terminal?
<abentley> RenatoSilva: yes, it is usually a terminal.
<radix> hey guys
<radix> is there an easy idiomatic solution to "the g+w problem" yet?
<radix> i.e., when I bzr push with bzr+ssh to a repo on a shared server, I want it to be group writeable
<radix> do I still have to use a debian "alternative" and a wrapper script? :(
<mwhudson> radix: i'm not aware of any new stuff in that area
<radix> ok
<radix> it'd be really nice if bzr serve had an option for that :)
<gthorslund> hi! is there a way in bzrlib to just check status for uncommitted changes. what I've found is http://people.canonical.com/~mwh/bzrlibapi/bzrlib.status.html#show_tree_status . so I guess it would be possible to put something on top of this, but is there a better way?
<arthur_> Hi. I have got two separate repo 'a' and 'b'. On 'b' a 'bzr pull' from 'a' was performed at some point, long ago. Now I want to consolidate 'a' and 'b' using 'bzr join' under the same repo and it fails since there are duplicates in the inventory. Any help to work around this problem would be appreciated.
<gthorslund> arthur_: can't you just pull all from 'a' into 'b'?
<maxb> arthur_: Could you explain a little more about the kind of history these repositories contain? It seems very odd that you would want to 'bzr join' repositories which already share ancestry. Why is 'bzr merge' not the right tool at this point?
<arthur_> alright. maybe I should rewind a little and listen to your suggestions. Here is the situation.
<arthur_> I just joined a company where they currently have ~20 repositories for various services.
<arthur_> We want to consolidate into a single repo.
<arthur_> while keeping the history. How should I proceed?
<dash> well, repos don't contain history so much as revisions :)
<arthur_> dash: well. you got my point
<maxb> arthur_: I think you should not proceed. It is natural and expected for various separate services to live in different repositories
<arthur_> maxb: there are much more tied than you think. Think of them as interfaces and implementations rather than services.
<maxb> So it truly makes sense for every developer who works on any of them, to work in a tree containing all of them, and to _always_ branch and tag them as a combined tree?
<arthur_> maxb: most changes are across 3-5 services... so with the current layout it is pretty complex.
<maxb> And the problem is that in the past, some services started as branches of other services?
<arthur_> maxb: that's right. one of them...
<maxb> hmm. This isn't going to be very nice :-/
<arthur_> which prevents me from doing a join. Believe me I was pissed when the very last join failed :)
<maxb> I cannot think of any workaround which will preserve the ability to follow all files history back to where it naturally began
<maxb> The only workaround I can think of is to effectingly delete and re-add the entire contents of one of the trees with duplicate file-ids
<arthur_> maybe I should do that on only the set of files that were common at the time
<arthur_> the pull was done pretty early (revno 6)
<lifeless> gthorslund: yes, you can layer things on top of that api
<lifeless> gthorslund: or the status command object
<lifeless> and there is now a hook for that too
<gthorslund> lifeless: since cmd_status is using show_tree_status that feels like a higher level then I need. looking at show_tree_status it appears to be nothing lower level that would be useful for me, so I guess show_tree_status would be right for me then.
<lifeless> gthorslund: depends on what you're trying to do, I guess
<gthorslund> lifeless: I'm looking at changing revert calls in bzr-bisect with update calls instead. if there have been local changes done I kind of end up with a mess of .moved files and other. (revert just removes local changes). I refuse starting without those changes being handled some way first.
<gthorslund> hi mtaylor!
<lifeless> gthorslund: iter_changes is probably what you want, then.
<gthorslund> lifeless: so http://people.canonical.com/~mwh/bzrlibapi/bzrlib.tree.InterTree.html#iter_changes would be my homework then, right?
<lifeless> yes
<lifeless> show_tree_status calls into this
<lifeless> if you want a crib sheet
<mtaylor> hi gthorslund !
<gthorslund> mtaylor: I'm hacking some python. hope that makes you proud of me ;-)
<gthorslund> lifeless: looks like it should give me enough of clues. thx
<mtaylor> gthorslund: excellent
<beuno> hi jam!
<beuno> got a minute to help me with meliae?
<beuno> jam, we have servers blowing up all over the place and we'd like to do some diagnosing
<mwhudson> beuno: jam is here at uds, so might not be very responsive
<beuno> mwhudson, well, lucky you, I hear you're quite involved in meliae as well  :)
<mwhudson> beuno: eh, a bit
<mwhudson> beuno: mostly a cheerleader :)
<beuno> mwhudson, what would be your guess if we only get a partial meliae dump?
<mwhudson> beuno: are you looking at jam's blog posts?
<beuno> mwhudson, I am
<mwhudson> beuno: missing a flush?
<mwhudson> beuno: how are you invoking meliae?
<beuno> mwhudson, this is what we have: https://pastebin.canonical.com/39038/
<mwhudson> beuno: meliae trunk?
<beuno> mwhudson, 0.1.3~1.CAT.8.04
<beuno> which I presume is some sort of monster we backported to hardy
<mwhudson> seems pretty recent
<mwhudson> although not tagged in trunk, naughty jam
<beuno> mwhudson, does that script look like we'd need to flush anything?
<mwhudson> no
<mwhudson> beuno: you get a nice 200 response back?
<beuno> mwhudson, not really, it complains about not being able to write to "+meliae"
<beuno> although it does write teh .json file
<mwhudson> beuno: ??
<beuno> mwhudson, scratch that
<beuno> I do get a 200
<mwhudson> beuno: i guess it's hard to say, but is the dump massively truncated or a little bit?
<jam> mwhudson: what needs to be tagged?
<mwhudson> jam: there's no 0.3.1 tag in lp:meliae
<beuno> 3:23 < beuno> (ami-hardy-i386)ubunet@ip-10-122-34-239:~$ wget http://127.0.0.1:8881/+meliae --no-check-certificate
<beuno> 13:23 < beuno> --18:23:00--  http://127.0.0.1:8881/+meliae
<beuno> 13:23 < beuno>            => `+meliae'
<jam> mwhudson: I don't think I did an official release, but I'm not positive
<beuno> 13:23 < beuno> Connecting to 127.0.0.1:8881... connected.
<beuno> 13:23 < beuno> HTTP request sent, awaiting response... 200 OK
<beuno> 13:23 < beuno> Length: unspecified [text/html]
<beuno> but I think it's something wrong with the return
<mwhudson> jam: oh ok
<beuno> 13:23 < beuno> +meliae: Permission denied
<beuno> 13:23 < beuno> Cannot write to `+meliae' (Permission denied).
<beuno> is what I get
<jam> mwhudson: I only have 0.3.0 here
<beuno> mwhudson, the process is ~800mb, and the dump is 13mb
<mwhudson> beuno: run that in a directory that you have write access to :-)
<beuno> I'd expect a lot to be missing
<mwhudson> or wget -O- or something
<beuno> mwhudson, heh, of course, wget wanting to write
<beuno> would that truncate the output file?   doesn't seem so
<jam> beuno: dump_all_objects() is what you want to be using, and will try to find everything
<mwhudson> it does seem unlikely
<jam> however, being 13MB is not strictly a truncated file
<beuno> jam, https://pastebin.canonical.com/39038/
<beuno> well
<jam> if you were reading and it said that there was broken content, *that* would be truncated
<beuno> I say it's truncated because at the end there is half a line
<jam> beuno: well, that is what I was pointing at.
<beuno> yes, that's exacly what I get
<beuno> :)
<jam> so there was an issue that os.fdopen().flush() wasn't actually flushing if you used the raw FILE * pointer
<jam> which was fixed (checking the rev)
<jam> beuno: you have "0.1.3" that is 0.1 series, not 0.3 series
<jam> definitely upgrade to trunk
<beuno> aha
<beuno> ok
<beuno> that's a good first step
<mwhudson> doh!
<jam> if it is just the truncation thing, that should make a big difference
<mwhudson> beuno: sorry for missing that :)
<beuno> mwhudson, no worries!  this is a lot of progress!
<jam> beuno: Flush was fixed in the 0.2.1 ish timeframe
<beuno> thanks jam, mwhudson, I'll update the server and see what happens
<jam> beuno: I believe mwhudson did something similar but returned the dumped content to the url rather than dumping it to disk, I'm curious why you prefer this method.
<jam> (certainly from a remote user, it would be nice to get the raw content back.)
<beuno> jam, I'm actually locally on the server, but what was there was this django middleware to trigger the dump
<jam> beuno: any luck?
<beuno> jam, just managed to get trunk on the server
<beuno> waiting for some more tests that are going on to finish
<beuno> and will try again
<jam> beuno: sounds good. If you need help debugging the dump, let me know.
<beuno> jam, will do, thanks. Hope to try again in 10-15
<jam> you aren't in UDS, right?
<beuno> no  :(
<beuno> missed it this time around
<jam> np
<jam> would have been nice to sit over your shoulder while you worked with it
<beuno> yeah, would of been great
<beuno> I'll break more servers next uds you are there too
<jam> beuno: well if necessary, there is always "screen"
<jam> anyway, switching rooms, bbiab
<beuno> jam, so, with the new version, they don't seem to truncate, although they do seem small
<beuno> they are smaller than expected
<beuno> but size may not matter after all
<jam> beuno: if you have very large strings, we only dump 100bytes of a given string
<abentley> jam, I am thinking that my algorithms in https://dev.launchpad.net/Code/BranchRevisions are slightly wrong, in that they assume that there is a single mainline_parent entry for each revision.
<jam> if you have lots of small objects, then the dump is usually about the same to larger than mem
<jam> abentley: IIRC, it could still work, you would just search multiple tips concurrently
<jam> I'd have to look closely again, though
<jam> beuno: there is also 'dark' memory that I've run into, which can be a lot more than I would like
<abentley> jam, this affects "Branch page" and "Merge proposal page".
<dash> jam: oh, that reminds me, thank you for writing meliae
<dash> jam: it has made my life easier. :)
<jam> zlib.decompress and zlib.compress tend to have a lot of buffers that aren't particularly accessible, for example
<jam> dash: I'm very happy it has proven useful to you. It certainly helped me. Feedback always welcome, btw
<dash> jam: well the only thing i'd change is the license. ;)
<jam> dash: to?
<abentley> jam: I worry that a given revision might not be the head of a mainline_parent_range.  Maybe the simplest thing is to accept ANY maninline_parent_range where the revision is mentioned.
<dash> something shorter :) gplv2 or apache/mit/etc
<jam> dash: why v2 vs v3?
<abentley> jam: i.e. not the range table per se, but any entry in mainline_parent_range where the revision id is correct.
<jam> (v3 is canonical policy unless there is specific reason to do otherwise, so if you have specific reasons, I'm willing to listen)
<abentley> jam: argh, "mainline_parent"
<dash> ah, i wasn't aware of that.
<jam> ok
<dash> jam: my real preference is permissive licenses, personally. it's just that gplv3 makes people in legal very nervous :)
<dash> anyway, it's not like i'm distributing it to customers, so whatever :)
<abentley> jam, maybe "SELECT range FROM mainline_parent_range WHERE revision = %s ORDER BY DIST DESC LIMIT 1"?
<abentley> jam, err "SELECT range FROM mainline_parent WHERE revision = %s ORDER BY DIST DESC LIMIT 1"?
<jam> dash: atm meliae is designed more as a helper than something you would bundle in your package, though
<jam> so the license doesn't matter as much
<jam> abentley: well that query doesn't require it to be the head
<dash> jam: Sure.
<dash> like i said, not a big deal.
<abentley> jam, right, because there might not be an entry where it's the head.
<abentley> jam, so this way at least you find the entry where it's closest to the head.
<jam> beuno: any interesting insight ?
<beuno> jam, well, not from the meliae dump
<beuno> it seems normal
<beuno> which is baffling
<beuno> since we see that processes memory grow over 1gb
<beuno> but, we found a piece of code that, when removed, stops the server from dying under a small amount of load
<jam> beuno: 1 are you sure you are dumping while it is at its peak, 2 it could be memory fragmentation
<jam> 3) ISTR that Thread objects take up a lot of memory, which may not be tracked
 * beuno nods
<jam> there are other possible hidden memory allocations
<beuno> right
<beuno> I am slowly getting into this part of the world
<beuno> so no good ideas yet
<beuno> the other problem we have
<beuno> is we can't really reproduce it locally
<jam> beuno: if the dump is small enough, you could bz2 it and put it somewhere and I'll give it a look
<beuno> only on ec2 instances on staging
<beuno> jam, sure, it's 14mb and it should shrink quite a bit
<beuno> will email
<beuno> jam, sent
<mgz> jml: in case you didn't see it, I can make those SIGINT tests pass, just whether or not you think the ctypes hackery is worth it.
#bzr 2010-10-26
<peitschie> hiya everybody :)
<spiv> Hi :)
<spiv> mgz: thanks so much for reviewing doxxx's mergetools patch
<spiv> vila: I just used run_script for the first time, and it basically Just Worked for me.  Nice!
<vila> spiv: cool !
<vila> hi all !
<peitschie> hiya vila :)
<vila>  _o/
<vila> alleluia, bzr-2.2.1 made it into maverick-updates :)
<peitschie> vila: congrats!  was it as painful as it sounds?
<vila> no, not painful, but since I didn't understood the process ,I was impatient :)
<peitschie> vila: hehe... i understand that feeling :S
 * KombuchaKip needs get Stallman to consume more raw fruits and vegetables.
<rryan> hey.. I screwed up and accidentally pushed a branch I was working on to my projects trunk because its remembered location was the trunk. I then pulled this push from my trunk branch and so I don't have a copy of what the trunk was before I pushed it. Nobody else has pulled this yet, so I'd like to push --overwrite the Launchpad trunk back to what it was. How can I restore my repository to the state it was in at a certain revision-spe
<rryan> sorry this is all on Launchpad
<rryan> like, in my history the trunk head was 'rryan@mit.edu-20101024063322-8b3jtqyn77k5c32t'
<vila> rryan: bzr push --overwrite -rrevid: rryan@mit.edu-20101024063322-8b3jtqyn77k5c32t
<vila> It seems I can't connect to lp via ssh right now though
<vila> Can anybody confirm or is it only me ?
<vila> right, confirmed in #launchpad
<rryan> thanks vila, all better now
<poolie> hi vila?
<vila> poolie: hey ! Wow, you're up ?
<poolie> yeah, up a bit early
<poolie> hi jam?
<jam> hi poolie
<jam> Having a bzr sprint at UDS next spring sounds good. I just need to double check if it overlaps with my wife's travel
<jam> I think that was april, though
<poolie> cool, thanks
<poolie> Kareem can come :)
<poolie> we have plenty of +easy bugs
<jam> :)
<jam> beuno: if you are around, I just checked the meliae dump you sent me, and it only sees 11MB of content... :(
<jam> you seem to have a lot of "function" objects (15k), but that really doesn't explain 1GB of ram
<beuno> jam, we don't know either  :/
<jam> beuno: what code is this? (do I have access to it?)
<beuno> jam, this is a django server from ubuntu one
<beuno> I can surely give you access to it
<jam> beuno: I don't know django code particularly well. I don't see any smoking guns just looking at the memory dump
<jam> meliae could only find about 113k objects, which is pretty small.
<beuno> yeah. we are puzzled
<jam> beuno: what version of python?
<jam> I think you mentioned that this is only reproducible on the server/ec2 ?
<jam> I assume this dump is from that process while it was at high mem?
<beuno> jam, 2.4, and yes, this dump is from when the usage is high
<jam> beuno: there is a possibility w/ 2.4. Do you do any heavy math?
<jam> integer or floating point?
<jam> IIRC 2.4 allocates integer arenas, and never returns that memory to the os
<jam> so any sort of "do lots of stuff here, and then stop" will still have a lot of memory
<jam> it can be re-used by the process, but it isn't returned to the os
<beuno> jam, not really. It's actually pretty simple, we stream files from amazon S3 and do basic db requests to return some data
<jam> beuno: would you be holding the content?
<jam> I certainly don't see big strings here
<jam> Are there any custom extension types? like S3 apis, or db apis, etc?
<jam> I'm assuming the "Method", "InterfaceClass", "Implements", etc classes are all coming from zope.interfaces code?
<beuno> we do have custom S3 apis
<beuno> I don't think we use any zope
<jam> beuno: are they Python "extensions" ? (C level code, not Python level code)
<beuno> jam, nope, this is all python
<beuno> we thought about that as well
<beuno> but no c extensions
<mwhudson> i _guess_ you could try running it under valgrind
<mwhudson> but i guess it only happens in production?
<jam> beuno: twisted uses zope.interfaces, and you certainly have 'twisted.python.zipstream' loaded
<beuno> mwhudson, right, can't reproduce it locally
<beuno> jam, right, we may from twisted
<jam> (total of 773 modules loaded, so I don't know everything, but there is certainly a lot loaded)
<jam> beuno: psycopg2.extensions
<beuno> yes, we use psycopg2
<jam> beuno: are you using python2.4 locally as well?
<jam> beuno: you are also using protocol buffers, would those have compiled extensions?
<jam> (it looks like python code, but it is something that might be involved)
<jam> 'ubuntuone.web.musicstreaming.views', sounds like something that could have large content blobs
<beuno> jam, no, 2.6 locally
<jam> beuno: that could certainly be the isuses
<jam> issue
 * beuno nods
<jam> protocol buffers could be doing lots of integer ops
<beuno> ubuntuone.web.musicstreaming.views accesses S3 to streaming multi-mb files
<beuno> aha
<jam> though it should be "peak ops"
<jam> for example, encoding a multi-mb file into a protocol buffer
<jam> would be a lot of 4-byte integers
<jam> beuno: also 64-bit vs 32-bit could be something
<jam> beuno: I also don't 100% guarantee meliae works on python2.4
 * beuno nods
<beuno> ha
<beuno> ok
<jam> I know some of the code is 2.5, but I think the scanner is 2.4 safe
<beuno> so a good thing to do is push for the lucid upgrade
<jam> beuno: it sounds useful, but I won't guarantee it solves your problems :)
<beuno> heh
<mwhudson> uh
<beuno> jam, it's a lot of new things to chase, thanks
<mwhudson> protocol buffers might have leaks?
<jam> beuno: my biggest suspect is python2.4
<jam> mwhudson: python2.4 doesn't return integer allocations back to the os
<jam> so it always allocates the peak integer arena
<jam> which should be reusable (without "leaks")
<jam> but you might have a big peak
<jam> beuno: which would show up as VmPeak being high, but VmRss being much lower
<beuno> it does seem like we get peaks, and in fact see some MemoryErrors now and then
<beuno> we usually see virtual mem at 1.5gb, and rss at 250mb
<jam> beuno: well, VM includes mmaped files, etc
<jam> I mean 'cat /proc/PID/status' and the VMPeak vs VMSize or VMRss sort of thing
<jam> if python2.6 "fixes it" the Peak would be the same, but the active size would be lower
 * beuno nods
<beuno> I'd have to look at it again
<mwhudson> the integer blocks might show up in /proc/$pid/maps?
<mwhudson> i can't remember how all this works
<mwhudson> beuno: you should try using pypy instead :-)
<beuno> heh
<beuno> I have not written 90% of this code, so it's been intersting trying to debug it
<jam> beuno: so it looks like the Implements and InterfaceClass may be protocol buffers stuff
<jam> beuno: clearly you need to look closely at that 10% then :)
<beuno> yes, that makes sense
<beuno> jam, heh. It has been failing for over a year
<beuno> so the only thing that can be blamed on me is increased usage
<jam> beuno: you've peaked my interest, if you want to give me a peek at the code
<jam> beuno: I can blame anything I want on you. Doesn't mean I'll be correct :)
<beuno> heh
<beuno> jam, I will add you to the team now
<jam> beuno: so the idea behind python2.4 vs 2.6 is that the actual peak is happening at some point in the past
<jam> and we are just holding on to the memory now
<jam> but it isn't in "active" objects, so meliae can't find it
<jam> I wonder about doing evil hacks and walking the actual PyInt buffers
<aaronfay> I have been using the bzr_upload plugin, fantastic btw, but I have a problem: the first time I uploaded I used a location that was wrong, now when I specify a new location, then use saved location it uses the old one, how can I change that?
<lifeless> --remember
<mgz> funny post on the mailing list. I wonder how large the set of users is that we render bzr inaccessible to by using such things as 1) configure 2) https 3) the gpl
<mgz> it might only be him.
<aaronfay> lifeless: Ah, fantastic.  And now I see it in the manpage also, I couldn't find it before.  Thanks.
<lifeless> mgz: 'not using configure' ?
<mgz> he even linked us to his website where he explains why he doesn't like configure.
<mgz> I... didn't try and understand too hard.
<lifeless> yeah
<lifeless> I can understand
<roryy> didn't know one had to run ./configure for bzr
<mgz> I looked at the message again, and he appeared be be complaining about bzr using python... which uses configure
<roryy> ah
<roryy> logical
<roryy> the taint of configure
<AJenbo> Hi i'm trying to pull a branch of openarena, but i keep getting a permission denied error :(
<AJenbo> Permission denied (publickey).
<AJenbo> Do i need to identify my self or some thing?
<AJenbo> bzr branch lp:ubuntu/maverick/openarena
<poolie> AJenbo, hi, there's a bug on the server, it should be fixed soon
<poolie> AJenbo, hi, i think it's bug 666642
<ubot5> Launchpad bug 666642 in Launchpad Bazaar Integration "incorrect data check branching lp:openobject-addons (affected: 2, heat: 10)" [High,Confirmed] https://launchpad.net/bugs/666642
<poolie> we're going to look in to it
<AJenbo> ok, it's been there for a while now
<AJenbo> any workarounds?
<peitschie> mornin all :)
<maxb> AJenbo: I think poolie may have mixed up two projects with "open" in their name, I can't see how that bug can apply to your issue
#bzr 2010-10-27
<maxb> What is the actual format of dump-btree --raw on a .rix /
<maxb> ?
<spiv> maxb: in what sense?  you mean where is there a description of how to parse that format?
<spiv> maxb: the docstring for bzrlib.btree_index.BTreeBuilder is probably a decent reference
<maxb> seems so
<maxb> I'm peeking at that corrupt openobject branch
<spiv> (Despite the embarrassing mistake in the definition of the _SIGNATURE part...)
<maxb> There's something very dodgy in the .rix of the last pack - it contains CR bytes!
<spiv> Ooh, wacky!
<spiv> After decompression?
<maxb> after dump-btree --raw
<thumper> spiv: hi
<thumper> ErrorFromSmartServer: Error received from smart server: ('error', 'Error -3 while decompressing: incorrect data check')
<thumper> spiv: is there a repair thing I can use on the server side?
<thumper> spiv: or are we talking restore from backup?
<maxb> That sounds like the branch I was looking at :-)
<thumper> maxb: maybe
<thumper> maxb: more like hopefully
<thumper> maxb: which branch are you looking at?
<spiv> thumper: "that corrupt openobject branch"
<thumper> spiv: yeah
<maxb> ~openerp/openobject-addons/trunk to be precise
<maxb> well that's disconcerting.
<maxb> I spliced the latest pack out of pack-names, and attempted to branch a revision left in the result.
<maxb> It still died
<wallyworld_> quick ? - i have a lw co of launchpad branch db-devel. bzr info says submit branch is devel, i want to change it to db-devel. i tried editing the branch.conf with submit_branch = ... but no luck. any ideas?
<spiv> maxb: hmm :(
<maxb> Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch
<maxb> wallyworld_: I don't usually use lw cos, but I would tend to assume that they would not even have a branch.conf
<spiv> wallyworld_: did you edit the .bzr/branch/branch.conf in the checkout?  That doesn't exist.  It only applies to the branch.
<spiv> maxb: ouch
<wallyworld_> spiv: i think i created a branch.conf file with submit_branch= in it hoping that would work
<wallyworld_> my workflow:  bzr checkout --lightweight bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel db-devel
<wallyworld_> this creates a local copy which i then branch from as required: bzr branch db-devel mynewbranch
<maxb> Unless your development workstation is in the launchpad datacentre, I wouldn't recommend using a lightweight checkout
<wallyworld_> what i do is create a "master" lw co and then have several sandboxes which i use bzr switch with
<wallyworld_> eg devel-sandbox. this one has the working tree
<wallyworld_> so i have separate working tree and branch directories and i reuse the working tree dir when i switch between branches
<wallyworld_> so i reduce local disk space by only having 1 or 2 full working tree directories
<wallyworld_> at least that's how i was recommended to do it when i started :-)
<maxb> Oh you're doing all of this inside a shared repository aren't you
<wallyworld_> i've been mainly working with devel not db-devel but just need to get my db-devel branch to accept that i want the submit_branch to be db-devel not devel
<wallyworld_> yes
<maxb> Why use --lightweight at all then?
<wallyworld_> i think i did a bzr repo-init or somwthing in my top level lp-branches dir
<wallyworld_> that's how i was recommended? :-)
<wallyworld_> the idea is to only have one or two full working trees on disk and share these amongst the branches you are working on by doing a bzr switch as required
<maxb> IIUC, you can only set things like submit_branch on a branch. And a lightweight checkout is not a branch
<wallyworld_> oh, ok. so bzr info showing devel being the submit branch must be a default or somwthing
<wallyworld_> i also tried hacking the .bazaar/locations.conf file
<wallyworld_> it seems you can create config blocks for branches in there
<wallyworld_> with things like push_location:policy = appendpath etc
<spiv> wallyworld_: a lightweight checkout is a reasonable thing to use
<spiv> wallyworld_: but make it a checkout of a (treeless) branch you create in your local shared repo
<spiv> wallyworld_: rather than of a ~launchpad-pqm branch that you can't possible 'bzr commit' directly too
<spiv> wallyworld_: and then you can use the local branch's branch.conf (or create a locations.conf entry that covers that *branch*)
<wallyworld_> spiv: i have --no-trees or something set globally. so i was just pulling from the wrong place initially?
<spiv> wallyworld_: the key thing here being that "submit branch", like most things, is a setting on a *branch*
<spiv> wallyworld_: so a checkout doesn't have a submit branch itself, it just asks its branch for that setting, just as it asks it for the revision contents, etc.
<wallyworld_> spiv: yes. that's why i have a "master" db-devel branch locally which i then branch from as i need to
<spiv> wallyworld_: that's not the workflow you described
<spiv> wallyworld_: your workflow description starts with you making a local *checkout* of db-devel
<wallyworld_> seems like i messed up getting the initial local copy of db-devel then?
<spiv> (A lightweight one at that!)
<spiv> You want a local branch of db-devel
<wallyworld_> yeah, i've had the devel one for so long i forgot how to "seed" a new one
<spiv> You can probably just go to your 'db-devel' checkout and do "bzr reconfigure --branch"
<spiv> I'm not certainly this is the cause of your immediate problem, but it's likely to be related.
<wallyworld_> cool. thanks. i'll give it a go. and the branch i've already peeled off that db-devel will be ok still?
<spiv> Yes.
<spiv> Well,
<spiv> It'll probably think it's parent branch is the one on launchpad rather than your local mirror.
<spiv> Check the 'bzr info' output.
<wallyworld_> will do
<wallyworld_> it would be great to have a way for point bzr to a top level projects directory and have it tell you things like what shared repos there were, what types of branches etc
<wallyworld_> a global overview if you like
<spiv> Yes, that would be nice.
<spiv> A bit tricky because there's not really any concept of a "top level projects directory" or anything like that in bzr except by convention.
<wallyworld_> spiv: the reconfigure fixed the "master" db-devel but the one i am using shows parent_branch=~projects/lp-branches/db-devel (correct) but submit_branch=~projects/lp-branches/devel (incorrect)
<spiv> Well, you should be able to fix that from the branch.conf or via locations.conf
<wallyworld_> with the overview thing, you would just give it a top level directory and it would decend to all the subdirs and see what i would find
<spiv> (vila is working on a config system improvement that will be able to tell to exactly where a given setting is coming from)
<wallyworld_> :-)
<wallyworld_> spiv: i edited the branch.conf for my working branch (it already had parent_location=../db-devel) and added submit_location=../db_devel but bzr info still has submit_branch wrong
<wallyworld_> thanks for the help and your patience btw :-)
<spiv> wallyworld_: the setting is "submit_branch"
<spiv> not "submit_location"
<wallyworld_> tried that too, but found something
<wallyworld_> in ~/.bazaar/locations.conf, there is a [/home/ian/projects/lp-branches] section as well as [/home/ian/projects/lp-branches/db-devel]
<wallyworld_> it seems the stuff in [/home/ian/projects/lp-branches] overrides the other settings
<wallyworld_> i would have though it was the other way around
<wallyworld_> and both of these seem to override what's in the local branches.conf file ??
<wallyworld_> everything seems upside down
<spiv> Yes, locations.conf overrides branch.conf: the idea is that branch.conf might not be under your control (e.g. for a remote branch) but locations.conf always is
<wallyworld_> ah, ok. makes sense now. thanks.
<spiv> So it allows a branch owner to specify what they consider reasonable defaults for some things, but users can still set their own policy.
<wallyworld_> so i guess i don't really need a locations.conf if i am working locally
<spiv> Well, I actually go the other way:
<spiv> I just do everything in locations.conf
<spiv> Because for me it's simplest to just have one place with all the settings,
<spiv> but more importantly because locations.conf allows you to set something once for many branches
<wallyworld_> ok. but then i would need new config sections for each new local branch i create eg  [/home/ian/projects/lp-branches/xxxx] ??
<wallyworld_> i have a section for db-devel but stuff i branch from my local db-devel doesn't seem to reflect that when a do a bzr info
<spiv> wallyworld_: that's what the foo:policy = appendpath is about
<wallyworld_> ah. makes sense. i need to go off and rtfm. sorry
<wallyworld_> i just copied those settings from an existing file and never really knew what they were for
<spiv> e.g. I have push_location = lp:~spiv/bzr  and  push_location:policy = appendpath  for the directory I keep my bzr branches in
<wallyworld_> light bulb goes on. thanks again for your help. really appreciated.
<spiv> Not a problem.
<spiv> It's a bit too fiddly :/
<spiv> It works well once you know how to use it, though.
<wallyworld_> the reason it's important is that i improved the bzr intellij plugin to allow change tracking against the submit branch and if the submit branch is wrong it sort of defeats the purpose
<wallyworld_> yeah, as a new user to bzr, there's a lot to learn
<wallyworld_> but i do really like bzr more than others i've used
<thumper> maxb: ping
<thumper> <maxb> Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch
<thumper> maxb: was that the openobject-addons?
<maxb> thumper: hi, and yes. I have noted on the bug 666642
<ubot5> Launchpad bug 666642 in Launchpad Bazaar Integration "incorrect data check branching lp:openobject-addons (affected: 3, heat: 16)" [Critical,Confirmed] https://launchpad.net/bugs/666642
<thumper> maxb: yep, ta, just commenting now
<dOxxx> howdy
<dOxxx> got a question about blackbox testing in bzr... how would I validate that a bzr command is changing the bzr config correctly, without affecting the user's bzr config?
<spm> *** FYI. codehost will be done shortly for an update. actual downtime should be < 30 seconds ***
<spm> taking it down now
<spm> and should be fine again
<jam> spiv: are you sure the email you replied to isn't just a troll?
<spiv> jam: hmm
<fullermd> Eh, he's always seemed honest to me.  Quirky nutcase, but an honest quirky nutcase.
<spiv> jam: grumpy certainly, but googling does indeed suggest they have their own SSH implementation.
<jam>  you mean lsh, or something else?
<spiv> Something else.
<spiv> Possibly something private.
<spiv> A quick google didn't find it (although it did find a reference to it)
<spiv> Given their attitude to the GPL I doubt they'd use GNU's ssh :)
<spiv> dOxxx_away: the bzr TestCaseInTempDir class should insulate you from the user's config
<spiv> dOxxx_away: grep for 'config' in the existing tests, perhaps
 * spiv -> lunch
<dOxxx> thanks spiv
<dOxxx> night all
<Glenjamin> hi guys, has anyone experienced a "too many open files" error hosting the smart server over http using mod_wsgi?
<Glenjamin> After much googling the theory is that there are some leaking file handles, and the long-running wsgi process ends up hitting the limit
<Glenjamin> but i have no idea how to test that theory
<maxb> You should be able to prove/disprove that easily with lsof -p PID#
<Glenjamin> i did lsof and counted the number of files for root, www-data and the user wsgi runs bzr as - all three were within the limit
<Glenjamin> but the requests still got the error
<Glenjamin> oh, progress
<Glenjamin> it apepars after each request the number of handles to bzr.log increases
<Glenjamin> which means it's not bzr, it's my wsgi wrapper
<Glenjamin> oh balls, i'm opening the bzr log on every request - due to not understanding how wsgi works at all
<ssandberg_> hi! is there a way to cherry-pick a changeset (bzr merge -r from..to) and include the changeset comments?
<poolie> sorry, no
<poolie> only as text
<ssandberg_> poolie, ok, that's a pity. do you know if there are any plans to add this? is there a bug report?
<poolie> yes there is
<abentley> james_w: What's the difference between NestPartInstruction.target_subdir and ChildBranch.nest_path ?
<poolie> meeting now about launchpad for upstreams in #ubuntu-uds-bonaire1
<james_w> abentley, where it is coming from and where it is going
<abentley> james_w: Remember, ChildBranch.nest_path is unset for NestPartInstructions.  What is the equivalent of ChildBranch.nest_path for NestPartInstruction?
<abentley> james_w: Is NestPart.subpath the equivalent of ChildBranch.nest_path ?
<abentley> james_w: FWICT, target_subdir is the TARGET-DIR in "nest-part NAME BRANCH SUBDIR [TARGET-DIR [REVISION]]" and nest_path is the TARGET-DIR in "nest NAME BRANCH TARGET-DIR [REVISION]", so why aren't they the same variable?
<ovnicraft> hi folks, i get myaddons/ in branch but i want to create a branch for each dir inside myaddons/ as a multibranch and keeps sync, there is any support in core of bzr?
<poolie> not in core, i suggest you use scmproj
<ovnicraft> poolie, its supported in lp?
<poolie> what would you want lp to do with it?
<Tak> is the cleanup_now() method no longer used in the bzrlib command api?
<james_w> abentley, I don't know offhand
<abentley> james_w: I see that TARGET-DIR is optional for nest-part.  What do you do if you want to specify a REVISION, but not a TARGET-DIR?
<james_w> abentley, you specify a target dir
<abentley> james_w: what target dir would you specify?
<roryy> hrm
<roryy> does anyone use wine on linux to run bzr selftest?
<poolie> roryy, yes, i do
<poolie> not automatically, but from time to time
<poolie> it's good
<roryy> cool
<roryy> do you use wineconsole ?
<poolie> i mostly use just 'wine python ./bzr ....'
<poolie> there are some list posts about it
<poolie> may also be something in the testing gudie
<roryy> cool, ta
<lvh> Hello
<lvh> Is there a way to push a bzr branch to svn?
<lvh> Ideally, I'd like to create a bzr repo from svn, branch (with bzr), and then put that branch on the svn repo.
<dash> yes.
<dash> it pretty much Just Works.
<Glenjamin> if you install bzr-svn (a plugin), it just works :)
<poolie> roryy, some tests probably fail but bugs or patches are very welcome
<roryy> poolie: cool.  mgz got a funny result on win with a merge i proposed, but i can't reproduce it under wine
<poolie> meeting now about bzr and ubuntu in #ubuntu-uds-curacao12
<mgedmin> suppose I have a checkout, not updated lately
<mgedmin> how can I find how what would be changed if I run 'bzr up'?
<mgedmin> I don't see a --dry-run in bzr help up
<vila> mgedmin: bzr missing
<mgedmin> bzr: ERROR: No peer location known or specified.
<Glenjamin> bzr missing :bound
<mgedmin> is there a short name for "the branch I'm a checkout of", or do I need to copy and paste--- thanks for preempting my question with an answer!
<mgedmin> awesome
<poolie> bzr st -r :bound ?
<poolie> mgedmin, you could file a bug asking for 'update --dry-run'
<mgedmin> I'm surprised you don't already have a bug "every command should have --dry-run"
 * Tak bzr info --dry-run
<poolie> we may?
<Tak> is UDS the reason that nobody at canonical is responding to email?
<mgedmin> https://bugs.launchpad.net/bzr/+bug/37829
<ubot5> Launchpad bug 37829 in Bazaar "dry-run option for pull, merge, etc (affected: 0, heat: 0)" [Low,Confirmed]
<vila> merge has --preview
<poolie> Tak, probably :)
<poolie> any mail in particular?
<Tak> ok - at least there's a reason ;-)
<poolie> i've been dealing with some
<Tak> myself and a coworker have sent some commercial-launchpad-question -related emails this week
<Tak> tsk, it's even in orlando - a year ago I would have dropped by
 * mgedmin wishes 'bzr unbind' wouldn't just forget the url
<jelmer> mgedmin: I think it's a feature, that way you can easily unbind and rebind
<mgedmin> oh, it remembers!  I assumed it forgot because 'bzr info' didn't show any related branches
<mgedmin> I could've done bzr pull :bound --remember
<mgedmin> instead of copying and pasting the url from my scrollback
<Remaille> hi, I have some code in a folder, I did a bzr init
<Remaille> and now I want to upload all of it into LP
<Remaille> I did a : bzr push lp:name
<Remaille> and i have : "No new revisions to push."
<vila> Remaille: may be you should create a revision now before pushing: bzr add ; bzr commit -m 'import blah' ; bzr push
<Remaille> This branch is empty.
<Remaille> hum ok
<vila> Remaille: then there is nothing to push
<poolie> Tak, i'll ping people
<Tak> well - I don't want to make trouble
<Tak> but otoh, I /do/ want everyone here to be blown away by launchpad's awesomeness
<Remaille> vila, ok thanks a lot
<Remaille> I use bzr once every two years :-)
<vila> Remaille: start by using it once a year then :)
<Remaille> :-)
<Remaille> and write down on a txt file what you told me :-) maybe you answered the same question from me two years ago ? ;-)
<vila> Remaille: I can't remember that far, that's why I use a DVCS ;)
<mgedmin> bug 1
<ubot5> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/1)
<mgedmin> oops, wrong channel
<james_w> abentley, any target dir you want. You probably want the same as the source dir, as that is what you get if you specify nothing
<abentley> james_w: So generating a manifest for "nest-part packaging lp:~foo-dev/foo/packaging debian" would produce "nest-part packaging lp:~foo-dev/foo/packaging debian debian $REVISION"
<james_w> abentley, hmm, not sure, might be a bug
<abentley> james_w: I think that is what it has to produce.  Based on the code, I think it actually produces "nest-part packaging lp:~foo-dev/foo/packaging debian $REVISION", but that would cause $REVISION to be interpreted as TARGET-DIR.
<james_w> I think it would produce "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION"
<abentley> james_w: There is a conditional on whether target_subdir is None.  If it is None, I believe it is completely excluded.
<james_w> right
<abentley> james_w: Which makes me think it would not produce "None" in "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION"
<james_w> right, you are correct
<abentley> james_w: I can patch it.  Do you think the "debian debian" version is the correct manifest output?
<james_w> abentley, https://code.edge.launchpad.net/~james-w/bzr-builder/fix-nest-part-manifest/+merge/39466
<abentley> james_w: that will not roundtrip perfectly.  Is that acceptable to you?
<james_w> why won't it?
<abentley> james_w: get_recipe_text will convert "nest-part packaging lp:~foo-dev/foo/packaging debian" into "nest-part packaging lp:~foo-dev/foo/packaging debian debian"
<abentley> james_w: if you wanted to make the roundtripping perfect, you would need to do "if target_subdir is None and revid_part is not None"
<james_w> abentley, I agree, but my test is saying different
<abentley> james_w: branching...
<james_w> abentley, I mean the second test I just wrote to fix that issue
<james_w> damn, my fault
<james_w> abentley, just pushed a new revision
<abentley> james_w: r=me
<abentley> james_w: thanks.
<james_w> thank you
<james_w> need a release?
<abentley> james_w: no, at this point we're not using manifests in anger.
<mtaylor> GAH
<mtaylor> bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-737'), ('unversioned executability', 'new-738')]
<mtaylor> I thought that was fixed like a million years ago
<mtaylor> http://paste.drizzle.org/show/103/
<abentley> mtaylor: sorry.
<mtaylor> abentley: do I just suck?
<abentley> mtaylor: This would be a case where one side deleted a file and the other side changed its executability.
<mtaylor> abentley: oh, lovely
<mtaylor> abentley: is there anyway for me to find out which file?
<mtaylor> abentley: because I can gladly fix it in one of the trees
<abentley> mtaylor: I think this requires setting a breakpoint where the exception was raised and then calling TreeTransform methods.
<james_w> mtaylor, we probably didn't squash all the cases
<james_w> mtaylor, can you tell me how to reproduce?
<mwhudson> BZR_PDB=1 should get you to an appropriate pdb prompt?
<abentley> mtaylor: tt._new_name.get('new-737') or tt.tree_id_paths.get('new-737') should give you the name or path.
<lvh> What are things like "lp:" called? Can I add my own?
<mwhudson> lvh: its a directory service, and yes
<lvh> mwhudson: Aha, thanks
<abentley> lvh: mostly, you need to write a plugin to do so.
<mwhudson> yeah, you need a plugin
<lvh> right, but I can just use the bookmark plugin and cover most use cases, right?
<mwhudson> yeah, the bookmark plugin handles many cases
<abentley> lvh: that will work great for static assignments.  For dynamic ones, like expanding prefix:* => http://example.com/*, I have bzr+ssh://bazaar.launchpad.net/~abentley/%2Bjunk/openlookup/, but it's not documented.
<lvh> abentley: Aha, thank you. I will take a look at that
<mtaylor> james_w: grab lp:~mordred/drizzle/test-elliott-release and then http://wc220.com/drizzlefiles/drizzle7-2010.10.02.tar.gz and then do bzr merge-upstream --version=2010.10.02 drizzle7-2010.10.02.tar.gz
<abentley> lvh: basically, you need to add a section to bazaar.conf like so: http://pastebin.ubuntu.com/520925/
<mwhudson> i have a plugin that lets me say things like bzr pull -d plugin:svn
<mwhudson> but sadly, not on this machine
<mtaylor> abentley:
<mtaylor> (Pdb) print tt._new_name.get('new-737')
<mtaylor> None
<abentley> mtaylor: okay, try  tt.tree_id_paths.get('new-737')
<mtaylor> *** AttributeError: 'TreeTransform' object has no attribute 'tree_id_paths'
 * mtaylor pokes around...
<abentley> mtaylor: sorry, leading underscore.
<mtaylor> yup. see it
<mtaylor> hrm
<mtaylor> u'drizzled/set_var.cc'
<mtaylor> so, in trunk, set_var.cc got renamed to sys_var.cc and then a new set_var.cc was added
<james_w> mtaylor, what's your version of bzr-builddeb?
<mtaylor> (repeat for set_Var.h
<james_w> I'm pretty sure that's one of the cases that I fixed
<mtaylor> james_w: builddeb 2.2.0
<lvh> abentley: Aha! Despite the fact that that *does* look sexy, unfortunately I can't use things that are undocumented or unsupported (yay policy)
<james_w> mtaylor, you need 2.6 or maybe 2.5
<mtaylor> james_w: should I just pull lp:bzr-builddeb
<james_w> mtaylor, what's your platform?
<james_w> that would work
<lifeless> ubuflu
<mtaylor> just branched - trying
<mtaylor> lifeless: hah
<lifeless> mtaylor: available now
<mtaylor> (actually, this is on a squeze box)
<mtaylor> lifeless: where r u?
<abentley> lvh: Well, undocumented I could fix, but unsupported is tricker... :-)
<lifeless> hallway?
<mtaylor> lifeless: will find - honestly not _important_ - more an idea - coming
<mtaylor> james_w: nope. still exception
<james_w> mtaylor, ok, I'll take a look
<mtaylor> james_w, abentley : also, the set_var.cc was modified in the same rev it was renamed in - so it may not be obvious to merge-upstream that renamed-set_var.cc is the same file
<mtaylor> is there anything you can think of I can do to my local tree to un-confuse merge-upstream? (like re-commit something or something?)
<abentley> james_w: are you using RenameMap to guess renames?  That should be able to detect a rename if the file hasn't changed excessively.
<james_w> abentley, we are not
<james_w> mtaylor, not without understanding the error better, sorry
<mtaylor> james_w: ok. cool
<abentley> james_w: ah.  Well, you might find it useful, and if not, I'd be interested to hear why.
<mtaylor> abentley: well... the file _did_ change excessively ...
<mtaylor> abentley: perhaps I should have done the rename as a commit and then the change as a commit... ?
<abentley> mtaylor: I don't know enough about bzr-builddeb to be able to answer that, sorry.  james_w?
 * mtaylor is now probably being annoying... will just try things
<mtaylor> just for the record, splitting rename and new content into different commits no helpie
<ovnicraft> h folks, maybe its OT but i want to know how add a user to push in my branch in lp?
<mtaylor> ovnicraft: it's more a question for #launchpad - but you want to create a user in launchpad and then that user can push branches to launchpad quite easily
<ovnicraft> mtaylor, yes but add a user i fixed thi teams
<ovnicraft> mtaylor, thx
<mtaylor> abentley, james_w: fwiw, I reverted the four files to a version before the rename, did the merge-upstream, then reverted the files to the version _after_ the rename - and all seems ok
<james_w> mtaylor, I'm getting somewhere with the debugging as well
<mtaylor> james_w: excellent :)
<james_w> it's actually a duplicate id problem, not unversioned executability
 * mtaylor likes causing complex problems...
<james_w> I'm not sure how to tell where the trans ids that I have came from though
<james_w> mtaylor, plugin/haildb/tests/r/insert_null.result plugin/haildb/tests/t/type_float.test
<james_w> any idea why they would be getting involved?
<mtaylor> james_w: gosh no
<mtaylor> james_w: they shouldn't be involved with this at all
<mtaylor> james_w: unless both changes hit trunk as part of the same merge
<lvh> Does svn-push no longer exist? Is it just push-with-an-svn-url now?
<dash> correct
<lvh> bzr push svn://host/repo/branches/new-branch-1234 will just work?
 * lvh is extremely skeptical, having played with hg-svn today
<dash> lvh: yes but it might make some svn users unhappy
<lvh> dash: Why is that
<lvh> dash: I'm trying to merge changes into twisted trunk without using svn (if possible)
<dash> lvh: if they use tools (like combinator) that expect branching to occur in a different revision from branch content adding
<dash> lvh: if you use svn cp to create the branch _then_ push to it, all will be right with the world
<lvh> oh okay
<dash> the only other twist is that there's 'dpush' which pushes without bzr metadata on the revision
<lvh> dash: Which for twisted is good?
<dash> lvh: glyph will probably complain if you don't use it
<dash> but i've ignored him and you can too ;)
<glyph> use dpush
<glyph> otherwise you will put corrupt revision metadata in the twisted repository
<glyph> you might have been able to get away with it last week, but we are facebook friends now, so I know where you live.
<dash> oh, hi.
<lvh> glyph: my lp thing used to have my address quite accurately
<glyph> lvh: More generally, dpush is the stealth way to go.  it does some rebasing and loses a bunch of information, but if you use it, it is basically indistinguishable from using the stock svn client, from the perspective of everyone else on the project.
<glyph> this is what it looks like if you use a regular push: https://trac.calendarserver.org/changeset/4434
<lvh> glyph: Okay so the way to not piss you off, working from scratch: bzr branch thesvnrepo; bzr branch to feature-1234; hack hack hack; create remote svn branch; bzr dpush svn://host/repo/branches/feature-1234?
<glyph> lvh: except +ssh, basically, yes.
<glyph> and that is the way I work these days, because of the aforementioned trac ugliness.
<dash> well
<glyph> Frankly if trac could hide those, and bzr never choked to death on its own metadata, I'd be fine with a normal push.
<dash> better to do svn cp then 'bzr branch' or 'bzr co' from the branch url
<dash> so that when you push you don't get "omg these branches have diverged"
<glyph> pull first!
<glyph> although man
<glyph> there really needs to be a 'bzr sync' or something, so I can just run that in a hurry, get on a plane and then do the merge later
<lvh> dash: Wait what pull where
<lvh> dash: Also does that work if I start from lp:twisted
<glyph> I hate the workflow where it's wait-wait-wait-okay connected to remote server wait-wait-wait-okay oops diverged, TIME TO WAIT AGAIN
<dash> lvh: instead of creating a local bzr branch from trunk, create a local bzr branch from the svn branch you're targeting
<lvh> glyph: works well IRL: "hey can you look at this piece of code" "um okay, what's wrong" "nothing I just wanted to make sure I merged first."
<lvh> dash: Right okay. And bzr-svn is smart enough to make that work if everything else is a bzr repo? I already have a shared repo with a "trunk" directory which is lp:twisted
<glyph> oh man
<glyph> lp:twisted is not a good scene
<glyph> don't use that
<lvh> Okay
<glyph> or... wait maybe I'm wrong, I haven't used it in a while.
<dash> i think it uses bzr-svn now
<glyph> Do the revision numbers match up with our branch-hosting bzr mirror?
<dash> lvh: the main thing is that if you branch from lp:twisted it won't prime bzr-svn's svn rev cache
<dash> glyph: AFAIR yes
 * dash checks.
<lvh> So, starting from scratch: bzr init-repo Twisted; cd Twisted; bzr branch svn://svn.twistedmatrix.com/svn/Twisted/trunk trunk; svn cp create-a-branch; bzr brach that-branch awesome-feature-1234; hack hack hack; bzr dpush?
<dash> yeah, looks like it.
<dash> lvh: yes.
<lvh> Okie, thanks
<glyph> we also have a bzr mirror
<lvh> glyph: Is it okay to use that or is that too a source of bad things
<dash> it's created using bzr-svn
<dash> as is lp:twisted
<dash> they should have the same history as anything you branch from svn yourself
<glyph> they match exactly
<glyph> basically they're an optimized way of bootstrapping
<glyph> although eventually you end up needing to prime your svn revision cache anyway
<glyph> because they lag
<lvh> Hm.
<lvh> dash: Sorry, I disconnected. If lp:twisted and the twisted bzr mirror are both made with bzr-svn, why is one a bad idea and the other not such a bad idea? SVN metadata?
<dash> lvh: glyph was remembering the old version of lp:twisted from before bzr-svn worked real good
<dash> it's fine now
<lvh> dash: So, I can still use my shared repo with trunk I stole from lp:twisted?
<dash> yep
<lvh> revno: 15682
<lvh> svn revno: 30182 (on /trunk)
<lvh> dash: So, to actually merge the change, I can just do it on bzr and push to svn trunk, since everyone knows trunk exists, and that won't piss glyph off?
<dash> lvh: i forget whether dpush sets svn:mergeinfo or not
<dash> glyph: re trac: "hide_properties = svk:merge, bzr:file-ids, bzr:merge, bzr:revision-info"
<peitschie> mornin everyone :)
<glyph> dash: okay, I just told a guy that
<glyph> dash: do you want to tell exarkun?
<dash> glyph: in the 'browser' section, specifically
<glyph> dash: now you've done it.  #calendarserver
#bzr 2010-10-28
<spiv> Morning folks.
<mgz> evenin' spiv.
<jelmer> good arvo spiv
<peitschie> hiya spiv :)
<peitschie> i'm good morning as well :P
<peitschie> i just merged a bunch of uncommitted changes from an svn working directory to a bzr branch... i just felt congratulations were in order to jelmer and co for such awesome escape routes
<twb> I happened to run bzr for the first time in a while, and it's complaining:
<twb>  /usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
<fullermd> https://bugs.launchpad.net/paramiko/+bug/271791
<ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 5, heat: 22)" [Medium,Triaged]
<spiv> twb: probably due to old paramiko?
<twb> spiv: NFI; I'm running sid, probably no paramiko at all
<twb> Sorry, I have python-paramiko 1.7.6-5 installed
<spiv> bzr doesn't use Crypto.Util.randpool directly at all.
<twb> OK, no worries.
<fullermd> Doesn't have to be old.  TTBOMK there IS no fixed paramiko release.
<fullermd> Last I looked, there wasn't even a merged fix.
<spiv> (And only tries to import Crypto in the test suite)
<spiv> fullermd: oh, :(
<twb> Is there a straightforward way to get the equivalent of hg's "[extension] color =" (i.e. --color=auto in diff/log -p)
<fullermd> Nope, still nothing landed since April.
<fullermd> http://github.com/robey/paramiko/commits/master
<jbowtie> twb: bzr cdiff in plugin 'bzrtools' should do what you want
<twb> I don't want to run a different command, I want it to be automatic when I run normal diff
<spiv> bzr alias diff=cdiff
<spiv> There's almost certainly room for improvement.
<twb> I'd also like it to auto-run the pager, like git does by default and (somehow, I can't see where) I have enabled for hg
<twb> cdiff also doesn't give me color in log -p, which is more important to me than diff
<twb> (Usually I only use diff via emacs' vc, which does its own colourizing.)
<twb> Hmph, "bzr help bzrtools" isn't very helpful.  It just emits the module docstring
<jbowtie> twb: I think the pager is bug 213718
<ubot5> Launchpad bug 213718 in Bazaar "Use bzr-pager by default (affected: 3, heat: 41)" [Medium,Confirmed] https://launchpad.net/bugs/213718
<twb> Ah, bzr-pager isn't in released versions?
<jbowtie> It's not installed by default as far as I know ('bzr plugins' will tell you if its installed)
<twb> Nod
<twb> At least it's straightforward to add plugins to bzr
<jbowtie> twb: Adding color to log output would be bug 597626
<ubot5> Launchpad bug 597626 in Bazaar "bzrlib should support color (affected: 2, heat: 4)" [Wishlist,Confirmed] https://launchpad.net/bugs/597626
<jbowtie> twb: looking through the mailing list poolie is on record says that cdiff should be merged into standard diff
<twb> Ew, it assumes SGR compatibility?
<twb> It should ask terminfo
<twb> Yeah, it does assume SGR
<jbowtie> twb: If you work up a patch, I'll review it.  :)
<twb> Eh, I only use bzr for one customer repo.  Actually contributing is too much like work
<jbowtie> Well, if you can comment on the bug it'll help me when I actually get around to implementing it.
<jbowtie> That way I can at least do it right.  :P
<vila> hi all !
<mgz> morning vila.
<vila> mgz: hey !
<mgz> do you know what the current advice is for antivirus software messing with file moves is?
<twb> don't run it?
<mgz> that doesn't sound persuasive.
<mgz> but by all means put that in bug 663957 for me twb.
<ubot5> Launchpad bug 663957 in Bazaar "TransformRenameFailed and Unprintable exception (affected: 1, heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/663957
<bob2>  /wii mgz
<mgz> is that advice or a mistyped irc command, and are you the IBM Rob Weir?
<vila> mgz: I don't fully disagree with twb :-/ I can't see what bzr can do about such unspecified random behaviours.... Retry once ?
<vila> Can the anti-virus be parametrized to ignore files under .bzr ?
<mgz> I thought there was something about telling things not to look in certain dirs, but haven't dealt with any of this myself.
<bob2> mgz: sorry, was just wondering if you were the submitter (and no, a different one)
<vila> And retrying... in TreeTransform... talk about a nightmare :-/
<mgz> bob2: nope, just the commenter on that bug.
<vila> as for not using rename() to move directories....
<mgz> I'm not certain that bug is down to a background process locking the files, though it was my first guess, but can't think of much useful to suggest to track the problem down.
<vila> I'm pretty sure there are bugs around the exception handling for renames involving non-ascii paths though, str(exception) is evil
<mgz> yeah, I've got a branch for that.
<mgz> needs tidying up and the testtools version bump.
<mgz> (the str(exception) stuff, that is)
<vila> mgz: you mean you modified bzrlib.errors.py to not use str(e) or something else ?
<vila> Eeerk, battery leak is bad isn't it ?
<mgz> ...they tend to contain nasty things, yes
<vila> AA battery, no smell though
<mgz> ^yeah, fixed that unprintable exception stuff.
<vila> mgz: you rock ;)
<vila> 5000mAh AA batteries were too good to be true :-/
 * spiv EODs
<idlecool> hi people.. i have a trouble using bzr
<idlecool> how to pull changes from the trunk if the current copy has a modified config file and doesnot intended to change
<GaryvdM> idlecool: Just pull. Bazaar will maintain that working change.
<GaryvdM> idlecool: The only thing which will make that change go away, is bzr revert
<idlecool> okay... let me check..
<idlecool> okay! i am working on a webframework, i need to install it to use it
<idlecool> i did a checkout of the latest release and made modifications to the config file.
<idlecool> now while i commit i dont want the config files to get updated nor the cache files which are created while using the framework.
<idlecool> i just want the files which i have modified to get update while a merge, commit, push
<vila> idlecool: if you intend to keep these changes around, the safe way is to commit them and then *merge* from trunk instead of pulling
<vila> oh, you want to stay compatible with trunk
<vila> you are on your own then, it's always tricky to keep uncommitted changes floating around
<vila> you may want to try looms but you will still need to remember to always commit in the right thread (well, that's what looms are for anyway)
<GaryvdM> I use loom to do this, but I would not recommend it for a beginner.
<idlecool> okay! if i dont do a bzr add then new temp/cache files will not be added.. am i getting right
<GaryvdM> idlecool: Yes
<idlecool> the only thing left will be my config file
<idlecool> ok! then i should have  a look at loom then. hope i get it working soon. :)
<idlecool> anyways thanx :)
<awilkins> peitschie, I may have missed some ; but I find that on Windows a combo of Powershell or cygwin bash + the qbzr stuff makes for a nice compromise for missing Tortoise
<peitschie_> awilkins: hiya :)... i have another programmer that swears by that too!
<awilkins> There is TortoiseBZR of course, but I find it makes my machine thrash on the working trees that I manage
<awilkins> That was a long while ago I tried it last though
<peitschie_> i agree about tortisebzr... i like the context menu stuff... always turn off the icons atm
<peitschie_> my poor computer has enough trouble running a few instances of VS2010 lol
<awilkins> Mostly I develop on Java right now ; the bzr-eclipse plugin is OK, not really tried the one that uses qbzr
<awilkins> For C# I use SharpDevelop
<peitschie_> ahh... i did try that once a while back
<peitschie_> (bzr-eclipse)
<peitschie_> sharpdevelop... i'll need to check that out
<Tak> there's monodevelop-bzr for monodevelop ;-)
<awilkins> The guts of VS with a much smaller install footprint
<peitschie_> oh... thats cool!  I never knew
<awilkins> It's not VS - it's an IDE
<peitschie_> i've never actually been a big fan of IDE plugins for my source control tho i must say
<awilkins> I find the cli more fluent
<peitschie_> awlikins: +10 lol
<peitschie_> i am also much less liable to miss files and such
<awilkins> And bad experiences with the VSS plugin for VB6 have biased my judgement
<peitschie_> and with bzr's auto-rename and intuitive add behaviour.... cli is very speedy and convenient
<peitschie_> *only* thing i'd find it useful for is inline annotation somehow
<peitschie_> but i dont know of many plugins that do that :(
<Tak> MD trunk has a nice annotation view
<Tak> one sec, I'll screenshot
<peitschie_> oh... thats pretty hot!
<peitschie_> i'm glad i hang out here... all neat kinds of dev tools i never realised existed!
<Tak> screenshot, finally: http://i.imgur.com/5LNLX.png
<peitschie_> *clicks*
<peitschie_> dagnamit
<peitschie_> i can never look at my poor poor VS the same again :(
<peitschie_> i will need to forever be unsatisfied that is isn't monodevelop >_<
<peitschie_> thanks for that Tak :)
<Tak> another nice thing is that it has that unified UI for svn, bzr (with monodevelop-bzr) and git (sort-of, so far)
<GaryvdM> Tak: Are you the author of monodevelop-bzr?
<Tak> jelmer, me, and palango, I believe
<GaryvdM> Oh - ok - it looks cool.
<Tak> yeah - I'm dogfooding it daily, when I'm working on bzr-hosted projects
<peitschie_> Tak: is it a lot of work to build MD from trunk?
<Tak> mmm, depends on the OS
<peitschie_> tak: ubuntu in my private time which is wen i'd be using it :)
<Tak> on debian or ubuntu, it's pretty straightforward: apt-get build-dep monodevelop; git clone git://github.com/mono/monodevelop; cd monodevelop; ./configure && make
<peitschie_> ahh... very straightforward!  thanks :)
<Tak> I think on ubuntu, you'd have to download and build mono-addins 0.5 from mono-project.com as well
<peitschie_> thanks for the help Tak... i'm still trying to get it all to get together... but will tackle more tomorrow :)
<peitschie_> hopefully tomorrow night i can get shiny new MD going :D
<Tak> np
<ronny> hi
<ronny> anyone knows if bzr-svn can be coerced into importing svn exernals as if they where part of the file tree
<lamalex> Can I ask tarmac questions in here? I'm trying to set up the command plugin to run test suite via make check, but "verify_command = ./autogen.sh; make check" doesn't work. It can't find the commands to run. Anyone have a tip?
<lamalex> I assume the problem is ./
<eydaimon> how can I set up bzr to use my own pager when doing bzr diff?
<zooko> Hm, I need this but for bzr: http://twitter.com/bos31337/status/28072630844
<vila> zooko: bzr-fast-import ?
<vila> https://edge.launchpad.net/bzr-fastimport
<glyph> hey guys
<glyph> that thing that always happens to me when I try using bzr for something new just happened to me again
<glyph> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps
<glyph> please tell me that there is a workaround for this
<dash> hmm yeah i think i got this earlier
<dash> you're not gonna like this
<glyph> I bet I won't
<glyph> dash: hit me
<dash> glyph: bzr reconcile --canonicalize-chks
<dash> i think
<dash> and you need 2.3b2, if i remember right
<glyph> looks like https://bugs.launchpad.net/bzr/+bug/485601
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 3, heat: 15)" [Medium,Incomplete]
<dash> yeah i may be getting this confused with a different thing.
<zooko> vila: thanks!
<glyph> dash: As bad as my experiences have been with release versions of bzr, my experiences with versions that have 'b' in the name have not been better :)
<glyph> I am going to see if any workarounds might help me
<fullermd> Well, we could make some 'a' releases instead.  That might help, since 'a' is better than 'b', right?
<dash> heh
<glyph> well, blowing away my shared repository and re-fetching everything seems to have fixed things for now
<vila> poolie: ping
<vila> anyone in touch or wired with poolie, thanks for forwarding ;)
<vila> jam: ping
<jam> i vila
<jam> hi
<jam> what's up?
<vila> jam: hey ! Can you forward my ping to poolie ?
<jam> if I see him. he isn't right next to me
<vila> bah, it's the revolution here, there are killing kings all over again...
<vila> jam: ok, thnks
<vila> well, kings... slight exaggeration, they cancelled trains...
<jam> vila: pretty much the same thing as beheading your national leader....
 * vila drools
<fullermd> If they behead a king WITH a train, THAT I'd pay to see.  That would be awesome.
<vila> jam: oh, by the way the ping's TTL is a couple of hours at least
<vila> fullermd: I wonder what kind of filter you have.... I *thought* I'll catch you with the kings but..... less than 3 minutes ? Wow
<fullermd> Well, there's certainly no filter between my brain and my mouth; ask anybody I know.  So it stands to reason I must have REALLY good filters elsewhere, to balance things out.
<vila> . o O (That's soo off-topic while not answering the question that it should be masterpiece of its kind...)
<fullermd> My work here is done.
<vila> > bash.org
<jam> vila: fullermd has no filter, he just sits on a socket which streams all irc conversation 24x7
<fullermd> Direct to the brain.  It makes my ear itch when people use caps lock.
<vila> SAY WHAT ?
 * fullermd scratches frantically.
<eydaimon> how can I set up bzr to use my own pager when doing bzr diff?
<mgz> eydaimon: bzr-pager and the PAGER env var
<eydaimon> my PAGER env is set. I don't seem to have a bzr-pager command
<mgz> it's a plugin. you can get it from lp:bzr-pager if you don't already have it.
<eydaimon> seems like an odd thing not to work with by default. but installing now
<eydaimon> [~ki]% bzr st
<eydaimon> bzr: ERROR: [Errno 2] No such file or directory
<eydaimon> I get errors no matter what I do after installing the pluign
<eydaimon> maybe it doesn't work with 2.2.1
<mgz> pastebin the traceback from you .bzr.log?
<eydaimon> ok, one sec
<eydaimon> http://gist.github.com/652419
<mgz> okay, that's pretty clear.
<mgz> do `$PAGER --help` in your console?
<mgz> whatever you've got in the var doesn't seem to be on your path.
<eydaimon> well, this is my pager: col -b | view -R -
<peitschie> mornin everyone :)
<mgz> is setting a shell expression as your pager even valid?
<mgz> just put that in a sh script on your disk somewhere as set your PAGER to that path.
<eydaimon> mgz: been using it for years without an issue :)
<mgz> it may be valid, or just happen to work with most things, I was just suggesting a way you could make bzr-pager work for you now.
<fullermd> You've been using it where it got expanded by the shell  :p
<mgz> feel free to file a bug against it tool.
<mgz> -l
<fullermd> Exec'ing that string is unlikely to work well, though...
<eydaimon> mgz: yes, appriciated :)
#bzr 2010-10-29
<glyph> If I'm working on one branch on a few different development machines, but I'm periodically rebasing it, is there a reasonable way to keep it in sync?
<lifeless> pull ?
<glyph> won't pulling fail if I've rebased on a different machine?
<lifeless> if you add --overwrite, no
<spiv> Hmm, BranchBuilder is just a bit more verbose than necessary
<spiv> I think I'll try making the start_series() unnecessary.
<lifeless> one way might be to glue that into setUp ()
<spiv> Hmm, perhaps.
<spiv> The with statement would be nice to have :/
<spiv> Hmm, actually, in this specific case I don't need to call start_series at all, as I'm only using build_commit.
<glyph> spiv: do you want a repo that can repro that bug mentioned above?  I notice you commented on it a while ago
<spiv> glyph: I should pester jelmer and/or jam
<spiv> glyph: the cause of that bug is actually understood now I think
<spiv> glyph: peitschie provided enough data privately that we diagnosed it, but the diagnosis ended up happening in private emails and not copied into the bug despite my nagging :(
<spiv> glyph: it boils down to: the way bzr-svn regenerates bzr revs from an svn repo can vary in a way that violates assumptions in bzr
<glyph> spiv: can you give me a hint as to _when_ this variation occurs?
<glyph> I would very much like to continue using bzr as my svn client
<glyph> but periodically having to trash all of my data is potentially a problem :)
<spiv> glyph: ghost revisions
<spiv> glyph: when the svn repo hasn't had all the bzr revs referenced pushed to it
<spiv> glyph: then later gets some of those pushed
<glyph> huh
<glyph> I could swear that's not what happened here
<spiv> glyph: it can change the metadata in other inventories that bzr-svn generates
<spiv> Well, it might be a different bug, or my recollection of the diagnosis might be a bit off.
<spiv> glyph: here's a test:
<spiv> glyph: do you get an error when branching from the svn repo into an entirely new bzr repo?
<glyph> no.
<spiv> And if not, do you get an error when merging/pull between that new repo and a previous bzr repo that has some of the same revs.
<glyph> yes?  I think?
<spiv> Ok, those are the expected answers :)
<glyph> okay so my question is
<glyph> what do I avoid doing?
<spiv> If it's not the same bug it's certainly related.
<glyph> The thing that confuses me is that I don't believe any of these bzr revs were ever pushed to svn
<spiv> glyph: there's zero bzr metadata in your svn repo?
<glyph> oh
<glyph> there is some.
<spiv> No bzr file-ids, no bzr rev-ids?
<glyph> Should I go delete it all?
<glyph> I tried to avoid any getting in there, but dash is always like "no, bzr-svn works great, I haven't seen a traceback in like a week" push push push
<spiv> Well, if you delete it you'll have a different problem, but perhaps a better one.
<spiv> You're using dpush or whatever the rebasing thingy is, IIRC?
<dash> yeah i'm not a good neighbour
<glyph> Personally yes
<dash> OTOH i've been using bzr-svn in a different svn repo with no problems... but i'm the only bzr user there :)
<glyph> spiv: this actually happened about 2 hours before I was going to decide that bzr-svn _did_ work well enough to start putting bzr metadata in Twisted's repository :)
<spiv> So I think the effect that has is that it basically rebases the local bzr revs after the push to svn... the key thing here is that you have a bzr rev that is meant to be equivalent to an svn rev.
<glyph> (we recently configured trac to be amenable)
<glyph> spiv: right.  it's like rebase++ though, right?  because it has a bit more information than rebase
<glyph> (I say this because I tried some experiments with 'rebase' and then 'push' and the effects were radically different)
<spiv> And if you delete the bzr metadata from svn, that bzr rev won't match anymore.  I don't know enough about the exact details of bzr-svn and dpush to say what will happen, it might be minor irritant, or it might be an equivalently bad situation to the current one.
<spiv> If the effect is "after stripping bzr properties bzr-svn will generate bzr revs with the same id as before but different contents", you have basically the same class of problem.
<spiv> If the effect is "after stripping bzr-svn generates entirely new bzr revs with new ids", then you just have basically a rebase situation, where there's a conflicting alternate history, but at least no actual violation of bzr's data model.
<spiv> FWIW, my current guess is that bzr-svn can be fairly easily fixed to not vary the way it generates this data.
<spiv> Hmm, I should get some lunch.
<glyph> OK I will have more questions once you have lunched :)
<peitschie> glyph: you still around?
<glyph> peitschie: hello!
<peitschie> glyph: hi :)... did you have any joy getting the answers you were looking for (i.e., bzr-svn with multiple devs using bzr)?
<glyph> peitschie: Sort of :)
<glyph> I'm about to give it a try and see what happens
<peitschie> glyph: cool.  let me know if things don't go well for you as we have a process here that is working ok for several devs... but it requires a shared network repository of some sort and a bit of careful planning (robust enough once the devs are trained tho lol)
<spiv> glyph: so, more questions?
<glyph> spiv: well, I can't reproduce the problem without my special messed-up repo
<glyph> so I'm going to assume that I did something bad
<fullermd> That's my motto.
<peitschie> lol fullermd
<peitschie> glyph: the problem is actually reasonably straight forward to reproduce if you check out the bug report :)
<peitschie> glyph: having said that tho... you generally need to separate devs (or deliberately be working on two different repos) to trigger it
<peitschie> glyph: main reproduction steps are:
<peitschie> 1. dev1 merges branch into svn
<peitschie> 2. dev2 updates from svn
<peitschie> 3. dev2 attempts to merge change directly from dev1's branch somewhere
<peitschie> 4. Profit!
<glyph> peitschie: yeah, that's definitely not what I was seeing
<glyph> basically what I saw was
<glyph> I got a bzr branch from svn trunk on two different machines
<glyph> made a bzr branch of that on one
<glyph> checked in one revision to that branch
<glyph> and then attempted to get the branch from another machine
<glyph> but when I got new repos on the defective machine and tried again, everything worked.
<spiv> glyph: "I got a bzr branch from svn trunk on two different machines" â did you get both those branches from SVN at the same time?
<peitschie> glyph: and it will.. up until the other machine checks in again
<peitschie> glyph: in _theory_ (i.e., if this is the same bug :)  ), wen the other machine checks in ,and the first updates again... any attempts to trade between them will break once again
<glyph> spiv: No.  I'm not really sure when I updated svn from each.  I _am_ pretty sure that no bzr-props-adding activity was going on between them though.
<spiv> glyph: interesting, but other svn activity may have gone on?
<dash> weird, i've never seen this
<spiv> glyph: btw, if you want to find out if a set of repositories have this inconsistency waiting to bite you:
<glyph> spiv: Yes.
<dash> i've seen some odd messages from bzr-svn use from time to time, but it's always gone away after doing a pull from svn into a new branch in my repo, then pulling from the fresh branch into my normal one
<spiv> glyph: grab lp:~spiv/bzr-crosscheck/integration and install it to ~/.bazaar/plugins/crosscheck, then you can do "bzr cross-check REPO_A REPO_B ..."
<glyph> spiv: what does that do?
<spiv> glyph: (that plugin almost certainly has rough edges, but it's one of the things I've been using to diagnose this sort of problem)
<glyph> Oh, hrm
<glyph> Here's an interesting clue.
<glyph> our repo has 2 URIs
<spiv> glyph: it basically finds all the inventories that exist in more than one repo (out of the N repos you pass it)
<glyph> http://svn.calendarserver.org/repository/calendarserver and http://svn.macosforge.org/repository/calendarserver
<spiv> glyph: and then compares them to see if they have the same contents
<spiv> Because bzr assumes that records with the same key in multiple repositories have the same contents.
<spiv> And if that assumption is violated then problems like this are to be expected :(
<glyph> spiv: OK!
 * spiv notices he has some uncommitted, experimental improvements to bzr-crosscheck.  He commits and pushes them up to a new branch...
<spiv> Wow, where did the week go?
<mgz> somewhere in america I think spiv.
<yann2> hello! When a developer pushes to a branch, the files are set with permissions = 644 .... How can I change the umask so I get 664?
<Tak> usually the default umask on a unix box is set in /etc/profile
<Tak> or you can set the umask for a given user in its ~/.profile
<Tak> now what's the best way to test a trunk branch of bzr-explorer (when I already have one installed with my system bzr)?
<GaryvdM> Tak: bzr branch lp:bzr-explorer ~/bzr-explorer
<GaryvdM> Tak: export BZR_PLUGINS_AT=explorer@/home/tak/bzr-explorer
<Tak> aha
<ChrisCauser> Hello everyone. Have I come to the right channel for bzr-svn support?
<GaryvdM> ChrisCauser: Yes
<ChrisCauser> Thank you. I am not having a problem as such, merely an annoyance.
<ChrisCauser> I have an svn repo with different branches. I have two mirrored in a local bzr repository
<ChrisCauser> (As in I checkout'd them, not branched them)
<GaryvdM> BZR_PLUGINS_AT has made my life much easier. Before, I had to use a horrible mixture of lightweight checkouts, treeless branches, bzr switch, and BZR_PLUGIN_PATH
<GaryvdM> Kudos vila!
<Tak> that does sound horrible
<ChrisCauser> I make changes in the DEV branch just fine, and merge them into my trunk branch
 * Tak add kudos as well
<ChrisCauser> The only problem is I cannot pull from DEV to trunk
<ChrisCauser> I get a diverged error.
<GaryvdM> ChrisCauser: Yes - you probably need to merge, not pull
<ChrisCauser> I know the histories are not in sync because of the merges I have done in the past, but is there a way to put that behind me (as it were) and allow pulling
<ChrisCauser> Because a merge squashes it for SVN
<peitschie_> ChrisCauser: is the dev branch an actual svn branch?
<GaryvdM> ChrisCauser: maybe pull trunk into dev. I would recomend doing "bzr qlog trunk dev" before and after so that you get an understanding of what it does.
<ChrisCauser> Peitschie: Yes, it is. I know the squash merge is no worse than what SVN does naturally, but I just wanted to see all the commits I've made in trunk.
<ChrisCauser> GaryvdM: Thank you for the advice. I will give that a go now.
<ChrisCauser> GaryvdM: I am afraid it does not pull because they have diverged as well.
<GaryvdM> ChrisCauser: qlog should show you how they have diverged. maybe merge dev in to trunk, then pull trunk into dev.
<ChrisCauser> GaryvdM: According to qlog, the diversion is because of the last merge to trunk I made. Other than that it looks fine. From the looks of how bzr is handling the merges, this will always be a problem no matter how I merge it.
<peitschie_> ChrisCauser: I fear that there is no easy way to get all commits in either direction.. at least, not when the dev branch is in svn as well
<peitschie_> ChrisCauser: you might be interested in the rebase plugin... but really you need your dev branch in bzr for that functionality
<ChrisCauser> peitschie_: That's what I feared. Again, this isn't a problem. It's merely something that's been bugging me.
<ChrisCauser> Thank you all for your help. Merging I guess is the only way forward.
<peitschie_> can anyone help me with installing the monodevelop-bzr plugin with the monodevelop trunk?
<Tak> yes, I can :-)
<peitschie_> :D
<peitschie_> yas!
<peitschie_> i finally got everything compiled and installed
<peitschie_> wat's the next step?
<Tak> ok, the easiest way is to add the community repo from addins.monodevelop.com using MD's addin manager
<peitschie_> i've tried the instructions from http://wiki.bazaar.canonical.com/MonoDevelop
<peitschie_> and it crashes wen i load it
<Tak> yes, those need to be updated :-/
<peitschie_> so i'm assuming i can branch to within the monodevelop source (i.e., extras) and rebuild it there somehow?
<Tak> even easier
<peitschie_> yay :D
<Tak> if you add http://addins.monodevelop.com/Alpha/Linux/master  using the addin manager
<Tak> you should be able to install it directly from there
<Tak> be sure to install a version from the 2.5 series if you're using MD master
<peitschie_> mm
<peitschie_> i must have done something wrong
<peitschie_> that added and installed ok
<peitschie_> but still crashes
<Tak> then restart MD
<Tak> well
<Tak> make sure you uninstall the other addin as well
<peitschie_> ok... it's working a little
<peitschie_> annotate shows log lol
<peitschie_> i think i have an off-by-one error somewhere here
<Tak> heh...MD master may occasionally have silly bugs ;-)
<peitschie_> hehe... if it's not bleeding it aint fresh enough!
<mwhudson>   1073kB    29kB/s / Fetching revisions:Inserting stream:Estimate 5736/2478
<mwhudson> this doesn't seem quite right
<mssever> I need to get a list of filesnames that have been modified or added since a particular revision, and a list of filenames that have been deleted. How can I do that?
<LeoNerd> bzr stat -r123
<mssever> Thanks.
<mssever> Somehow I missed that in the docs. It works OK.
<LeoNerd> Mm.. I find it's a lot like Lego. A set of commands, a set of options... Hard to document every possible combination of options on commands.
<poolie> poolie_droid, hello?
<poolie_droid> Hi there
<GaryvdM> mwhudson: You are not the only one to have seen that - http://osdir.com/ml/bazaar/2010-10/msg00381.html
<GaryvdM> mwhudson: so I think a bug report is in order.
<poolie> hi gary
<GaryvdM> Hi poolie
<GaryvdM> How has uds been so far?
<poolie_droid> excellent, bit manic though
<poolie_droid> i hope we can invite you to the next one in Europe in May
<GaryvdM> :-)
<rubbs> bzr: ERROR: Failed to rename .../dev/www/login/index.php to .../dev/.bzr/checkout/pending-deletion\new-16: [Error 5] Access is denied <- coworker gets this error when trying to merge in his changes into the dev branch. Permissions problem?
<rubbs> the weird thing is that I did a chmod -R 775 on the whole repo and double checked to make sure he was in the right group
<beuno> rubbs, yes, in the .bzr/* dir
<rubbs> k. I'll double check, but I thought I did a recursive group change and chmod 775 on it
<rubbs> ok I did a chmod -R g+rwxs and chgrp -R staff on the .bzr directories on each of the branches, the .bzr dir in the shared repo location, and on all the bound branch locations, but I'm still getting that access denied error
<rubbs> could it be he's doing this over a mounted sshfs?
<rubbs> Ok, can someone help me figure this out. I've pasted the .bzr.log messages into this paste: http://paste.ubuntu.com/522232/  I also added a ls -Rlh on the .bzr directory of the /dev/ branch. both user1 and user2 are in the staff group.
<rubbs> hmmm... looks like it's something with the bound branch. once I unbound the branch everything worked fine
<poolie> hi there vila
<poolie_droid> Hi vila, everyone
<poolie_droid> Hi AfC
<fullermd> The machines!  They're taking over!
<poolie_droid> :)
<poolie_droid> *zap*
<AfC> fullermd: it's ok. Droids can't think
<fullermd> That's just what they WANT you to think.
<glen> i created tag wrong, now i can fix it locally but i fail to push it back to launchpad
<glen> complains on conflicting tags and i can't resolve that
<fullermd> Does --overwrite make it force tags?
 * fullermd doesn't remember.
<glen> boverwrite to which command? push?
<glen> i can fix locally ok, problem is that it won't go "up". i.e bzr push does not replicate the fixed tag, instead it aborts on conflict error
<fullermd> Yah.
<glen> ok thanks
#bzr 2010-10-30
<glyph> is there a way to customize the font used by qbzr?  (in particular, on the mac)
<methods> when i port an svn repo to bzr can i make it continue from the same revision number ?
<jelmer_> methods: Hi
<jelmer_> methods: Depending on how you do the conversion it should still show the old revision numbers in "bzr log"
<jelmer_> methods: We can't really keep using the same revision numbers - you'd get gaps as bzr's revision numbers are per-branch whereas they are per-repository in svn.
<methods> yea but if the initial import of the svn history is in the main branch then the main branch should be boot strapped to the last svn number + 1 or somthing right ?
<jelmer_> methods: if you have only one branch, yes
<methods> what about svn banches... they are just copies with remembered history ...  how is that transition to bzr ?
<jelmer_> methods: if the branches were created by e.g. copying from trunk that relationship is preserved
<methods> yea i heard that you could have issues if you didn't use a proper naming convention for folders ?
<methods> i mean my branches were not names like branches/<name>/trunk
<jelmer_> methods: yeah, there might be issues if you have branches in usual locations, they might not be imported as branches
<jelmer_> methods: Since there's no real way of knowing what a branch is in svn
<jelmer_> methods: if you use /trunk and /branches/<name> as branch names you should be fine
<methods> no i never did
<methods> tell you truth i don't really care it would be nice to have a way to just tell bzr to convert the whole thing as a single branch and not attempt to branchify it... you said history is remembered so that's all tha tmatters
<methods> can I tell bzr to treate the whole svn repo as a single branch ?
<jelmer> methods: bzr branch <location> <new-path>
<methods> well I'm going to convert svn to bzr
<jelmer> methods: Yes, location can be a SVN repository
<methods> what i mean is i want bzr to not attempt to figure out branches in the svn history
<jelmer> methods: Yes, that's what this will do.
<henke> I am having problems using bzr fast-export on a repository of mine. I get an AttributeError that a directory doesn't have a children attribute. However, it seems to mistake a file for being a folder, related to a rename that is listed as.. 'a/b/foo.h' => 'a/c', where 'a/c' is a folder, while other renames are of the form 'a/b/bar.h' => 'a/c/bar.h'. Has anybody run into this problem?
<jelmer> henke: I don't think I've seen it before. Have you checked the bugtracker?
<henke> jelmer, I have been searching a bit but haven't found anything directly applicable.
<jelmer> henke: do you have a way to reproduce it on a public repository?
<henke> jelmer, it seems to think it is a directory rename instead of a file rename into the folder
<henke> jelmer, unfortunately I don't. I can try to make a new repo to trigger it
<jelmer> henke: it could be a kind change (directory being turned into a file)
<henke> jelmer, it's a file being moved to a directory
<jelmer> henke: the change is 'a/b/foo.h' => 'a/c' ?
<jelmer> so "a/c" is a file?
<henke> jelmer, yes
<henke> jelmer, a/c is a directory
<henke> jelmer, the file is then at a/c/foo.h
<jelmer> henke: no, a/b/foo.h is being renamed to a/c
<jelmer> henke: assuming this is output from "bzr log -v"
<henke> jelmer, I used bzr diff -c <rev>, bzr log -v -r <rev> gives:
<henke> moment, checking something
<henke> strangely enough, it says, disregarding other files: added include/shaders/basicshader.h, renamed: include/engine/basicshader.h/ => include/shaders/, modified: include/shaders/, in the revision after the change, the file basicshader.h is located in include/shaders/
<henke> jelmer, I think the incongruence could be due to the repo being old and having been upgraded a few times, something going awry along the way with regards to the renames
<henke> I wonder if there's any way to reconstruct the repo so that it makes sense at that point
<jelmer> henke: I doubt that would be related, this more looks like a bug in bzr-fastexport.
<henke> jelmer, well, the revision that makes it crash is initially from GNU Arch, and the rename looks wonky. It's computed by the Tree.changes_from() which is not part of fast-export
<henke> jelmer, it does seem like the file is renamed into a directory (kind-change?), and then a new file with the same contents is added to that directory
<jelmer> henke: right, that's a valid operation in bzr (albeit a bit strange) and I suspect bzr-fastexport doesn't expect that
<henke> it seems very strange to rename a file into a directory
<henke> jelmer, thanks for the help, it seems like I managed to make a temporary fix that works
#bzr 2010-10-31
<Kamping_Kaiser> does anyone know if the bzr-builddeb project is still ticking?
<jelmer_> Kamping_Kaiser, yep, very much so
<Kamping_Kaiser> jelmer_: ok, cheers
<Kamping_Kaiser> bzr hung up ~9 revisions short branching from an svn repo. is there some way i can finish it? pull/merge/up/co all throw errors
<jelmer_> Kamping_Kaiser, what sort of errors?
<jelmer_> Kamping_Kaiser, you can perhaps "bzr pull -r-9"
 * jelmer_ gets sleep
<Kamping_Kaiser> jelmer_: 'Not a branch' or 'No WorkingTree exists for' file:///home/kgoetz/sourcecheckouts/debian-installer/.bzr/checkout/
<Kamping_Kaiser> jelmer_: sleep well
<TzilTzal> Does anyone know how bzr finds the BASE version during a merge?
<fullermd> It's the LCA of the branches.
<TzilTzal> so how could a criss cross ever occur if that was the case?
<fullermd> Well, in the case of a criss-cross, there isn't a unique LCA.
<fullermd> I dunno what (or if) bzr puts in .BASE then.
<TzilTzal> I think by definition there has to be one LCA
<TzilTzal> a criss cross is when there isn't a unique BASE...
<TzilTzal> but I don't know how this BASE is found.
<fullermd> Well, semantics.
<TzilTzal> heh
<TzilTzal> well, that's what I'm asking. how doe bzr find BASE?
<TzilTzal> 'cuz I"m a bit confused about criss crosses and what could cause them, really..
<fullermd> I'm not sure what it calls BASE in the case of a crisscross.  Probably just walks back until it finds a real unique LCA.
<fullermd> Which would be [much] farther back than the set of CA's the criss-cross gives.
<TzilTzal> that could depend on the resolution algorithm.
<TzilTzal> but I'm talking about just finding any BASE.
<TzilTzal> anyone?
<fontanon> Hi everybody! Does anyone had some experiences migrating from bazaar to git with fast-export/import ?
<TzilTzal> anyone knows how bzr finds the BASE version in a merge?
<GungaDin> does anyone have any idea how bzr finds the BASE version during a merge?
<bob2> http://doc.bazaar.canonical.com/latest/developers/lca_tree_merging.html perhaps
<GungaDin> doesn't that apply only to -lca?
<spiv> GungaDin: well, the merge base is the Latest Common Ancestor
<spiv> Although that doc is about the case where there are multiple revisions matching that description.
<GungaDin> that's actually the reason I'd like to know. I don't understand exactly what would cause a criss cross (i.e. multiple BASEs)...
<GungaDin> ll
<GungaDin> (oops)
<spiv> GungaDin: Well, look at the revision graph in that link
<spiv> (And also see the text at http://doc.bazaar.canonical.com/latest/en/user-reference/criss-cross-help.html)
<GungaDin> spiv - so after a merge from A to B the latest common ancestor is that commit"
<GungaDin> ?
<spiv> GungaDin: I don't know what you mean by "A" and "B"
<GungaDin> branches
<spiv> GungaDin: perhaps the first bit of http://revctrl.org/CrissCrossMerge will help
<spiv> GungaDin: an intuitive (rather than formal and precise) description of the merge base for merging A into B would be "the most recent revision in A that is already in B."
<spiv> GungaDin: because when the user asks bzr to do a merge of A into B, they presumably want all the "new" revisions from A, the revisions that B doesn't have yet.
<GungaDin> that's sort of what I thought.. but with this case, how could you have a criss cross merge then?
<spiv> GungaDin: well, as you can see from e.g. that CrissCrossMerge page, if A has been merged into B at the same time as B has been merged into to A, you don't have a clear choice of merge base.
<GungaDin> How can they exactly both be done together, really?
<spiv> One way to think about it is both branches have a revision that merged b1 with c1, but they quite possibly resolved the merge differently.
<spiv> So now when you merge those new revisions with each other, which resolution should "win"?
<spiv> GungaDin: look at the diagram and story on the CrissCrossMerge page.
<GungaDin> I understand the reasoning of what you're saying.. but can't completely understand how it could happen with the way of finding BASE
<spiv> Well, you tell me which of [a, b1, b2, c1, c2] should be the base for a merge of b2 with c2?
<GungaDin> I can't completely understand how you can both merge from and to a branch at the same time.
<GungaDin> I thought it was also locked for changes during that time
<spiv> There are two branches
<spiv> Which means two independent sets of changes.
<GungaDin> yes
<spiv> In this example, Bob has one branch and Claire has the other
<spiv> Perhaps Bob and Claire typed "bzr merge" truly simultaneously.
<spiv> Perhaps Claire's mirror of Bob's branch was slightly out of date
<spiv> There's no locking that prevents that.
<GungaDin> but when they're trying to merge "simultaneously", wouldn't one branch get locked so the other can't merge?
<spiv> No.
<spiv> Just because someone's branch is write-locked doesn't mean I can't read to it.
<spiv> (What if they are pushing over a really slow connection?  I wouldn't want to be prevented from reading the revisions that were already there.)
<GungaDin> I'm talking about writing. You wouldn't be able to commit at the same time.
<spiv> Or perhaps one or both of these people were working offline at the time.
<spiv> They aren't committing to the same branch!
<spiv> There are *2* branches.
<GungaDin> yes.
<spiv> Owned by different people (in this example, and usually in practice)
<GungaDin> one you start a commit, don't they get write locked?
<spiv> Their own branch does.
<spiv> "bzr commimt
<spiv> "cd mybranch; bzr merge $other_branch; bzr commit" never write-locks $other_branch at all.
<spiv> Why would it?  It never writes to other_branch.
<GungaDin> no, I didn't mean exactly that.. anyway, that's fine.
<spiv> Keep in mind also that there can be many copies of a branch: perhaps Bob is on an airplane, and working offline.
<GungaDin> this is a simple case though.
<spiv> But has a copy of Claire's branch at the time he left to catch the plane.
#bzr 2011-10-24
<Noldorin> hey jelmer
<poolie> hi Noldorin
<Noldorin> hi poolie
<Noldorin> poolie, good job on 2.5 so far. working nicely so far, and liking the co-located branches support
<poolie> great
<poolie> thanks
<Noldorin> is it going to be part of core in the RTM?
<poolie> yes it should be
<Noldorin> ah good
<Noldorin> when jelmer gets round to fixing up the last few nags with bzr-git, mirroring should be a breeze
<Noldorin> poolie, oh, and is the url format for colocated brnaches being improved?
<poolie> improved meaning shorter?
<poolie> i'm not completely sure
<Noldorin> poolie, indeed. just replacing ",branch=" with "," i mean
<poolie> not sure
<Noldorin> i think i submitted the bug for it a while ago. not sure though
<Noldorin> ok
<vila> hi all !
<poolie> hi vila
<vila> poolie: 1 on 1 ? mumble ?
<poolie> oh hi
<poolie> bah, vila, sorry, sure, mumble would be good
<vila> :)
<vila> hmm, if mumble can start...
<poolie> vila, so something like
<poolie> judge 'bzr2.4 st' 'bzr2.5 st'
<Merwin> Hi, I got a very strange problem :
<Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/Logica/addons$ bzr resolve --all --take-other
<Merwin> bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]
<Merwin> What does it means ? :-/
<poolie> Merwin, hi, it's a bug, perhaps due to you trying to resolve some unusual merge state
<poolie> i don't recall seeing that before
<poolie> vila, do you?
 * vila fighting silly bt mouse
<vila> Merwin: it's a bug
<Merwin> I'm using bzr 2.4.1 on Ubuntu
<vila> 'Tree transform is malformed' is *always* a bug
<Merwin> So, how can I do ? Should I upgrade bzr ?
<vila> Merwin: file a bug specifying which branches you were merging and the precise revids involved so we can reproduce it
<Merwin> Unfortunatly, I can't. My company don't want us to release the sources right now :/
<vila> Merwin: resolving the conflicts one by one may work around the issue
<vila> ha, well, that makes it harder to fix the bug then :-/
<AuroraBorealis> i'm sure they won't do anything with it
<Merwin> AuroraBorealis: I'm sure too, but I want to keep my job :p
<AuroraBorealis> ask maybe?
<Merwin> They have been clear about this
<AuroraBorealis> ITS LIFE OR DEATH MAN
<Merwin> vila: May the bug have already been fixed ?
<Merwin> I mean, in a moire recent bzr version
<AuroraBorealis> doesn't hurt to try
<vila> Merwin: let me check
<vila> Merwin: but yeah, if you can test with a more bzr version that would also help
<Merwin> Ho I'm stupid the branch is not one of ours
<Merwin> I will update it, but it's a hudge branch
<AuroraBorealis> well its still causing a bug o.o
<Merwin> How can I send it to you? Should I zip the folder ?
<vila> Merwin: a quick inspection of the bugs fixed since 2.4.1 reveals nothing obviously related
<Merwin> vila: Ok. I can send you this branch, just tell me how :)
<vila> Merwin: no need to zip  and send huge amount of public data ;) Just file a bug, mention the branches involved and the revids
<Merwin> The branch is not on lp
<Merwin> How could you test it ?
<vila> https://bugs.launchpad.net/bzr/+filebug
<vila> are the branches public (I can access them) or not ?
<Merwin> Not
<Merwin> And the dir have a 633MB size xD
<vila> unpractical then :)
<Merwin> I will push it on lp
<poolie> Merwin, just the traceback would be a reasonable place to start
<poolie> you don't need to attach the whole thin
<vila> g
<Merwin> poolie: I've no traceback, just the message I showed you, unless I have somthing to run in "debug" mode ?
<poolie> there will be a traceback in ~/.bzr.log
<Merwin> Ok, I'll post it
<Merwin> poolie, vila: https://bugs.launchpad.net/bzr/+bug/880701
<ubot5> Ubuntu bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [Undecided,New]
<mgz> morning all
<Riddell> hi mgz
<vila> mgz, Riddell : hi !
<vila> Merwin: please also mention the output of 'bzr st'
<Merwin> ok vila
<Merwin> vila: Done
<Merwin> Hum, I just saw in bzr st that there were some .OTHER file 'added', wtf
<vila> yeah, wtf indeed ;) I think it's due to a 'parallel import' where the same files have been added in the two branches,
<vila> are seen as different (even if their content is the same) due to a known glitch in the way bzr tracks renames
<Merwin> I never did a bzr add of this files, I'll revert and do the merge again
<vila> Merwin: try resolving the conflicts one by one
<Merwin> vila: How can I see a list of the versionned files ?
<vila> bzr ls --versioned -R
<vila> Merwin: in general, *never* use 'bzr resolve --all' it's not meant to be used to resolve "regular" conflicts but to just *delete* them relying on the user to have resolved them
<vila> s/to have resolved/having resolved/
<Merwin> vila: But here I have 51 conflicts without any conflicts to resolve, just a BASE and an OTHER files, I don't know why because I never modified these files
<Merwin> bzr ls --versioned -R | grep OTHER returns nothing after a revert
<Merwin> So files are added during the merge -_-
<vila> Merwin: they are so-called 'Content conflicts' where the same path is used for files which are seen different by bzr
<vila> bzr help conflict-types
<vila> Merwin: or also when files are deleted in one branch but modified in the other
<Merwin> humf
<Merwin> No shortcut to reolve the 51 conflicts in one command without using --all ? :D
<Merwin> vila: I already got some "Content conflicts" from the same files last time I merge, will this happen every time ? How could I fix it ?
<vila> Merwin: ECONTEXT, I can't say for sure without knowing more about why these conflicts occur
<vila> Merwin: just using 'bzr resolve --take-other' should work (but they were bugs in the past about that, I'm not sure we fixed them all)
<vila> Merwin: so resolving them one by one is the safe path
<Merwin> ok
<Merwin> vila: I got the same eeror  for each file
<Merwin> Resolving one by one doesn't solve the problem :/
<vila> o.0 highly unexpected
<vila> Merwin: can you post the traceback for one of these single file attempt ?
<Merwin> yep
<Merwin> lol lp down :p
<vila> it's back
<Merwin> It's ok vila, posted
<mgz> vila: new unhappy test, don't think I've seen this one fail before <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/569/testReport/junit/bzrlib.tests.test_config/TestConcurrentStoreUpdates/test_writes_are_serialized_bazaar_/history/>
<mgz> and, I'm patch pilot this week? :)
<vila> mgz: yup you are \o/
<vila> mgz: failing test: permissiondenied, so, known symptom, cause unknown
<mgz> well, the word 'concurrent' makes me suspicious
<vila> mgz: never failed anywhere else for that matter
<mgz> possibly a factor outside the test suite? we can hope.
<Merwin> vila: How can I resolve these conflicts ? Does overwrite the with the .other and bzr resolve --all could work ?
<mgz> another process having the file open at the wrong time could do something like that.
<mgz> Merwin: did you try --take-other?
<mgz> if that works for you, it's the right solution
<Merwin> mgz: Yes, nothing work, I have the TreeMalformed bug
<vila> mgz: concurrent here is with threads, strongly sync'ed
<vila> Merwin: to clarify, Mlaformed transform  is not *one* bug but a catch-all
<Merwin> ok
<Merwin> But, does this means that my branch is broken and won't be able to any merge ?
<Merwin> This might be a problem :x
<vila> well, I don't think your branch is broken
<vila> most of the malformed tranform bugs in the past had to do with bugs in the code itself
<vila> but not being able to reproduce the issue locally is a blocker to do the diagnosis :-/
<vila> Merwin: 'bzr st --show-ids' may shed some light
<Merwin> vila: Whith the pending merge ?
<vila> yup
<vila> having no .THIS hints at a deleted/modified case though
<vila> which confusingly translate into .OTHER being added
<Merwin> vila: Posted on LP Bug
<Merwin> vila: Curiously, it's not clearer to me :D
<vila> say file F is deleted in trunk, modified in feature and you merge 'feature' into 'trunk',
<vila> there is a conflict because 'trunk' said: I don't want F anymore, but 'feature' says: I've modified F
<Merwin> vila: Here, we work on a branch that is never merged back to the original one
<vila> when creating the conflict helpers, F.OTHER contains the 'feature' version but the is no F.THIS since trunk deleted it
<vila> Merwin: so what ? if you deleted locally, the version you deleted has been modified, there are cases where you know want this file back *because* the reason you deleted it doesn't exist anymore
<vila> s/know/now/
<Merwin> hum
<vila> that's why it's a conflict, there is no way to automate such decisions
<vila> on the other hand, there is a need to express that the deletion is permanent and that you're not interested in the modifications and won't be in the future
<vila> this need is known and will be implemented when time permits
<vila> Merwin: it
<vila> it's kind of being able to say: for this file, if a conflict occur, just resolve it with --take-other
<vila> or --take-this
<vila> Merwin: do you have the same error for 'bzr resolve --take-other crm/crm.py'
<Merwin> vila: Yes
<vila> Merwin: and by the way, if you use '--take-other' for a delete/modified case, you are indeed saying: hey, if the other side changed, I want the file back
<vila> Merwin: ok
<Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/Logica/addons$ bzr resolve --take-other crm/crm.py
<Merwin> bzr: ERROR: Tree transform is malformed [('duplicate', 'new-2', 'new-204', u'crm.py')]
<Merwin> vila: I didn't understand all you explained, but I'm glad if you understood the problem :D
<vila> Merwin: what if you do 'bzr mv crm/crm.py.OTHER crm/crm.py' ; 'bzr resolve crm/crm.py'
<Merwin> ERROR: Could not move crm.py.OTHER => crm.py: crm/crm.py is already versioned.
<mgz> just `mv`
<mgz> vila is too used to typing 'bzr'
<mgz> :P
<Merwin> 1 conflict(s) resolved, 49 remaining
<Merwin> vila: <3
<vila> no, I really meant 'bzr mv', what is this already versioned 'crm/crm.py' ??
<mgz> ...really?
<Merwin> erf
<vila> hold on
<vila> just 'mv' worked ??
<Merwin> Yes
<mgz> I thought mv name.OTHER name; bzr resolve name was ~same as --take-other?
 * vila blinks
<vila> mgz: bzr mv x.OTHER X ; bzr resolve X should be ~same
<vila> hence my surprise
<Merwin> hum. I tried to create a new repo from the remote one we use (the on I push after merge). I then merged from the original trunk, and in this case I onlyt have the text conflict
<Merwin> Not all the content conflicts I got
<vila> haaaa, can you explain that in the bug report ?
<vila> Merwin: at least you're out of trouble right ?
<Merwin> I still have ONE content conflicts
<Merwin> I'll try to resolve it using --take-other
<vila> which one ?
<Merwin> crm/test/test_crm_meeting.yml
<Merwin> I've got the same problem on this file :D
<Merwin> And same error with 'bzr mv'
<vila> with --take-other ? Or with a bare 'mv' + resolve ?
<Merwin> bzr mv doesn't work (already versionend error), --take-other raise the Malformed error
<Merwin> mv worked
<Merwin> Ok, I did my merge ! finally worked !
<vila> great
<Merwin> I pushed the "copy" repo, and pulled from the other repo (which was bugged) after I reverted it, it's ok
<Merwin> I let the bug opened vila?
<vila> Merwin: yup
<vila> Merwin: We won't be able to fix your issue but we can at least output a traceback to make it clearer that it's an internal bug and not a user error ;)
<Merwin> vila: Why you won't fix it ?
<vila> Merwin: if your branches become public though, we will be able to reproduce it so please specify the revids involved
<vila> Merwin: because I have no way to diagnose it properly so I can't fix it
<Merwin> ok, I will push it on lp
<vila> Merwin: you can ?
<Merwin> Yes, it's not a branch where we push our things
<vila> Merwin: in this case commit after your merge and mention this branch in the bug report and I will be able to diagnose \o/
<Merwin> Ok, it will take time, I'll keep you informed :)
<vila> cool
<vila> in other news, the importer made tea this morning during lp downtime and 4 more signatures have been added
<Merwin> signatures for ?
<vila> Merwin: no relation with your bug :)
<vila> signature here refers to a traceback encountered when lp is down in the package importer http://package-import.ubuntu.com/status/
<Merwin> vila: https://code.launchpad.net/~thibaut-dirlik/+junk/bzr-bug-880701
<vila> Merwin: thanks, please mention it in the bug report explaining how you proceeded in the ned
<vila> end
<Merwin> vila: To reproduce the bug, revert to the previous rev, and merge with lp:openobject-addons
<Merwin> Ok
<vila> Merwin: right, the tip should give me all the needed revisions :)
<vila> branching
<vila> Merwin: huh ? got your branch (revno 4921), created 'work' revno 4920 and 'from' revno 4899.14.120
<vila> Merwin: in 'work' doing 'bzr merge ../from' gives: Nothing to do.
<Merwin> vila: hum try to merge from lp:openobject-addons from revno 4920
<vila> ha, indeed, diferent result
<Merwin> do you get the errors ?
<vila> yup when merging from lp:open..-addons
<vila> good enough
<Merwin> Ok, happy you can reproduce it
<Merwin> Thanks for your support ;)
<vila> Merwin: I'll take a closer look after lunch but I already suspect some weirdness in revno 4908
<Merwin> vila: Hum it seems my boss removed the crm module and replaced it right ?
<Merwin> I see that crm/* have been added in rev 4908 whereas it already existed in the original trunk (lp:open...-addons)
<vila> Merwin: something like that yes, *this* could lead to files being seen with different file-ids
<vila> Merwin: aka the so-called 'parallel import'
<vila> Merwin: but I'll look closer later
<Merwin> Ok, thank you again ^^
<vila> Merwin: I'll let you know if you stay connected here ;)
<Merwin> I'll be there :)
<mgz> vila: can you confirm that import-package does actually run with a valid locale?
<mgz> the init.d script for mass-import tries to set one, but given certain failures I have doubts that it's actually getting all the way down
<mgz> okay, I think I understand this,
<mgz> for some reason the import-dsc is on a slightly different path an unpacks the tarball
<ChrisCauser> Hi everyone, has anyone managed to install loggerhead on Lucid which has bzr 2.5 installed?
<ChrisCauser> or am I doing something silly?
<ChrisCauser> http://paste.ubuntu.com/717742/
<mgz> ChrisCauser: that looks like the latest bzr daily, which loggerhead is saying is too new
<mgz> what loggerhead package are you trying to install? the daily as well?
<vila> mgz: care to clarify this path issue ? Afaics mass-import should indeed set it correctly and I know no code path that could reset/change it
<vila> mgz: now, the importer is a bzrlib client not a bzr one so there may be some holes...
<mgz> vila: minor confusion, from the import-dsc command and the import-package script doing something slightly different
<mgz> the basic issue is in bzr-builddeb, just in a couple of forms
<vila> mgz: you know we run old versions of them on jubany right ?
<vila> them == bzr and bzr-builddeb
<mgz> yeah, which won't help matters in fixing this.
<vila> right
<vila> so,
<mgz> because it can't be done from lp:udd
<vila> mgz, Riddell, jelmer : Do you know a reason why we shouldn't run bzr.dev on jubany ?
<vila> i.e. : install and use our own branch
<mgz> well, I don't need the latest bzr, but we need to be able to fix things in bzr-builddeb
<vila> mgz: we use revno 613 and we can deploy more recent versions if needed
<vila> as long as it doesn't break horribly :)
<vila> oh, jelmer is away this week right ?
<vila> or at least in some unreachable TZ ;)
<mgz> I want to break things with better error messages :)
<mgz> vila: yeah, he's off being a git
<vila> :)
<lamont> jelmer: around?
<mgz> lamont: he's mostly away this week
<lamont> well then. fine.
<ChrisCauser> mgz: Doh, thought it was in the same PPA. Thanks. :). Right, now, next stupid question, where is the loggerhead PPA? Typing in loggerhead PPA takes you to the source code, but I cannot seem to find the ppa url. Is there one?
<mgz> ChrisCauser: it's the same ppa, I just wanted to know the full name of the loggerhead packaged you're trying to install
<mgz> as according to <http://people.canonical.com/~jelmer/recipe-status/bzr.html> the loggerhead-daily is green on lucid
<ChrisCauser> mgz: Thanks: http://paste.ubuntu.com/717851/
<mgz> hm yup, that is what it should be
<ChrisCauser> mgz: Cool, well, at least you guys know that something fishy is afoot. I haven't done anything unusual with my system other than add the bzr daily ppa.
<allenap> Can anyone help with a weird mutual stacking issue on Launchpad? https://answers.launchpad.net/launchpad/+question/175926
<allenap> It looks like lp:~afcowie/java-gnome/mainline is stacked on lp:~java-gnome/java-gnome/4.1 ... which is stacked on lp:~afcowie/java-gnome/mainline.
<mgz> allenap: yup, that's a nice infinite recursion traceback
<mgz> things like this have been fixed manually in the past, right?
<allenap> mgz: Indeed. I don't know about that, but I can probably figure out how to do it. I wanted to check this wasn't something that requires a big response, or if it's just a curiosity.
<mgz> I've got a little list of things like this I was planning on asking you about on thursday
<mgz> looking through mailing list archives to see if that gives any clues
<mgz> bug 726976 and dupes look like this
<ubot5> Launchpad bug 726976 in Bazaar "Stacking loop causes unhelpful "unable to obtain lock" errors during "bzr up"" [High,Confirmed] https://launchpad.net/bugs/726976
<mgz> "Edit the .bzr/branch/branch.conf files for those branches via SFTP"
<mgz> appears to be the suggested solution.
<jelmer> lamont: hi
<allenap> mgz: Ta, I'll do that.
<vila> tada ! Here comes jelmer :-)
<Noldorin> hi jelmer
<mgz> it's not clear whether the step 2 from the earlier bug of touching the branch to purge a launchpad cache is still needed
<jelmer> hi vila, Noldorin
<mgz> jelmer, while you're here to bug,
<mgz> any idea why loggerhead is uninstallable from the dailies on lucid?
<mgz> it says it wants < 2.5 and the bzr-daily-lucid is newer, so unhappiness
<mgz> it's green on your status page though.
<jelmer> mgz: it probably built fine, but has anm invalid dependency for the binary package
<mgz> ...that seems like it'd be a problem for every plugin than declares a bzr version though
<mgz> because 2.5 isn't released yet
<mgz> or are the rules just written inconsistently?
<jelmer> mgz: Plugins usually declare they support version X or pre-releases of version Y
<jelmer> mgz: as far as I can tell loggerhead claims support for bzr >= 1.17 && bzr < 2.5.0~
<vila> Merwin_: just so you know, I'm working on a fix but it's tricky. This is indeed caused by one case of 'parallel import' though
<mgz> okay, so it is just that dep that's borked, and the builders don't catch it because they don't install. thanks!
<Merwin_> vila: Ok !
<lamont> jelmer: also, I'd love to have a bzrtools/hardy
<mgz> this is the stupidest fix
<mgz> but it's the sanest choice short of ripping out the whole of bzrtools_import and starting again
<jelmer> lamont: I'll have a look
<jelmer> lamont: (I'm in CA this week)
<jelmer> mgz: which fix?
<mgz> bug 508258, proposing now.
<ubot5> Launchpad bug 508258 in bzr-builddeb "Failure to import non-ascii filenames" [High,In progress] https://launchpad.net/bugs/508258
<poolie> hi all
<jelmer> hi poolie
<poolie> hi, how's it going?
<jelmer> having fun :) How are you?
<poolie> good thanks, camping was good
<poolie> thanks for the notes
<jelmer> anytime
 * jelmer runs off to some sessions, back later
#bzr 2011-10-25
<vila> hi all !
<poolie> hi there, nice to see you!
<poolie> i'm just reviewing your possible_transports patch
<vila> oh great !
<poolie> done
<poolie> wow look at all these patches
<mgz> morning!
<poolie> hi mgz
<vila> mgz: _o/
<vila> poolie: 'feel free to land with post review' ? I can't parse that, especially the 'with post review' part ;)
<poolie> ah i mean
<poolie> you don't need to wait for review
<vila> oh
<poolie> i do appreciate you making an mp, so people can see the diff
<vila> yeah, I intended to deploy it but wanted to chit-chat with jml... can't remember exactly why though :)
<vila> ha, good analyze-log script :) 22h20 is how long it takes to catchup the imports for chromium-browser (still failing though)
<vila> ha crap, jml refactoring broke *all* scripts, the modules are not found anymore
<poolie> yeah i see
<mgz> yeah, I wondered about that yesterday when trying to run the importer locally
<poolie> but i thought they were all already on jubany
<poolie> i checked it was up to date with trunk the other day
<vila> thinking he was the one infecting me with TDD ;)
<poolie> but perhaps they had not yet been merged
<mgz> moving the script out of the base dir means "udd" is no longer on the path
<mgz> so you can't run without installing (or setting PYTHONPATH or something)
<vila> mgz: exactly but not only, jquery.flot.js not found too
<vila> I just created bin/udd -> ../udd but that's not enough
<vila> (not to mentioned hackish ;)
<mgz> ehee, that's even worse than most symlink hacks :)
<vila> ok, I'll revert it and comment on the mp, too much to fix without guarantee I get them all
<mgz> could revert that change for now, and only land it w...
<mgz> ...hen there's a setup.py script to go with it
<vila> :)
<vila> oh, setup.py, worth thinking about it
<vila> but we run from source and it's also a useful thing
<vila> bah, let's try a bit harder, reverting is not trivial either and is going in the wrong direction anyway
<poolie> vila, mgz, i think it's just us this week so we could talk whenever you like
<vila> comfy :)
<vila> Riddell is not here either ?
<poolie> i might be confused but i thought he was going to be en route to uds this week?
<vila> hmm, by boat ? :-D
<poolie> exactly, kayak
<vila> wow
<poolie> not really
<vila> hehe
<vila> ok, some sanity restored, categorise-failures works
<vila> etc scripts 101: you can't remove PATH or you won't do a lot
<poolie> gz you're in ~bzr-explorer-dev now
<mgz> poolie: cool, will land that branch
<poolie> feel free to also add a <land it!> button to lp! :)
<poolie> i'm seriously tempted to do it myself
<mgz> vila: so, if you could walk me through what to do to deploy the latest bzr-builddeb in jubany and requeue one of the failing packages some time today
<vila> mgz: sure thing !
<mgz> poolie: but doing it manually is such fun...
<vila> I've just fixed the last glitch and the importer is running again
<vila> I'm waiting a bit before calling it a win ;)
<vila> ... and stopping it before requeuing chromium-brower...
<vila> so, let's deploy builddeb as soon as you're ready
<mgz> I'm guessing the procedure is basically stop importer, pull, start, then... tell it what package somehow?
<vila> yup
<vila> so, first thing, read README_DEPLOYMENT to make sure it's accurate
<mgz> which lives...?
<vila> in lp:udd :)
<vila> with a symlink also in place in pkg_import@jubany:/srv/package-import.canonical.com/new/scripts
<mgz> okay, that tells me the dir.
<vila> mgz: you know how to connect there ?
<mgz> yep, I'm there
<vila> via ssh + sudo su - pkg_import ?
<vila> k
<vila> hmm './' is probably missing in front of the etc-init.d-mass-import examples
<vila> can you confirm that ?
<mgz> yup.
<vila> ok, fixed locally (I'll take the notes, you do the work ;)
<mgz> and in fact, when I stopped it last time, used the script in /etc/init.d/
<vila> we should resync them but better use the one in the branch
<mgz> which is I guess just the same thing, or an older copy, or a symlink
<vila> an older copy
<vila> you haven't stopped it yet right ?
<mgz> yup, has the wrong path
<vila> use graceful-stop
<mgz> not stopped yet.
<vila> k
<mgz> doing now
<vila> yup seeing it
<vila> oh, I should mention that,
<mgz> how do you monitor a running importer?
<vila> I usually have 3 connections to jubany:
<vila> oh failure !
<vila> crap dpkg-mergechanglogs is not in PATH anymore
<vila> stopped nevertheless
<mgz> there's an old import_package.pyc and .py~1~ in here for some reason...
<vila> mv dpkg-mergechangelogs bin/ should take care of that but we need a more formal way to track it
<vila> someone did a revert probably
<vila> back to monitoring:
<mgz> tail some log?
<vila> 1) tail -F logs/driver/progress_log
<vila> 2) crap, broken now, just a sec
<vila> 2) export PYTHONPATH=${HOME}/src/udd/trunk ; (ssh -AY jubany.canonical.com tail -F /srv/package-import.canonical.com/new/logs/driver/progress_log) | ~/src/udd/trunk/bin/analyze-log  -
<vila> 3) in .../scripts: '. ./fixit.sh' to get some shorcuts and setup the env
<mgz> okay.
<mgz> so, is lp:udd in a usable state now? should I pull in the latest bzr-builddeb?
<vila> lp:udd is deployed, so, yes, pull the latest builddeb, check that no uncommitted changes are there though
<mgz> will do.
<mgz> one shelve. :)
<vila> yeah, looking at it ;)
<vila> it's an old one, should be safe to delete but doesn't hurt to keep it until we fix the dpkg-mergechangelog for good
<mgz> okay, that's got the fix in question
<mgz> start time?
<vila> yup
<vila> started ok
<vila> notice that it says ' Read 4 in /srv/package-import.canonical.com/new/max_threads'
<vila> I changed from the default 8 while debugging the scripts issues
<mgz> so, how are you running the scripts in bin? I need to do requeue-package next
<mgz> ^right
<vila> I use '. ./fixit.sh' first
<mgz> k
<vila> it provides 'requeue'  as a shorcut to requeue-package
<mgz> done.
<vila> failure
<mgz> I see it.
<vila> run 'categorise-failures' to force the status page generation
<mgz> stop importer first?
<vila> yup
<vila> err
<vila> no they are independent
<vila> it's useful when you don't want to wait for the crontab to run it
<vila> every 5 minutes (see importer.crontab in lp:udd)
<mgz> done
<mgz> all looks like the same issue in import_dsc
<vila> but you can stop the importer too as the failure seem to spread
<vila> you'll be able to requeue all the related failures by doing 'requeue --all <one-package-that-failed>'
<vila> good thing I didn't requeue chromium :)
<vila> one sucessful import still ;)
<mgz> looking for blame.
<vila> hehe
<vila> now, the usual choice is to either revert to a known-working rev and restart or fix before restarting
<vila> it's ok to fix locally and only then do a merge proposal because the importer is stopped and we don't want to accumulate too much stuff
<mgz> probably in lp:udd
<mgz> hm, nope, the singular->plural was a builddeb change
<mgz> vila: bzr diff to see possible fix
<vila> +1
<mgz> starting
<mgz> will let a few go past before requeuing
<vila> oh, I couldn't commit on jubany last time I tried and didn't investigate a workaround (just so you won't be surprised)
<vila> nope, try requeuing one that failed instead
<vila> with:
<vila> requeue --priority paraview
<vila> --priority will ensure it's run asap
<mgz> done
<vila> if you run categorize-failures now it should appear in outstanding jobs
<mgz> run, but, where am I looking?
<vila> oh, that was related to multiple tarballs, we should check with jelmer telling him we've deployed that
<vila> which one did you requeue ?
<mgz> paraview, was the last one in the log
<vila> oh, sorry, that generates the status page
<mgz> currently pending
<vila> running already
<mgz> I must be being blind then, didn't see current jobs on status
<mgz> *running, even, yeah
<vila> top of the page
<vila> 4 running
<vila> 30 outstanding jobs
<vila> and in the last 50 failures you've got the ones related to extract_upstream_tree
<mgz> ...I'm now not sure if I needed that refresh or if I was just being blind
<vila> go with refresh ;)
<mgz> tail is looking happy.
<vila> the fact that this page also refreshes itself from time to time doesn't help ;)
<mgz> will let paraview go through, then requeue the one I wanted and all those that hit that issue
<vila> yup, that's the idea
<vila> you'll requeue them with: 'requeue --all polyglot'
<vila> adding --priority as you see fit
<vila> --all will requeue all packages that share the same failure signature
<poolie>  ok, i should go, good night
<mgz> night poolie!
<vila> poolie: g'night !
<mgz> paraview done.
<vila> \o/
<mgz> okay, everything set up I think.
<vila> bump max_threads to 8 (echo 8 >../max_threads)
<mgz> done.
<vila> categorize-failures again to see the effect (or look in the logs)
<mgz> yeah, following log
<vila> k
<vila> I'll requeue the ones related to dpkg-merge...
<vila> ...and I'll requeue chromium-browser once the outstanding jobs are (will be ?) done
<vila> ha great lxc fails
<mgz> ...lock contention on lxc?
<vila> did you see that ?
<vila> yup
<mgz> ...great as in, really was good, or great as in, annoying?
<vila> in some cases (for yet unknown reasons) an exception manage to escape the finally clause where the lock is released
<vila> great to explain the issue and how I resolve it (hackish, needs to investigate one day and make it more robust, should probably file a bug)
<mgz> hey, I think my test package went through okay while I was distracted
<mgz> how do we see sucesses? (...apart from in the log)
<vila> to resolve: look at the traceback, it gaves hints about where the lock is still pending, in this case 'precise'
<vila> you don't, it's a bug I'm working on, let me find the number
<vila> bug #831699
<ubot5> Launchpad bug 831699 in Ubuntu Distributed Development "no report/log of successful packages" [High,In progress] https://launchpad.net/bugs/831699
<vila> so, cd ../updates/lxc/precise
<mgz> pygobject also had an unhappy lock experience
<vila> yup, same issue
<vila> bzr info -v
<vila> it's a local lock so 'bzr breack-lock'
<mgz> okay, I'll requeue all the other UnicodeDecodeError packages, and hopefully a couple of them will fail with new nicer errors
<vila> two locks broken
<vila> sometimes it's a remote one and I do 'bzr break-lock :push'
<mgz> libproxy is a different issue
<vila> two broken locks for pygobject too
<vila> and requeued
<vila> rats another failure ;-/
 * vila blinks, that's an unknown one
<mgz> all unicodedecodeerror packages queued
<vila> will need to repro locally
<vila> can you land your fix on lp:udd ?
<mgz> 51, 10, 5, 3
<mgz> ^will do
<vila> hmm, the lxc failure spreads
<vila> something changed in the merge hook
<mgz> yeah seems like it
<vila> probably worth stopping the importer when all your jobs have passed
<mgz> huh, it's doing paraview again
<vila> ha
<vila> there is a bug there (not filed), some jobs seem to be re-processed for no good reasons
<mgz> oh, probably because I did requeue --all on a similarly failing package after it had succeeded?
<vila> nope, it shouldn't it's more obscure than that
<vila> I've seen jobs being re-processed without being involved in anything recent
<vila> mgz: mwhahaha, conflicts in bzr-builddeb locally
<vila> mgz: import pdb; pdb.set_trace() in bzrtools_import.py getmembers :)
<mgz> hehe
<vila> I went there trying to diagnose some unicode issue at one point ;) I should have tried harder ;)
<vila> mgz: did you note the revno before upgrading builddeb on jubany ?
<mgz> should I just push to lp:udd?
<mgz> vila: ...no, but I think you told me it yesterday
<mgz> r613?
<vila> you rock !
<vila> yup 613
<mgz> hm, a bunch of these current packages aren't doing anything new
<mgz> maybe should stop, fix the merge hook issue, then see if I can get some non-utf8 filename failures
<vila> mgz: yup, I'm trying to reproduce locally with lxc buno success so far
<vila> s/buno/but no/
<vila> mgz: you just got one !
<vila> 2 even :)
<vila> make that 3
<vila> of, what's you trick ? ;-P
<vila> s/of/ok/
<vila> s/you/your/ :-(
<mgz> woho!
<vila> bah, can't reproduce locally as it's code involved when pushing only ;_/
<mgz> what the hell paraview is going through for like the fourth time
<vila> yeah and outstanding jobs up to 120 (was down to 70)
<vila> so, categorize_failures requeue some but I suspect some cruft in the db
<mgz> so, these will be packages with real filename encoding issues: <http://package-import.ubuntu.com/status/08eff66a5fe37a967e2f2b06210cc608.html>
<vila> real as in ?
<mgz> as in, not utf-8
<vila> will never be able to encode ?
<mgz> most of the ~70 failures should now pass
<mgz> and the subset that don't will be listed there
<mgz> basically, bzr core needs a strategy for handling that edge case, so the package importer failing is reasonable
<mgz> the only other option would be to have a way of attaching a different encoding to the package metadata if they're using a valid, but non-utf-8, encoding
<mgz> but I suspect that won't be worthwhile
<vila> ..and may not be enough (I suspect this should be attached to each file in some cases)
<vila> libperl5i-perl also enjoys being processed
<vila> qcomicbook too
<vila> eerk and libjgrapht0.6-java enve more !
<vila> ok, so, this issue is now really bad
<mgz> I have run categorise-failures several times, will stop doing that
<vila> down to 69 outstanding jobs, don't run.. yeah me too, let's stop :)
<vila> there are some basic tests for db now and one FIXME is mentioning something related
 * vila back to the merge hook issue
<vila> ok, I think I got it
<vila> mgz: two bugs: dpkg-merchangelogs was not in PATH anymore, the merge hook can't find it but returns a single value instead of 2
<vila> mgz: we can stop the importer ;)
<vila> DONE
<mgz> what happens to the current queue when it's stopped?
<vila> it's in the db (meta.db JOBS_TABLE)
<mgz> cool.
<vila> 4 more failures for you :)
<vila> err 3
<mgz> yep, seeing them
<mgz> perhaps a latin-1 fallback in the importer wouldn't be so bad.
<vila> yeah, add an NFD too ;)
<vila> I forgot which package, but I'm pretty sure there is one with a contrib/docs/xxxx.pdf where xxx is in NFD
<mgz> heh
<vila> some db related one
<mgz> aaaa, that error message is so much nicer
<mgz> reminds me, I should improve UnicodeError display is bzrlib
<vila> mgz: bzr diff on builddeb for the fix
<mgz> have we got a bug for it? we've talked about it before
<vila> mgz: oh yes please !
<vila> I don't think so,
<vila> but there should a place where all unicode exceptions can be trapped their *args* put to good use
<vila> i.e. the broken string is args[0] IIRC
<vila> but it's not displayed by default (strange idea)
<mgz> diff looks reasonable, is this the right end of the interface to change?
<vila> I'm 90% sure as it's a recent change and match the error we see
<mgz> yep, looks more unambiguously correct with more context
<mgz> goforit
<vila> hmpf, it was still running :-}
<mgz> the last job was being slow :)
<vila> yeah, chromium would have been even slower :)
<mgz> openclipart... I fear a little for the contents of that branch
<vila> oh crap, I pushed to lp:bzr-builddeb :-(
<mgz> quick, uncommit! :)
<vila> jelmer: so sorry about that :-/
<vila> jelmer: the fix is trivial though, shouldn't be a problem ?
<vila> ETOOMANYBRANCHES
<vila> mgz: anyway, in this case, 4 fourth terminal with: 'tail -F logs/packages/openclipart' :)
<mgz> paraview is in the queue again...
 * mgz switches tails
 * vila switches to lunch ;)
<vila> mgz: this import looks like it will take some time to finish anyway
<mgz> :)
<mgz> I'll restart if I notice it's done before you return
<vila> mgz: I have some shopping to do after lunch, I'll ping you when I'm back, feel free to play around as you like (my fix needs to be deployed first though)
<vila> k
<mgz> ...bzr-builddeb just needs to be pulled, right?
<vila> taking care about the pending change yes
<mgz> vila: all done, also requeued the packages with affected by the tuple unpacking issue
<vila> mgz: yup, still there for a couple of minutes, they fail with lockcontention :-0
<mgz> ...but they seem to now all be failing with the lock...
<vila> probably time to find a better way to addres that :)
<vila> I'll look into it when I get back
<vila> delayed again :)
<vila> huho
<vila> mgz: panic in the driver we may need to kill hard
<mgz> woha!
<mgz> ha, normalisation kills the world
<mgz> did a hard stop
<vila> mee too :-/ But it seems I'm still receiving output from tail -F
<mgz> there was a *lot*
<mgz> it's basically in infinte log loop
<vila> bug in mass-import then ?
<mgz> printing the failure triggered a complaint about normalisation caused a failure...
<mgz> yeah
<vila> bad bad bad
<vila> good we encountered it while online
<mgz> was going well till that, a bunch of packages imported, and a bunch more failed with useful errors
<mgz> the invalid normalisation error class in bzr should really use repr
<mgz> 326570836 is a lot of bytes of log
<mgz> manually truncating that a bit wouldn't hurt
 * mgz logs out of jubany for a short food break
<vila> no, please leave it there as evidence for forensics, it will be log'rotated when needed anyway
<vila> I'm already rsync'ing it
<vila> we had cases like that long ago, it's not an issue in itself
<rom1> Hi all
<rom1> Is there a hook triggering once a checkout is done completely ?
<rom1> I have tried post_pull, post_branch_change, but none of them is triggered after the .bzr/checkout directory is made
<vila> rom1: I don't think there is such a hook yet, patches or bug welcome !
<rom1> that's what i thought : thx vila !
<vila> mgz: http://paste.ubuntu.com/718773/ should fix the issue, weird that we never encountered the case though
<mgz> vila: the replace is redundant
<mgz> otherwise looks about right
<vila> meh ? The one I delete ?
 * mgz bops self on head
<vila> bah, sorry you don't have the context here
<mgz> yes, the code you're deleting is wrong
<mgz> that it triggered a loop though is still a bit concerning
<vila> mgz: look at the method itself, this was the last place we use unicode_output
<vila> mgz: I suspect some similar case happened in the paste leading to the introduction of ascii_output to avoid the problem
<vila> s/paste/past/ :)
<vila> re-starting with max_threads = 2
<mgz> yeah, seen
<vila> hu ho
<vila> dandling scripts/main_lock, never see that before
<vila> wow, we'll now soon enough, praat requeued
<vila> hmm, otrs2 and console-tools didn't finish, they are still running
<vila> one more trick to monitor: 5) run top ordered by MEM used
<vila> that's how I found back otrs2 and console-tools (you need to add cmdline to the displayed columns)
<vila> those two orphan imports...
<jml> vila: sorry
<vila> ... will finish... eventually... but won't be marked as such in the db ??? May be another cause of those random imports coming out of sequence
<vila> jml: hehe, too soon to be sorry, join the fun fixing the fallouts ;-p
<vila> jml: kidding, I think we nailed them down
<jml> vila: cool. thanks.
<vila> jml: your way to remind me why you TDD-infected me is naughty though ;-D
<vila> mgz: in the mean time, the importer fail to start the already running imports so we should be safe...
<vila> bbiab
<mgz> okay, first one back can try again
 * vila nods
<jml> vila: :)
<mgz> ^I do 5) all the time on this box :)
<ccxCZ> can anyone help me with bzr-git failing? http://paste.pocoo.org/show/497924/
<ccxCZ> seems like https://bugs.launchpad.net/bzr-git/+bug/706990 but that should be fixed in bzr-git I have
<ubot5> Ubuntu bug 706990 in Bazaar Git Plugin "git-import fails on remote repository with AttributeError: 'RemoteGitRepository' object has no attribute '_git'" [Critical,Fix released]
<mgz> ccxCZ: the traceback *is* different
<mgz> ccxCZ: bug 849250
<ubot5> Launchpad bug 849250 in Bazaar Git Plugin "pull into remote git branch fails" [Low,Fix committed] https://launchpad.net/bugs/849250
<mgz> you need 0.6.3
<ccxCZ> seems if I just do branch, it works
<mgz> ...which I'm not sure when jelmer plans to release
<mgz> +affectsmetoo that bug at least.
<mgz> okay, now I need to get going.
<ccxCZ> seems eadd fails consistently though
<ccxCZ> doesn't seem to be the same bug to me
<mgz> ccxCZ: the line in question with the bug is that one
<ccxCZ> yeah, in the end it ends up in the same function, failing on the same row, should I post my traceback there, or just +1 it?
<ccxCZ> does lp allow some formatting? I guess the traceback should at least be monospaced
<james_w> mgz, would you have a minute to review https://code.launchpad.net/~james-w/udd/config-location/+merge/80337 ?
<james_w> vila, you've experience related to ^ I think?
<james_w> vila, https://code.launchpad.net/~james-w/udd/base_dir-config/+merge/80350 removes one of your FIXMEs if you would take a look
<vila> Mcough> finally back :-}
<mgz> gra, that was annoying
<mgz> will have a look at those udd branches unless vila gets there first
<vila> james_w: I won't be able to look at them today, but probably tomorrow
<vila> james_w: on the overall and given the issues we had this morning I really like to have basic smoke tests so this kind of refactoring can be done safely without breaking horribly in production though
<james_w> oh, there were issues?
<vila> well, if you look at lp:udd recent revisions I'm sure you will spot the fixes ;)
<james_w> :-)
<james_w> do you have an idea what form those smoketests would take?
<vila> from the top of my head, we have 5 or 6 scripts that should runnable with a minimum setup in the db (the ones from crontab)
<vila> mass-import itself could to with a dedicated import-package simplified replacement
<vila> import-package is the trickiest
<james_w> yeah
<jml> you know what would make that easier?
<jml> the changes in the branches that james_w has proposed
<vila> heeh chiken and egg
<vila> unit tests for paths covering these changes will be a significant relief too ;)
<jml> vila: I think there are tests, in fact.
<jml> vila: again, a part of the work that james_w has done is to make some of this more testable.
<vila> jml: tests that exercised the paths ? I don't think so. Even the config tests are very basic
<james_w> there aren't tests for the values, no
<vila> jml: you know the udd/iconfig already allows you to define more specific values in locations.conf right ?
<jml> vila: No, I don't.
<jml> vila: oh, wait, yes
<jml> vila: but that's a really bad idea for running a production service
<vila> i.e. in the short term you don't *need* an out-of-tree config
<vila> ha right, but that's more long term
<jml> vila: not really
<jml> vila: long term is you guys coming up with an effective test suite so you can be confident about accepting contributions :)
<mgz> right, lets have one more go at the package import queue
<jml> vila: we're planning on deploying sooner than that :P
<vila> jml: yeah for more production services with no effective test suite ?
<vila> :-p
<vila> more seriously, it seems allowing paths.paths to be monkey patched (which I suspect is your short term target) is more risky than allowing iconfig.Iconfig to use a different config file (which can indeed be out of tree) as long the paths are turned into config options
<mgz> ah good, it's nearly there
<james_w> the first branch adds the support for an alternative config file
<james_w> the second is just to remove the hardcoding of base_path
<james_w> as an alternative config file doesn't help us with hardcoded paths
<james_w> with both we can have the alternative config and all the sysadmins to configure all the important paths to their liking
<vila> I understand that james_w , I'm talking about an alternative started long ago which would get rid of paths :-/
<vila> family time here, don't let me block you, go ahead with the branches, Ill catch up, but please, do some basic testing first so it doesn't blow up at deploy time
<thumper> abentley: hi
<thumper> abentley: I have a pipeline question
<thumper> abentley: is there a command to check my pipeline to see if any previous pips has revisions that aren't in the next pipe?
<vila> jml, james_w : oh, and tell me where I can look at the other service code, I'm sure it will be far clearer
<mgz> oo, symlink failure on ikiwiki
<jml> vila: lp:pkgme-binary. It probably won't make it clearer.
<abentley> thumper: You can compare two pipes with "bzr missing", but there isn't something that checks the whole pipeline.
<abentley> thumper: But "bzr pump" is a no-op if there's nothing to pump.
<thumper> ok
<thumper> cool
<thumper> might be a nice to have though
<abentley> thumper: yeah, I think so.  Could you file a bug describing the UI you'd like to see?
<thumper> abentley: sure... although in the middle of a 13 branch pipeline right now :)
<thumper> pre-merge trunk fix ups
<james_w> vila, I'm not sure I understand what the alternative you are proposing is. I'd like to consider it if it's something you've been working towards
<vila> james_w: basically: get rid of udd.paths by turning them into config options. From there we can focus on the config file handling
<jml> vila: I'm surprised. there's already so much redundant stuff in the config file
<jml> vila: why would it be a good thing to make them independent options?
 * jml â lunch
<vila> jml: the redundant stuff is a different issue, you want to redefine root_dir right ? So, it's a config option.
<mgz> vila: you stopping the importer?
<mgz> gnome-games is the last one I wanted to see through
<mgz> hopefully won't be too much longer :)
<vila> mgz: yup, sorry, didn't know you were looking, console-tools was stuck for too long
<vila> mgz: and still mentioned in the running jobs while not under the mass-import control => too much weird stuff
<vila> so: stop/start to see
<mgz> yeah
<mgz> I'm just going to do a quick post to the dd list about the unicode status
<vila> yup, would be nice, I've seen two different signatures but don't know how to interpret them (yet)
<vila> mgz: ha ! acidbase I think is the one with NFD path
<mgz> yeah, there's one more like it too
<mgz> *two more
<mgz> okay, gnome-games succeeded
<mgz> amusing that was the last packaged through, given the original bug report was about it.
<vila> huh ?
<vila> mgz: gnome-games is still running
<mgz> hm, looked finished from the package log
<mgz> but you're right, the driver hasn't got there yet
<vila> more data in the package log as we speak ;)
<vila> where are you looking ?
<mgz> I was clearly being over-eager :)
<mgz> okay, will save draft and send this email when I get back later
<vila> mgz: but looking at the log it went far further this time
<vila> mgz: it failed in the dapper era and is now in the gutsy one
<mgz> right, time for me to head off, will check in a bit later
<jelmer> hi *
<james_w> hi jelmer
<BlackDex> Hello there.. I get the following error: bzr: ERROR: Permission denied: ".": OPTIONS of 'https://*': authorization failed: Could not authenticate to server: rejected Basic challenge (https://*)
<BlackDex> And when i use SVN to check out the same repo, it works as it should
<BlackDex> Using Ubuntu oneiric
<jelmer> BlackDex: hi
<BlackDex> jelmer: Hello
<jelmer> BlackDex: how does svn prompt for credentials?
<jelmer> bzr should be able to use the credentials stored in ~/.subversion
<BlackDex> It asked once, and now it doesn't any more so i know they are saved
<jelmer> BlackDex: how did it ask though, using a simple password prompt?
<jelmer> (on the commandline)
<BlackDex> jelmer: That i can't remember
<exarkun> is there a way to use a file url to access and svn repository using bzr-svn?
<exarkun> /and/an/
<BlackDex> i can remove/rename the .subversion and try again
<jelmer> exarkun: it should support file URLs and local paths
<BlackDex> jelmer: It asked on the prompt via the cli
<exarkun> Ah, indeed.  Thanks.
<BlackDex> Although if i check. There is a file in "~/.subversion/auth/svn.simple"
<BlackDex> And there i see it is using gnome-keyring but it has my username in it and the correct info
<BlackDex> as far as i can tel
<BlackDex> but not the password it self
<jelmer> BlackDex: ah, we don't integrate with gnome-keyring well yet so that's probably the issue
<jml> vila: I seriously don't get why you want us to add more variables to the config file that no one actually wants to configure
<BlackDex> strange.. it worked under natty
<vila> jml: you don't want to redefine root_dir ???
<jml> vila: root_dir, no. base_dir, yes. download_cache_dir, hell no.
<exarkun> if "discovering tags" is taking ages when checking out an svn branch with bzr/bzr-svn, is there something that should be configured that would make it faster?
<vila> jml: yes, base_dir from which all the other paths are derived from (including root_dir, the names confused me)
<jml> vila: right. I don't want to configure download_cache_dir or debian_diffs_dir or any of those other things separately from configuring base_dir.
<vila> jml: I'll be fine if they are all  calculated from base_dir, making them config options is one possible way to get there
<vila> jml: yes, me neither
<vila> but if I have to (and today I have) I'd rather have all the definitions in a single place
<jelmer> exarkun: newer versions of bzr-svn are somewhat more efficient in that regard
<jelmer> vila: hi
<jelmer> vila: I think I saw something about the rollout of a new bzr-builddeb
<jml> vila: so maybe let's move the things we don't want to configure out of the config file
<vila> jelmer: hey, we've deployed a newer buildeb on jubany, is it ok to retry the multiple tarballs imports
<exarkun> jelmer: So it's just slow (~5 minutes to branch) until I upgrade?
<vila> jml: and separate base_dir from the others ?
<jelmer> exarkun: it might be related to the number of tags in the twisted repo
<jelmer> vila: yeah, go for it
<jml> vila: well, if it's the only thing that needs to be configured, then yes.
<jelmer> vila: worst that can happen is that they still fail I guess?
<vila> jelmer: roughly yes, but it's funnier to requeue them if there is some hope it's useful ;)
<vila> jml: what if one site want to put web_base_dir somewhere else ? They will still have to chnage the code ?
<vila> jml: the hierarchy about where the log files are stored have already changed
<jml> vila: then we'll deal with that use-case when we get to it?
<jelmer> vila: I haven't tried it on a large number of packages yet, but I think it should work - at least for a fair number of the currently failing ones
<vila> jml: we *did* get to it, maxb created udd/paths by starting centralizing them
<jml> vila: ok, so I'm confused
<vila> s/centralizing/to centralize/
<jml> vila: what do you want?
<vila> if we change the way we access the paths (as james_w proposed) I'd rather change it to something that makes it clear that these paths *can* be configured
 * maxb thinks there should just be one config var, for the root of the tree. People can use symlinks if they must for the rest :-)
<maxb> *especially* the various paths within the www dir
<vila> more nightmare for testers
<vila> or any other alternate installation really
<vila> unless you want a setup.py ? or a proper package ?
<vila> and I still don't know how to add comments on symlinks and I really like having comments to describe such a hierarchy
<jml> well, the start of having a proper package is getting the config file out of the branch
<vila> jml: it was out of the branch and as such made the deployment harder
<BlackDex> jelmer: In Natty i had to manualy gif my username and password, now i just get an error..
<BlackDex> But i try to config it so it doesn't use gnome-keyring now
<maxb> Why would we ever want a "proper" package?
<jml> vila: what do you suggest we do for our deployment then?
<jml> vila: maintain a fork?
<jml> just for the config?
<vila> nope
<vila> having your config file override the one in the branch and maintain it as you see fit
<jml> every single setting
<jml> better not miss one
<maxb> Actually, what if we remove all the path configuration. ALL of it. Just find paths relative to the running script
<vila> until we can make the options depend on each other as mentioned in the config file
<jelmer> BlackDex: I think the difference is that svn now uses gnome-keyring by default
<jml> wait for a facility to allow a config file to do something that code can already do, just in case someone comes along who wants to customize something?
<vila> jml: at which point you'll have only to define the differences which should be very narrow
<vila> meh, I'm not the one asking for the change right now, I want to have it for tests but just create the same /srv dir for now
<james_w> isn't https://code.launchpad.net/~james-w/udd/config-location/+merge/80337 allowing for having a config file that overrides the one in the branch?
<jelmer> BlackDex: svn in oneiric that is
<vila> james_w: yup, I have only minor (if even) objections to that one
<jelmer> vila: can you requeue the multi-tarball packages?
<vila> jelmer: asap but I'm waiting for the importer to gracefully stop right now
<james_w> vila, cool
<jml> vila: what sort of tests do you want for the other branch? self.assertEqual(paths.web_dir, os.path.join(root_dir, "www"))?
<BlackDex> jelmer: It also seems i can't force it to store it as plaintext
<vila> james_w: i.e. if a config file is found take it, otherwise use the old one is perfectly fine with me
<BlackDex> jelmer: Well there is only one way to bypass all this.. by putting the username and password in the branch.conf in front of the URL
<vila> jml: for unit tests, yeah, make sure we still produce the same as before, smoke tests that all scripts are still behaving correctly are more important though, failing that, tell me it still run for your deployment
<vila> s/it/they/
<vila> jml: that's where I have most fears, these paths where collected from scripts where they were evaluated very early, they should all be more dynamic now. So making them use base_dir *should* work, but the only way to be sure...
<BlackDex> jelmer: If i want to create a bug report, where should i report this bug?? bzr-svn or bzr?
<jml> vila: ok.
<vila> jml: sorry to sound picky here, but right now, I'm waiting for an import to finish so I can restart the importer one last time hopefully fixing the last issue introduced by deploying PATH/PYTHONPATH shuffling across the scripts ;-P
<vila> and it's EOD ;)
<jml> vila: understood :)
<james_w> vila, is http://paste.ubuntu.com/719082/ like what you are thinking for unit tests?
<vila> james_w: eeerk, base_dir is already define there but we still don't use it :-/
<vila> grr
<vila> jml: by the way, expanding the options *is* available in bzr-2.4
<vila> jml: which bzr version do you use or require for you pkgme ?
<james_w> vila, defined where?
<jml> vila: I think anything better than 1.14 would work
<vila> in pkgimport.conf
<james_w> yes, and this branch makes it use it I thought?
<vila> jml: hehe, seriously, are you constrained by some LTS support or something ?
<james_w> the second branch that I submitted
<jml> vila: probably we'll deploy on the IS standard: lucid
<james_w> we can ask for a newer bzr if it's needed, but we're not interested in making use of the expansion behaviour
<vila> jml: urgh rmadison bzr =>  2.1
<james_w> and neither is package-import as far as I am aware
<james_w> so I don't feel the need to do the work to allow configuration of paths that no-one wants to change at this point
<james_w> we do want to configure the base dir though
<james_w> I think maxb's suggestion makes sense, but I don't know why I didn't just do that in the first place :-)
<jml> brb
<james_w> but I can see that wanting to put the output somewhere other than where the code lives would desirable
<james_w> even if it's not how it's deployed on package-import
<vila> james_w: then I think I kind of miss the point of your proposal, why not create a symlink from /srv/pack.... to where you want your new deployment to live and be done with it ?
<james_w> we certainly could, but there was a big FIXME in the code when we found this, so we thought we would FIXIT
<james_w> and perhaps IS will want to deploy to the same machine, we don't know yet
<vila> james_w: well, back to .... go ahead :) I will be able to redefine base_dir in locations.conf with your proposals so it's already a good step
<james_w> ok, thanks
<lamalex> hi, how to i delete my launchpad login info?
<peitschie> morning all :)
<poolie> hi all
<jelmer> hi poolie
<poolie> hi there, how's cali?
<jelmer> sunny :)
 * jelmer bets Sydney is even sunnier
<poolie> mm, not today, ~14C and cloudy
<poolie> it was 36C and sunny on monday
<fullermd> Fortunately, we don't have any of those "C"'s in this country.  Sounds like a commit plot to me.
<jelmer> fullermd: I'm in your country but I'm sticking to SI, thankyouverymuch. :-P
<fullermd> Onoes.  The Red Invasion proceeds   :(
<peitschie> (I'm late to the party... but you can tell you work with source control too much when your mistype "commie" as "commit" jelmer :P)
<poolie> :)
#bzr 2011-10-26
<peitschie> hi poolie btw :).  It's been a while!
<fullermd> Jeez.  I didn't even notice that.
<poolie> hi guys
<fullermd> That explains why bzr keeps redistributing my files according to need...
<peitschie> roflmao
<spiv> fullermd: funny thing for a decentralised system to do ;)
<spm> Q: have branch A (master) and my edits to that in branch B. want to verify the diff between A and B. I typically do this as cd A ; bzr merge --preview ../B/ Is there a 'better' way of achieving this?
<spiv> spm: perhaps âbzr merge -d ../A --preview .â
<spiv> Depending on how you define âbetterâ ;)
<jelmer> "cd B && bzr diff -rancestor:../A" ?
<jelmer> (if you want to see the differences new in B rather than the result of the merged tree)
<spm> spiv: not having to have my cwd in A would be ideal. I have powers in there and avoiding even accidental pulls/merges etc is the goal. So yeah, that solutions works nicely!
<spm> jelmer: ooo. that works nicely too. I think I prefer that. clearly a 'diff' action, vs a merge trial. ta muchly!
<spm> and yes, want to verify that my changes are what I expected (lots of people are all working to the master, so is constantly updated). A final sanity check before I put the MP up. more or less.
<peitschie> is there anyone here that could assist with bazaar explorer hats?
<peitschie> i'm trying to create some custom toolbar entries (as opposed to "tools" entries), and just can't seem to get it to show up :(
<poolie> hi spiv
<poolie> peitschie: i can try to help but i don't have any suggestions just off that
<poolie> probably i'd just try to see what's different between your configuration and what it ships with
<poolie> or put in some trace messages to work out why they're not active
<peitschie> poolie: i can get the toolbar to show up if its in the user-coded file, and the button highlights when the hat is actually selected in the explorer hats window... but there doesn't seem to be any examples of people doing it in the wild that I can tell
<poolie> so what exactly is going wrong?
<peitschie> poolie: thats the question :).  I'm getting a local branch of the current head now and will start with the print statements.  Basically, when the user browses to the repository screen, I want to add a new button up near the existing 3 in the toolbar that says "Create new feature"
<peitschie> poolie: the toolbar element appears to work when I put it in the user file directly (the one stored in their main bzr configuration)
<peitschie> poolie: just doesn't do anything when I put it in the hat's own toolbars.xml file
<poolie> ok
<poolie> i don't know off hand, it may just be a bug, i'll try to help you fix it
<peitschie> poolie:... ahh... that'd do it.  I don't think the file is even being requested :/.  Will investigate further :)
<peitschie> poolie: found the problem.  Filed a bug https://bugs.launchpad.net/bzr-explorer/+bug/881783 :)
<ubot5> Ubuntu bug 881783 in Bazaar Explorer "Hat toolbars are not displayed (though user ones are)" [Undecided,New]
<poolie> oops
<peitschie> poolie: the problem is to do with the toolbar builder not refreshing after the hat is loaded... I don't have enough system knowledge to know the proper way to fix it though :(
<poolie> peitschie: still here? do you want me to look into it?
<peitschie> poolie: i am still around :).  As I stated in the bug, I know the system cause (lazy loaded hats), but don't have a fix.  If you've got time for a fix, I'd never turn it down... I was potentially going to glance at it this weekend though outside work to see how difficult it is to rejig
<poolie> i'll leave it with you then because i have some things in my queue already, but please do ask if you get started on it
<peitschie> poolie: alrighty :)... thanks for the assistance!
<poolie> hi jam, you're up late, or early :)
<mgz> morning all
<vila> hi mgz, poolie
<vila> hi all other :)
 * fullermd flails around in a vaguely wave-like fashion.
<Merwin> hi vila :)
<vila> Merwin: I've made progress on your bug, resolve is not the root cause, merge is
<Merwin> Pfiou, seems to be a big and complicated bug
<poolie> hi vila, mgz
<mgz> okay, sent a note to the udd list about yesterday's fun with the package importer
<ccxCZ> jelmer: current bzr-git claims to require dulwich 0.8.1, but I don't see that released anywhere, does that mean dev version then?
<ccxCZ> and if so should I branch you @ samba.org or at launchpad?
<mgz> ccxCZ: I hope he's asleep, but to answer your questions, yes, and either, launchpad worked fine for me
<poolie> ok, signing off now
<poolie> mgz, good for you
<mgz> have a nice evening poolie
<ccxCZ> ah forgot this is slow channels :] he spoke few lines back and I forgot to check the timestamp
<vila> g'nignt poolie
<mgz> I can help out if you get stuck, but all you should need (provided you have the right -dev packages) is the normal setup.py run for dulwich then bzr-git after removing your current versions
<poolie> this was fun, and should be useful
<ccxCZ> how the hell this happened http://paste.pocoo.org/show/498354/
<mgz> I picked something other than the stats module for a reason when I studied maths...
<ccxCZ> seems to work with --no-plugins, hope newer dulwich will fix this
<mgz> ccxCZ: ah. that looks like the latest bzr-git not liking bzr 2.4, checking
<ccxCZ> humm, didn't help one bit http://paste.pocoo.org/show/498360/
<mgz> sec, I'll try and repo here with your versions. you're on the very latest bzr-git and dulwich now, and bzr 2.4.1 right?
<vila> mgz: so, it eems I was wrong about categorise-failures adding spurious jobs. What I think is happening is that add-import-jobs is the culprit. It queues imports that *may* be needed by looking at the last know publication and subtracting 10 minutes for safety. So what we probably observe are imports that already succeeded but are still retried for safety, pfew.
<mgz> vila: that sounds hopeful
<vila> mgz: the 10 minutes interval may be wrong (probably more like at least one hour based on my observations), but overall this scenario makes sense: the usual suspects vary in time and new ones keep appearing
<vila> like the one surprising us yesterday paraview or something ?
<Pegasus_RPG> Hello. How can I effect a 'bzr launchpad-logout' command and bind the branch back to the anonymous http variant?
<ccxCZ> mgz: yup, I got the bzr-git off launchpad and dulwich off jelmer's samba.org repo
<Pegasus_RPG> nvm, I found %appdata%\Bazaar and deleted authentication.conf and bazaar.conf. That seems to have done the trick since I can now bzr bind http://blah.
<mgz> right, all you need to delete is the launchpad_username in bazaar.conf
<mgz> rather than the whole thing (for future reference)
<vila> or comment it out
<vila> mgz: so, for the record,  right now, voms and asmix are recurring
<vila> there may be others but let's lazily monitor these ones ;)
<ccxCZ> vila: btw where was your gentoo cheatsheet? I had few comments on it
<mgz> wooo
<mgz> bzr: ERROR: Connection error: while sending GET /bzr/jelmer/dulwich/.bzr/repository/packs/b67bf1ab2764bc006a2178d144dbd819.pack: [Errno 8] _ssl.c:499: EOF occurred in violation of protocol
<mgz> never seen that before
<vila> mgz: reproducible ?
<mgz> doesn't look like I get ccxCZ's bug though
<mgz> vila: trying again
<vila> ccxCZ: http://paste.ubuntu.com/719529/ ?
<mgz> vila: nope, worked second time
<vila> mgz: which server ?
<mgz> samba.org
<vila> no idea then
<vila> net glitch ?
<mgz> possible, I might file just so it's recorded
<mgz> ccxCZ: so, python2.7, bzr 2.4.1, dulwich trunk, bzr-git trunk works for me
<ccxCZ> mgz: doing the eadd on git repo?
<mgz> no, but doing a branch over git, which is your first traceback
<mgz> and comes from the same line in bzr-git for you.
<ccxCZ> if by first traceback you mean this: http://paste.pocoo.org/show/498354/ then that's doing bzr branch it mistakes for git.
<ccxCZ> maybe I should disable irrelevant plugins to test it
<ccxCZ> is there way to blacklist/whitelist plugins without uninstalling them?
<mgz> `bzr help env-variables|grep PLUGINS`
<vila> `bzr help env-variables|grep PLUGIN` unfortunately one of them has no S
<mgz> ^that exact command works for me though, using bzr-git to branch the repo
<mgz> looking at the code, I'm a little mystified as to how this inheritance is working, it *looks* wrong for GitRepository to pass None to super()__init__
<ccxCZ> whitespace delimited?
<mgz> but apparently doesn't break things for me
<mgz> ccxCZ: colon
<ccxCZ> hmm, it still lists them in the backtrace
<ccxCZ> okay, I typoed, seems to branch now, so it's not bzr-git's fault
<mgz> can you binary it down to one plugin at fault?
<mgz> the builtin ones should all be okay as they didn't mess things up for me
<ccxCZ> probably some ages old forgotten plugin in my homedir
<ccxCZ> seems the bzr-svn is doing it (and that should be fairly recent version afaik)
<mgz> ccxCZ: yeah, you've got the latest version apart from the release from last night
<mgz> ccxCZ: I'd suggest filing a bug against bzr-git, with your traceback, and highlight the versions of which plugins are needed to trigger it
<mgz> ccxCZ: I'm guessing just `bzr info` in a git branch is enough to trigger it?
<mgz> if so, post that traceback
<ccxCZ> this happens with the latest bzr-svn http://paste.pocoo.org/show/498377/
<ccxCZ> there was no git branch involved, it was remote bzr branch (https) somehow mistaken for git branch
<ccxCZ> jelmer's public bzr branch of dulwich to be precise
<mgz> fileabug.
<ccxCZ> kay
<ccxCZ> this is bzr-svn bug definitely though
<mgz> it seems like it, and maybe a fixed one
<mgz> but I don't see any likely looking existing bugs
<mgz> and given the info we've got already, pasting it all in and getting duped against something is probably still a good thing
<ccxCZ> yup, I'll paste behaviour of all combinations
<ccxCZ> let me try on different server with and without https first
<ccxCZ> okay it's definitely https that triggers this, writing a bug
<ccxCZ> seems it's already reported: https://bugs.launchpad.net/bzr-svn/+bug/774571
<ubot5> Ubuntu bug 774571 in bzr-svn (Ubuntu) "bzr-svn: svn plugin seems to mess with read-only basic https connection" [Medium,Triaged]
<mgz> hm, what's the best way of merging in an older branch that doesn't really apply any more?
<mgz> I could cherrypick individual changes, or merge the whole thing and resolve out/revert parts
<mgz> or some other cunning scheme?
<fullermd> What does "doesn't really apply any more" mean?  As in "things have diverged enough that merge is a mess", or as in "some of these changes are OBE and should be dropped"?
<mgz> the latter really.
<fullermd> Ah.  I don't have any excessively brilliant suggestions there.
<mgz> but it's different enough that merging then reverting individual bits doesn't makea great deal of sense probbly
<fullermd> You have the obvious additive and subtractive options.
<fullermd> Either making a new branch and cherrypicking over the pieces to keep, or adding on to the end of the existing branch reverting the bits you want to dump, and then merging in whichever end result.
<mgz> so, I can resolve the initial conflicts in ways that don't actually make sense without also backing out non-conflicting parts
<fullermd> (depending on the relative scales of keep-vs-lose, and whether you care about having/not the to-lose bits hiding in the history, etc)
<mgz> I guess there's no actual requirement that each revision makes sense with mainline-y operation
<mgz> hm. actually thanks fullermd, the second one there is sanest and I hadn't thought of
<fullermd> Insofar as the former (massively-divered) applies, I've found the best way of dealing with that is just incremental pullins of trunk.
<mgz> reverting in the branch then merging makes way more sense than merging then reverting, which is what I was thinking of
<fullermd> Yeah, I always like doing as much prep as possible off to the side before worrying about doing the merge.
<ccxCZ> vila: http://codepad.org/nUKU3Qcx my comments start with #
<vila> ccxCZ: thanks !
<mgz> gra, paramiko upstream being dead is a problem
<mgz> and can't work around this one by patching in ubunut as it's win64 issue
<mgz> ...I need to stop typing ubuntu like banana, the t always ends up at the end
<vila> mgz: bananut ? :-D
<mneptok> mgz: try typng "l-i-n-u-x" ;)
<vila> mneptok: G-N-U-/-L-i-n-u-x :-D
<mgz> linus doesn't distribute a copy of paramiko, I feel.
<mgz> nor gnu, for that matter.
<mgz> ubunut is quite a good name for a fan club though.
<mneptok> or the name for a male endocrinology clinic for characters in early 20th century theatre-of-the-absurd plays.
<vila> bug #880701 half-fixed, yes it makes sense :)
<ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
<mgz> vila: did you do the easy half or the difficult half? :)
<vila> dunno yet, but the first half was a royal pain...
<vila> ghaaaaaa mgz pleeeeease make 2.4 pass the whole test suite ;_;
<vila> testools 0.9.12 compat or something
<mgz> okay, I'm looking at that area anywa
<mgz> y
<mgz> it's just jelmer's hack-around got one little bit wrong
 * vila kneels down
<mgz> in case I need it later: 5967.1.81..-1
 * mgz switches
<mgz> okay, recent testtools is the one that passes, going back to...
<vila> huh ?
<mgz> 0.9.5
<vila> I'm at revno 224
<mgz> okay, current passes, 0.9.6 passes, r224 fails.
<mgz> fixing
<vila> by current you mean 230 ?
<mgz> I guess I mean whatever I had installed, which I assumed was recent but may have been older
<mgz> oh, I see, it's simpler than that, Jelmer's change never landed on 2.4
 * vila bangs head
 * fullermd cranks up some Slayer.
<vila> dang, the other half is *not* symmetric :-(
<vila> and to make matter worse, it seems to require 2 conflicts, not a single one, which in itself means more pain down the road
<mgz> vila: fixed on 2.4, and merged up to dev, will propose both branches
<vila> great !
<mgz> took a bit of a diversion as this code should be deleted on bzr.dev shortly, but makes sense to merge fix from 2.4 for now
 * vila nods
<vila> hmpf
<vila> when you've tried all reasonable approaches, start looking at the stupid ones
<vila> so, I've got the second half fixed but it's so obscure I don't dare proposing it :-/
<fullermd> Just make a giant pile of whitespace cleanups, and sneak it in with them.
<vila> hehe
<vila> the funny thing is that the fix is roughly: don't generate a conflict because the magic will create the right one later
<mgz> gra, too easy to mistarget branches in launchpad, especially when juggling several
<odin_> is the version (of a package in launchpad) only set in the comment line at the start if the recipe ?  no other way to derive it (say from the git last commit date) ?
<odin_> this shell command gives of roughtly the right version number I want to be used: date -u -d $(git log -n1 --pretty="@%ct") "+%Y%m%d%H%M%S"   # "20110930161611"
<lamont> speaking of recipe builds... I need someone clueful to help me test the new bzr-builder...  any takers in jelmer's absence?
<wgz> you're the wrong end of the day for me I'm afraid lamont
<wgz> and I've hit a different random failure on pqm...
<vila> wgz: which one ?
<vila> wgz: and on which branch ?
<wgz> bug 882168 which was from <https://code.launchpad.net/~gz/bzr/dev_2.4_integration/+merge/80484>
<ubot5> Launchpad bug 882168 in Bazaar "Connection refused on TestTCPServerInAThread test" [Undecided,New] https://launchpad.net/bugs/882168
<wgz> doc only change in dev.
<vila> wgz: yup, known one, seen occasionally on babune
<vila> wgz: not having different tests *exactly* for this one makes it hard to know the root cause
<wgz> have we got a bug already? a quick search didn't turn one up.
<vila> no
<wgz> k.
<wgz> vila: oo, you have the merge fix up, looks fun
<vila> yeah, read the log scrollback, the second half is... making the test pass ? May be the right way... a bit scary still
<vila> but, well, that may just be the tree transform way...
<wgz> vila: can you eyeball the merge of my test_selftest change to bzr.dev?
<wgz> then I'll send the 2.4 version and that to pqm
<vila> I think my hesitations are captured by: I'm happy to not have to review it :)
<wgz> ehehe
<vila> done, EODing, have fun !
<wgz> thanks!
<jimis> hello all, is it possible to annotate from one revision until today?
<jimis> I've tried --revision=REVNO but I think it annotates up to that revision, any ideas?
<fullermd> You mean to just attribute any earlier lines to $REV1?
<fullermd> I don't think so...
<fullermd> Not via the UI at least.
<wgz> it's probably worth a bug report jimis, against bzr and qbzr
<jimis> fullermd: I mean annotate all more recent lines than REVNO
<wgz> he got that. the question is what to do with lines that predate REVNO
<fullermd> What would you do with lines that predated it?  Omitting them would be kinda a-POLA...
 * wgz wins
<jimis> :-)
<jimis> POLA?
 * fullermd breaks a couple of wgz's fingers to ensure his future victories.
<fullermd> Principle Of Least Astonishment.
<jimis> :-)
<jimis> probably just not annotate at all earlier lines
<fullermd> You Expect(tm) annotate to show the whole file.  Or at least a contiguous bit of it.
<jimis> yes show it all, but leave blank the sidebar on earlier lines
<fullermd> Blank on the sidebar already means "same as previous".
<jimis> so you can concentrate on the lines that interest you :-)
<jimis> ah ok
<wgz> it might be quite easy in qbzr
<fullermd> Anyway.  I'm not arguing against it in principle.  A proper-ish UI could be found.
<wgz> as that already loads the file content then fills in the revision info and colours
<fullermd> Would just take someone doing it.
<jimis> I always use cmdline ui
<fullermd> The Obvious(tm) invocation would be "bzr annotate -rX..Y $FILE"
<jimis> right :-)
<jimis> hmmm I think I found a relevant bug #700878
<ubot5> Launchpad bug 700878 in Bazaar "bzr blame: annotate --revision takes exactly one revision identifier; ideally any arbitary range should work" [Wishlist,Confirmed] https://launchpad.net/bugs/700878
<wgz> that looks likely, +affectsmetoo it
<jimis> anyway thanks guys, hopefully someone will look into it :-)
<poolie> hi all
<Noldorin_> hi poolie
<poolie> hey there
<Noldorin_> :-)
<Noldorin_> hmm, funny timing.
<Noldorin_> seems i'm having trouble with pulling from LP with 2.5b2:
<Noldorin_> bzr: ERROR: Unable to connect to target of bound branch BzrBranch7(file:///C:/Users/Alex/Documents/V
<Noldorin_> isual%20Studio%202010/Projects/IrcDotNet/0.4/) => bzr+ssh://bazaar.launchpad.net/~noldorin/ircdotnet
 * poolie tries
<Noldorin_> just a standard bzr pull lp:ircdotnet/0.4
<poolie> seems to work for me
<poolie> do you get a traceback in ~/.bzr.log
<poolie> Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: mgz
<Noldorin_> poolie, http://pastebin.com/qtgm59ny
<poolie> does 'bzr info bzr+ssh://bazaar.launchpad.net/~noldorin/ircdotnet/0.4/' work?
<spiv> Noldorin_: lp:ircdotnet/0.4 is ~ircdotnet-dev/ircdotnet/0.4, not ~noldorin/...
<spiv> Noldorin_: so I'd guess the problem is the remote branch has moved rather than your bzr version.
<Noldorin_> spiv, poolie ah darn. i changed the branch owner after binding it locally... my bad, sorry!
<Noldorin_> spiv, thanks for that
<spiv> Noldorin_: you're welcome!
<poolie> hi spiv
<poolie> biab
#bzr 2011-10-27
<poolie> peitschie: maybe ian's names are too cute :)
<peitschie> poolie: hehe.  They are awkward to type in doco's thats for sure! ("Please install your... wait... what is the singular of clothes? Outfit? Cloth?")
<poolie> clothing?
<peitschie> poolie: clothing XD
<peitschie> I must admit, I do like the direction these things are going.  The next step up for me would be to make the hats & clothing easier to redistribute
<peitschie> quite a portion of my doc is related to "copy folder A to destination B", because I can't distribute a set of things (clothes, hats & plugins) all at once
<poolie> awesome
<poolie> i think that's the direction he wanted to take it
<poolie> towards being something that encapsulates a lot of the setup and policy for a particular project
<peitschie> yar... that'd be very cool.  Bazaar Explorer is the only tool I know of that is working towards this kind of thing for source control :).  very exciting!
<peitschie> for a corporate network / dev environment, it'd almost be nice to be able to point bazaar explorer at a specially structured bzr repository to retrieve these things from
<peitschie> would allow automatic versioning, distribution of updates, as well as easy management for multiple projects all at once
<poolie> yeah
<peitschie> (not that you guys are suffering a shortage of ideas ;))
<peitschie> Is there anyone around that could potentially cast an eye at https://bugs.launchpad.net/bzr-svn/+bug/882388 for me?
<ubot5> Ubuntu bug 882388 in Bazaar Subversion Plugin "Fetching svn revision info seems to be very slow" [Undecided,New]
<wgz> dark dark dark
<wgz> peitschie: nothing in particular rings a bell there.
<wgz> if you can reproduce the 30 revs/min with just the first N revisions,
<peitschie> wgz: it seems to be very consistent at the moment.  I added some more bits to the bug report though... my HDD is thrashing like crazy at the moment which makes me wonder if this is fsync related
<wgz> I'd do `bzr --lsprof-file callgrind.out branch svn:...` and attach that.
<wgz> would tell you at least who's IO was to blame
<wgz> ^+ -r100 or similar
<wgz> you can also try disabling fsync at the bzr level (can't remember what exactly the effect on windows is) with er...
<wgz> dirstate.fdatasync = false in config.
<wgz> and repository.fdatasync
<peitschie> wgz: I'll give those whirl... thanks :)
<peitschie> wgz: are those branch config options or bazaar.conf options?
<wgz> they can be global
<peitschie> wgz: those haven't seemed to help a lot (as in the HDD still goes crazy, and it isn't faster).  I've spammed the bug with a few callgrind combinations... mmm. Any more ideas?
<wgz> that looks like a good set of things for diagnosis
<wgz> as for workarounds...
<wgz> branching from svn on a nix box or older version of bzr if that's faster then branching that bzr copy?
<wgz> you could also try putting the svn-cache dir on temp storage
<wgz> there seems to be a config option, but setting up ramdisk under windows is a little annoying
<wgz> or disable the cache entriely.
<wgz> try use-cache = False in ~/.bazaar/subversion.conf
<peitschie> wgz: hehe.  I found a fun one that works!  I installed a ram-disk, and moved the svn-cache file onto that = mega faster!
<wgz> yeah, it looked from the files you posted that your sqlite hunch was right
<wgz> okay, bus time
<peitschie> wgz: thanks for your help :)
<lifeless> btw
<lifeless> there is a pragma you can set
<lifeless> in sqlite db's
<lifeless> to tell them to use a larger page cache
<peitschie> I suspect its more a transactional thing than a page cache thing though... but if anyone knows the settings I can give it a whirl :)
<peitschie> as it is, this sucker is flying along quite well with the ramdisk... and once I have a copy I can email that to the other team members I *think*
<lifeless> http://www.sqlite.org/pragma.html
<lifeless> heh, they have deprecated it (because apps are meant to set their own I think)
<lifeless> anyhow, pragma default_cache_size = 4000;
<lifeless> or some such
<lifeless> or just hack bzr-svn to issue a cache_size pragma.
<peitschie> potentially playing with the synchronous might be fun as well
<lifeless> that will need ot be issued from the process using the db
<lifeless> so hack it into bzr-svn
<jelmer> we should really finish the pack-based cache format for bzr-svn, that will fix a whole bunch of issues
<redwyre|w> is it possible to make a bzr branch/depot read only?
<maxb> chmod it?
<redwyre|w> I can't change the file permissions :/
<redwyre|w> do you mean just set the readonly flag?
<vila> hey all !
<vila> jelmer: I requeued the mutiple tarballs yesterday, AFAICS they all fail: http://package-import.ubuntu.com/status/56c18c6ef2106c8a91a81b26466fa557.html
<vila> jelmer: some shallow thing may be ?
<mgz> remorning!
<vila> mgz: hehe. hi !
<vila> mgz: posted a better explanation for bug #880701 in the mp, let me know if it helps or if you need more
<ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
<vila> mgz: 2.4 full test suite passing again, I'm so grateful for that...
<mgz> will have a look at that mp again vila
<vila> thanks in advance
<vila> damn, John McMaccarthy too !
<vila> fullermd: we'll soon be the only ones left ;)
<maxb> ok, who moved all the udd scripts into a bin/ directory and broke stuff? :-/
<maxb> jml: Hi. There's a problem with moving all the udd scripts into bin/ . They were deliberately using the fact they were in the same directory as the udd/ namespace in order to import from it
<vila> maxb: search the history a bit :) I've fixed the fallouts that appeared in production, did you find more ?
<maxb> hmm, fixed how?
<vila> maxb: oh, for interactive use, you need to set PYTHONPATH
<maxb> that sucks - before you didn't
<maxb> I'm likely to MP moving the scripts back :-)
<vila> maxb: I suggest you discuss with jml before starting an edit war :-)
<vila> maxb, jml: And having more tests for the scripts is likely to help in any case ;)
<maxb> bzrlib.errors.RevisionNotPresent: Revision {james.westby@ubuntu.com-20110209140824-ftq14u7pfwalt6f2} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<maxb> Am I right in thinking we've not got to the bottom of why that happens?
<maxb> (branching a precise branch)
<vila> obviously :)
<mgz> cleaning up the lp:udd layout without also adding an install step does seem to have been... disruptive
<maxb> pleeeeeeeeaaaaaaaaaaaaaaaaase no install step
<mgz> ^which branch maxb?
<maxb> ubuntu/precise/libraw
<vila> maxb: oh, that one, yeah, weird, I can't reproduce the failure seen by the importer myself
<mgz> maxb: in which case, reverting the bin move may be the best option, can always install *into* bin from root of repo
<odin_> is there a comment to check if the tree is clean "bzr status ." via exit status ?
<vila> mgz, maxb: Let's not have this discussion without jml and james_w or we'll run into circles :-}
<maxb> yeah
<odin_> s/comment/command/
<mgz> I was wondering odin...
<vila> a discussion on the udd mailing list may help gather all the point of views, pro and cons though
<vila> odin_: IIRC there is an opne bug about status not returning a documented retcode.
<vila> odin_: but I'm not sure everybody agree about what constitutes a 'clean' tree (with or without 'unknowns' for example)
<mgz> status doesn't seem to return anything in fact
<odin_> Set also: status-flags  (does this exist anymore?)
<mgz> it's always 0 or an internal error
<odin_> then add that as an option
<odin_> bzr status -q --exclude-unknowns && echo "Tree is clean"
<vila> odin_: --strict is used for commit already may be more coherent, care to file a bug or +affectsmetoo the existing one ?
<maxb> hm, it's looking like oneiric/libraw was damaged, and precise just copied that
<mgz> maxb: the branch-distro check log doesn't complain about it, wasn't one of the ones with stacking issues
<vila> mgz: was this log posted in a bug ?
<vila> mgz: or did we never get the whole file ?
<vila> (got ?)
<mgz> I have a copy.
<mgz> scped from carob
<odin_> ok will lookup bug system in a moment, for now I try: wc=$(bzr status . | wc -l); if [ $wc -eq 0 ]; then echo "Tree is clean"; fi
<maxb> waiiit. now I can branch precise but not oneiric?
<maxb> Perhaps a mis-reading by me earlier
<maxb> But, bzr 2.3 'bzr check's oneiric, whilst bzr 2.4 fails it
<vila> maxb: while you're there (good to see you by the way ;) any issue with the beta ppa or just lack of time ?
<maxb> just lack of time. I can probably devote some this weekend
<vila> that would be awesome !
<mgz> curious parties can see branch-distro-2011-10-14.log in my homedir on jubany for the full log with stacking warnings
<maxb> uhoh, has bzr 2.4 regressed where accessing stacked repositories containing zero packs?
<maxb> libraw/{oneiric,precise} have the same last-revision. oneiric is stacked on precise, and oneiric has no packs. Yet I can branch precise but not oneiric
<maxb> whereas I *can* branch oneiric on jubany using the bzr 2.3 there
<maxb> Also I'm seeing lots and lots of spurious-looking refresh_possible_transports errors
<vila> maxb: really ? where ?
<maxb> logs/packages/libraw, for example
<maxb> it makes me wonder if the recent changes to broaden the caught exception there have gone a bit too far
<vila> maxb: well, if the transport is dropped, there are not spurious, they are supposed to avoid errors while trying to reuse a dead transport
<vila> but the fact that there are so may of them makes me wonder about proper tracking of connections for reuse...
<vila> hmm, may be it's too aggressive indeed as it seems to drop even valid transports...
<maxb> yup
<maxb> In particular "No such file: file-that-does-not-exist" is not a problem with the connection :-)
<vila> maxb: http://paste.ubuntu.com/720526/ ?
<vila> maxb: the previous 'bzrlib isn't supposed to raise this error, but it does' comment when catching errors.PathError was a bit misleading no ? ;)
<vila> Merwin: I've got a fix under review for bug #880701
<ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
<Merwin> Hi vila!
<mgz> okay, other tasks done, I will now bang my head against vila's conflicts code
<vila> mgz: make some tea first ;)
<Merwin> vila: Nice work ;)
<mgz> argh, speaking of conflicts...
<mgz> were it not for release-notes I wouldn't even know what a conflict was
<mgz> ...okay, that's a slight exageration
<vila> Merwin: thanks, that was a really hairy bug
<vila> mgz: bzr help conflict-types ?
<vila> maxb: ping ?
<spiv> mgz: improve news_merge then ;)
<vila> spiv: hey !
<vila> spiv: news_merge works pretty well in general, the issue to have it correctly configured (but you know that ;)
<vila> s//is/ somewhere
<mgz> or at all I think, with pqm
<mgz> okay, and ...I can't get this conflict locally, what was pqm's issue
<vila> mgz: and you don't have the news_merge configured locally ??
<mgz> nope.
 * vila blinks
<mgz> okay, I'm mystified
<mgz> and pqm doesn't give me any more information apart from:
<mgz> Executing star-merge http://bazaar.launchpad.net/~gz/bzr/lru_cache_refactor at Thu Oct 27 09:59:03 2011
<mgz> Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt
<maxb> vila: pong
<vila> maxb: nm, I wanted feedback on http://paste.ubuntu.com/720526/ but it's quite trivial
<maxb> ah. looks superficially fine, and as I presently on a bus, I don't have easy access to additional context
<maxb> * I'm
<mgz> reviewing diffs from a bus is impressive in itself
<vila> maxb: hehe, don't worry, enjoy your ride ;)
<mgz> okay, getting somewhere understand merge
<vila> mgz: great, that's a very tricky area with ramifications
<vila> ..unsurprisingly...
<mgz> vila: posted review, lunch lunch
<vila> 1) thanks ! 2) good idea !
<vila> :)
<vila> mgz: thanks for the review, I've replied, we can discuss here to reach an agreement if you want
<vila> something weird seem to have happened to the chromium-browser import... it lloks like it has been restarted? at  Time (UTC): 2011-10-27 04:52:29.428890 ???
<mgz> vila: review responses look fine to me
<vila> ha, good, thanks !
<vila> mgz: good to land then ?
<mgz> hm. ideally I think someone else should have a chance to look at it as well, but we are a little short of someones currenty
<vila> yeah :-/
<vila> Now, I think the risk is pretty low there,
<mgz> especially as its 2.4 targetted and we're overdue a 2.4 release, landing this is a little uncertain
<vila> I'm not adding a new kind of conflict, I'm refining a case with exceptions that were leading to a malformed transform
<vila> which partly explains why the fix itself seems so obscure
<vila> yeah, 2.4.2...
<vila> I'm one the biggest fan of timely releases but I feel this one could be delayed until after UDS (unless you've seen an unusual number of bug reports for 2.4.1)
<vila> I'm a bit more pro-active than usual when it comes to conflict/resolve related bugs as they generally mean some user is blocked
<vila> hard
<vila> and this fix will help a lot of people encountering first-level parallel import issues,
<mgz> yeah, I think the targetting is good
<vila> I also suspect these are generally not reported as people may feel they were at fault since it occurs only when you add the same file in two different branches
<mgz> I'm just wondering whether releasing a 2.4 version with this, right now, is a good idea
<mgz> I'd prefer not to delay till after UDS, but obviously I'm not the one who's doing the work
<vila> oh, if I were to release 2.4.2 today, I probably won't land this
<vila> on the other hand, without a release, few people will be able to test it
<jml> maxb: I thought vila fixed that yesterday
<mgz> we just said on the list of a couple of people who's bugs we fixed in 2.4 that we'd release this week
<vila> mgz: so, land on trunk ?
<vila> crap, missed that
<mgz> vila: in the mgz ideal world, release 2.4.2, land merge fix for 2.4.3
<vila> mgz: ok, so.... 2.4.2 freeze time I guess :-{
<vila> .me nods
 * vila nods (hehe typos in irc commands now)
<maxb> jml: vila's worked around it by adding PYTHONPATH in places, but formerly there was no requirement to set PYTHONPATH to make the scripts work
<mgz> jml: basically running from source got a bit more annoying I think, it's certainly possible to do
<jml> mgz: there are tricks we can do to work around it. I think the separation is worth it for code discovery.
 * jml â meeting
<exarkun> Why can't I branch http://svn.twistedmatrix.com/bzr/Twisted/branches/halfclose-tls-5341 ?
<vila> mgz: finding bug #839461 again, mentioning it so you can update your in-brain-bug-db ;0)
<ubot5> Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461
<vila> mgz: to be clear, I'm not suffering from it right now, just read it again in releasing.txt
<exarkun> uuugh
<exarkun> Why does bzr need over 2GB of memory to make this branch?
<exarkun> jelmer: is the reason newer versions of bzr-svn are "more efficient" is that they use a ton of memory instead of a ton of time?
<exarkun> up to 2.8GB, which is almost 6x as much memory as this machine actually has, so I guess this operation will never complete, will probably get OOM killed, and I suppose that's why I can't check out that branch.
<mgz> exarkun: how much of that is the sqlite cache and how much is python?
<exarkun> mgz: is there an option to `topÂ´ to split up like that?
<mgz> vila: right.
<mgz> exarkun, no it's all in-process so basic nix tools won't help unfortunately.
<exarkun> How would I answer that question, then?
<mgz> finding the cache dir and looking at it should tell you the basics though
<exarkun> ugh
<exarkun> the cache dir has two kinds of database in it
<exarkun> The sqlite3 database is only 51MB
<exarkun> So I hope the sqlite3 cache isn't a lot larger than that
<mgz> that sounds reasonable indeed.
<mgz> the other one isn't huge either I take it?
<exarkun> 16MB
<mgz> probably just having the whole tree in memory or something instead then
<exarkun> This wasn't a problem before I upgraded to the latest bzr-svn
<exarkun> I could actually check out branches, though it took 5 minutes.
<mgz> file a bug, 2.8GB is clearly bad
<mgz> I'd suggest getting a meliae log of all objects as well, but that's unfortunatly not straight forward
<exarkun> https://bugs.launchpad.net/bzr-svn/+bug/191731 seems related, though it was filed 3 years ago
<ubot5> Ubuntu bug 191731 in Bazaar Subversion Plugin "Memory problems prevent branch of very large svn repositories" [Medium,Triaged]
<mgz> happened to look at that earlier today, nothing left there but general bzr problems with big branches
<mgz> I'd file a new one, as this is a regression from your upgrade
<exarkun> Okay
<exarkun> filed <https://bugs.launchpad.net/bzr-svn/+bug/882578>.  seems somewhat anemic.  I don't think I can get a meliae log.  Maybe I can try if the problem isn't reproducable elsewhere.  Anything other information you'd suggest adding?
<ubot5> Ubuntu bug 882578 in Bazaar Subversion Plugin "Too much memory used when branching" [Undecided,New]
<mgz> well, knowing if downgrading bzr-svn would be useful (to you as well, if that means you can branch again)
<mgz> and a .bzr.log extract is always worth it
<mgz> otherwise seems find as a symptom-bug
<mgz> s/find/fine/
<exarkun> Okay.  Thanks for the help.
<mgz> vila: thanks for the 2.4.2 release!
<vila> hehe, looks like your nudge was the right trigger to make it quickly (or quicker than usual at least) ;)
<vila> woohoo we can compile the bzr extensions on jubany :-D
<mgz> that was fast. I wondered if asking for the bzr build deps was a bit much, given the junk we pull in to do pretty docs and such like
<vila> easier to express :)
<vila> the idea was that even old build deps should be enough and I didn't need to list them either
<vila> now, if chromium-browser would finish (or at least say *something* in its log...)
<vila> I smell something weird going on there...
<vila> ... but top reports it's happily crunching on something memory even (but less than the observed maximum), the CPU goes up and down (so IOs somewhere ?)...
<bigjools> can anyone help with an svn import weirdness please?
<bigjools> https://code.launchpad.net/~vcs-imports/spamassassin/trunk
<bigjools> taking massively longer than normal
 * bigjools hopes jelmer is around today
<bigjools> Darxus: this is a better place to ask as it's essentially a bzr thing. I hope someone replies.
<Darxus> Thanks.  Can you paste me the question?
<vila> <bigjools> can anyone help with an svn import weirdness please?
<vila> <bigjools> https://code.launchpad.net/~vcs-imports/spamassassin/trunk
<vila> <bigjools> taking massively longer than normal
<vila> nothing obvious (not already mentioned in #launchpad) comes to mind
<bigjools> vila: I PMed him P)
<vila> ha, sorry
<Darxus> The other weird thing is that the last automated daily build attempts from that import failed to upload:  https://launchpad.net/~spamassassin/+archive/spamassassin-daily/+recipebuild/107643/+files/upload_3002271_log.txt
<bigjools> Darxus: that is symptomatic of a change in the repo such that it's trying to build the same version with different source files
<bigjools> which is forbidden in archives
<bigjools> this ties in with the long running import - it's almost like the import address is pointing somewhere else
<vila> wag: the change is the svn repo was... changed in a way that makes bzr-svn *slowly* re-process a lot of stuff
<Darxus> The version is 3.4.0-0~{revno}.  You're saying somebody altered the repo without incrementing the revision number?
<bigjools> looking at the last revno, something odd has happened
<Darxus> bigjools: What are you looking at?
<bigjools> "determining revisions to fetch 0/1189081" versus "fetching svn revision info 4603/1135013"
<Darxus> Ah, the last import log?
<bigjools> 1189081 on old imports, 1135013 on the slow one
<bigjools> 30k revisions disappeared?
<vila> bigjools: could it be that the cache was cleared ?
<vila> bigjools: jelmer didn't deploy a new version recently (as in pst hours or days) AFAIK
<vila> s/pst/past/
<vila> bigjools: or could it be that such a new version were deployed as part of an lp deployment ?
<bigjools> I have no idea
<bigjools> we roll out new stuff every day
<vila> bigjools: and about the svn cache ?
<bigjools> no idea :(
<bigjools> I know less than nothing about code imports
<vila> bigjools: tsk, tsk, that's still more than me ;)
<Darxus> Thanks for looking into it.  I'm not in a rush.  If jelmer hasn't popped up when I get back on in an hour I'll probably email him and open a bug against launchpad like last time :)
<vila> bigjools: for example, do you have an idea about whether this cache is local to 'pear', 'neumayer' and 'galapagos'
<bigjools> well it's currently running on galapagos, which it hasn't lately, so .... :)
<vila> bigjools: and whether galapagos may be a newer player here (and as such... see ? :)
<vila> let's wait for jelmer then, sry Darxus !
<Darxus> Er.
<Darxus> 2011-10-27 14:59:47 INFO    copying revision:fetching svn revision info 1/1129313
<Darxus> 2011-10-27 15:00:12 INFO    copying revision:fetching svn revision info 1/1129286
<Darxus> The total number of revisions is decreasing.
<Darxus> I was going to try to calculate when it would be finished, and it... didn't cooperate.
<Darxus> I think there's something wrong :P
<mgz> did anyone state what version of bzr-svn is on the buildds?
<vila> Darxus: hehe, on the other hand, it's better than having revisions disappearing from the svn repo ;)
<vila> Darxus: for now, I'll bet on a local cache being populated
<vila> Darxus: the slowness is disconcerting though
<mgz> if it's the same version as peitschie or exarkun were complaining about earlier (for different) that may be relevent
<mgz> +reasons
<vila> mgz: I had some feeling that may be the case but didn't closely follow your discussion with exarkun
<vila> mgz: but didn't he used a very recent version ?
<mgz> yes, and the buildds were on a much older one.
<mgz> but I don't know what they're currently running.
<vila> bigjools: did the buildds use the same code as the code importer ?
<bigjools> vila: same code in what regard?
<vila> bigjools: bzr-svn
<bigjools> vila: probably not but we'd need to check to be sure.  The buildds don't get rolled out with the rest of LP
<vila> bigjools: and the code importer is part of lp right ?
<bigjools> there is a new one waiting to go out actually, lamont is doing it soon
<bigjools> yes
<odin_> how might I script some actions ... checkout a sub-branch (use the current branch name, append some fixed label, check it out), then rebase the sub-branch on the master, add/commit, then checkout the original branch ?
<odin_> current branch is lp:foobar/master  so I want lp:foobar/master/ubuntu-lucid  (but this only has a 2 line patch difference between it and lp:foobar/master so I want it to rebase itself everytime master is committed and pushed)
<mgz> odin: I suggest looking at the python api rather than trying to do it in shell script
<vila> odin_: why simply merge master instead ?
<vila> odin_: why *not* simply merge master instead ?
<mgz> but I wonder if there isn't a better way of working on distro branches than your proposed way there
<odin_> unfortunately I only do C/C++/Java/sh/perl no ruby no python
<mgz> there are a lot of existing tools for making that kind of maintanance easy, though I'm only just starting to learn them myself
<vila> once your branches are setup, it's will just be: bzr merge ; bzr commit -m 'merge master' ; bzr push
<vila> odin_: also, lp already handle the namespace for you if you're dealing with ubuntu releases
<odin_> so I change to recipie to be 3 stages, main project (git mirror) lp:foobar-git-mirror, nest debian lp:foobar/master debian, merge lp:foobar/master/ubuntu-lucid debian ?
<vila> ha, recipes :-/ I should *really* look into them
<odin_> the main project does nto know about package management, and is check out into "/" and then recipe checks out  lp:foobar/master into subdir "/debian"
<odin_> so I need the merge to take place inside the subdir "/debian" as well
<odin_> since it only applied to the package management control files
<vila> but yeah, this sounds more appropriate (except for the last branch name which should be something like lp:~<you>/ubuntu/lucid/foobar/<whatever>)
<mgz> odin_: have you looked at the bzr-builderplugin?
<odin_> define "look at" heh, I know I have it installed, I know I am using it for dailydeb local testing
<mgz> well, it does seem a little short on examples, but the idea seems to be you can do what you're trying to there without extra rebasing steps
<mgz> I guess you just need someone to tell you what recipe spelling to use
<mgz> try posting your example problem to the list? most of the people who know this best are in a different timezone currently.
<odin_> yes I will look up the "merge" recipe details/arguments in a moment
<odin_> is launchpad used by other debian based systems?
<odin_> so I push first, like "bzr push --create-prefix --stacked lp:~group-project/ubuntu/lucid/packaging"  then make change(s), then add, then commit, then "bzr push" ?  then how do I go back to the original branch ?
<jelmer> odin_: the --create-prefix and --stacked options shouldn't be necessary
<jelmer> odin_: what tdo you mean with the original branch?
<odin_> I have a 2 file patch, that removes 1 line from each file, I want it to always be a kind of patch on top of a base
<odin_> but I don't want to have to manually rebase after every commit into base
<odin_> I want to let bzr-builder be the thing to notice a problem with a "merge" than means I have to manually rebase this time to get it working again
<Darxus> jelmer: Did you see the issue with the lp:spamassassin import?
<Darxus> It looks like galapagos is having similar difficulty importing songbird:  https://code.launchpad.net/~vcs-imports/songbird/trunk
<lamont> vila: bzr-svn is not generally installed on the buildds
<jelmer> Darxus: hi
<Darxus> jelmer: Hi.
<jelmer> Darxus, bigjools: it looks like somebody killed the cache on galapagos
<Darxus> jelmer: So it is actually working, and it makes sense for it to take at least 7 hours?
<jelmer> Darxus: no, that's not really correct either but it would explain why it's fetching the history metadta again from scratch
<jelmer> vila: hi
<jelmer> Darxus: I'm pretty sure I can fetch something like spamassassin in less than 30 minutes, from scratch
<jelmer> Darxus: not sure if that helps much, but it seems to be an issue specifically with galapagos to me
 * jelmer goes back to his holiday
<jelmer> odin_: I don't think it's possible to do something like that
<Darxus> jelmer: So.. how do I get this in the hands of somebody that can and will fix it?
<Darxus> And yeah, fetching all of spamassassin takes seconds.
<jelmer> Darxus: filing a question against launchpad is probably the best course of action
<Darxus> Thanks.
<jelmer> Darxus: svn only fetches a single revision, bzr fetches the entire history. It's correct that it takes a bit longer, but that shouldn't be significant for incremental imports
<Darxus> Ah, okay.
<Darxus> https://bugs.launchpad.net/launchpad/+bug/882681
<ubot5> Ubuntu bug 882681 in Launchpad itself "lp:spamassassin import is taking 8 hours so far, usually ~5 minutes" [Undecided,New]
<GRiD> hello
<jelmer> hi GRiD
<Darxus> galapagos's import of Songbird failed, I expect the same for spamassassin:  https://code.launchpad.net/~vcs-imports/songbird/trunk http://launchpadlibrarian.net/83846750/vcs-imports-songbird-trunk.log
<Darxus> bzrlib.plugins.svn.errors.IncompleteRepositoryHistory: Unable to fetch revision info; first available revision: 16493
<wgz> poor jelmer isn't getting much of a break...
<Darxus> Heh.
<Darxus> SpamAssassin import has been running for 10 hours.
<Darxus> I have a feeling it would've worked fine, but a tcp connection failed and it handled it badly or something.
<poolie> hi all
<GRiD> hi poolie
<poolie> hi there, how's it going?
<peitschie> hi everyone :)
<peitschie> ouch... my bzr-svn checkin has been now running for 15hrs
<Kamping_Kaiser> peitschie: impressive :)
<peitschie> It is stable it seems... just taking a long time to find rhs ancestors
<peitschie> And doing them at a rate of 1 every 10s of seconds
<fullermd> It causes back injury if you do them too fast.
<peitschie> ahh... that makes sense.  I guess I wouldn't want to cause my pc significant health problems in its old age
<peitschie> I wonder what their health cover is like?
<peitschie> "sorry mister pc... you ran some wild software in your younger days... we really don't cover that mad source compiling"
<fullermd> Yeah, compiling is like the computer equivalent of skydiving.
<Kamping_Kaiser> hehe
<poolie> :/
<poolie> peitschie: is this the one you said was faster in a previous release?
<poolie> jelmer's away til monday
<peitschie> poolie: I don't actually know to be honest.  The last time I had to build the svn metadata from scratch was like April last year.  Which means we've gone from 3000 commits to that branch to 11000.  It may be that this is some type of exponential problem that was not significant back then
<peitschie> poolie: I'm hoping this stuff is only a once-off hit, that once I generate the required indexes etc. on my computer, I can just copy it over to the other devs.  So in theory it won't be a show stopper for us... just painful for now :)
<peitschie> at the moment though, its downloaded, uhh, 12Gb @ 256kb/s overnight trying to find these rhs ancestors
<poolie> if you can get an lsprof profile that would probably help
<poolie> i should really write up some troubleshooting data
<poolie> *docs
<peitschie> it's in the middle of a commit, the file has landed in svn already (did last night before it took this step).... am I likely to damage something if I interrupt things?
<poolie> i think not, but i couldn't guarantee it
<peitschie> I'll just let it go for now then.  Safer not to risk it :(
#bzr 2011-10-28
<peitschie> yay! finished!
<peitschie> that only took uhh... 18hrs to do a single checkin :/
<Darxus> Heh, lp:spamassassin import still going, 16 hours.
<poolie> jeez
<peitschie> poolie: good news is that while the next checkin was then slow again, all ones after that appear to be reaaaasonably speedy
<peitschie> poolie: do you have any concepts what kind of size the bzr-svn bridge was designed for?  My sqlite db is like 240Mb... >_>
<Darxus> When building lp:spamassassin, which is synced via svn, it generates a .orig.tar.gz to satisfy quilt.  How can I do something like that when building from the command line?  How do I generate the .orig.tar.gz?
<Kamping_Kaiser> -sa
<Darxus> Kamping_Kaiser: Nice, thanks.  That's listed in the dpkg-buildpackage man page with no documentation?
<Kamping_Kaiser> Darxus: dpkg-buildpackage, but i think its man page refers to dpkg-source for details
<Kamping_Kaiser> (its man page)
<Kamping_Kaiser> dpkg-buildpackage has some options around this too, dpending on what you are working with. --split and --export-upstream=ARG
<mgz> morning all
<vila> hey mgz and al !
<vila> jml, james_w : out of curiosity, how did you test your paths shuffling proposal ?
<mgz> vila: did you see the note about the jenkins openid plugin?
<vila> mgz: yup, thanks
<vila> but the description is a bit sparse, I don't really know if babune is at risk,
<vila> at worst, AIUI, some can start jobs or modify stuff
<vila> in the former case, the fans are close enough to me that I will notice their noise, in the later case, every relevant file is version controlled so I can revert any malicious change
<mgz> I'm not sure that's all that could be done, but agree the risk in general is pretty low
<vila> mgz: if nothing else, the unusual port I use will hopefully help staying below the radar ;)
<mgz> :)
<nigelb> Will bzr let me merge one revision from one branch into another?
<nigelb> Or skip the last revision but grab the one right before.
<nigelb> nevermind, found it :)
<mgz> vila: any idea how best to test the fix proposed for bug 882541?
<ubot5> Launchpad bug 882541 in Bazaar "bzr version-info very slow" [Undecided,New] https://launchpad.net/bugs/882541
<mgz> if there was a working-tree-open hook, could assert that the tree isn't opened unless clean is in the template, but only branch gets an open hook, not tree or repo
<mgz> anyway, I need to nip out now will be back a little later
<odin_> bzr: ERROR: Permission denied: "Cannot create 'ubuntu'.  Only Bazaar branches are allowed."
<odin_> with: bzr push --create-prefix lp:~project-group-account/foobar/snapshot/ubuntu/natty/
<indigo> does bazaar have a feature that allows me to emded checkouts of other branches in a branch? If so, what's it called?
<indigo> what i'm trying to accomplish is to create a puppet package that deploys an application from a bzr branch. I could make puppet rules that have the target host check out the code itself, but getting authentication right in that case is hard. So, I thought I'd embed a checkout of the code inside the puppet package (which is also stored in a branch)
<mgz> indigo, there are a couple of plugins for managing branches within branches, but it sounds like you should just get your deploy right, rather than versioning the dependency
<mgz> see bzr-externals and scmproj
<jam> mgz: vila: I'm off to pack, see you guys in about 48 hours or so :)
<jam> (I leave tomorrow way-to-frickin-early)
<jam> s/to/too/
<smoser> i think someone has helped me with this before, but I dont recall how to ignore this.
<smoser> http://paste.ubuntu.com/721725/
<smoser> bzr has a different view on reality than i do.  i'd like for it to not show me entire deletes and replaces of the same file contents
<smoser> i think there is some way to do that
<mgz> smoser: that's generally a sign of a bad merge
<smoser> well you, either I or the launchpad importer are to blame for that.
<smoser> but the output is not really useful.
<mgz> if you've inadvertantly told bzr that you've got a new file (by id) that happens to replace an existing file with the same contents, you want to Not Do That
<mgz> the output is bad, but the problem is worse if it continues becase it leads to bad history
<mgz> ^where 'you' could well be 'the importer'
<smoser> i dont know if i did it or not. it is quite possible i did.
<smoser> but realistically, its a bug in the tool to consider a file 100% different to itself.
<smoser> is there a way to either fix it  or tell it "from now on, consider those files the same"
<mgz> sure but that's likely just a symptom
<mgz> redoing the merge, taking the original files, should do it.
<mgz> there may also be a cleverer way
<mgz> filing a bug with the exact problem revisions (and ideally how you got them) would help, or posting the details to the list
<mgz> right, I need to pack and things
<smoser> mgz is gone now.
<smoser> bug 883207 is filed with info.
<ubot5> Launchpad bug 883207 in bzr (Ubuntu) "bzr reports huge differences compared to 'diff'" [Undecided,New] https://launchpad.net/bugs/883207
<wgz> I'm still here in essence, just less corporally
<wgz> bug looks useful, thanks.
<hikiko> hello, I would like to install the launchpad plugin on mac osx but I can't find it
<hikiko> (only in launchpad)
<hikiko> how can i get it?
<indigo> is there some command i can run to know if the working tree of a lightweight checkout is out of date? ie, if 'bzr update' will change anything?
<fullermd> indigo: status will tell you, I think.
<fullermd> You could also compare 'revno' (branch) vs 'revno --tree'.  Though of course it's possible for them to match and be different.  Unlikely with most workflows I'd think.
<sproaty> hi, if I have a directory that's basically the same code my bazaar repo, but the dir is not 'connected' to bzr...is there a way I can do that and make this a working branch?
<Noldorin_> hi jelmer
#bzr 2011-10-29
<ccxCZ> sproaty: you can replace the content of the repo's working directory with the code and commit it. or alternatively make unified diff an apply it
<sproaty_> ccxCZ, so copy my current dir contents somewhere, checkout my branch into that folder then move my back over?
<sproaty_> move my code*
<ccxCZ> it's one of possibilities, actually I'd rather suggest rsync -av --delete --exclude .bzr code/ new_branch/
<ccxCZ> that will make sure you leave the .bzr dir intact and copy over all files along with permissions etc.
<fullermd> I'd make a temporary branch, rm away all the files in the WT, then move the .bzr dir into the existing place.
<fullermd> (well, I guess you could skip the rm'ing and just mv .bzr)
<ccxCZ> that's also an alternative
<sproaty_> on windows unfortunately :(
<ccxCZ> well, then the trick with moving .bzr is more easilly done I guess
<sproaty_> cheers :)
<michaelh1> Sorry for the spam, but any Australians here going to UDS on Qantas tomorrow?
<hikiko> hello
<hikiko> how can i get a previous revision of my launchpad tree?
<hikiko> (revert to the previous)
<jelmer> hikiko: bzr revert -rREV
<jelmer> hikiko: if you also want to change the branch back, use "zr update -rREV"
<hikiko> thank you :)
<hikiko> hmmm it doesn't download anything
<hikiko> i added some textures (png images) to my branch previous revision
<hikiko> and now i want them back without checking out and then copy and then commit etc
<hikiko> is this possible?
<thumper> hikiko: it doesn't need to download anything as it has the local history
<hikiko> no
<thumper> (assuming you didn't use a light weight checkout)
<hikiko> i replaced them
<hikiko> with low resolution textures
<hikiko> and now i want the previous high resolution
<hikiko> from the previous release
<fullermd> In that case you want to use 'revert' on those files.
<hikiko> bzr revert file 1 file2 etc?
<fullermd> revert -rWHATEVER file1 file2 ...
<hikiko> thank you :)
<mgz> hm, apparently it's midnight back home.
#bzr 2011-10-30
<jelmer> hi mgz
<jelmer> how's life in Florida?
<mgz> quiet so far jelmer :)
<jelmer> mgz: heh
<mgz> did you manage to enjoy a few days off after gitting?
<jelmer> yeah, went to see yosemite park, bitts of nevada and some of the local hackerspaces
<jelmer> *bits
<jelmer> I saw I have a lot of bzr email to catch up with..
<mgz> you came in at the end of a day full of bzr-svn and builder questions before
<mgz> I tried to get people to file bugs for everything where they got stuck, some may just want duping/explaining
<mgz> jelmers need holidays
<jelmer> :) thanks
<mgz> I should probably go and try and find some people, but don't know who's around and this place is massive
<mgz> a little suprised vila isn't here yet, hope air france haven't done bad things
<jelmer> isn't jam also going to be there?
<mgz> yeah, but he was in newark not long so won't be here for a while yet
<jelmer> ah, ok
<mgz> various other people are presumably around but busy doing useful things
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, how's it going? had any time to think about bzr-git stuff recently? :-)
 * mgz hopes it's all been geysers
 * jelmer wonders if mgz means geysers literally
<Noldorin> ?
<jelmer> Noldorin: I've been away on conferences and holoidays
<Noldorin> oh i see
<Noldorin> lucky you heh
<jelmer> I did manage to implement git-remote-bzr this week
<Noldorin> jelmer, oh what's git-remote-bzr?
<jelmer> Noldorin: it's the reverse of bzr-git
<jelmer> gtg, back later
<Noldorin> jelmer, oh ok. how about the other way round eh? ;-) i'm looking forward to the new dpush implementation heh
<Noldorin> okay then
<Noldorin> ciao
<mgz> vila is here :)
<chromaticwt> does bzr use sha1?
<jelmer> chromaticwt: for some things, yes
<sbarcteam> hi. how do I install bzr for python2.5 ?
<sbarcteam> (tried pip-2.5 install and easy_install-2.5, neither works)
<jelmer> sbarcteam: bzr 2.4 requires python 2.6 IIRC
<sbarcteam> jelmer: Inside the setup.py file there is a clause: if sys.version_info < (2, 6):
<sbarcteam> the question is WHY. I remember when there was no bzr 2.4, bzr 2.3 would install nicely in py 2.5
<sbarcteam> now I can't even installl 2.3
<bob2> 2.3's setup.py demands 2.6?
<jelmer> sbarcteam: 2.3 should still work in python2.4 and 2.5
<sbarcteam> jelmer: So I can simply DELETE that condition ?
<jelmer> sbarcteam: I'm pretty syure that condition is not present for bzr 2.3
<jelmer> removing that condition in bzr 2.4 won't work, it will just cause you trouble later
<sbarcteam> is it possible previous failed installation attempt of 2.4+ affects next installation attempt of 2.3 ?
<jelmer> I'm not sure - what's the exact error (incl traceback) you're getting?
<sbarcteam> I have gotten a consistent "need python 2.6" error.
<sbarcteam> and then I downloaded the tarball, and installed without a problem.
<sbarcteam> So, maybe pip does some checking based on something.
<sbarcteam> if I am running pip-2.5 it is using py 2.5 interpreter.
<sbarcteam> I have no idea. but this simply made me waste 1/2 hour.
<sbarcteam> which is ... a bummer.
<m1sc> hi. i try to create a new branch based on a tag. inside the source branch "bzr tags" gives me 1.0.5 (among others), but "bzr branch -r tag:1.0.5 source dest" doesn't work. what's wrong?
<m1sc> i get "ERROR: The branch upstream has no revision"
<mgz> what happens if you try to branch the revno that tags tells you correspondsto 1.0.5?
<m1sc> mgz: hmm, it doesn't tell anything. output is "1.0.5               ?"
<m1sc> mgz: ? is the missing revnr?
<mgz> m1sc: yes, the '?' means the tag refers to a revision not in that branch
<mgz> (sorry for the delay, freenode wouldn't let me connect again)
<mgz> it might just need something as simple as a pull in that branch first
<kise> Is there a command to get the list of files being tracked in a repo?
<fullermd> Branch, not repo.  Look at `bzr ls`.
<kise> fullermd: Thanks!
<poolie> hi kise, fullermd
 * fullermd waves at poolie.
#bzr 2012-10-22
<delinquentme> jelmer, know of a way to branch off of a particular revno of a bzr repo?
<spiv> delinquentme: "bzr branch -r REVNO"
<jelmer> delinquentme: bzr branch -rX
<delinquentme> lol am i supposed to get nothing returned when I run a bzr status for a newly branched dir?
<bob2> what do you think it should show?
<bob2> you have no local changes
<delinquentme> should it not say that ?
<bob2> no
<delinquentme> sounds like a quiet fail
<delinquentme> it should :D
<bob2> it's not a quiet fail, it had nothing to say, so said nothing and exited with 0
<jelmer> I think it says "X revisions branched." usually?
<bob2> bzr branch does, delinquentme is talking about 'bzr status' in the branched dir
<jelmer> bob2: ah, whoops - sorry
<mgz> morning!
<fullermd> ETOOPERKY
<vila> hi there
<fullermd> Where??
<mgz> behind you!
<fullermd> Oh, good.  I could use a good backrub.
 * vila rubs
<fullermd> bzr ping ->  Headers: {'Software version': '2.0.3'}
<fullermd> Furrfu   :|
<mgz> heh, against which server fullermd?
<fullermd> Sourceforge
<fullermd> But hey, their docs claim they support bzr 1.10, so in relative terms...
<crazydip> having commited rev 1, 2, 3, 4, 5 how do i "undo" the changes done in 2 and 4 without "undoing" (reverting, uncommiting) the changes in 3 and 5?
<fullermd> A better phrasing for what you want to do is "reverse" the changes; you can't undo them per se, since they're part of history.
<fullermd> Basically the [im]mortal equivalent of something like "bzr diff -c2 | patch -R".
<fullermd> You can use merge to do a lot of the work.  e.g., "bzr merge -r 2..1 ." (note the reversed numbers, and don't miss the trailing '.' there)
<fullermd> That'll stage up a "reverse" of rev 2, which you can then check and fix any conflicts and test and commit.
<fullermd> Then you can do the same for rev 4.
<crazydip> does the trailing . in "merge -r 2..1 ." mean "all files" in -r 2..1?
<fullermd> Not exactly.  It tells merge what branch to 'merge' from.  In this case, the branch you're sitting in.
<crazydip> ok :)
<crazydip> and can I merge both 2..1 and 4..3 before commiting? Like with "merge -r 4..3 . --force"?
<fullermd> You could.  My impulse would be not to, just for cleanliness.
<crazydip> that's some great and clear advice! thank you fullermd!
<fullermd> That's 'cuz I'm clearly great   8-}
<crazydip> I did not want to say anything and look too much like a newb, cause it was so obvious :D
<fullermd> Oh, don't worry, we never point and laugh at anybody on this channel.
<fullermd> We've got a whole separate channel for that.
<crazydip> #bzr-lolz? :)
<fullermd> That's too easy to confuse with #bzr-lolcats, where we concentrate on things like "I can has merge proposal?" and "I made you a patch, but I uncomitted it"
<danielbrauer> fullermd: I've often seen talk between svn folks wishing there was an "svn obliterate", which would roll back the repository, removing revisions entirely. It still doesn't exist in svn, but is there something like that in bazaar? Or does it make even less sense for dvcs in general?
<fullermd> It's not conceptually impossible, but there are a number of practical difficulties, and I'm not aware that anybody's actually implemented it in a particularly clean way.
<fullermd> The usual fallback involves creating a new history without the thing you want to obliterate, and flag-day'ing everybody over to it.
<danielbrauer> I could see it being difficult to resolve if you've got a lot of branches.
<fullermd> Just so.  The CVCSen have a somewhat easier time of it, since clones of the 'main' repo are in practice read-only, so there's only one place to have to remake the world.
<fullermd> Still, easier is a long way from "easy".
<fullermd> It was "easy" in CVS.  Since the repository had no awareness or meaning to corruption, you're free to corrupt the crap out of it, and everything keeps working as well as it used to   ;p
<danielbrauer> I'm super-new to bazaar, and have a repository going but I've only read the first few pages of the manual. I feel like I have a poor grasp on the relationship between different branches. Is it the case that all working copies and repositories are equal, except that they have a hierarchy in terms of where they were branched from?
<crazydip> i'm so glad we have dvcs's and can just ignore aweful cvs :)
<fullermd> No, a set of branches can have any arbitrary relationship to each other.  Alternately, they have _no_ necessary relationship to each other.
<fullermd> In a technical sense, any two branches are related based on what revisions they do/don't share.
<fullermd> Of course, _socially_ speaking, in any project you probably have something rather like a hierachy.
<fullermd> But that's a matter of your convention and human/social necessity, not tool technical necessity.
<danielbrauer> Ok. So every branch is a full-fledged repository with a full history, and it will share history with another repository from before the branch happened.
<fullermd> You might find some of http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs useful, particularly starting with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<danielbrauer> Ok, that probably answers my next questions, which were about the relationship between all the different commands that appear to do similar things. I'll be back when I've read these pieces. Thanks!
<crazydip> danielbrauer: in short, forget about all the restrictions of cvs - each branch is a clone of whatever you branched from... you can do whatever you want with it, make changes, commit changes, revert changes and if you choose, another person can merge those changes to their branch  or you can merge someone else's stuff into your branch --- like fullermd said, the restrictions come on a social level, not technical
<danielbrauer> Right. I sort of get that, but it confuses me when I see checkout as well as branch, and merge as well as commit, whereas those two pairs each seem to accomplish the same sort of thing.
<danielbrauer> Is the difference a matter of "binding"?
<crazydip> danielbrauer: i know this is about bzr but to tell you the truth, what best helped me understand how dvcs' work is Linus' presentation on git at Google from a few years back - it's all relevent to bzr (just search "linus git" on youtube)
<danielbrauer> Will do, thanks
<fullermd> Plz to ignore binding.  It'll only confuse things way more.
<danielbrauer> Ok, I'll do that too. (:
<fullermd> checkout/branch and merge/commit are definitely not at all the same thing.
<danielbrauer> No, I assumed not. It's just that so far I've only read explanations that involve similar-looking arrows.
<fullermd> I'd start with trying to internalize the beginning of that PiecesInBrief.  If you think of everything in terms of Revisions, things get a bit clearer.
<danielbrauer> Yeah, the inherent unrelatedness of revisions is something I hadn't gathered before.
<fullermd> Commit is a way (almost the only way, ignoring exotic situations, which you should) that Revisions get created.
<fullermd> Everything else is just a matter of how they get shared around after being created.
<fullermd> Oh, Revisions are very strongly related.  They're just the _only_ thing that relates.
<fullermd> Branches are nothing but collections of Revisions, and two Branches that have the same collection are for most purposes interchangeable and indistinguishable.
<fullermd> (I'm rather othersimplifying for the purposes of this discussion, so don't try to push it too far, but from where you're sitting, it's near enough to true)
<fullermd> (sorry, I just used up my daily allotment of commas...)
<danielbrauer> No problem. I appreciate the time.
<fullermd> If you have a background with any VCS, you probably understand enough about the inspection-type commands like diff and status and log, that we can ignore them.
<fullermd> So it's only the action-type ones you should worry about right now.
<danielbrauer> Yeah, I've used svn for a long time and while it still manages to confound me every now and then, I do understand what all the commands are supposed to do in most cases.
<danielbrauer> I think the thing that confused me until now is that you can have a repository, branch, and working tree all in the same place.
<danielbrauer> That's not obvious from the beginning of the manual.
<fullermd> We can make a quick 2-category division there, between the commands that _make_ new revisions (only 'commit'), and the ones that move revisions around amongst branches (push, pull, merge)
<danielbrauer> Ok.
<fullermd> push and pull can be thought of as symmetric; one makes THAT branch equivalent to THIS one, and the other makes THIS branch equivalent to THAT one.
<fullermd> (or refuses to do so, if that would lose history)
<danielbrauer> Ok. Presumably the branches have to be related in some way for that to work?
<fullermd> Yes.  Colloquially speaking, the "target" branch (THAT or THIS, depending on whether you're push'ing or pull'ing) has to be an "older" version of the source.
<fullermd> Or alternately phrased, only one side can have changes the other doesn't.
<danielbrauer> Got it.
<fullermd> If both have changes the other doesn't (they've diverged), you need to use merge to pull them together.
<danielbrauer> What's the difference between update and pull?
<fullermd> And merge doesn't _quite_ bring them together, it just prepares them to bring together; you need to use 'commit' afterward to make a new revision, which does the entogetherication.
<fullermd> (it's totally a word.  Look it up.  As soon as I hack the OED.)
<fullermd> Let's ignore update for right now; that'll just confuse things a bit.
<danielbrauer> Ok, that's similar to svn's merge. The result is a bunch of modifications to your working copy.
<fullermd> I believe so, yes.  It leaves you with a stack of changes to check over, and then commit.
<danielbrauer> But I guess merge preserves more history in Bazaar?
<fullermd> Yes.  The history models are somewhat different.
<jml> https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850
<fullermd> In svn, history is basically linear (and then there's some extra metadata that gets written about merges, off to the side)
<danielbrauer> Right.
<fullermd> Whereas in bzr (and most other major DVCSen), history is a DAG.
<fullermd> And if that meant something to you, we get to shortcut a lot of explanation.
<danielbrauer> Yup.
<danielbrauer> Yeah, I
<danielbrauer> 'm a CS graduate. They only taught us CVS but I do know some theory. (:
<fullermd> Eggselent.
<fullermd> So every revision is a vertex in the graph of history.
<fullermd> And it's got some number of edges sprouting out of it pointing at other revisions, which are its parents.
<fullermd> It may have 0, which means it's an initial revision you created from nothing (e.g., after a 'bzr init')
<danielbrauer> Ok. Now should I be thinking about "history" as a single branch, or all related branches from a repository?
<fullermd> It may have 1, which means it's a "normal" rev, like you have in svn.  You started from some existing rev, made a change, and committed it.
<fullermd> Mmm.  Both, in a way.
<fullermd> Or, it may have 2 (or more, though that's rare and usually pointless) "parents", which means it's a merge.  That's how most DVCSen model it; merges are some extra metadata, it's just a rev with 2 parents instead of 1.
<fullermd> So in high concept, a _branch_ is really just a pointed to some node, saying "That's where I am", and the history of the branch is gotten by walking back along the edges.
<fullermd> (pointer)
<danielbrauer> That makes sense.
<fullermd> So, with a CS background from that, you can see how relationships between Branches come about; you look at the DAG of each, and find the common subgraphs.
<fullermd> If they both have the same head, they're identical and functionally interchangeable.
<fullermd> If the head of A is in the history of B, then B is a "later" version of A.  You can "cd B ; bzr push A" or "cd A ; bzr pull B", to sync them up.
<fullermd> If the head of neither is in the other, there's some divergeance.  You can walk back the history and find the common node, and now we know where they diverged from each other.
<fullermd> (or there may be no common node, all the way back; then we know one branch is gcc, and the other is mozilla, say)
<danielbrauer> Ok. And for any branches that share history, the history will all be shared before a certain point? That is, from the most recent revision they share, they will share all revisions previous to that one?
<fullermd> (or >1 unconnected common nodes, which...  well, we'll ignore that)
<fullermd> Right.  Revisions have a purportedly universally unique identification, so a given rev is always the same everywhere.  And since part of that identity is the parent list, everything earlier is known identical.
<danielbrauer> Got it.
<fullermd> So what "merge" does is stage you up for a commit with 2 parents, which connects the two separated branches/histories into a new branch that contains both.
<danielbrauer> Ok. In Subversion, I find we do a lot of cherry-picking changes when merging. Instead of taking everything from a branch that isn't in common with trunk, we just take a few revisions here and there. That sounds different from DVCS, because it would mean that two branches shared a revision but not all of its history.
<fullermd> Right.  Which is impossible, by the data model.
<fullermd> So cherrypicks are unrecorded; the tool can't tell after the fact that it wasn't just a manual change.
<fullermd> (except in systems like darcs, which are fundamentally different)
<danielbrauer> Ok. So although revisions necessarily record a set of changes and allow you to trace the history that led to the revision, they can't be moved around as arbitrarily as svn's revisions, which are more "change sets".
<fullermd> Not exactly right on the svn side, but right on the limitations of the DVCSen.
<danielbrauer> Ok. That's fine because I decided a while ago that I don't need to understand svn fully in order to use it properly.
<fullermd> Each rev is conceptually "the whole history up to this point", so you can't move them around in the graph after they're created.
<fullermd> (so when we talk about about "moving revs around" with push/pull/etc, what we really mean is just changing which subgraph a branch refers to; can't change how the graph is shaped)
<fullermd> In a sense, there's One Giant Universal DAG out there, with some large number of head nodes, which isn't remotely entirely connected, that contains the world of every software project.
<fullermd> If you just handwave away the minor implementation issue of getting the contents of a rev once you've named it (and that's just the sort of detail academics are supposed to ignore), you can shortcut all that silly development effort and create software from thin air just by naming the right revision   ;)
<danielbrauer> Ok. So I could set out to merge Mozilla and gcc?
<fullermd> It's perfectly possible.
<fullermd> The result might be silly, but it's possible   :)
<danielbrauer> I'll get started right away.
<fullermd> You'd wind up with a branch (one head node) that, if you follow back, terminates in (at least) two separate nodes with no parents.
<fullermd> Which is a perfectly valid graph.
<danielbrauer> Understood.
<fullermd> Actually, a large number of the branches I work with every day have at least 2, sometimes 3 or 4 or more "initial" revisions.
<danielbrauer> What are some examples?
<fullermd> Think of the process "import a vendor branch"; that's what you're doing in that case.
<danielbrauer> Oh, right.
<danielbrauer> So kind of like an external, but you're actually folding it into your branch?
<fullermd> So I've got an existing libthis and libthat that I want to use in projectfoo; I just merge those (independent, unrelated) branches, and boom; I've got a branch with 3 initial revs.
<danielbrauer> And then you could merge future revisions of those libs into your branch later if that's what you want.
<fullermd> Roughly, yeah.  You can think of an external as "include by reference", whereas merging it in is "include by value".
<danielbrauer> Right.
<fullermd> Right.  Especially useful if I don't actually want libthis, but rather libthis-plus-some-local-changes.
<alkisg> Hi, here's a "view" URL where I can see a specific file from my branch: http://bazaar.launchpad.net/~ts.sch.gr/sch-scripts/trunk/view/head:/debian/sch-scripts.gconf-defaults
<alkisg> I'd like to find the equivalent "download" URL, to use in some script for some weird reason that doesn't really matter. Is that possible, or the download links are dynamically generated + temporary?
<fullermd> The local changes just happen in my branch, and the pristine libthis's merge cleanly (I hope)
<danielbrauer> Surprise API rewrite!
<fullermd> "API" is the sound you make when it changes out from under you.
<fullermd> alkisg: I'm not sure.  That's a launchpad/loggerhead question...  I'm not sure there is one, but I'm no authority on the matter.
<alkisg> fullermd: thanks, I first asked in #launchpad but I was instructed to ask here... I'll wait for a bit in case some loggerhead guru answers :)
<danielbrauer> Ok, lunch now. Thanks for the explanations. It's really helped, along with the Fuller ones.
<JPeterson> whats the link to the raw file in a launchpad repo? for example http://bazaar.launchpad.net/~kovid/calibre/trunk/download/head:/src/calibre/libwand.py doesn't return a valid file.
<JPeterson> it returns "The resource could not be found. "
<JPeterson> searching for "launchpad wget repo file" doesnt return an answer unfortunately. sadly and answer would be valuable to me.
<mgz> JPeterson: `bzr cat -d lp:calibre src/calibre/libwand.py`
<mgz> unless you're also trying to build an iso and don't have anything installed...
<JPeterson> thx. what if i have curl but not bzr?
<mgz> disappointingly inefficient still, and ick, that's some ugly ctypes
<mgz> JPeterson: `curl https://launchpad.net/bzr/2.5/2.5.1/+download/bzr-2.5.1.tar.gz`
<JPeterson> what if dont have write access?
<mgz> but pipe that to something...
 * fullermd waits 'till we get to the "fire up the virtual machine you just mounted over an ssh tunnel" stage...
<mgz> it's thought-experiment day apparently
<fullermd> I think these are more thoughtless-experiments.
<mgz> "what's the least convenient way of getting a file from launchpad in order to put it in an iso"
<fullermd> "Look, python's not that complex a language, and you've got those toggle switches just sitting there anyway..."
<mgz> JPeterson: what are you actually doing, out of curiosity?
<JPeterson> reading a launchpad repo file
<mgz> JPeterson: on the grand scale
<mgz> when you have completed all the little steps that include reading this file, what will you have done?
<JPeterson> same thing as bzr cat
<JPeterson> the html interface show that "http://bazaar.launchpad.net/~kovid/calibre/trunk/download/head:/645%40b0dd1a5d-880a-0410-ada5-a57097536bc1:libprs500%252Ftrunk:src%252Flibprs500%252Flibwand.py/libwand.py" is a valid url
<JPeterson> but i would like a shorter url than that
<JPeterson> one that only include the path. not revision.
<mgz> why? what are you actually *doing*...
<JPeterson> same thing as bzr cat
<mgz> no, that's not what you're doing
<mgz> it's what you're trying in order to do something else
<mgz> in absense of answer, I shall choose to believe you're writing a script to live-patch a locked down device
<mgz> in which case, just stick the file you want up on a url you control, and write a cronjob that updates it from the branch
<mgz> loggerhead doesn't promise stable download urls, so hardcoding something may break in future.
<mgz> if that's not what you want, sorry, but I can only guess so far
<alkisg> Hehe fun, two people asking the same question at the same time...
<JPeterson> how do i edit in tbzrcommand.exe --command=diff?
<JPeterson> i mean in the  tbzrcommand.exe --command=dif window
<JPeterson> why is the diff window read only?
<JPeterson> someone isn't thinking?
<JPeterson> how does http://doc.bazaar.canonical.com/bzr-0.10/bzr_man.htm#bzr-diff-file tell me how i ignore lines like "=== modified file 'src/templite/__init__.py' (properties changed: -x to +x)"?
<JPeterson> should i use "bzr diff|filterdiff --clean"?
<fullermd> I don't think I understand the question.  But why are you reading docs from a 6 year old release?
<JPeterson> how do i bzr commit --amend?
<jelmer> JPeterson: 'bzr uncommit && bzr commit'
<JPeterson> thx
<tbf> how would i figure out the name of the current co-located branch - by looking at the data in the .bzr folder
<tbf> need that information for display in qtcreator. calling "bzr nick" old would work as fallback there, since launching python and all takes too long for the purpose
<JPeterson> how do i revert all (properties changed: -x to +x)?
<jelmer> JPeterson: bzr revert
<JPeterson> jelmer: how will it know to only revert (properties changed: -x to +x)?
<jelmer> JPeterson: it would revert all changes
<JPeterson> oh
<JPeterson> a bug report say ""bzr status" will set every X bit in the branch." is this true?
<JPeterson> seems dumb
<mwhudson> seems unlikely
<JPeterson> i belive this is the scenario: call bzr cli in cygwin.
<JPeterson> well first time i've used bzr and it's already shown to be written by retards beyond comprehension
<JPeterson> does this make sense to you `bzr: ERROR: Path "/cygdrive/c/Files/Source/Programs/calibre/repo/src/templite/__init__.py" is not a child of path "/cygdrive/d/Files/Source/Programs/calibre/repo"`?
<danielbrauer> c vs. d?
<JPeterson> thx
<JPeterson> why can't i revert the "(properties changed: -x to +x)"?
<JPeterson> bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`; bzr diff still return ""(properties changed: -x to +x)""
<danielbrauer> Sorry, I'm just getting started with bzr myself.
<JPeterson> i believe this question has been discussed here https://bugs.launchpad.net/bzr/+bug/248333. and i added a rhetorical question "When you wrote the code in question, did you test tbzrcommand.exe and cygwin /usr/bin/bzr on the same repo?".
<ubot5> Ubuntu bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed]
<JPeterson> sadly, the answer to that is no
<JPeterson> i wonder if the repo maintainer will reconsider applying the patch when it changes the x bit on 888 files in the repo
<JPeterson> i hope it doesnt reduce the possibility that my patch is accepted
<JPeterson> maybe i wont seem like an absolute retard because of this bug
#bzr 2012-10-23
<jelmer> JPeterson: still there?
<JPeterson> ya
<jelmer> JPeterson: not sure if I follow your question, if you're running tbzrcommand then you're not accessing the win32 filesystem from Linux?
<jelmer> so bug 248333 shouldn't be relevant
<ubot5> Launchpad bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed] https://launchpad.net/bugs/248333
<JPeterson> jelmer: i wrote "cygwin /usr/bin/bzr"
<JPeterson> in "tbzrcommand.exe and cygwin /usr/bin/bzr"
<jelmer> JPeterson: that has the same limitaion though - cygwin pretends that the FS supports the X bit whereas it doesn't, and then makes it up on the fly
<jelmer> JPeterson: is there a particular reason you're not using the native bzr executable for windows? that wouldn't have this problem.
<tbf> is there documentation a tutorial on how to use --development-colo ?
<jelmer> tbf: there is no reason to use --development-colo anymore, all functionality is present in --2a nowadays
<tbf> jelmer, ok. good to know. basically fighting with the details to get this qt-creator patch accepted: https://codereview.qt-project.org/#change,37680
<tbf> (without really understanding bzr... but well :-))
<JPeterson> jelmer: as you can see in this http://cygwin.com/packages/ and this ftp://sourceware.org/pub/cygwinports/portslist.txt lsit there are cygwin builds of programs that there also exist windows builds for. one reason for this is that when a program is build for cygwin1.dll it understands cygwin paths.
<tbf> jelmer, do you know where to look for the current colocated branch, when by-passing "bzr nick" for performance reasons?
<tbf> jelmer, oh. it still is in .bzr/branch/location
<jelmer> tbf: Ah, cool to see that work happening
<tbf> just separated by a comma
<JPeterson> jelmer: this applies to bzr too, using a windows build of bzr.exe is not equivalent to using a cygwin build of it.
<jelmer> JPeterson: sure, but that's a limitation in cygwin
<jelmer> tbf: in most cases, that's true but it might be in a different location or use a different format in the future
<jelmer> tbf: the colocated branch support is unfinished, so I don't know if it is all that relevant at the moment
<tbf> jelmer, yup. plus plugins messing around there
<tbf> jelmer, seems the qtcreator maintainer for that module is using them and wants them support :-/
<tbf> ...the burden of open source contributions... make the gatekeeper happy
<jelmer> tbf: can you call the python method to get the branch nick?
<tbf> (i wish python would just start up more quickly, so that one could directly call "bzr nick")
<jelmer> tbf: or otherwise, is there a reason you can't call 'bzr nick' ?
<tbf> jelmer, it's all C++ code. already suggested embedding the python interpreter in the plugin, to directly use bzrlib.commands.main() instead of invoking the command line tool
<tbf> ...but seems they don't like that idea :-/
<jelmer> tbf: looking in .bzr/branch/location is a good way of making sure the plugin breaks in the future though, if formats change
<tbf> jelmer: that information is shown in the project tree view. synchronous code. "bzr nick" needs about 2 seconds to run on cold start and still 200 ms on warm start. way too long for ui code
<jelmer> tbf: or if we add extra stuff to the URL after the comma
<tbf> the really sad part: bzr.commands.main() invoked from embedded python interpreter only takes about 8 ms
<tbf> so all the other overhead are the gazillions of modules, cpython inspects upon start
<JPeterson> jelmer: my point is, i object to the argument "as a workaround use a windows build of bzr instead of a cygwin build". also, my first question in the post is "How do I fix the repo when this has occurred?".
<tbf> heh... crazy idea... wondering if it'd make sense to ship shared library, that embeds the python runtime and provides direct access to libbzr.commands.main()
<jelmer> JPeterson: what other workaround would you have us suggest?
<tbf> bzrlib.commands.main()
<jelmer> tbf: heh, that would work - even nicer if it was a generic shared library that others could use
<tbf> a simple "int bzr_main(const char *argv[])" that hides all the nasty bits of the python API
<JPeterson> jelmer: i mean, i'm reluctant to use the workaround.
<tbf> ...that's just crazy enough, that i should try this tonight
<jelmer> JPeterson: 'bzr revert' will change the executable bits back to the last committed revision (and will wipe all other changes since the last committed revision)
<tbf> after all I already have a sample implementation on my disc
<tbf> probably should just add an out-of-process mode to make the nay-sayers happy
<JPeterson> jelmer: this contradicts what i wrote that "after "bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`" the first command still return 888"
<jelmer> JPeterson: are you running this under cygwin as well?
<JPeterson> jelmer: yes that refers to cygwin bzr
<jelmer> JPeterson: because cygwin is probably telling bzr that it has successfully changed the file mode while in practice it hasn't
<jelmer> JPeterson: I'm not sure how to fix this with cygwin bzr, to be honest
<tbf_> (seeing how long it takes to download lp:bzr the first time on a 50 mbit line, i wonder if bzr requests data in too small chunks)
<jelmer> tbf_: is this over bzr+ssh:// or http:// ?
<tbf_> jelmer, bzr+ssh://bazaar.launchpad.net/+branch/bzr/
<jelmer> tbf_: and with what version of bzr? are you saturating the connection?
<JPeterson> jelmer: git also saves the x bit. replicating cygwin git will therefore fix cygwin bzr.
<jelmer> JPeterson: bzr also saves the X bit in its dirstate file; comparing the X bit in the dirstate file to the X bit on the filesystem is what causes the problem
<jelmer> JPeterson: since cygwin just pretends that all files are executable
<jelmer> the bug you linked is about bzr checking what the filesystem actually supports, and just ignoring the X bit on the fs if it doesn't support it
<JPeterson> jelmer: you can use #ifdef __CYGWIN__ for that.
<JPeterson> jelmer: what i wrote before also applies to '/cygdrive/c/Program Files (x86)/Bazaar/bzr' revert `bzr diff|grep 'properties changed'|awk '{print $4}'`
<jelmer> JPeterson: except that this is not a platform-specific thing, but a filesystem-specific thing
<jelmer> JPeterson: the same happens if you try to access a FAT filesystem on Linux
<JPeterson> the question "How do I fix the repo when this has occurred?" therefore is not answered by using /cygdrive/c/Program Files (x86)/Bazaar/bzr
<jelmer> JPeterson: a patch to add an exception for cygwin would be very welcome
<jelmer> JPeterson: that wouldn't be perfect but still a significant improvement over the current situation
<JPeterson> jelmer: "bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`" return "bzr: ERROR: Path(s) are not versioned: ... [list of files]". how can a file from bzr diff not be versioned?
<jelmer> JPeterson: It would be versioned in one way or another, perhaps there is something wrong with the command?
<jelmer> what are the files it's listing?
<JPeterson> jelmer: this list http://pastebin.com/eirVksUh
<JPeterson> could the list be too big for the argument buffer? so that it's cut off midway
<jelmer> JPeterson: are those files actually versioned ?
<jelmer> JPeterson: and are you running the command in the branch root?
<JPeterson> jelmer. how can they not be? yes.
<jelmer> JPeterson: and bzr revert errors about all of these files?
<jelmer> what happens if you run bzr revert manually for one of them?
<JPeterson> jelmer: yes. bzr diff|grep 'properties changed'|wc -l return 883 and bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'` 2>&1|tr " " "\n"|wc -l 889, so it's for all files.
<JPeterson> jelmer: that is accepted
<jelmer> JPeterson: it sounds to me like there's something wrong in your shell magic in that case
<JPeterson> it used to be 888 files, and a bzr revert for one or two files at a time has reduced it to 883
<JPeterson> jelmer: there is no shell magic involved, it's a string
<jelmer> JPeterson: it's something in backticks, that's shell magic :)
<jelmer> JPeterson: what if you add 'head -2' to bit inside of the backticks?
<jelmer> if that fails too then I'm inclined to blame the shell command, not bzr revert
<JPeterson> jelmer i updated the paste with the cat -A output http://pastebin.com/eirVksUh. it's "'manual/custom.py'$". i believe that should be valid.
<jelmer> JPeterson: it's including the quote signs in the filename
<tbf_> jelmer, 2.5.1. will check later
<JPeterson> jelmer: thx. i updated my post at https://bugs.launchpad.net/bzr/+bug/248333 with the answer to the question about fixing the repo that i previously wrote
<ubot5> Ubuntu bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed]
<JPeterson> jelmer: whats the bzr equivalent to "git config core.filemode false"?
<LarstiQ> JPeterson: what does it do in git?
<JPeterson> LarstiQ: what does what do?
<LarstiQ> JPeterson: "git config core.filemode false"
<JPeterson> it disables file mode versioning
<LarstiQ> aha
<JPeterson> i like what youre trying to say "bzr is so good that i use bzr more than git"
<LeoNerd> It's my first {only?} choice for personal things
<JPeterson> wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list?
<LeoNerd> possibly   bzr bundle   ?
<LeoNerd> or  bzr send
<JPeterson> thx
<JPeterson> "bzr log -1" return bzr: ERROR: no such option: -1
<LeoNerd> Indeed so.
<JPeterson> what is the intended way to print the last log?
<LeoNerd> Perhaps you meant  -r -1 ?
<JPeterson> last commit
<JPeterson> ok
<JPeterson> that gives "committer:" but no author
<JPeterson> how do i print the author?
<LeoNerd> I don't believe such a distinction exists
<LeoNerd> "committer" is just the  bzr whoami  value from the time of  bzr ci
<JPeterson> oh boy
<JPeterson> how do i track the commit for my ohloh account?
<JPeterson> how does ohloh know i authored the patch?
<LarstiQ> LeoNerd: that distinction does exist
<LarstiQ> JPeterson: bzr commit --author to set it
<JPeterson> LarstiQ: thx. how do i read it?
<LarstiQ> JPeterson: for me, it is certainly true that I use bzr almost exclusively over git
<JPeterson> whatever
<LarstiQ> JPeterson: it should be included in the log output when set?
<JPeterson> ok
<JPeterson> thx
<LarstiQ> JPeterson: but the more general point is that people might not be familiar with what you are talking about
<JPeterson> LarstiQ: an author is someone who write something, kind of
 * LarstiQ was referring to the core.filemode question
<JPeterson> LarstiQ: i know
<LarstiQ> ok
<JPeterson> well no id didnt know that for certain, but i was certain you knew what author is
<LarstiQ> JPeterson: programmatically, if you have a Revision object, .get_apparent_authors() will give you the names of the authors if set, or the committer otherwise
<JPeterson> thx
<JPeterson> this {{{rm -rf .bzr; rm *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr bundle -r-1 -o1.patch && bzr uncommit && bzr merge 1.patch}}} returns "bzr: ERROR: No submit branch known or specified". whats' the right command?
<LeoNerd> I imagine its the  bzr merge  that complains, yes?
<LarstiQ> it's the bundle I think
<LarstiQ> JPeterson: I'd use `bzr send upstreambranch -o1.patch` instead
<LarstiQ> JPeterson: instead of bzr bundle
<JPeterson> LarstiQ: what does that do?
<JPeterson> can i look at the stuff before i send it?
<LarstiQ> JPeterson: yes
<LarstiQ> JPeterson: it compares your current branch with 'upstreambranch', and writes a merge directive to 1.patch
<JPeterson> LarstiQ: it {{{rm -rf .bzr; rm *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr send upstreambranch -o1.patch && bzr uncommit && bzr merge 1.patch}}} returns bzr: ERROR: Not a branch: "C:/Users/User/Downloads/bzr/upstreambranch/".
<LarstiQ> JPeterson: right, you need to have an upstream
<LarstiQ> JPeterson: in your case you could try `bzr branch . ../upstream` before the commit
<LarstiQ> and refer to that
<JPeterson> LarstiQ: can that be replaced with the "-f ARG, --from=ARG    Branch to generate the submission from, rather than" argument?
<LarstiQ> JPeterson: -f replaces '.' with the argument to f
<LarstiQ> JPeterson: so that is setting the other branch in the (submitfrom, submitto) pair
<LarstiQ> JPeterson: doesn't seem like you can specify the submit branch (which is the _to_ location) like that
<LarstiQ> JPeterson: what you _can_ do, is not mention it and it will use the remembered location
<LarstiQ> JPeterson: so you could set that first and then not mention it
<LarstiQ> JPeterson: `bzr config submit_branch=../upstream`
<JPeterson> {{{rm -rf *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr config submit_branch=../upstream && bzr send upstreambranch -o1.patch && bzr uncommit && bzr merge 1.patch && bzr log}}} return bzr: ERROR: Not a branch: "C:/Users/User/Downloads/bzr/upstreambranch/".
<LarstiQ> JPeterson: yes, see the `bzr branch . ../upstream` I told you about. Also, after setting the submit_branch, leave out the 'upstreambranch' argument.
<JPeterson> {{{rm -rf * .*; bzr init; printf '0'>'test.py'; bzr add; bzr commit -m"m0" --author "a0"; bzr log; bzr config submit_branch=../remote && bzr send -r-1 -o1.patch && bzr uncommit --force && bzr revert && bzr merge 1.patch && bzr log}}} return "bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562"
<ubot5> Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed]
<JPeterson> {{{rm -rf * .*; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"m9" --author "a0"; bzr branch . ../remote}}} return "bzr: ERROR: Already a branch: "../remote"."
<JPeterson> my response is: how is that possible?
<JPeterson> or rather, by what decree?
<JPeterson> it doesn't seem to be by my will, so by who's will is there " Already a branch: "../remote".""?
<JPeterson> oh, ok i get it
<JPeterson> (i read it as ./remote)
<JPeterson> can bzr merge update bzr log?
<JPeterson> the reason i'm asking is because {{{rm -rf * .* ../remote; bzr init; printf '0'>'test.py'; bzr add; bzr commit -m"m0" --author "a0"; bzr branch . ../remote && bzr config submit_branch=../remote && printf '1'>'test.py'; bzr add; bzr commit -m"m1" --author "a1"; bzr log; bzr log ../remote; bzr send -o1.patch && bzr uncommit --force && bzr revert && bzr merge 1.patch && bzr log; bzr log ../remote;}}} return revno: 1 instead of revno: 2
<JPeterson> is the author saved in the patch?
<JPeterson> why intention with asking "[16:51] <JPeterson> wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list?" was how to write author to the patch
<JPeterson> (and commit message)
<mgedmin> whoever added the "use 'bzr push :parent'" suggestion to the 'bzr push' error message in a fresh checkou^Wbranch: THANK YOU!
<LeoNerd> Ooh, nice
<jelmer> mgedmin: you're welcome!
<bjp> i've been using bzrlib in one of my scripts for a little bit now and it's 'mostly' working smoothly.
<bjp> it occationally hangs, though, and right now it's hanging on WorkingTree.open()
<bjp> is there a way i can tell what its doing or how its failing?
<lifeless> bjp: hit ctrl-\
<lifeless> that will drop you into a debugger
<lifeless> if you've installed the post mortem hook
<lifeless> if you haven't, you may want to , its super useful
<lifeless> failing that, check ~/.bzr.log, or whereever you are logging output to, its probably opening a network branch/repository
<bjp> yea it's a lightweight checkout
<bjp> i haven't installed any hooks
<bjp> i don't see any bzr logs (i'm on windows)
<bjp> weird
<bjp> it's a batch job, it kept hanging on the 6th branch
<lifeless> bjp: bzrlib.breakin contains the postmortem hook
<lifeless> bjp: I believe it works on windows - have a look at pydoc bzrlib.breakin -
<jelmer> bjp: note that if the working tree has a remote branch or a bound remote branch, it might try to be contacting that server
<jelmer> *be trying to contact
<bjp> it is, the branches are on a server on the LAN
<bjp> so i just called hook_debugger_to_signal() to get the hook?
<lifeless> yeah
<lifeless> then if it hangs hit the magic key
<lifeless> and you should find yourself in pdb
<bjp> k, i put it in, now i just gotta wait till it hangs again
#bzr 2012-10-24
<JPeterson> how do i get past bzr merge, bzr: ERROR: Working tree ... has uncommitted changes (See bzr status).
<JPeterson> so what?
<JPeterson> how do i force merge?
<JPeterson> how do i do git stash?
<JPeterson> Answer: bzr shelve --ll
<JPeterson> *--all
<JPeterson> holy cow. "bzr shelve --all; bzr merge; bzr unshelve" now show both the reomte and my changes
<JPeterson> should i do bzr pull instead?
<JPeterson> the answer to "22:30] <JPeterson> how do i get past bzr merge, bzr: ERROR: Working tree ... has uncommitted changes (See bzr status)." is "bzr pull"
<JPeterson> this will not revert the local changes
<fullermd> For forcing a merge, you want --force.  What do you expect from shelve;merge;unshelve but a combo of the changes?
<bob2> er
<bob2> a) don't merge when you have local changes
<bob2> b) commit immediately after merging + fixing conflicts
<bob2> it's dvcs, no reason to let your code get screwed up like you would with svn
#bzr 2012-10-25
<LarstiQ> JPeterson: git merge = bzr merge; bzr commit
<jml> hey, it's been a long, long time since I submitted something to bzr. How do I land a patch to bzr?
<jml> I'm not sure if I've got commit privs,
<jml> but poolie gave me the go-ahead for https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850
<jml> but when I pqm-submit, I'm told it can't verify my gpg kkey
<mgz> jml: the normal way is lp:hydrazine `./feed-pqm bzr`
<jml> mgz: ok.
<jml> wow, hydrazine, huh?
<mgz> and you then 'n' till your proposal, 'm' set the message, and 'e' gpg sign and email for pqm to land
<jml> mgz: ok, thanks.
<jml> mgz: unfortunately, I have to step away for a bit now, but is it OK if I ping you later if I have trouble landing this?
<mgz> jml: certainly
<jml> mgz: ta
<fullermd> I'll be around to be completely unhelpful too, if that'll help.
<jml> fullermd: I was going to say "possibly", but I'm not sure that's strictly true. I appreciate the gesture though.
<fullermd> Oh, well, you can just lie to me about it.  I do it to me all the time, and I never seem to catch on.
<jml> fullermd: I'm just not sure it's logically possible for being completely unhelpful to ever help.
<fullermd> Pfft, logic.  What has logic ever done for me?
<jml> mgz: does hydrazine just loop?
<jml> mgz: also, it looks like I'm not a committer.
<jml> mgz: so maybe I should just ask you to merge https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850
<mgz> yes, blast, and okay.
<jml> mgz: thanks :)
<mgz> ah, and your branch needs to be marked approved, which is why it doesn't appear in the list
<mgz> so, pqm may in fact allow you to land it
<mgz> want to give it a go? if you get rejected, I'll do it.
<jml> mgz: sure, I'll try now.
<jml> PQMException: 'Failed to verify signature: gpgv exited with error code 2'
<jml> mgz: ^, I think you need to do it.
<fullermd> Maybe pqm forgot how to commit to bzr...
<mgz> I shall capture a webop later and get you added, landing now.
<yaiza> hi!
<yaiza> is it possible to rename a branch in launchpad?
<yaiza> I would like something like: lp:~ybailen/canonical-openerp/employee-registry-payroll -> lp:~ybailen/canonical-openerp/canonical-payroll
<yaiza> keeping the versioning
<yaiza> but I'm not sure if this is possible
<jpds> yaiza: Yes, click "Change branch details" on the Launchpad page.
 * yaiza tries
<yaiza> hmm, if I choose Target branch as Personal I get this error "Only private teams may have personal private branches."
<yaiza> jpds^ ?
<jpds> yaiza: But you only want to change "Name".
<yaiza> jpds, if I leave Branch Target as it was: canonical-openerp then I get this error: "Private branches are not allowed for target Canonical OpenERP."
<yaiza> so I tried to change that
<yaiza> with no success :(
<mgz> yaiza: you can ask for help in #launchpad if you're stuck
<yaiza> ok mgz, thanks
<hno> How do I add --no-trees flag to an existing shared repository? Just noticed I forgot specifying it when creating a shared repository some time ago.
<hno> I know how to drop the working trees from it's branches. But like the flag to be recorded so bzr branch remembers to do the "right" think when branching.
<fullermd> hno: There's an arg to 'reconfigure' for it.
<hno> fullermd, thanks!
<hno> To rusty on bzr merges. Need to backport a working branch to an older branch point. Is there an easier way than to cherry pick each revision listed by bzr missing?
<fullermd> Mmph.  Well, if your looking at "cherry pick _each_ rev", the answer would just be to do a merge.  But since you're asking, I presume you're wanting to actually skip some...
<fullermd> You can do a merge -rX..Y to grab just a range.  It would still be a cherry pick if the graph isn't connected, but it would at least get you N at a time instead of 1.
<fullermd> Though that's a drawback too, in that it mushes more things together and gives you more chances for big conflicts.
<hno> fullermd, the working branch is based on trunk, and need the same changes based on a release, skipping all the changes between the release and current trunk.
<hno> Do "bzr merge -r branch:../trunk..-1 ../trunk-feature-branch"  look sane?
<fullermd> Not at all   8-}
<hno> Any saner suggestion?
<fullermd> It may be _correct_, of course.
<fullermd> At a glance it _looks_ like it's asking for what you described, so it may be right.
<fullermd> Does twist the eyes a bit though.
<hno> "bzr merge -r submit:..-1 ../trunk-feature-branch" is probably better.
<hno> "bzr merge -r submit:.. ../trunk-feature-branch" works as well, but not sure it's documented that one do not need to specfy the last revision in the range.
<fullermd> It is.
<hno> where?
<fullermd> No idea   :)
<fullermd> But it is an explicit feature, and I know it's in the test suite.
<hno> Hm.. that merge for some reason set my submit branch to the trunk-feature-branch. Not what I intendend.
<fullermd> merge will always set the submit branch if it isn't already.
<hno> and branch don't..
<hno> In which use case do merge implicit --remember if unset produce a meaningful result? To me it's only confusing.
<LarstiQ> hno: all cases where there is only ever one branch you want to merge from
<LarstiQ> hno: like merging trunk into feature branches
<LarstiQ> hno: meaningful, but still can be confusing (re: list discussions about this)
<hno> LarstiQ, in those cases parent is also trunk and separate submit location is not needed.
<LarstiQ> ah hmm, submit
<fullermd> Yes, but merge uses a separate saved location.
<hno> it uses parent is submit is not set.
<fullermd> Right.
<LarstiQ> hno: in the cases where it makes sense to submit to the location you merged from then :)
<LarstiQ> but it becomes less obviously the right choice I think
<hno> there is a --remember flag for the odd cases needing it..
<LarstiQ> hno: on the other hand, when do you want submit to be something different without setting it explicitly??
<LarstiQ> argh
<LarstiQ> s/?//
<hno> LarstiQ, exactly. I do not want merge to set the submit branch for me when doing a random merge from some other branch.
<hno> when otherwise only using parent.
<LarstiQ> right
<LarstiQ> does anything using submit fall back to parent if submit is not set?
<LarstiQ> that would be rather annoying
<hno> LarstiQ, yes.
<hno> bzr merge, and also submit: revision spec in general so also bzr diff etc.
<LarstiQ> hno: right, so how to balance
 * LarstiQ would (now) lean towards not setting it automatically
<hno> Yes. Unless there is some very common use case which I fail to see where it makes sense.
<fullermd> Available evidence (it's there, and hasn't been a major cause of complaint in the last N years) suggests it does OK in the common case.
<fullermd> The whole arena has certainly been the cause of plenty of acrimony in the past.
#bzr 2012-10-26
<jam> lifeless: I have a question about using fixtures during testing. I'm playing around with having a service that gets brought up as a fixture, and it generates a log file.
<jam> Which I would like to add as a test detail, if the test fails.
<lifeless> jam: cool
<jam> however Fixture.setUp() doesn't have access to the test.
<jam> So do I just change the test code to do:
<jam> f = self.useFixture(MyService); f.updateDetails(self)
<jam> or is there some other useful way to have the fixture touch TestCase.addDetails ?
<mgz> so, lp:rabbitfixture uses addDetail early with testtools.content.content_from_file
<jam> mgz: yeah, I missed the fact that fixtures *themselves* have an addDetail method.
<jam> vs just TestCase having it.
<lifeless> jam: so, TestCase.useFixture will automatically grab fixture details IIRC.
<jam> that wasn't particularly documented on: http://pypi.python.org/pypi/fixtures
<lifeless> jam: you should just need to add whatever info you want to the fixtures details (during setUp - the actual content grab will be lazy)
<jam> lifeless: right, addDetail('log', content_from_file(log_file)) looks like it will work, though I need to actually test it
<lifeless> jam: looks like I need to document addDetail, could you file a bug pleasE?
<jam> lifeless: what is the ordering between addCleanup(delete_the_file) and addDetail(..., content_from_file) ? Is addCleanup always run after detail collection?
<jam> I'll file a bug
<jam> lifeless: https://bugs.launchpad.net/python-fixtures/+bug/1071649
<ubot5> Ubuntu bug 1071649 in Python Fixtures "Document addDetail" [Undecided,New]
<lifeless> jam: detail capturing run when an error is happening in the test framework
<lifeless> jam: cleanup runs after an error is caught or the test ends normally
<lifeless> rephrase
<lifeless> detail capturing runs when *reporting an outcome*
<lifeless> cleanup runs after reporting outcomes or at test end
<lifeless> the nasty bit there is that the success outcome only happens after cleanup completed successfully
<lifeless> so if you need logs etc for tests that pass (and you may want them - up to you :)) you need to stash stuff
<lifeless> jam: TBH this stuff hasn't been polished - it was written, Just Worked, and we haven't reviewed it or had cause to spend more time on it (because it Just Worked :P)
<jam> yeah, I don't need it right now. For failures is fine. Though interestingly it means you lose the 'shutdown' part of the log, since the cleanup to shutdown the server happens after the error that indicates you want to cleanup.
<jam> but yes, it works quite well for my purpose.
<lifeless> cool
<lifeless> shiny stuff is shiny
<lifeless> openstack are just adopting this now
<lifeless> beginning of a learning curve for them on test effectiveness :)
<jam> lifeless: yeah, I just wish this kind of goodness was already in go.
<jam> It looks like our team will be working on juju-core in the near future, and I'm noticing things like really-good testing infrastructure stuff.
<lifeless> :)
<lifeless> perhaps you can add it.
<jam> yeah, a bit of 'as needed'. But always the "to do your simple problem X, first you need to implement all of Y and Z"
<jam> lifeless: so fixture already seems to know about cleaning up state between test runs. Is there much to be gained to poke into testresources?
<jam> (i imagine it mostly adds test organization to bring together similar resourced tests?)
<lifeless> jam: right
<lifeless> jam: FixtureResource will adapt a fixture for you
<lifeless> poo/win 61
<lifeless> bah
<fullermd> Better than a poo/loss.  I think.
<fullermd> lifeless: Incidentally, I was wondering the other day about that libcpuinfo you had.  Is that still live?
<lifeless> fullermd: I haven't touched it, but it should still work
<lifeless> fullermd: and I'll happily merge and review patches
<lifeless> fullermd: (working code == no touch no more :))
<fullermd> I noticed there's an outstanding merge request on it.
<lifeless> oh
<lifeless> I wish LP was better at showing me things like that
<lifeless> jml filed a bug about that :P.
<fullermd> Sadly, nobody noticed the bug because LP didn't show them?   :p
<lifeless> fullermd: I won't look at it tonight.
<lifeless> fullermd: trolololol
<fullermd> Oh, no rush at all.  Just wondered it in passing a week or two ago.
<fullermd> Should add a sysconf() method.  Early on, maybe; library calls are cheap.
<Han> If you want to forget your local changes and just update your branch to
<Han> match the remote one, use pull --overwrite.
<Han> So I run bzr pull --overwrite and guess what I get to see after bzr diff... :P
<Han> How do I really get the remote tree like it should be?
<vila> Han: the should read "If you want to forget your *committed* local changes"
<vila> Han: to get rid of your uncommitted local changes, use 'bzr revert'
<Han> arrrrr
<Han> vila, thanks
<lamalex> hello, is it possible to search through a tree's entire history?
<lamalex> i'm trying to find a function and determine if it was removed, and there's no commit message indicating
<mgz> lamalex: see bzr grep. it's built in to the latest development bzr, or available from lp:bzr-grep as a plugin for earlier versions
<jelmer> lamalex:  I usually just grep through 'bar log -p' for that
<jelmer> *bzr
<lamalex> mgz, im trying to use bzr grep but it doesnt seem to run through my entire history (or is it and im just not realizing?)
<mgz> that relies on the nice person saying they removed function X in their commit message :)
<fullermd> Not with -p it doesn't   :p
<mgz> lamalex: see `bzr help grep` for details
<lamalex> ahh
<lamalex> :)
<beuno> lamalex, also, bzr-search
<timour> Hello, I am experiencing the following problem while trying to revert a branch to a previous version:
<timour> bzr push --overwrite
<timour> Connection Timeout: disconnecting client after 300.0 seconds
<timour> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<timour> bzr 2.4.1
<timour> with bzr 2.62b - same problem
<timour> tried from different boxes in different countries
<timour> Sorry, forgot to mention that the tree I push to is on Launchpad.
<timour> Is this some know problem with BZR or Launchpad?
<jelmer> timour: can you connect to bazaar.launchpad.net with sftp?
<timour> jelmer, will try now
<timour> jelmer, yes, no problem
<timour> jelmer, also please notice that I asked my colleague to try the same, he is an different country, different account
<timour> jelmer, do need to know what is the source tree?
<jelmer> timour: does e.g. "bzr ls lp:bzr" work?
<timour> jelmer, yes
<jelmer> not sure what's going on then
<timour> jelmer, could it be something specific to this tree
<jelmer> timour: if you run with -Dhpss, then ~/.bzr.log might help you see what's going on
<timour> lp:maria/5.5
<timour> jelmer, ok, will try now
<timour> jelmer, this is some of the interesting errors:
<timour> ooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://timour@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<timour> there is a call stack as well, not sure if anyone wants to see it here
<timour> jelmer, thanks for the help, have to go to sleep. I pushed an 'undo' patch, which is the only solution ATM.
#bzr 2012-10-28
<mark06> how to merge a branch without a common ancestor?
<fullermd> Manually specify the rev range to merge.  Usually the whole history, i.e. "-r0..-1".
<jelmer> I wonder if we should just add that as suggestion to the error message.
<fullermd> I'd hesitate, I think.
<fullermd> Worth a FAQ entry, maybe.  If we have a FAQ.
<mark06> I think clarify the error message would be nice, because I went through exactly the same steps as described here, without knowing this page: http://selfdocumentingcode.blogspot.com.br/2009/04/merging-unrelated-branches-in-bazaar.html
<mark06> is there a way to specify a bug in commit comment without using full URL?
<mark06> I want to reference bug 308562 in the dummy initial commit
<ubot5> Launchpad bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555
<jelmer> mark06: there is the --fixes option which adds a commit property
<mark06> I know, but it doesn't fix the above bug :)
<jelmer> mark06: it allows you to use shortcuts for bug tracker URLs
<jelmer> mark06: --fixes lp:4545 will reference http://bugs.launchpad.net/4545
<ubot5> Ubuntu bug 4545 in amsn (Ubuntu) "amsn crashes on start-up/won't load" [Medium,Fix released]
<mark06> ok, I know, but it doesn't fix that bug, it's that bug which required the commit, so would be rather --forced-by
<jelmer> mark06: I'm not sure I follow what you mean in that case
<jelmer> mark06: do you want to reference a bug without actually changing anything else?
<jelmer> mark06: you want --unchanged in that case
<mark06> I'm already using --unchanged
<fullermd> I think you're just trying to outsmart yourself   :)
<mark06> I want to reference the bug in the commit comment, something like:
<fullermd> Just reference "LP bug 12345" in the commit message.
<ubot5> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<fullermd> ISDN?  Yeesh.  How 1990's   :p
<mark06> yeah fullermd, just wondered if it was possible
<jelmer> mark06: Why though? This is what the commit properties are used for, and what all bzr tools will display
<jelmer> Having two different ways of referencing bugs would seem very confusing to me, and not particularly useful.
<mark06> jelmer: ...something like: bzr commit -m "This is a dummy, empty commit required because of bug lp:308562"
<jelmer> mark06: ah, no, there isn't any way to do that. I don't think that would be particularly useful.
<mark06> btw, it would be nice if tags weren't unique, or if we had options like --not-very-important (e.g. code formatting) --broken (for broken revisions we don't open a bug for)
<mark06> about the dummy commit, nothing much important
<mark06> or --fixes=revision
<jelmer> mark06: what do you mean with --not-very-important, what would that do?
<mark06> add a metadata to the commit stating it is not as important as "regular" commits, so we could for example bzr qlog --exclude-not-much-important
<jelmer> mark06: one of the fundamental properties of tags is that they're unique; without that; if you want to use them to annotate revisions I think what you want is a different feature (perhaps stored as revision property?)
<mark06> yeah, as a property then...
<mark06> is it possible to add arbitrary properties and have them showing in qlog juts like tags or --fixes?
<jelmer> mark06: you'd have to have a plugin installed that can display those properties
<jelmer> similarly though, you'd need a plugin to set them
<mark06> :(
<mark06> what's the difference between -r 0..-1 and -r 1..-1?
<fullermd> 1   8-}
<fullermd> The former runs from null, the latter from rev1.  Just what the result is probably varies a bit by command and how they interpret the rev range.
<Guest40826> Could someone explain to me the relationship between repositories and branches in bzr?
<jelmer> Guest40826: the repository is the thing that holds the revisions, and a branch is a line of history
<mark06> how about the merge command, does it make any difference like merging uncommitted commits or something?
<fullermd> mark06: Yes, -r1..-1 would mean the revs {2,3,4,...,-1}, in contrast to 0..-1 meaning {1,2,3,...,-1}
<Guest40826> So, if I want to have two completely separate projects, would I create two separate repositories for them?
<jelmer> Guest40826: no, you can have them in the same repository without problems. The repository is merely a container for the revisions, it doesn't require them to be related in any way and it doesn't have any effect on their relation either.
<fullermd> However, if they really are completely separate, there would be no _gain_ from having them both in the same repo.
<jelmer> indeed
<fullermd> Potentially a minor loss in performance in some cases, since half (or whatever proportion) of the data to be sorted through would be pointless for any individual activity.
<mark06> fullermd: ah thanks!
<fullermd> Probably pretty unimportant, unless either branch is huge.
<Guest40826> So, I could create one repository (using the init-repo command?) that would have multiple branches inside of it (created using the init command?) and could develop two different codebases within that one repository?
<Guest40826> Do I have that right?
<jelmer> Guest40826: yep
<fullermd> You could, yes.  The repository doesn't care; all it knows is it gets told "find me revision XYZ" or "here's a revision; hold onto it"
<mark06> maybe just create standalone branches (each branch contains its own repo)
<Guest40826> mark06: What do you mean by that?
<fullermd> Guest40826: What's your VCS background?
<Guest40826> almost strictly svn
<fullermd> OK.  So the difference here is that svn is very repo-centric, whereas bzr is branch-centric.
<fullermd> In svn, the repo boundary is important.  You checkout the whole thing, or some arbitrary subpart of it.  All your operations take place inside it.
<fullermd> Whereas in bzr, you deal only with branches; the whole branch, and nothing but the branch.  You checkout the whole thing, you make a new branch of the whole thing, etc.
<fullermd> Operations like merge take place between two branches.  And any two branches; they don't have to be in the same repo (or in any shared repos at all)
<Guest40826> okay, so what is a standalone branch?
<Guest40826> (mentioned by mark06)
<fullermd> Whether a branch is in a shared repo or not doesn't make any difference to how you interact with it; it only changes some backend storage details.
<fullermd> A branch that's not in a shared repo.
<fullermd> How about an example...
<fullermd> "mkdir ~/work ; cd ~/work ; bzr init projA ; bzr init projB"
<fullermd> Now you've got two unrelated branches to work in, each of which is standalone.  All the history for projA is in ~/work/projA, and for projB in ~/work/projB.
<fullermd> Or add a step instead:
<fullermd> "mkdir ~/work ; cd ~/work ; bzr init-repo . ; bzr init projA ; bzr init projB"
<fullermd> Now you've got two unrelated branches to work in, both of which use the shared repo for their history storage.
<fullermd> Inside ~/work/ is a giant bucket that all the revisions get dumped into.  projA knows which of them belong to it, and projB know which belong to it.
<fullermd> For pretty much anything you _do_ day to day, the two cases are identical.
<fullermd> Unlike svn, the repo isn't [generally] a semantically meaningful unit.  It's the branches that are the granularity you work with.
<fullermd> And in this case, it doesn't convey any advantages, since the two projects don't share any history.
<fullermd> Where it's useful is when you have projA-trunk/ and projA-frob_foo/ and projA-from_bar/ branches, which _are_ related.
<fullermd> Standalone, each would have the entire history (both the stuff common to all of them, and the new stuff in each)
<fullermd> With a shared repo, all the history is in one place, so the common history isn't duplicated.  Saves disk space, I/O bandwidth, buffer cache, etc.
<Guest40826> Here is my situation: I have two development teams, neither of which has any relationship to the other (outside of that fact that they have them same system admin). Team A is dealing with one codebase, Team B is dealing with two codebases (for two entirely separate pieces of software). I want to give Team B one domain at which they can access both codebases and choose which one to modify based on what they are going to be working on.
<Guest40826> Which sounds to me like one repo with two branches in it for Team B.
<fullermd> Is that 3 codebases, or 2 (one shared, one B-only)?
<Guest40826> 3 total - one for team A, the other two for team B
<fullermd> I'd just make one repo for each codebase then.
<fullermd> Sharing a repo between unrelated codebases doesn't gain you anything, so go for simplicity.
<Guest40826> okay
<Guest40826> so how do I serve those two repos for team B at the same domain?
<Guest40826> Just by placing the two repos in the same directory and giving team B access to that parent?
<fullermd> Yeah.
<fullermd> How are you accessing them?  bzr+ssh?
<Guest40826> That is another question I have :(
<Guest40826> Is there a difference between bzr and bzr+ssh
<Guest40826> ?
<fullermd> bzr is a standalone server, like svn://.  bzr+ssh ssh's into the server and talks to a spawned process over that channel, like svn+ssh
<Guest40826> so I bzr:// what you would use when running the http://doc.bazaar.canonical.com/bzr.2.5/en/admin-guide/other-setups.html#direct-smart-server-access setup?
<Guest40826> *is
<fullermd> Note that bzr doesn't have any concept of AAA, so in general you'd only use it for readonly stuff.
<fullermd> (bzr:// that is)
<Guest40826> Okay,
<Guest40826> I am going to be accessing this using bzr+ssh
<Guest40826> With user accounts being restricted to bzr
<mark06> http://i.imgur.com/z0zsX.png o/
<fullermd> Definitely an odd use of tags.
<mark06> actually I changed it to fixes_rev_0.11.5 on 0.11.6
<fullermd> Yeah, that would also fall under "pretty odd"   :p
<mark06> yeah I know :)
<mark06> oh wait, fixed_by_0.11.6 :)
 * fullermd reaches for the smelling salts.
<mark06> I think I've found a bug, if merged branch contains tags already present in current branch, then it gets deleted after merge! (current branch wins the tag)
<fullermd> That's not exactly a bug.
<mark06> I would personally add a merge conflict to let the user decide
<fullermd> The trouble is, there's no way to record a resolution.
<fullermd> Actually, I'd expect merge to spit out a warning about it.  pull does.  But maybe it gets lost in all the other stuff merge outputs.
<fullermd> I guess it doesn't.  That's probably worth a bug.
<mark06> hmm ok leaving... thank you all!
<fullermd> Oh look, a Wacky Log Bug.
<jelmer> fullermd: where?
<fullermd> I'm gonna have to work up a repro script.  's hard to explain, but it winds up with "bzr log $DIR" (or $FILE I presume) not showing you what it should.
<Konomi> hi I am trying to use checkout and I am doing bzr checkout sftp://user:pass@host
<Konomi> and bazaar seems to ignore hte pass field entirely and still ask for a password
<fullermd> That's because bzr doesn't have access to the password-asking; sftp talks to your terminal directly for that.
<Konomi> is there anyway to automate it at all?
<Konomi> I get sick of typing in a password everytime?
<fullermd> Use key auth (possibly with the aid of ssh-agent).
<Konomi> meh okay thanks for your help fullermd
<fullermd> Possibly you could force it to use paramiko instead of an outside ssh client, and pass it in that way?  I dunno.  Not as nice a solution at any rate.
<Konomi> what is a bit annoying is http://doc.bazaar.canonical.com/bzr.1.11/developers/authentication-ring.html
<Konomi> says I can embed the pass in the url but I guess it doesn't note the exception for sftp
<Konomi> fullermd: I'll just put up with entering the password for now at least I know the url is remembered I was typing that too
<Konomi> thanks again
<fullermd> Boy, this thing is tricksy...
<lifeless> fullermd: which thing ?
<fullermd> Weird log bug I'm tracking.
<bob2> why would you not just use keys
<lifeless> harmony
<fullermd> Yeah, you might be Berg or Schoenberg.
<bob2> it is far too early on a monday for classical music jokes
<fullermd> Good thing it's late on a sunday   8-}
 * fullermd writes up a terribly confusing bug...
#bzr 2013-10-21
<tuv> how do i merge a specific revision of a remote branch (non-head)? i have the global revision id
<tuv> bzr merge -r <revno> <branch>
<tuv> how do i show the source branch of an uncommitted merge?
<tuv> bzr ifno ?
<tuv> bzr info ?
<tuv> ok.. how do i find out the source revision of an uncommitted merge?
<spiv> tuv: bzr status --show-ids
<spiv> (or -v?)
<spiv> bzr status is the command that summarises uncommitted changes for you, and that includes merges.
<tuv> spiv: i only need to find the parents for the merge? branch and revision of each parent
#bzr 2013-10-22
 * LeoNerd sets command alias of  untag = tag --delete
<LeoNerd> By symmetry to  uncommit
<Malinux> I made a team-page on launchpad. How do I push code with bzr to it? I need step by step for dummies on how to it :)
<MEB> Hi, does anyone have experience using Bazaar to push revisions over fpt?
<MEB> *ftp
#bzr 2013-10-24
<yacc_> Just wondering, does bzr have builtin support for ssh, or does it require an external ssh/plink executable?
<jelmer> yacc_: it can either use external ssh/plink, or the python paramiko module
<yacc_> jelmer, :)
<yacc_> Any description how private/public keys are handled with paramiko?
<jelmer> I think it just reads them from ~/.ssh, but I'm not entirely sure
<yacc_> jelmer, openssh format?
<jelmer> yacc_: I'm not actually sure, sorry
<yacc_> jelmer, no problem, it's such a PITA to support Windows users if one has no Windows box at hand ;(
<fullermd> I enjoy supporting Windows.  First you find a good solid branch, then tie a noose on the end of the rope...
<yacc_> fullermd, well, there are some improvements on this, I mean you might be forced to use subversion repositories, Windows PC as work stations, ...
<yacc_> fullermd, getting a DVCS (I've reached the point where I don't care if it's bzr, git, hg, monotone or whatever) that can work with such an setup (did I mention that the subversion repo is full of nice or not so nice svn:external properties?) can get one into an asylum really quick.
<fullermd> Obviously, you'd need to about that "subversion" stuff and get something industrial strength.  Like ClearCase.
<yacc_> fullermd, well, at least I work for the bleeding edge part of the company, we already have svn and don't even need to have CC installed on our PCs, ...
<fullermd> Gotta be careful.  You never know when it might mutate and become airborne   :|
<yacc_> It's not really funny. git is a pure joy under Windows (and because the svn bindings for perl are even more fun to create than the python ones it uses an ancient git-svn)
<yacc_> bzr/hg have their own joy, e.g. random grass root pythons installed on the developer/tester work stations, ...
<yacc_> Ok, I've setup that plink.exe can access hostname.org (saved session as hostname.org) with a password. (eg. plink hostname.org id / plink hostname.org bzr do work without a password)
<yacc_> set BZR_SSH="c:\program files (x86)\putty\plink.exe"
<yacc_> bzr branch bzr+ssh://hostname.org/path asks for a password.
<yacc_> Ok, I've setup the putty session so it can login WITHOUT a password (using a PPK)
<yacc_> ErrorFromSmartServer: Error received from smart server: ('PermissionDenied', '/home/andreas/private/conf2html/.bzr/repository/upload/9hzeuy945jl4nur1wlo9.pack', ": [Errno 13] Keine Berechtigung: u'/home/andreas/private/conf2html/.bzr/repository/upload/9hzeuy945jl4nur1wlo9.pack'") <= any idea why my branch has no repository directory?
#bzr 2013-10-26
<reisio> how would I grab a specific milestone?
#bzr 2013-10-27
<mark06> how can I know if bzr --uncommit has been performed on a branch?
<jelmer> mark06: 'bzr log' will tell you
<mark06> where exactly? I though log only showed commits, not undone commits...
<jelmer> mark06: well, I meant you can see that a particular revision disappears from "bzr log"
<jelmer> mark06: there is no real recording anywhere that an uncommit had previously been done
<mark06> but the uncommit is still there, so maybe I could grep/find for something in .bzr?
<jelmer> mark06: the revision is there in the repo, but the fact that a child revision of the current head is present doesn't necessarily mean that there was an uncommit
<mark06> then I need not to rely on that
<mark06> maybe something within .bzr\repository?
<maxb> Why do you need to know this? (Tell us more about your use case so we can suggest alternatives)
<mark06> I just wanna know
<jelmer> mark06: uncommit only touches files under .bzr/branch, and it just resets the branch tip - doesn't do anything else
<maxb> There is no explicit record that an uncommit has occurred
<mark06> maxb: e.g. bzr commit -am > ctrl+v > "secret info about my new cryptographic system inviolable by spies, which was accidentally pasted from text editor"
<mark06> maxb: then bzr uncommit won't actually delete such info
<mark06> There is no explicit record that an uncommit has occurred -- ok then I need to recognize the uncommit objects by hand...
<maxb> No, you need to understand that there is no such thing as an 'uncommit object'
<mark06> *-m
<mark06> ok, call it whatever you like
<mark06> but it's there
<maxb> Actually, it's not there
<mark06> it is
<mark06> branches growing for no reason in the past
<mark06> it was the uncommits
<mark06> call it whatever you like
<mark06> but the info is there somehow, in some form
<jelmer> mark06: there is no such thing as a "uncommit object" - uncommit doesn't create objects
<mark06> as I said, you may call it whatever you like
<jelmer> it seems like you're possibly referring to the objects left behind in the repository after a branch stops referring to it
<mark06> name it like you wish
<mark06> info is not deleted, completely deleted at least, when we uncommit
<jelmer> mark06: sigh, you're being very sloppy with terminology which makes it hard to understand what you're talking about
<mark06> yeah if those are the uncommits
<jelmer> I don't have the patience for that, sorry
<mark06> if there are other ways to leave these objects unreferenced, then I could try to figure out how to differentiate
<mark06> if these unreferenced objects should not normally live within a branch, then I may assume they're likely uncommits and it it does not harm to delete these unreferenced objects, then I could just do it
<maxb> There's no reasonable algorithmic way to do that
<mark06> ok so will it be harmful just deleting all unreferenced objects?
<maxb> I'm curious... how do you think you're going to 'delete unreferenced objects' ?
<mark06> rm
<mark06> or bzr api
<mark06> or bzr api hacks
<maxb> Nope
<mark06> why
<maxb> They're not objects in the filesystem, nor are there bzrlib apis for this
<mark06> I need to seek for references and find none?
<mark06> then bzr api hacks I think
<mark06> are these objects somehow tagged as 'unreferenced' or I need to actually seek for references all though the branch to check it's actually unreferenced?
<maxb> I don't think you really understand the bzr storage formats enough, they're fairly append-only
<maxb> The functional way to get rid of unneeded objects is to branch what you do want into a fresh repository
<mark06> that's what I do, but it's boring...
<mark06> needs to push and pull with  --remember
<mark06> if I could have a program to go through all branches on a directory tree and just remove or at least report them would be nice...
<mark06> I could write a similar program for branching like this instead.... but so ugly...
<mark06> but that would be much easier at least...
<mark06> mv b b.old; bzr branch b.old b; extract parent and push from b.old's branch.conf; then push --remember; pull --remember...
<mark06> even more easier than I thought: grep -E "^(parent|push)_location" b.old/.bzr/branch/branch.conf > b/.bzr/branch/branch.conf :)
<mark06> thanks anyway maxb, jelmer
#bzr 2014-10-20
<mwenning> hi, I'm getting an error on bzr push :parent:
<mwenning> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~dell-poweredge-team/charms/trusty/openmanage/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<mwenning> Any help?
<CcxCZ> mwenning: bzr push using lp: uri instead
<CcxCZ> you can't push to http
<CcxCZ> (I think)
<mwenning> CcxCZ, worked!  thx
<mgrandi> Does anyone have any 'better' documentation on the bzr pack format? I think i have it but if someone already wrote something up that would be easier =P
#bzr 2014-10-21
<bukai> Hi,  i hav installed bzr but when i am writing this : bzr branch lp:~kubuntu-website/kubuntu-website/kubuntu.org, I am getting the following result: http://pastebin.kde.org/pcvnsiluc how do i resolve this?
<bukai> *have
<qolund> Hello. I'm looking for the mysql <4.1 source code, and they are using bzr which i never used.
<qolund> (I use git) is there a way to list branches/versions ?
<qolund> They kept old functions in ./sql/password.c
<qolund> :D
<CcxCZ> qolund: bzr tags ought to tell you which revision belongs to which release, in case that's what you're asking
<CcxCZ> and they did tag it accordingly
#bzr 2014-10-22
<mtakkman> i made: bzr init; bzr add *; bzr whoami "my info..."; but when i do bzr commit; i get "ERROR: Could not acquire lock "(local)"". i made bzr break-lock; but without result. i use sorry to say windows and i am new in bzr. What i don't understand?
<mtakkman> Bazaar 2.5.1
<LeoNerd> I wonder if it's upset about the Windows filesystem maybe?
<mgz> mtakkman: it also gives you a directory it's trying to create? can you manually make that?
<mgz> presumably bug 1172533 which should be avoidable by putting the branch somewhere else that doesn't trigger whatever the issue is
<ubot5> bug 1172533 in Bazaar "Cannot acquire lock on Windows 7 when configuring my details" [High,Confirmed] https://launchpad.net/bugs/1172533
<mtakkman> Unable to obtain lock file:///some path/ held by "my info in bzr" on "name of current user of windows" (process #7592), acquired 60 minutes, 33 seconds ago.
<mtakkman> Will continue to try until 19:18:57, unless you press Ctrl-C.
<mtakkman> See "bzr help break-lock" for more.
<mtakkman> bzr: ERROR: Could not acquire lock "(local)": file:///some path
<mtakkman>  
<mgz> mtakkman: the path is actually relevent, I want to know if it has url escapes or anything else unusual in it...
<mgz> mtakkman: at least, try the same in a different directory that your user has full perms on, and doesn't have any odd characters in
<mtakkman> ok i do it. This error was becaus i don't correctly close popup window for commit's message. So in other dir it work
<mgz> ah, so commit was still going, and holding the lock
#bzr 2016-10-27
<anddam> hello
<anddam> does bazaar have a concept of version that is different from tag?
<anddam> I'm trying to specify a version for a project on launchpad using https://pip.pypa.io/en/stable/reference/pip_install/?highlight=bzr#bazaar syntax
<anddam> it says "tags or revisions" but on launchpad I see "version"
<anddam> to be more clear https://launchpad.net/pygobject/trunk/3.0.2
<anddam> I see 3.0.2 is not a revision, it could be just a tag that in the previous example is specified with @v but I tried both @3.0.2 and @v3.0.2 and I got a message saying "that revision doesn't exist"
<anddam> nvm, I didn't need the launchpad repo in first place, upstream is on git
<anddam> bye
