#bzr 2008-01-07
<lifeless> spiv: FWIW I think RemoteRepository really wants to be a Repository subclass; but lots of Repository stuff wants to be on other subclasses
<spiv> Yeah, I think RemoteRepository wants to be a subclass too.
<lifeless> poolie: I've popped up for air; its going really well.
<poolie> great
<lifeless> poolie: if you want a call; now is a good time for me.
<poolie> sure
<lifeless> and to the crowd in general, review sought on [MERGE] New development format (unchanged) and alias support for format
<lifeless> poolie: I'll call in a sec
<poolie> lifeless, did you say something the other day about the feisty bzr repo being out of date
<poolie> (as in https://answers.launchpad.net/bzr/+question/21602)
<core-ix> i have a question about bazaar vcs: does it support user rights (access to branches like read/write) and secure communication over the internet (i.e. SSL/TLS) ?
<poolie> core-ix, yes, you can do access control either through the 'bzraccess' hook, or by OS permissions on the repo
<poolie> and you can use either bzr+ssh, sftp, or https for encrypted access
<core-ix> ok, thanks poolie ... i'm choosing new VCS for several projects and i need those features i mentioned before
<lifeless> poolie: yes, on my todo
<lifeless> poolie: I should get to it today I hope; I figure its not life or death right now
<indu> hiall
<indu> hi all
<indu> in loggerhead, i want the Log, Inventory, RSS,Repository under the branch itself , means, how can I  do it?
<indu> just similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev
<indu> how can i improve my loggerhead look similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev
<indu> mwhudson, can you help me in this please
<indu> Do I need to use redirect option of apache for this ?
<indu> mwhudson, are you there
<indu> anyone please tell me where can I get help in loggerhead,
<poolie> indu, from mwhudson,
<poolie> or i suggest you use the list or http://answers.launchpad.net/bzr
<indu> poolie, he is in leave till feb 4th itseems
<poolie> indu, i'm not sure but i think that page is actually running the webserve plugin
<poolie> which is different to loggerhead
<ubotu> New bug: #180969 in bzr "export to a non-existing directory failed" [Undecided,New] https://launchpad.net/bugs/180969
<TFKyle> hmm, for some reason bzr pull lp:someproject doesn't work here (tries to use a local dir /cur/path/lp:someproject/) even though bzr ls lp:someproject does, is there a reason for that? (bzr 1.0 and 1.1rc1)
<poolie> TFKyle, that is strange, could you please file a bug on http://launchpad.net/bzr ?
<siretart> 'bzr get lp:bzr' takes about 5 minutes. is this 'normal'?
<siretart> feels quite slow
<vila> abentley: BB down since more than 12 hours now
<abentley> vila: Thanks.  Restarted.
<ubotu> New bug: #180996 in bzr "bzr checkout fails with 'No buffer space available'" [Undecided,New] https://launchpad.net/bugs/180996
<indu> anyonw here again now, who has idea about loggerehad configurations
<indu> could some one give me the path for webserve, download
<indu> is there a way of receiving a mail when someone uploads some source into my repo
<vila> abentley: thanks to you ;-)
<abentley> np
<vila> abentley: now, that I can access it again, I notice you voted tweak on http://bundlebuggy.aaronbentley.com/request/%3Cm2fxxl1yzv.fsf@free.fr%3E
<vila> but I *never* saw the email ???
<abentley> Yeah, it's a problem because I changed my email, but BB wants to use the wrong one.
<abentley> Which Mailmain no longer recognizes as a subscriber.
<vila> abentley: ok ok
<abentley> So for now, I can only vote by mail, which I didn't realize then.
<dennda> http://paste.pocoo.org/show/19892/ <-- Any thoughts on how to resolve that?
<dennda> works again
<dennda> magic
<Peng> dennda: Perhaps you had another bzr process running?
<dennda> maybe
<lifeless> indu: perhaps ask on list
<lifeless> indu: I suspect people are not understanding the question.
<lifeless> ngiht all
<mgedmin> I don't suppose there's a vcscommand vim plugin for bzr?
 * mgedmin settles for bzr get lp:bzr-vimdiff ~/.bazaar/plugins/vimdiff
<mgedmin> why does 'bzr st' print paths that aren't valid in the current directory, when you're not in the root of a working dir?
<Peng> Yeah, it prints paths relative to the root.
<Peng> God knows who made that choice and why.
<Peng> There's at least thought of changing it.
<mgedmin> I think I vaguely remember a discussion about this, maybe on the mailing list
<mgedmin> today it bit me, and I wanted to ask here before filing a bug report
<Peng> Yeah, mailing list.
<mgedmin> do you perchance have a url/date + subject?
<Peng> Nopers.
<asac> lifeless: is bzr init without any repo format option what i should use for large projects/max speed nowadays (latest 1.1.0.dev.0)?
<vila> asac: yes
<dlee> Got a bzr bind that stalls seemingly forever (until I kill it), but a bzr push to the same repo works fast.  The repo is a bzr:// one where the marchine name maps to a VPN-accessible subnet.  Since bzr push works, I figure it's not a connectivity problem though.  Bzr 1.0.
<salgado> hey there
<salgado> is there any easy way to find the latest N revisions which touched a given file?
<luks> bzr log path/to/file --limit N
<salgado> that easy!?
<salgado> thanks luks. I hadn't notice I could use 'log' on a file/dir
<luks> well, log on a dir will probably not do exactly what you expect
<luks> but on a file it should work fine
<dlee> Re my earlier issue with bzr bind hanging where bzr push works fine:  bzr tags -d <same_repo> also hangs.  Ideas for what to look for welcome.
<vila> dlee: have a look at $HOME/.bzr.log, then you can also try -Dhpss
<dlee> Doing...
<lifeless> moin
<dlee> Results: Stall after "ok" result from repository.get_revision_graph; sending SIGINT gives a traceback in the log.
<lifeless> dlee: file a bug please
<dlee> Will do
<dlee> Etiquette questions btw: Is it best to check here before filing a bug, or just to go file and ask later?  Also, I park here to ask and (when I actually know enough) answer questions.  I'm not a Bazaar developer though (if I learn a bit of Python this may change...).  Please let me know if there's a better way before I unwittingly become a pest. :)  (I say all this because, for whatever reason, many questions I've asked since the day I fil
<beuno> dlee, asking for help and before filing a bug is just fine
<beuno> it's a bzr-in-general channel
<dato> dlee: (your line broke up at "the day I fil")
<dlee> Arg... my client shows it all. :P thanks for the catch
<dlee>   filed the cvsps-import_under_Cygwin bug have drawn no comment)
<lifeless> dlee: I'd rather you file a bug than the issue go unknown by folk who are coding; asking here first is good but if its inconclusive please do file a bug
<lifeless> on IRC people will often not respond if they have no clue
<lifeless> so if what you're asking is not obvious you may get no commit ;)
<dlee> Lifeless: ok thanks.  I figured silence meant uncertainty, but after a week or so of the same luck, I thought, "I'm too new to find so much new stuff already!" :)
<zeasier> are there any bug tracking applications that work with bzr?
<zeasier> heard of the trac module but haven't gotten it to work
<Peng> Well, there's Launchpad.
<lifeless> and trac
<lifeless> and cart
<lifeless> and bugs everywhere
<lifeless> and I think there's a buzilla module for bzr, so you can write a script to interrogate a bzr repo and use that to modify bugzilla
<zeasier> launchpad is pretty cool
<zeasier> but it isn't for closed source projects
<zeasier> never heard of cart and bugs everywhere
<Rinchen> Hi folks.  I have a quick question.  When I do a bzr whoami, I get my correct email address (verified in bazaar.conf) but when I do a bzr commit  it uses a different gpg key (from another email address in the ring).  Ideas on how I can fix that?
<lifeless> zeasier: you should talk to 'statik'
<zeasier> just found the cart thread in lists.ubuntu.com
<zeasier> looks interesting
<lifeless> Rinchen: you can set a gpg signing command
<lifeless> Rinchen: possibly there are other gpg options; have you looked in the manual ?
<Rinchen> lifeless, I've been scanning through it now
<Rinchen> so far, no luck
<lifeless> abentley: still thinking about annotating inventory changes? I'm thinking that this format can generate revision markers for execute bit/sha/name/parent etc quite easily during composition
<lifeless> abentley: course at the start of a new delta chain it would be all new :(
<lifeless> Rinchen: probably the wrong way, but I'd start with gpg_signing_command = gpg --id FOO (or whatever gpg takes as options)
<lifeless> Rinchen: I think that that will work
<ubotu> New bug: #181115 in bzr "bind and tags hang where push does not" [Undecided,New] https://launchpad.net/bugs/181115
<Rinchen> so lifeless, it seems that it was a gpg thing as you suspected.  Looks like seahorse does not actually include the "default-key" option in gpg.conf when you select it (bug maybe) so I had to manually specify that. By default it seems gpg uses the oldest private key to sign with (per a pipermail archive)
<lifeless> woo
<lifeless> 2 tests failing only (but inter foo is entirely absent)
<Peng> Oooh, I forgot that 'bzr branch' uses the branch format of the branch being branched from, not the repo.
<Peng> Seems I did have some older branches.
<ubotu> New bug: #181123 in bzr-cvsps-import "Tags import as branch tips, not tags" [Undecided,New] https://launchpad.net/bugs/181123
<ubotu> New bug: #181124 in bzr "short options for bzr ls" [Wishlist,Confirmed] https://launchpad.net/bugs/181124
<abentley> lifeless: No, I'm not actively planning to handle criss-cross inventory merging.  It strikes me that we could apply LCA merge, though.
<lifeless> I'll need to read up on lca merge
<mtaylor> 24605 mtaylor   18   0 1205m 976m 7928 D   19 32.5   9:06.60 bzr
<mtaylor> damn that's a lot of memory
<jelmer> what is it doing ?
<abentley> lifeless: One way to look at it is 3-way, extended to handle multiple bases.
<abentley> If it's really painless, then by all means, include annotation.
<abentley> lifeless: Bugs Everywhere and Cart are unfortunately abandoned now.
<mtaylor> jelmer: svn-import
<mtaylor> jelmer: copying revision 3341/6851
<mtaylor> :)
<jelmer> ah
<jelmer> mtaylor: you did see the link to the python-subversion memory leak fix?
<mtaylor> oh, no... is that what that is?
<jelmer> I think so
<mtaylor> ahhhhh. that would make sense
<jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
<jelmer> or the matching Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428755
<ubotu> Debian bug 428755 in python-subversion "bzr-svn: 'bzr push' consumes memory" [Important,Open]
<lifeless> abentley: oh, ok :(
<lifeless> abentley: I think InterRepository._same_model is the reason you can pull subtrees into rich roots
<abentley> Hrm.
<lifeless> it only looks at one of the two parameters
<abentley> I'm wondering whether our InterRepository approach is too much LBYL.
<abentley> If you look at what we did with diff, for example.
<jelmer> abentley: LBYL?
<lifeless> well it was intended to be simply a multimethod; the model stuff that has crept in adds confusion I think
<lifeless> look before you leap
<abentley> lifeless: But perhaps it would be nicer if it you just called interrepo.fetch() on all registered interrepos until it succeeded or you ran out.
<abentley> That way, we would have enough data to determine whether a fetch from 'subtrees' into 'rich-root' could succeed.
<lifeless> ah, I see
<lifeless> so nuke is compatible
<lifeless> and do a loop
<abentley> Right.
<lifeless> I don't think it would make a difference in this case; we need something that knows 'subtrees allowed/not allowed' and raises when it sees them
<lifeless> so one interrepository can do all rich-root variations that use the same inventory serialisation API
<lifeless> when do you start with Canonical ?
<abentley> A fetch from subtrees into rich-root could look for subtrees in the inventories it was fetching.
<abentley> lifeless: I start next week.  And I'll be in Sydney the week after.  Too bad I'll miss you.
<lifeless> right, and a fetch from subtrees into subtrees needs to look for subtrees in the inventories as well to fetch dependent data doesn't it ?
<abentley> Mmm.  Not sure.
<lifeless> so a InterSubTree parametereised with either "lambda x: raise NotSupported " or "queue a revision id to copy"
<abentley> I think that's right.
<abentley> The problem of fetching dependencies was one I had put off.
<lifeless> anyhow, I only noticed that as I refreshed my head on InterRepository to do this journalled inventory logic - I need to make sure that all the delta elements are fetched correctly injounralled->journalled, and that revisions are reserialised in journalled<->non-journalled
<abentley> injounralled->journalled ?
<lifeless> in (journalled->journalled)
<abentley> right.
<lifeless> a journalled inventory repository has inventory deltas rather than xml deltas
<lifeless> cool
<abentley> Are you doing unidirectional or bidirectional deltas?
<lifeless> minimal unidirectional with full entry contents included
<abentley> Also, you were asking about why we're including revision-ids in inventories.
<lifeless> that is we write out a new entry and nothing about the old state, and we also write out a line when a delete occurs
<abentley> jam could answer that better, but I believe it was a performance win.
<lifeless> I was having a brain-fart morning;
<lifeless> I'm pretty sure it was for the working tree basis cache
<lifeless> so that we didn't have to reserialise the XML
<lifeless> which is a bit bogus when you think about it (you can just prefix the repository xml with a revision id). But it doesn't matter anyhow, because I already had a version: field for the journal entry
<abentley> Sounds plausible.
<lifeless> so, I don't think this journal contents is necessarily optimal; I only claim its better than the xml delta style
<lifeless> in fact I may change it to only have the basename of the path
<lifeless> because the case where the exact pathname is interesting is insufficient to do things log like PATH or 'find PATH in history'
<lifeless> so it doesn't seem like a useful optimisation and it costs quite some duplicate text for the dirname of the path to be included.
<abentley> lifeless: Or to be really minimal, you could just include the paths of parents once.
<abentley> Since we have the parent-id already.
<lifeless> not quite sure what you mean there; how is that different from just the basename of the path ?
<abentley> I assume if you have three children of 'foo/bar', you would include 'foo/bar' three times.  Correct?
<lifeless> currently yes; it was moddelled on the python inv delta object
<abentley> Future: no?
<lifeless> Well like I say above I'm considerring dropping it back to just the basename
<lifeless> so foo/bar/baz and foo/bar/quux -> 'baz' and 'quux'
<abentley> The example I gave had just the basename
<abentley> I think we're probably in violent agreement.
 * lifeless is confused
<abentley> No, my bad.
<abentley> I was thinking dirname, not basename.
<lifeless> ah!
<abentley> Not enough sleep.
<abentley> So if the dirname was considered useful at all, a future format could include it only once.
<lifeless> e.g. on the dir itself
<fullermd> Sorta mtree-style-ish.
<lifeless> but that then prevents grep style matching
<abentley> The dir itself might be unchanged?
<abentley> Therfore not included in the delta.
<lifeless> well, I need to keep the stuff I'm working on paged in
<abentley> Okay, nm.
<lifeless> so I'm going to not chase this just now
<lifeless> but yes - iteration on the basic concept++
<abentley> What you've got already sounds quite useful.  I look forward to applying it to iter_changes.
<lifeless> cool
<lifeless> I don't think it will save 'load the full inventory' but it should drop it from loading 2 to loading 1 and using the delta
<lifeless> I think you can also do log -v well from it with some care
<abentley> Yes.  bidi is what will give us the ability to avoid the full inventory.
<lifeless> abentley: I think we need more than journalling to achieve that
<lifeless> abentley: but I may be wrong. I'm htinking about operations on children of renamed dirs.
<abentley> Well, path reconstitution is not actually needed for iter_changes.
<abentley> though it would be for generating an inventory delta.
<abentley> But we can sort it out later.
<lifeless> yah
<lifeless> I wonder if its time to write the 'tree at a time copier' again
<abentley> Likely.
<abentley> It's as old as the hills.
<lifeless> I thought we didn't have one
<lifeless> it got lost in the -> weave transition
<abentley> InterDifferingSerializers is a tree-at-a-time fetcher, if that's what you mean.
<lifeless> oh sweet
<lifeless> cause I need to fix:
<lifeless> BzrError: Corrupt repository, final inventory validator mismatch for robertc@robertcollins.net-20051005095108-6065fbd8e7d8617e, '0db02bfb8702b10a0df52ecc6ba89bb5aefd61c6' != '1132d23eb4e5ce1c73470259de6c84789a32adff'
<lifeless> (this format checks the sha1 on every inventory access)
<abentley> Ah.  Perhaps something is matching that shouldn't.
<lifeless> yah
<lifeless> :)
<lifeless> at least thats my current theory
<lifeless> erm no
<lifeless> there's a bug in that fetcher :)
<lifeless> it installs the inventory
<lifeless> but it doesn't capture the inventories sha1
#bzr 2008-01-08
<ubotu> New bug: #181143 in bzr "inventory sha1 is not checked during routine operation" [Undecided,New] https://launchpad.net/bugs/181143
<abentley> In xml5, those sha1s are not reliable, because there are two xml5 serializations.
<mtaylor> anybody have a problem with a little patch to allow the passing of a File() object in the output param of cmd_send._run() ?
<lifeless> abentley: we should _always_ have the sha1 in the revision and that of the inventory match within a given repo
<lifeless> abentley: if they don't, then  check and reconcile should allow correcting that / reporting on discrepancies
<lifeless> abentley: so what I ened is a InterDiffingSerializer that also does Model1To2 stuff
<lifeless> abentley: is _install_revisions used by bundles?
<abentley> Yes.
<lifeless> so I think we generate check errors from it
<lifeless> search for 'FIXME: TODO: The following loop *may* be overlapping/duplicate'
<abentley> Old bundles only.
<lifeless> oh, new bundles don't use it?
<abentley> They don't use it for file texts.
<abentley> Not sure about the rest, but I think not.
<lifeless> hmm, I think CommitBuilder may fit in there now
<abentley> For old bundles?
<abentley> I think Jelmer had something that used it.
<lifeless> heres what I'd like to do. I'd like to allow InterDiffereringSerializer to match (non-rich-root, rich-root|subtree)
<lifeless> and use CommitBuilder in install_revisions which will take care of the differences automatically
<lifeless> does that sound ok to you?
<abentley> Seems okay.
<lifeless> cool
<abentley> Wait,
<jelmer> abentley: I don't use install_revisions() anymore
<lifeless> did you see the iter_inventories patch?
<abentley> What about the tree_root knit?
<lifeless> abentley: commit builder abstracts that out
<abentley> Okay.
<lifeless> you add the root, and a rich root repository will add an entry; non rich ones will assert that the revision is unmodified etc
<abentley> What about Inventory.revision ?
<lifeless> thats the inventories creation id so set by the commit
<lifeless> IIUC
<abentley> When converting from plain to rich-root, we assume the root revision changes every commit.
<lifeless> right; the old tree has inv.root.revision == inv.revision
<lifeless> so the commit builder will see those revisions when writing to a rich root repo
<lifeless> I'm going to start a new isolated branch for this
<lifeless> I'll make sure there are tests
<abentley> Doesn't the commit builder have all sorts of clever logic determine the file's revision?
<lifeless> yes, thats what we're missing in install_revisions which causes it to generate bad file graphs
<lifeless> you're wondering if it will overwrite the information during conversion
<abentley> If the commit builder commits to a rich-root repo, won't it assume the root revision should not change?
<lifeless> yeah, I'll need to extend the api to be able to force this
<lifeless> which is fine, it'll still be cleaner I think
<mtaylor> jelmer: mtaylor@solace:~/src$ bzr svn-import --trees http://code.djangoproject.com/svn django
<mtaylor> bzr: ERROR: Not a branch: "http://code.djangoproject.com/svn/django/branches/queryset-refactor/".
<poolie> abentley, hi
<abentley> poolie: hi
<poolie> abentley, are you working at canonical now?
<abentley> No, next week.
<jelmer> mtaylor: You may want to remove the entry for django in ~/.bazaar/subversion.conf
<mtaylor> jelmer: really? what's that entry for?
<jelmer> remembers the branching scheme so it doesn't have to be recalculated each time you use bzr-svn
<mtaylor> ah
<mtaylor> how very, very weird
<jelmer> ?
<mtaylor> jelmer: I tried to do an svn-import of http://reviewboard.googlecode.com/svn/trunk/reviewboard
<mtaylor> and it "worked"
<mtaylor> except it left stuff out
<mtaylor> or
<jelmer> what sort of stuff did it leave out?
<mtaylor> directories and stuff
<mtaylor> the djblets dir for one
<jelmer> you would probably want to import the full repository
<jelmer> not just a part of it
<mtaylor> yeah... sorry. I meant... http://reviewboard.googlecode.com/svn
<mtaylor> (bad cut-n-paste)
<jelmer> where should djblets be?
<mtaylor> the trunk has one dir, reviewboard
<mtaylor> and djblets should be in that dir
<mtaylor> at least, it is when I do an svn co
<jelmer> I don
<jelmer> 't see it in the Svn webview
<jelmer> are you sure you subversion checkout is up to date?
<mtaylor> yeah - I didn't see it there either :)
<mtaylor> I did this:
<mtaylor> svn co http://reviewboard.googlecode.com/svn/trunk/ reviewboard-read-only
<mtaylor> ls reviewboard-read-only/reviewboard
<mtaylor> accounts      contrib       __init__.py  README                  settings.py
<mtaylor> AUTHORS       COPYING       iphone       reports                 templates
<mtaylor> autogen.sh    devserver.sh  m4           reviews                 test.py
<mtaylor> ChangeLog     diffviewer    Makefile.am  scmtools                urls.py
<mtaylor> conf          djblets       manage.py    server.sh               utils
<mtaylor> configure.ac  htdocs        NEWS         settings_local.py.tmpl  webapi
<mtaylor> which I find _exceptionally_ odd
<lifeless> externals perhaps ?
<jelmer> yup, externals
<jelmer> mtaylor: bzr-svn doesn't support externals yet
<mtaylor> aha
<mtaylor> stupid svn people and their externals :)
<lifeless> abentley: still around ?
<abentley> I can answer a quick one.
<lifeless> when we load a non rich roots inventory, is inv.root.revision set correctly?
<lifeless> that is, is it set == inv.revision
<abentley> I remember working on that, so I'd expect so.
<dlee> I know we don't yet have line-ending stuff in bzr, but is there any way to get CRLF line endings from cvsps-import, or is that strictly an issue of what cvsps itself puts out?  I think it might be in Bazaar territory because --use-cvs doesn't change anything, and without it,
<dlee> I think Bazaar uses direct RCS access.
<fullermd> It pretty much takes what comes out of the RCS files.
<dlee> ...and RCS includes in its spec (or at least CVS does) that line endings should be LF only.
<dlee> CVS converts per OS on checkout.
<dlee> Interestingly, I got expected behavior (OS-proper endings) using Tailor, but cvsps-import gave me LF-only everywhere.
<dlee> and Tailor missed all my CVS tags. :P
<fullermd> One guess is because tailor checks out the files into a tree to work on, while cvsps-import just captures the file versions from stdout.
<dlee> Hmm... but I'd think stdout would be OS-translated too... so is this even sensibly addressable in Bzr or cvsps-import, or would it have to be in cvsps?  Or somewhere else... maybe a cvsps wrapper that converts line endings--but that sounds dangerous without knowledge of file types etc...
<fullermd> cvsps just synthesizes the changesets.  cvs or co is used to get the file versions.
<dlee> My cvs checks out with CRLF though; this is why I'm surprised --use-cvs didn't help.
<fullermd> Yeah, but co'ing a dir tree doesn't necessarily give you the same thing as 'co -p'ing a file version to stdout.
<winzo_> I'm trying to capture bzr output test for use within a bash script. I've tried several things and googling proved fruitless. Anyone know what I'm missing?
<winzo_> text*
<dlee> I can test that anyway; it's a good start.  Thanks much. :)
<winzo_> i.e., echo " $( bzr update ) " > myfile
<dlee> (I have some 40 projects I want to talk my company into moving from CVS to Bazaar, and they're all in CVS; so the plan is to come up with a nice clean conversion plan, then pull it off, and then start demonstrating pros :)
<spiv> winzo_: just "bzr update > myfile", surely?
<winzo_> You'd think so. But it didn't work.
<winzo_> A newline char gets written, though. :?
<dlee> What command are you using for your test? (bzr command I mean)
<spiv> Possibly "bzr update > myfile 2>&1" then.
<spiv> (to capture stderr as well as stdout)
<dlee> that's where I was heading...
<winzo_> That was it! Looks like I was re-directing wrong. :D
<winzo_> Thanks guys!
<indu> how to install webserve
<dlee> fullermd:  cvs update -p produces CRLF here.  Does --use-cvs literally make cvsps-import run the cvs command on my path?
<fullermd> AFAIK.
<dlee> Filing a bug for lack of a better idea...
<indu> could some one please help in installing webserve
<lifeless> indu: If I can make a suggestion. Ask specific questions.
<lifeless> indu: e.g. 'When I XXX YYY happens'
<ubotu> New bug: #181161 in bzr-cvsps-import "Line endings go from CRLF to LF under Cygwin, but not with Tailor" [Undecided,New] https://launchpad.net/bugs/181161
<lifeless> dlee: have you tried without cygwin? cyginw does some file mode seting magic
<dlee> I don't happen to have a non-Cygwin cvsps, though I do have a non-cygwin cvs I think.
<indu> lifeless, i am not knowing the procedure of installing webserve
<indu> lifeless, i have seent he docs folder of the webserve source, where there is a README.txt file, which is giving information about how to configure webserve
<indu> which is to be done after the installation, of webserve, and no info about the installation procedure
<indu> its in python coding
<spiv> indu: the README.txt has a section titled "Install"
<indu> spiv, yeah, its in the last line of the README, I am sorry, i missed seeing it. thanks
<indu> spiv, but without knowing this, i have done the copying of the webserve into the plugins fodler
<indu> and then I have done the proper configurations also in the apache.conf file
<indu> then I started webserve, using #bzr webserve --port=9099 "Official repository" http://localhost:9099/bazaar/
<indu> now, when I am trying to access the http://localhost:9099/bazaar, its displaying nothing on the browser
<indu> Unbale to connect
<spiv> Running "bzr webserve ..." has no relation to Apache AFAICT.
<spiv> i.e. you run that command to run it as a standalone server.
<indu> spiv, now i have dont the all the explained configurations, and when i am accessing, through http://localhost/bazaar, my apache error.log is showing the mesage as
<indu> http://pastebin.com/m6e80c8b0
<spiv> indu: it sounds like you don't have bzrlib properly installed
<lifeless> woot, it pulls
<spiv> indu: oh actually, that looks like a bug in the webserve plugin
<spiv> indu: put "import bzrlib.commands" in the webserve plugin's __init__.py
<spiv> indu: or just change the line that says "import bzrlib" to say "import bzrlib.commands"
<indu> any idea about this error message
<dlee> If I do bzr send ... > outfile, then email outfile to a committer, (I) is this the best way to submit code changes where I can't commit/push, and (II) can the committer select among my (possibly multiple) commits in outfile easily and apply at will, in whole or in part?
<spiv> dlee: (why not just run "bzr send", and let it start the email client for you?)
<dlee> I'm afraid so far my emailings of this sort have just been typo fixes in comments, but I assume those are still of use.
<spiv> dlee: yes, that's a good way to give your changes to someone else
<dlee> Hehehe, good idea but this box isn't set up very well for that.  This is Windows+Cygwin without Windows mail or well-configured Cygwin SMTP... mea culpa :)
<spiv> dlee: they get all the revisions that you added, so they can do with them everything you can locally
<spiv> dlee: including examine individual revisions, etc.
<spiv> dlee: ah, I see :)
<indu> spiv, yeah, now i can see something in my browser, but an error message, saying section not found
<dlee> Cool...because one thing I just saw involves a misspelled class name, and the author may wish not to mess with that
<indu> where as I have the repositories in the approprate lcoation
<spiv> indu: I'd guess there's a problem with the configuration file for webserve, but I have no experience with that myself.
<spiv> indu: so I can't offer much help on that
<fullermd> Of course, if they cherrypick revs, you lose the identity.  But if upstream is in CVS anyway, it hardly matters...
<dlee> There must be a way to grab --mail-to from bzr log or somesuch though...
<spiv> fullermd: yeah, but "bzr send" doesn't make that situation any better or worse.
<dlee> Oh this is for Bazaar plugins actually.  I don't know Python (yet), so the best I can do so far is to send typo fixes while I read code and docs...
<fullermd> Yeah.  `send` is uninvolved in that part of the process.
<indu> anyone else there, who can help me in this please
<dlee> I read with a talking computer, and it seems to catch types of spellos that more easily escape the eye... if you type "Don't forget you hat," I'll catch it right quick; but if you type "Seems theirs a bug here," I won't...
<fullermd> Whereas that latter instantly grabs my eye and makes me want to beat the perpetrator with a 2x4   :p
<dlee> hehehe
<indu> hmm, there seem to be a mistake in the my webserve conf file, could some one please correct it, http://pastebin.ca/846269
<ubotu> New bug: #181165 in bzr-webserve ""import bzrlib" should be "import bzrlib.commands"" [Undecided,New] https://launchpad.net/bugs/181165
<spiv> indu: it would help to also tell people what the error you are getting is.
<indu> spiv, my error is on the browser only, and it has lot of details, i think i can take a screenshot and send, any site where I can upload the screenshots images
<indu> in simple, my Error messages on my browser says that ,, section not found: None
<indu> Section Not found
<indu> no one here, who can provide me help in webserve ?
<dlee> Spiv: fwiw, bzr send direct to email now works here--nicer indeed.  I may be the only Windows user using Mutt though....
<spiv> dlee: :)
<fullermd> Well, surely there's at least one other sensible Windows users in the wor...   no, you're probably right.
<dlee> fullermd :)
<dlee> fullermd: btw, I tried checking through cvs-import code, and now I wonder if subprocess.popen() is capable of being told something that might help with the line ending conversion issue--but that's a taller stack of stuff to paw through than I want to start tonight...
<fullermd> Well, that's waay over my head   :)
<dlee> Does the cvs-import guy come in here?
<fullermd> Oh, yes, he's in here most days.  But he's in my TZ; it's almost midnight now.
<fullermd> He's usually here during the day (say, 1500-2300Z).
<dlee> Nick?
<fullermd> jam or jam-laptop or some such.
<fullermd> The list would probably also be a good place to check.
<dlee> Since I submitted a bug on the cvsps-import line ending issue, if I do manage a code fix that works in my strange environment, would I be better to send it to Jam or somehow paste or attach it into the bug report?
<spiv> dlee: you can attach patches to bugs
<spiv> dlee: or even upload a branch to launchpad and link it to the bug.
<dlee> Ah, the former doesn't surprise me but I didn't spot how to do it; the latter is beyond me to date...
<dlee> but sounds cool
<jamesh> dlee: you can add attachments in followups to a bug report
<jamesh> we don't currently have a way to create an attachment when the bug is filed.
<dlee> jamesh: gotcha; explains how I missed it.
<mtaylor> jelmer: you around? is there any way to do an svn import do that svn tags show up as bzr tags and not bzr branches?
<fullermd> svn has tags?   ;)
<jamesh> fullermd: as much as they have branches ...
<indu> no help in webserve i can get here?
<lifeless> indu: you've been getting help; its a shame it hasn't been enough to sort it all out yet.
<lifeless> indu: I suggest mailing the list; goffredo reads the list and he knows all about webserve
<fullermd> lifeless: Oh, hey, it just mentally penetrated that you're fiddling with inventories...
<fullermd> lifeless: How amenable is our current setup and/or your work to referencing unchanged files?
<lifeless> fullermd: EPARSE
<mtaylor> is svn2bzr still in work? or has bzr-svn pretty much supplanted it?
<fullermd> lifeless: `bzr ci --unchanged -m'foo' asdf.c ; bzr log --limit=1 asdf.c (check for 'foo')`
<lifeless> fullermd: it won't record that
<lifeless> fullermd: a new version of asdf.c isn't recorded, nor does the metadata about it change.
<fullermd> Does it require major surgery to do so?
<lifeless> yes
<lifeless> whats the use case
<fullermd> Conversions, for one thing.  Forced commits are very common in the CVS world for making notes on files (updating incorrect commit messages, etc)
<fullermd> Losing that information would make 'log $FILE' misleading at best.
<fullermd> And with --unchanged existing in bzr, one can imagine doing similar things; if we need --unchanged, we can just as well need to reference files in it, and having 'log' not show those revs would be Wrong.
<lifeless> so two things
<lifeless> conversions
<lifeless> hmmm
<fullermd> Of course, the very thought of "high fidelity CVS conversion" is giggle-inducing.
<fullermd> But still.
<lifeless> I think this is worth raising; the conversion argument is not strong - because the upshot of that argument is being a usperset of everything, good bad and ugly
<fullermd> Just a thought; ISTM that it's something we otter be able to represent, so as long as we're rototilling inventory handling anyway it's a capability to bear in mind.
<lifeless> the argument about 'what is --unchanged for' is however really good
<lifeless> if --unchanged is to allow logging extra information, there's no good reason you can't tickle some files in passing
<lifeless> we can represent a new change in the per file graph in the current disk format
<lifeless> the surgey is in the commit code is all
<lifeless> and in UI, to diferentiate between 'selecting' and 'annotating'
<fullermd> 'k.  Should I file a bug, or open up a list discussion?
<lifeless> discussion i think
 * fullermd nods.
<fullermd> Good 'nuff.  Thanks.
<jelmer> mtaylor: No, bzr-svn doesn't support creating tags yet, that's an open bug.
<ignas> hi
<ignas> how do i release a lock on a launchpad repository ?
<ignas> i have lost the connection during the initial stage of a push
<LarstiQ> ignas: tried bzr break-lock <remote/url>
<ignas> thanks
<samiam> hi all
<samiam> quick question
<samiam> I was trying to install bzr v1.0 onto a ubuntu feisty install and I am getting the following error "Failed to fetch http://bazaar-vcs.org/releases/debs/feisty/./Packages.gz  MD5Sum mismatch"
<samiam> does anyone have an idea if it  is possible for me to fix this on my end or must I wait for changes at the bazaar site?
<samiam> there is the obvious alternative that I can install from source, but I liked being able to apt-get the newest release... it will significantly beat version .15 that I have now
<Odd_Bloke> samiam: What did you add to your sources.list?
<luks> I don't see the actual deb files for feisty there
<samiam> Odd_Bloke: deb http://bazaar-vcs.org/releases/debs/feisty ./
<luks> but you can use http://launchpad.net/~bzr/+archive which seems to have them
<samiam> I followed the instructions provided on http://bazaar-vcs.org/DistroDownloads
<samiam> thanks luks
<samiam> looks like getting it from launchpad works properly
<mtaylor> BAH! The link from bazaar-vcs.org should be changed to the PPA
<jelmer> mtaylor: Well, PPA doesn't build stuff for feisty and dapper yet afaik...
<elmo> jelmer: sure it does?
<elmo> oh, rather, PPA itself can
<elmo> the packaging would probably need altered to be able to build on all those
<mtaylor> jelmer: I see bzr packages for dapper-gutsy
<jelmer> elmo: oh, ok. when was that added?
<jelmer> elmo: last time we discussed this (a bit before the holidays iirc) PPA supported only gutsy and hardy
<elmo> jelmer: don't know actually, someone only pointed it out to me in the last week or so
<thumper> is there any way I can ask a branch what locks it has?
<Peng> thumper: I think 'bzr status -v' gives some information.
<thumper> Peng: ta
<thumper> Peng: it seems that status requires a working tree
<thumper> Peng: which I don't have
<statik> hi!
<statik> if I want to convert a subversion repository to bazaar
<Peng> thumper: Sorry, I meant info, not status.
<statik> and I have a lot of tags in my subversion repo (from every nightly build), what is the best way to get that tag info into bazaar without importing every single tag branch?
<thumper> Peng: oh, ok, it isn't showing anything about locks
<Peng> thumper: Even with -v?
<thumper> yeah
<thumper> morning statik
<statik> hey there thumper
<dlee> Ok I'm *sure* I'm missing the obvious this time, but... if I have 320 revs in my local branch but I need to undo just revision 313, how do I do it?  I'm used to applying what amounts to a reverse patch, then committing rev 321... but I've never done it in Bazaar.
<LeoNerd> You can merge it in reverse
<LeoNerd> bzr merge -r 313..312
<Peng> Might need to use: bzr merge -r 313..312 .
<Peng> (with the . at the end)
<dlee> Ah... I hadn't put the . for merge branch, so I was getting an error.  Why does "bzr merge -c313 ." say "all changes applied successfully" but appear to do nothing at all?  (Granted that was an experiment...)
<Odd_Bloke> dlee: Check 'bzr status'.
<dlee> Odd_Bloke:  I must be fine; "bzr status --versioned" is empty.
<dlee> ...and "bzr diff" is also empty.
<dlee> Peng: Worked, thanks.
<fullermd> dlee: '-c313' means '-r312..313', not '-r313..312'.  And it's expected to do nothing, since it's an attempt to merge something you already have.
<dlee> fullermd:  That was my guess, but I experimented to see if it would figure out (from having nothing to do otherwise) that I wanted to go the other way. :)  I was just surprised it said nothing about it, except to indicate success at doing nothing.
<dlee> Is there a shortcut for reversing just one revision?  I think subversion would do -C313.  That was confusing to me when I saw it, but I'm slipping Bazaar methods into a project hand-over report and making them look as easy as pie so people might start liking Bazaar as much as I do. :)
<dlee> -r313..312 is good enough otherwise.
<Peng> hg has a backout command.
<dlee> peng: Could be done pretty quick with a plugin I bet.
<Peng> Probably be done with an alias.
<Peng> What the heck?
<Peng> .bzr/repository.backup?
<lifeless> hmm, side effect of a failed upgrade most likely
<Peng> I didn't know anything other than '.bzr.backup' was used.
<Peng> I ran a 'find' and upgrade to pack-0.92 to upgrade branches a couple days ago.
<Peng> Repos were already updated.
<Peng> There was only a 'repository.backup' directory, no 'repository' directory.
<mtaylor> hey guys - given a MergeDirective - what's the best way to get a list of revisions contained within it
<Peng> And a .bzr.backup was created.
<mtaylor> I'm guessing I want to get deserialize the MergeDirective.bundle, right?
<lifeless> Peng: strange; care to file a bug with any info you can think of that might be relevant?
<Peng> Ok.
<Peng> Very little info though.
<mtaylor> ah... found it
<Peng> Bug 145812, perhaps?
<ubotu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] https://launchpad.net/bugs/145812
<lifeless> Peng: so the repository is not working at all ?
<Peng> I renamed it back to 'repository' and it's fine.
<poolfool> I have been using bzr under linux for a while now, I am now trying to get a National Instruments (NI) LabView (LV) project under revision control with bzr (1.0.0); my project directory has sub directories with whitespace (proj/a sub proj). This seems to cause problems when I try to branch.
<poolfool> I get the error "bzr: ERROR: Not a branch: "C:/Documents and .../Desktop/proj/a sub proj". what am I doing wrong? Does bzr on Microsoft Windows not handle whitespace as well?
<lifeless> it should
<GaryvdM> is "proj/a sub proj" the dir you are branching from, or to?
<poolfool> Just for a point of refrence, 'bzr branch "proj" "proj.a"' works fine ...
<poolfool> important ... note the ' " '
<poolfool> GaryvdM: branching from
<GaryvdM> And if you go into that dir, is there a hidden directory called .bzr?
<poolfool> GaryvdM: So ... on a linux machine what I think I would type is "bzr branch proj/a\ sub\ proj proj/a\ sub\ proj.b"
<Peng> Ah ah.
<Peng> I just checked .bzr.log.
<Peng> It is the bug I mentioned earlier.
<poolfool> GaryvdM: Under 'proj' there is a folder .bzr; under the folder 'proj' "bzr status" returns nothing. ie. every file in there (including 'a sub proj') are under bzr control.
<GaryvdM> on windows what you would type is: bzr branch "proj\a sub proj" "proj\ a sub proj.b"
<Peng> lifeless: Comment?
<GaryvdM> I think your branch is "proj" - not "proj\a sub proj"
<lifeless> Peng: what bug earlier ?
<Peng> Bug 145812.
<ubotu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] https://launchpad.net/bugs/145812
<Peng> You triaged it a few months ago. :)
<poolfool> GaryvdM: Yep ... I was trying to branch an individual sub directory in the project ... not the whole project. My Bad.
<Peng> Trivial to reproduce.
<Peng> bzr init --pack-0.92-subtree; bzr upgrade
<lifeless> ok
<lifeless> I have no browser right now, will check it later
<Peng> You don't have a browser open?
<lifeless> nope
<lifeless> performance testing
<lifeless> need the memory for cache
<Peng> Ah.
<Peng> With that 20-second commit I do with hg, when Firefox is really chewing RAM, it can take over a minute. :)
<lifeless> yah
<ubotu> New bug: #181367 in bzr "bzr update should work in a treeless bound branch" [Undecided,New] https://launchpad.net/bugs/181367
<poolie> good morning
<statik> hello! when I try to run bzr qcommit under gnome (ubuntu 7.10 gutsy), I get a window with no window decoration. When I run qtconfig, I get normal looking window decoration. Do I need to do anything special to make qbzr get window decoration?
<jelmer> statik: luks is the person you would want to talk to, when he's around
<statik> jelmer: ok, thanks
<statik> I did try just a very simple pyqt application, and I get window decoration
<statik> and I don't see any errors in ~/.bzr.log
<jelmer> lifeless: Now that PPA supports Dapper, Edgy and Feisty, do you have any plans to move the bazaar-vcs.org debian repo to PPA or would you rather keep it separate because of the signing?
<mtaylor> statik: the best way to fix that is to use pygtk
<statik> mtaylor: did you know qbzr already has the commit message save and restore in it?
<mtaylor> really?
<statik> yep
<mtaylor> SWEET
<statik> you'll need to modify it to handle per-file commit messages, but that should be not so hard
#bzr 2008-01-09
<asac> lifeless: fyi, http://paste.ubuntu.com/3387/
<asac> lifeless: local operations on that tree is now working well performance wise btw. thanks
<lifeless> asac: cool
<asac> lifeless: yeah ... but 25min is too long ... the 81M should be much faster. but maybe that lp
<asac> lifeless: wow ... i tried https://code. ... it just took 6 minutes. thats fair. so maybe it was indeed lp ssh server slowness
<lifeless> asac: its in pack format now ?
<asac> i used just bzr init with 1.1.0.dev.0
<asac> bzr info says: Standalone tree (format: pack-0.92)
<lifeless> yah
<ubotu> New bug: #181391 in bzr "model 1 to 2 conversion breaks revision sha1 validator" [High,Triaged] https://launchpad.net/bugs/181391
<lifeless> poolie: I'm off to buy groceries bbiab.
<poolie> k
<jelmer> lifeless: Now that PPA supports Dapper, Edgy and Feisty, do you have any plans to move the bazaar-vcs.org debian repo to PPA or would you rather keep it separate because of the signing?
<poolie> jelmer, i'd kind of like to do it in PPA, i think Robert has unresolved objections
<poolie> mainly that it's not signed, and cannot build on non-intel architectures (which we don't build now anyhow)
<poolie> iirc
<poolie> oh, also that there's more latency
<bignose_> I'm trying to 'rm' a file, and 'mv' another file into its place, as part of a single revision
<bignose> 'bzr rm foo'
<bignose> 'bzr mv bar foo'
<bignose> result: "Could not move bar => foo: foo is already versioned."
<bignose> but this is conceptually part of a single change. how can I achieve it without separate commits?
<spiv> bignose: works for me.  What version of bzr do you have?
<bignose> Bazaar (bzr) 1.0.0
<spiv> Hmm.  I'm using bzr.dev.
<spiv> bignose: works for me with 0.92 too.
<bignose> ahhh. I'm in a 'bzr shell'
<spiv> bignose: I see this result: http://rafb.net/p/rnDFwP86.html
<bignose> experimentation shows that 'rm' in the shell **doesn't* invoke 'bzr rm'
<bignose> why would that be?
<spiv> bignose: I think "rm" in the shell executes /usr/bin/rm
<spiv> (or rather /bin/rm...)
<spiv> bignose: it appears "bzr shell" from bzrtools special cases "rm" and "ls" to always use the system version rather than the bzr command.
<bignose> spiv: thanks. it's annoying, but I can at least see the reason now.
<lifeless> poolie: and that we can't poke and tweak it; its behind an automation barrier as opposed to an admin barrier
<mlh> poolie: would it be fair to say that you are the Designer of bazaar?
<mlh> because there's a message on http://thyrsus.com/lists/uvc-reviewers/2008-January somewhere
<mlh> that says that 'the designer of bzr was an Arch hacker' which is not really true as far as I know
<mlh> I'll find the exact url if you like
<mlh> lifeless: ^ also
<lifeless> is that a leading question?
<lifeless> uvc ?
<lifeless> anyhow, thats bogus
<mlh> er maybe
<mlh> esr's attempt to write a guide and history to version control systems
<lifeless> martin architected the overall initial design 2 years ago based on a review of arch/monotone/svn/cvs/some others
<mlh> bogus - that's what I though
<mlh> that's what I understood.  and esr should have been able to go over the sourcefrog blogs perfectly well on his own
<lifeless> bzr's current design only has a little resemblance to that first design, though the design -goals- have not changed.
<mlh> nod also
<lifeless> I was an Arch hacker; and I've had some influence on the design, as have Aaron Bentley and many others
<mlh> yes, and that's where I persume they get tat imperssion
<lifeless> I would label Martin Architect, not designer, to me it carries a less solitary-load-bearing-sole-responsibility thing
<mlh> but he has an obligation to write history acrruately if at all
<mlh> yeah architect, .. that's why I wrote Designer with a captial D :-)
<mlh> perhaps it's a nice goal to draw a narrative out of the histoy, but he(inevitably?) over simplifies
<mlh> Here's the link: http://thyrsus.com/lists/uvc-reviewers/2008-January/000023.html
<mlh> quote: bzr -- Designed and written by a former Arch hacker.
<mlh>  he's been taken to task for the other bits in that message but not that one
<mlh> I can folloow up if you don't care too
<AfC> bzr has been written by a great many people.
<mlh> oh I'mm well aware of the history of bzr.
<mlh> reading esr and -t's messages gived me indigestion
 * mlh feels woozy  - decides to go home
<AfC> Glancing at the commit history, it doesn't look like that will be a very interesting book. I'm sure it will be widely read, though {sigh}.
<dlee> Fwiw, I think bzr's history a bit interesting but its future far more so. :)  I may seem a bit overzealous, but I expect it will become king among the free VCS out there at some point.
<dlee> It just doesn't get in my way very often at all...
<fullermd> I sure would like to insert it into a place or two...
<dlee> fullermd: Was that to me or AfC?
<lifeless> mlh: please follow up
<fullermd> To your general thrust (though I rather doubt bzr will become king, or that there will be a king)
<Lo-lan-do> Hi all
<Lo-lan-do> What's the current recommended storage format for bzr if I want to use bzr-svn?
<dlee> Hehehe, well, I hesitated looking for a better word than "king," but I mean in the sense of being most widely preferred.
<fullermd> Yeah, I'm just not sure there will be one.  I'm pretty much certain there will never again be a VCS that owned the market like CVS did.  I'm not sure there will ever be any majority system.
<fog> Hi. I have a problem with bzr but maybe it is just me (and not bzr)
<fog> from last time I used it the "bundle" command disappeared and "send" doesn't produce anything.
<mwhudson> i think you can say send -o output.bundle can't you?
 * mwhudson checks
<fog> I'd like to get the last n revisions and bundle them but while "patch -rX" works, "send -rX" doesn't produce anything
<fog> just a header
<mwhudson> fog: yes, looks like it
<fog> mwhudson: yes, I tried send but it outputs just the header.
<fog> I can use diff (sorry, not patch) and produce a meaningful output but I can't put the same diff in a bundle using send.
<fog> :/
<fog> so, how can I use send to produce the "same content" of diff, but in a bundle?
<jamesh> fog: try "bzr send -r X..-1"
<jamesh> that will bundle the sequence of revisions from X to -1 (the head revision)
<jamesh> or "bzr bundle -r X..-1" even
<fog> ah.. it works.
<fog> jamesh: the help text about "-r" says to see revisionspec but revisionspec doesn't talk about "..". should't be better if the help explained that some commands take a range of revisions?
<fog> jamesh: btw, many thanks.
<astraw> Hi. A while ago, I exported my svn repo and used it as the start of a bzr branch, which I've been committing to. Now I want my svn history.
<jamesh> fog: that sounds like a bug
<astraw> I have successfully created a new bzr branch with all the svn history. How do I take all the revisions from my original bzr branch and append them to my new bzr branch?
<jamesh> astraw: perhaps try the bzr rebase plugin
<jamesh> it will let you apply a sequence of changes to an unrelated branch
<astraw> jamesh - thanks, that looks like what i want. i knew there had to be a way.
<astraw> hmm, rebase is giving me: "bzr: ERROR: Repository KnitRepository('file:///repo-with-recent-changes/.bzr/repository/') is not compatible with repository KnitRepository('file:///repo-newly-created-with-svn-history/.bzr/repository/')"
<astraw> This is the outcome of running: bzr rebase --dry-run /repo-newly-created-with-svn-history
<astraw> from the repo-with-recent-changes branch
<jamesh> astraw: what are the types of the two branches as reported by "bzr info"?
<astraw> jamesh: Standalone tree (format: dirstate) and Standalone tree (format: rich-root)
<astraw> (repo-newly-created-with-svn-history is the rich-root)
<jamesh> so the dirstate one is the old branch with your changes in it?
<astraw> yes.
<fog> mwhudson, jamesh: thank you for the help. cu.
<dlee> fog/jamesh: 'bzr help revisionspec' includes an example using '..' but, as fog says, does not actually discuss '..' directly.
<jamesh> astraw: I'd take a copy of the branch and run "bzr upgrade --format=rich-root" on it.
<fog> dlee: yes, I've seen the example after jamesh told me about .. :)
<jamesh> astraw: use the copy as the source for the rebase
<fog> dlee: but I missed it the first time. it is buried quite deep.
<Lo-lan-do> Is rich-root-pack still considered experimental in 1.1?
<fog> anyway go to go. thanks again.
<dato> Lo-lan-do: seems to be, still. a patch went in recently to mark pack-0.92 as non-experimental (!!!), so...
<dato> so it should be marked as non-experimental as well, given that rich-root is not experimental itself
<dato> Lo-lan-do: thanks for bringing up
<Lo-lan-do> I'm about to start a new repository, and since it's going to interact with SVN, I'm pondering about the best format.
<Lo-lan-do> A bzr branch from the SVN repo gives me a rich-root format, currently (1.0)
<Lo-lan-do> I'd like to switch to a packed format, but only if it's reasonable :-)
<dato> rich-root-pack is very reasonable :)
<Lo-lan-do> Cool.  I'll upgrade as soon as the branching is done then.  Thanks.
<astraw> how do I specify a "merge base revision" with rebase?
<dlee> I've been sticking to pack-0.92 because I thought all newer stuff was experimental.  I use bzr 1.0 and nothing older for projects I'm starting or transferring into it.  Should I switch now to something else for any reason (I know bzr-svn needs rich-root, but other than that...)?  I need not to risk data loss or problems my would-be Bazaar collaboraters could hit with newer formats,
<dlee> but if it's safe to use something newer already, it could save me a lot of upgrades later.
<dlee> I don't know what the -subtree variants of formats are either... I keep mixing that up with nested-tree, for which I wait anxiously. :)
<Lo-lan-do> From what I understood, the -subtree variants has been replaced by rich-root
<dato> -subtree is the format of the repository needed for the nested-tree functionality. as it is regarded as experimental, rich-root was created, which is afaik a very small (and safe) subset of -subtree, and it's enough for bzr-svn's purposes.
<dato> dlee, Lo-lan-do ^
<dlee> Lo-lan-do: I thought there was a rich-root-subtree, but I'm probably wrong; it's not listed in 'bzr help formats' (1.0) anyway.
<Lo-lan-do> Nested trees aren't implemented yet, right?
<dato> dlee: also, if you are not using bzr-svn, pack-0.92 should be enough for you, and afaik rich-root-pack would give you nothing (but if you fear upgrades, you could anyway upgrade)
<dato> Lo-lan-do: "work in progress TM" afaik
<Lo-lan-do> 'kay
<dlee> dato: I'm setting up (hopefully) to convert about 40 projects at work into Bazaar (if I can get everyone to use Bazaar), so this is more about picking a format to start with as part of that process.
<dlee> I think I am to where I just need to deal with a line ending issue (I discussed that in here last night I think), then the conversion process will be ready to test on a fairly large scale...
<jmhodges> i'm missing something obvious.  trying to do a bzr rspush to 'deploy@biggecko:/home/deploy/bzr/atelier-main'.  i can login into ssh via deploy@biggecko just find, and the bzr directory is there already. what am i missing?
<dato> AfC: markdown is pretty cool
<fullermd> I've never managed to get my interest piqued by any of that class of formats   :|
<AfC> dato: it's lovely to work in
<AfC> One can, of course, use anything ... including raw HTML for that matter;
<AfC> the point I was trying to encourage is that the front side web site can and should be in version control
<AfC> (ideally right alongside your source code, but that's up to you; but it works out nice when doc/* is right in the sources and in the website both)
<AfC> thus allowing the thing to be static or nearly so (thereby allowing things like Expire headers to be sent properly)
<AfC> not to mention WAY faster
<AfC> (wikis are always terribly slow for some reason)
<AfC> (and Bazaar's website is terrible in this regard)
<AfC> ... but I like Markdown because it is so unobtrusive;
<AfC> *especially* because it means the documentation can be nice 80 or so character wide text files readable in a terminal with less right there in your source tree;
<AfC> or rendered to HTML for the pretty factor online.
<AfC> It's all about having your cake and eating it too :)
<dato> anyhow, if ReST is used elsewhere for bazaar documentation, I doubt another markup format would be adopted
<AfC> dato: very likely.
<AfC> dato:  find ReST to be unnecessarily overweight, but that's a side issue
<AfC> dato: the main point was getting text based doc sources to drive the website but be in the source code or very near it
<AfC> (thereby allowing patches, review, etc but most of all a flow of information that allows anyone to contribute but still allows a measure of consistency and refinement)
<AfC> [The part I love is that your entire website can be a single 404 page: ask for BzrVsGit.html and, not finding such a page, the 404 handler checks to see if BzrVsGit.txt exists. It does, so it renders it. Done. Ta-da.
<AfC> (and you can cache if you like by writing BzrVsGit.html, but that's not necessary)
<abentley> AfC: Achitecturally, I see little difference between Moin-markup-in-moin-vcs and Markdown-in-Bazaar.
<AfC> abentley: the difference is that you access the whatever-in-$VCS directly, and the same [review and approval] paths apply.
<AfC> You can edit text files properly and then submit changes as patches, instead of working in random edits through some cumbersome web-app front end that has no quality control
<abentley> I don't think that's an improvement.
<abentley> I like the instant feedback of vcses.
<abentley> Of wikis, I should say.
<abentley> And the same people who review code also keep a close eye on the wiki.
<abentley> The pages that are coming in for the most criticism at the moment are BzrVsHg and BzrVsGit, and both were written by Ian, with tweaks from myself and others.
<AfC> abentley: well, you and I disagreeing about fundamentals is nothing new
<AfC> abentley: but the quality problems with the Bazaar website far far exceed those two pages.
<AfC> both in terms of content and performance.
<Lo-lan-do> Hi again.  Can I disable a plugin for just one invocation of bzr?  With a CLI parameter maybe?
<dato> not only one afaik
<abentley> Lo-lan-do: bzr --no-plugins
<Lo-lan-do> Hm.  It'll do.  Thanks :-)
<AfC> 'night all
<Lo-lan-do> Is it possible to store that in a branch-specific config file?
<abentley> Lo-lan-do: no
<abentley> Why do you want that?
<Lo-lan-do> Actually, in a lightweight-checkout-specific would be even better.  But I'll manage.
<Lo-lan-do> I have a bzr branch inside which I did an svn checkout of a subdirectory (debian/).
<Lo-lan-do> bzr commit debian/changelog complains that an assertion has failed, presumably because the svn checkout isn't rooted at the same point as the whole bzr branch.
<Lo-lan-do> Ignoring the bzr-svn plugin for operations seems to fix the problem for me.  I can live with --no-plugins :-)
<Lo-lan-do> But if there's a better way, by all means tell me about it :-)
<abentley> This sounds a lot like a bug in bzr-svn.  It should just try to commit to the svn repo.
<Lo-lan-do> I don't want it to.  I'm doing a one-way gateway.
<abentley> Yeah, but there definitely shouldn't be assertion failures.
<abentley> Maybe there should also be a way to flag an svn checkout so that bzr ignores it.
<abentley> Anyhow, if you could report the assertion failure against bzr and bzr-svn, that would be helpful.  We can sort out where the bug actually lies.
<Lo-lan-do> Will do
<abentley> I think causing .svn directories to be ignored is a bzr-svn issue, because presumably you'd need some metadata in the .svn directory to do that.
<abentley> But you can also control your plugins by setting your plugin directory.
<abentley> If you set the BZR_PLUGIN_PATH environment variable to a directory that doesn't contain bzr-svn, that should also disable it.
<dlee> Any way to push a conflicting (locally moved via --force) tag?
<luks> --overwrite
<dlee> The help for that looks dangerous... does that also erase stuff others might have pushed to the same repo?
<luks> it does not erase anything in the repository
<luks> but it does overwrite the branch history in case they are diverged
<dlee> I'm having trouble understanding the difference between overwriting history and erasing info (by overwriting it) in the repo.
<luks> repository is a storage for revision data, branch is a pointer to a revision in the repository
<luks> so if your remove branch is on rev2, and you are pushing branch that is on rev1 with --overwrite it will set the pointer to rev1
<luks> but rev2 is still in the repository
<luks> as far as I know, none of the current formats will remove any data from the repository on push
<luks> it's similar to uncommit locally, where you also only change the pointer
<dlee> Hmm... I thought uncommit removed data also.
<luks> no
<dlee> So I commit rev 320, uncommit it, and commit again.  I'll get a new 320 but have both 320's in the repo somehow, with one being inaccessible??
<dlee> (Disclosure:  I've not used uncommit :)
<luks> right
<luks> using revnos makes sense only in context of a branch
<luks> but yes
<dlee> Does anything then provide access to, or show, the first r320?
<luks> -r revid:<revision-id>
<dlee> Ah... you'd probably need the revision ID...
<dlee> right
<dlee> but without pulling it directly like that, you'd never see it again.
<luks> yep
<luks> unless somebody else pulled/merged the branch before uncommitting
<luks> but you probably won't use uncommit on a public branch
<dlee> Makes sense... now just trying to figure out what could be messed up if I push a tag move while others are pushing stuff up to the same repo...
<dlee> true
<luks> to the same branch or repository?
<dlee> branch
<luks> well, in any case, nothing
<luks> because push requires a lock
<dlee> hehe
<dlee> Actually... are branch, repo, and shared repo all three different things?  I know what a shared repo is pretty clearly.
<luks> bzr push complains about conflicting tags and not diverged branches, --overwrite should be quite safe thing to do
<luks> there is no technical difference between repo and shared repo
<dlee> yes, but that makes non-atomic the whole process:  push, get a tag conflict but not a diverge notice, push again but discover someone else just pushed inbetween...
<luks> hm, right
<dlee> I wonder if we should have a way to --force just tag settings?  Not fully thought out...
<dlee> I actually thought earlier about whether anyone would have a use for a strictly local type of tag that does not push, but again, not thought out.
<fog> hi *, I have a problem with bundle/merge without a central repository:
<fog> machine A initialize and repo and commit revno 1
<fog> machine B branch from machine A at revno 1
<fog> machine A gets 2 more commits (revno go to 3)
<fog> then we are disconnected and I want to pass changes 1..3 from A to B using a bundle
<fog> on A: bzr bundle -r1..3
<fog> on B: bzr merge thebundle
<fog> at this point merge fails and says that revision XXX (it is the id of revno 3 on A) can't be found in B
<fog> log on B show the correct id for revno 1 on A
<fog> so, why do it fails?
<fog> seems to me that B has evenrything needed to do the merge
<fog> there is something that I am missing?
<jamesh> as a bit of extra context, the resulting bundle appears to assume that the recipient has all the revisions passed in the revision spec
<jamesh> I am pretty sure that "bzr bundle-revisions -r X..Y ." used to produce a usable bundle for for a branch containing X
<jamesh> looking at the help text, I think it is a regression
<dato> the bundle probably does not include the revisions because the submit branch does contain them
<fog> dato: the bundle does not contain the bundle (but it contains the diff!)
<fog> I just did a test and if I branch locally at -r1 and then pass that as the argument, the bundle is correct
<dato> yep
<fog> let suppose my original branch is in XXX
<fog> bzr branch XXX -r 1 XXX.ouch
<fog> cd XXX
<fog> bzr bundle -r1..3 -> does not work
<fog> bzr bundle -r1..3 ../XXX.ouch -> works
<dato> (personally I believe that whenever -r is specified, those revisions ought to be included in the bundle metadata no matter what, but maybe abentley has a good reason why it shouldn't be like that)
<dato> abentley: ^
<dato> fog: correct
<fog> dato: ok, but ... why? I feel extremely stupid here and I just don't understand why I need an "extra" branch to generate the bundle.
<dato> fog: abentley would be the person with the canonical answers here. the idea is that you generate a bundle in order to apply it to some target branch (the "submit branch"), and not as a means of arbitrarily bundling up revisions from the repository
<dato> personally, what I said above about -r being specified, but I cannot do more, I'm afraid
<fog> dato: ok, so the new question is "how do I arbitrarily bundle up revisions from the repository"?
<fog> because creating a new branch every time I want to send something to a collegue is inelegant (it is cheap, ok)
<radix> you shouldn't need an extra branch, you should already *have* an extra branch :)
<radix> I'm not sure exactly of your use case here, but generally, if you're developing each feature or bugfix (or whatever concrete change) in its own branch, then things work out nicely
<fog> radix: why should I have the branch my colleague is working on?
<dato> fog: how do you know which revisions you have to send?
<radix> I don't know what you mean by that
<jamesh> fog: I often keep copies of branches I need to access when offline
<jamesh> fog: given the setup you described, you are effectively offline from your colleague so it could be useful to have a local mirror
<jamesh> (for more than just this case, which I consider a bug)
<fog> dato: we keep in touch by email and usually is just the last one.
<fog> jamesh: yes; I think this is the best approach
<fog> dato: it is something like "I fixed this bug, merge now istead of tomorrow when we're togheter at the office"
<dato> fog: *personally* I'd just publish my branch somewhere, and have them pull from there. maybe in a private server over sftp if the code is not public.
<dato> food time, bbl
<fog> anyway, I understand why it works that way.
<fog> thank you everybody.
<jelmer> dlee: yeah, pack-0.92 would be the best choice. I think it's also the default now
<Lo-lan-do> Hi jelmer
<jelmer> hey Lo-lan-do
<Lo-lan-do> I suppose you've seen my latest bug reports? :-)
<Lo-lan-do> There's no hurry, really, I just didn't want to forget about them.
<jelmer> yup
<jelmer> the first one's already closed
<fog> jamesh, dato: ok, everything is working. thanks again.
<dlee> jelmer: thanks
<ubotu> New bug: #181520 in bzr "bzr log FILE don't show revisions where file was removed" [Undecided,New] https://launchpad.net/bugs/181520
<dlee> Verification of my understanding of where nested-trees are going:  If I now (in pack-092) create a branch "proj" that contains subdirs "proj/a" and "proj/b," can I (when nested-tree comes out) upgrade my branch and then do something like "bzr co (path)/proj/a" to get just the "a" part in its own branch?
<dlee> Planning project layouts here...
<jelmer> dlee: that's partial checkouts
<jelmer> dlee: nested trees would be the ability to add one branch to another other or "upgrade" a directory in a branch to a branch
<dlee> What's the status of partial checkouts then?
<jelmer> don't think there's anybody working on them at the moment
<dlee> Scenario (hopefully not summarized beyond comprehensibility):  We do development in an environment where it is sometimes advantageous to have a "live" checkout--one in a directory of files managed (or partly managed) by a running program.  To do this requires that there be no directory names/levels above the files:
<dlee> In my example, I would need .bzr to be in the folder with the files.  It's fine to check it out as "a," but then I'd move the files and .bzr to where the live system is.  We do this so the VCS can catch changes made from GUI screens to config files etc. among other reasons.
<dlee> CVS and Svn support this, though maybe not by design so much as happenstance.
<jelmer> you may be able to work around it a bit using nested trees, but what you really what (as I understand it) is support for partial checkouts
<jelmer> probably best to bring it up on the mailing list, I'm not sure what the plans in this area are
<dato> dlee: so proj/a and proj/b really belong in the same branch?
<dlee> So a determining question:  If my branch is (as above) proj with proj/a, proj/b, etc., is there now (or do you think there soon will be) a way for me to arrange that "bzr commit ..." can be issued from a dir containing proj/a's files but without requring that the folder be named something/a or proj/a?
<dlee> We do work for many companies, and the standard here is to make (in CVS now) a dir for each company.  Most of those are just one project, but some contain several.
<dlee> Often, the code for different projects for one company *are* related or share common components.  We do accessibility work, and the code is mostly scripts for a product called JAWS (http://www.freedomscientific.com).
<jelmer> dlee: I don't think there is a way to do that at the moment
<jelmer> dlee: There will be a way to do that with nested trees because you could make each company's directory a separate branch
<dlee> I figured that, but I also figured it was soon coming... looks like I may have to rethink a couple plans. :)
<jelmer> the code is there, but it's still experimental
<jelmer> and a couple of tests for it are still broken
<jelmer> s/broken/not passing/
<jelmer> I'm not sure how much it is to get those to pass
<jelmer> LarstiQ: ping
<dlee> Sample structure, each dir of which should allow checkout: co1 (one proj so no subdivision), co2, co3, co3/a, co3/b ...  (co3 AND co3/a and co3/b should be checkoutable if possible)
<dlee> If not checkoutable, as I said, at least we'd want a way to go "cd co3/b; mv * (including .bzr) (live path); cd (live path); (work on stuff); bzr commit ..."
<dlee> I'll need to assess how many people besides me really do this I guess. :)  It may be mostly me...
<Stavros> I want to version my various system config files, but i imagine making a repository at the root would not be advised, correct?
<dlee> I don't see a problem with that if you don't do 'bzr add' and scan the entire filesystem into your repo. :)  But I'm assuming things like "bzr commit" (without filenames) will *not* scan the whole fs... I think I'll experiment with this myself.
<Stavros> dlee: doesn't it search the whole fs when you do a status/commit though?
<Stavros> for unknown/unversioned files?
<dlee> I'm new enough to Bazaar not to be sure of this yet... but I do get an error on 'bzr init' in /
<Stavros> did you run as superuser? :P
<Stavros> i think it'll scan everything though, i wouldn't try it :)
<dlee> Yes, and I got this on bzr init:  bzr: ERROR: Transport error: rrno 21] Is a directory: '/' rrno 21] Is a directory: '/'
<Stavros> haha, wow
<Stavros> sounds like a bug
<Stavros> i don't think anyone expected anyone to do that :P
<dlee> I have a small FreeBSD system here; if it scans the whole box, all that happens is my mail gets slow :)
<Stavros> ah, okay then :p
<dlee> Workaround:  cd /tmp; bzr init; mv .bzr ..
<dlee> I'll probably file a bug on the above error, though I doubt a lot of people are inconvenienced by this one.  Certainly a corner case :)
<Stavros> i'd say :p
<dlee> To your original question:  All else I'd say is to watch those perms... you pull a file full of passwords into a repo, beware who else can read it...
<Stavros> ah, noone will, but i am still afraid that it'll scan the whole system
<ricardokirkner> hi. I just found out that bazaar tracks changes in the execute bit of the files. Just out of curiosity, is there any way I could tell bzr to ignore that bit on certain files?
<ricardokirkner> or, is there a way to see in what what did the permissions change?
<jelmer> ricardokirkner: atm you can only ignore /all/ changes on a file
<jelmer> ricardokirkner: bzr log -v will show a "*" next to the file
<jelmer> whenever the execute bit changes
<LarstiQ> jelmer: pong
<luisbg> a bzr push to launchpad got cut midway because I lost the internet connection, now I'm trying to push again and it tells me it can't create because it already exists
<luisbg>  how do I fix this?
<luisbg>  bzr: ERROR: Can't rename ... already exists
<jelmer> LarstiQ: Was just wondering whether there was anybody workin on nested trees atm
<jelmer> LarstiQ: Also, are you going to the sprint?
<LarstiQ> jelmer: I don't know.
<LarstiQ> (on both accounts)
<jelmer> k
<Peng> luisbg: bzr break-lock $URL
<LarstiQ> jelmer: I'd like to, but atm I'm not really contributing anything.
<luisbg> Peng, sorry for the hazzle but what should the $URL be?
<luisbg> the push location? going to try :)
<luisbg> Peng, thanks a lot!!!
<luisbg> :)
<jelmer> LarstiQ: I still have time for the occasional bzr-svn patch, but shallow branches are still on my list :-/
<Peng> Uhm, how do I reverse a revision?
<jelmer> peng: like uncommit?
<jelmer> or commit the reverse of it?
<Peng> Latter.
<Peng> "bzr merge -r 10..9 .", right?
<Peng> It's doing nothing.
<jelmer> yep
<jelmer> and commit
<Peng> Well it's not doing anything.
<Peng> It says "All changes applied successfully." but doesn't change a thing.
<jelmer> bzr st doesn't show anything either?
<Peng> Correct.
<jelmer> does not specifying "." change anything?
<jelmer> it shouldn't, I think, but I never specify .
<LeoNerd> Try   bzr di -r 10..9    first, to see if that revision actually has any changes
<LeoNerd> It's possible to make empty commits
<ubotu> New bug: #181585 in bzr "bzr push --create-prefix sftp:// crashes" [Undecided,New] https://launchpad.net/bugs/181585
<Peng> Oops, forgot about this.
<Peng> jelmer: I dunno. It contacts the server.
<Peng> LeoNerd: It added a few files.
<Peng> jelmer: Yeah, that worked.
<Peng> Why?
<jelmer> re
<Peng> re?
<jelmer> with a path means a cherrypick I think
<Peng> Um.
<Peng> So?
<Peng> Of course it's a cherrypick.
<jelmer> no, it's an inverse cherrypick
<jelmer> I'm not trying to justify it, it is a bug.
<jelmer> there are probably two codepaths
<jelmer> one that works on a part of the tree (when a path is specified)
<jelmer> and one that works on the full tree (when no path is specified)
<dato> well, without a path
<dato> the -r argument refers to the remote/parent location, ain't it so?
<jelmer> yes, but in the root of the branch, "." does change the meaning
<dato> jelmer: ah
<dato> jelmer: I thought it just meant "this branch", at least for merge
<jelmer> sorry
<jelmer> I meant *does not* change the meaning
<jelmer> bad typo
<Peng> What did I miss?
<Peng> Last I saw was "the -r argument refers to the remote/parent location, ain't it so?".
<dlee> My experience is that "." is required for this sort of backout "merg":  "bzr merge -r10..9" gives me an error, but "bzr merge -r10..9 ." seems to work.
<Peng> Yeah, and just now for me, . did nothing and no-. worked.
<dlee> I'm assuming that "bzr merge -r10..9 ." is *the* way to reverse a commit so I can commit it again; I discussed this recently in here actually.  If there's a better way, I'm all ears.  "cherry pick" sounds bad to me now because of it messing with merges in general, but I'm not sure it's a problem for this case.
<Peng> (but no-. contacted the server)
<Peng> FWIW, hg has a "backout" command to do it. It also makes the new revision a child of the old one.
<dlee> Peng: Um...?  Interesting... so periodless reversals can work... (files in the "unsolved mysteries" corner of the brain :)
<Peng> Works fine in a simple test branch.
<dato> I insist that if it works without the dot, it must be because you have a parent where the revision you specified with -r is the revision you want to back out
<dato> as for why it won't work with the dot, I agree that'd be a mystery
<pygi> hey poolie
<poolie> hello
<lifeless> dlee: its documented in bzr help merge I think ;)
<pygi> poolie, nice to see sprint announced :)
<poolie> :)
<pygi> I was just about to mail you to ask you about the idea I had, and sponsorship
<poolie> i hope you can come
<poolie> do you want to tell me now?
<pygi> well, sure
<pygi> basically I wanted to work on a Personal Revision Control for Gedit
<pygi> So you can commit regular milestones of your documents, and put comments on each of them
<pygi> ofcourse, all that powered by bzr :)
<pygi> poolie, how bad is idea? :P
<dlee> lifeless:  Which thing are you saying is documented there?
<lifeless> merge to reverse commits
<dlee> Uh oh, ok :)
<radix> it depends if the commit you want to reverse and re-commit later is a merge... if it is, things are more complicated
<dlee> I'm not seeing it there.  Am I just missing it, or is it in .dev?
<dato> I don't see it either
<Peng> Nor do I.
<lifeless> huh, its not explicit but its there
<lifeless> I guess adding an example of a negative range will help
<lifeless> file a bug or a patch please :)
<dlee> I might get an rtfm-like answer to this, because I know I haven't looked hard enough yet, but... if there's a quick answer, what do I do to get the right branch for submitting Bazaar patches, and then what's the best way to submit them?  If this is easy to find, I won't be offended by the rtfm-like answer either...just looking to help out between other projects
<dato> b get  bzr.dev; bzr branch bzr.dev bzr.yourfeature; hack & commit; bzr send bazaar@lists.canonical.com
<dlee> I've seen lp: URLs, but so far I've just pulled plugins via the http: URLs on the Launchpad page.  I think bzr.dev or bazaar.dev is the dev branch name...
<dato> the location of bzr.dev should be mentioned in the downloading page or so (it's not a lp url)
<dlee> ok thanks
<dlee> Ah, an example of the earlier discussion of "get a local copy of the branch"... I've been doing bzr get; hack and commit; bzr send ... and it's worked.  Then bzr pull when I'm informed of an update.  Not sure why the extra branch is better; might have to reread the earlier discussion.
<dfoerster> Hi. Can anyone help how to debug bzr? I once read about an env variable to drop into a python console on errors. Does this still exist?
<jelmer> dfoerster: yep, that's BZR_PDB=1
<Peng> Also, .bzr.log and the various -D arguments are helpful.
<dfoerster> jelmer: thx! I just reopened the bug report about the bzr-svn unicode error. Can't find any trace you applied my patch.
<dfoerster> jelmer: fyi: I just tried to checkout a 1gig svn repository using bzr-svn and bzr got killed after using more than 80% of the 4Gb(!) memory.
<jelmer> dfoerster: there is a memory leak in the python subversion bindings
<jelmer> it has been fixed recently, but there are no packages with the fix yet
<jelmer> see Subversion issue 3052
<dfoerster> alright, that's good to know
#bzr 2008-01-10
<fullermd> Sheesh, it's quiet today.  Did I miss a memo about a picnic?
<quik_> hey folks
<quik_> if `bzr break-lock` isn't breaking the lock set yesterday.. what does one do?
<Peng> quik_: Are you running it on the URL of the locked branch?
<quik_> eh?
<Peng> quik_: Are you trying to break the lock on your local branch or the server you push to or what?
<quik_> the server I want to push to
<Peng> quik_: Does "bzr break-lock" prompt you about the lock or do nothing?
<quik_> seemingly, nothing
<Peng> quik_: You need to pass it the URL of the branch. "bzr break-lock sftp://..." or whatever.
<quik_> ah right
<Peng> :)
<quik_> thanks Peng
<Peng> You're welcome. :)
<jmhodges> hey, i can't bzr rspush to, for instance, deploy@foobar:~/thing. it tells me its not a branch or empty directory.  however, i have previously bzr pushed to that same directory.  is this a problem with the macports install of bzr and bzrtools or am i missing something?
<fullermd> Yes   :)
<fullermd> I have no real knowledge of the domain.  But I have a hard time picturing a way the install could be horked up, and it would work well enough to run, but be broken enough to look in the wrong place.
<fullermd> You sure you're not accidentally push'ing instead of rspush'ing?
<lifeless> jmhodges: what does ls -l of that directory show ?
<jmhodges> lifeless: not the place for unix quesions. this is #bzr
<jmhodges> lifeless: the #linux or #bsd or whatever you're on :)
<jmhodges> s/the/try/
<lifeless> jmhodges: also rspush is very old; you may prefer push + jam's post-push rsync plugin
<lifeless> jmhodges: I'm helping you debug it, but whatever.
<jmhodges> lifeless: jesus i'm sorry i misread
<lifeless> jmhodges: I'm one of the core authors of bzr.
<lifeless> jmhodges: still, I meant 'ls -al'
<jmhodges> lifeless: i thought you asked me what ls -l always does
<jmhodges> lifeless: like a newbie asking a question about ls
<lifeless> heh
<jmhodges> lifeless: i was like "wtf? havnt i seen this guy here before?"
<jmhodges> sorry
<jmhodges> one sec
<jmhodges> lifeless: its just .bzr
<lifeless> ok
<jmhodges> lifeless: from the pushes i did before
<lifeless> cat .bzr/branch-format, and .bzr/repository/format
<jmhodges> lifeless: locally or in the remote?
<lifeless> in the remote
<jmhodges> branch-format: Bazaar-NG meta directory, format 1   and format: Bazaar pack repository format 1 (needs bzr 0.92)
<jmhodges> that looks.. wrong somehow
<jmhodges> bzr --version says "Bazaar (bzr) 1.0.0"
<lifeless> ok, thats all good
<jmhodges> yay
<lifeless> the most likely thing then is that the path you are giving is not resolving correctly; could you try an absolute path ?
<lifeless> deploy@foobar:/path/to/thing
 * jmhodges nods
<jmhodges> one sec, need to ci some changes
<jmhodges> bzr rspush deploy@biggecko:/home/deploy/bzr/atelier-main # => bzr: ERROR: Remote location is not a bzr branch (or empty directory)
<jmhodges> lifeless: ^
<jmhodges> lifeless: again, sorry for being a jerk earlier.  i blame the couple of hours of sleep i've been getting for the past week and my own inattention.
<lifeless> interesting
<fullermd> Does rspush stuff anything in .bzr.log?
<lifeless> forget about it
<lifeless> jmhodges: I really recommend you try jam's plugin instead of rspush
<lifeless> jmhodges: it ssh's in and runs bzr update
<jmhodges> lifeless: jams plugin?
<jmhodges> i've been out of bzr for too long
 * jmhodges googles
<fullermd> push-and-update, I think.
<fullermd> Something like that.
<jmhodges> fullermd: that's it
<jmhodges> cool.  i'm assuming then that speed gains of rspush aren't worth other problems that i dont know about (other than "it not working")?
<lifeless> oh, rspush is likely slower
<fullermd> Actually, with packs, the speed gains of rspush can become very negative.
<jmhodges> ohhh
<jmhodges> thanks!
<jmhodges> i'll just grab it out of trunk then.  thanks again
<jmhodges> hm.. it pushes fine, and the command shows up in `help commands` but bzr push doesn't "do what i expected" or does it really require running `bzr push-and-update` ?
<jmhodges> weird
<fullermd> Probably, if that shows up in the command list.
<lifeless> try bzr help push-and-update :)
<jmhodges> natch.  for some reason, i thought it "overwrote" push
<Laurens_S> Hello, is there someone here who has experience using bzr 1.0, with bzr+ssh on windows? I can't seem to get it to work. sftp works fine, but I'd like the speedimprovement of bzr+ssh which I've seen in linux
<spiv> Laurens_S: what problem are you having?
<Laurens_S> this is the error I get:
<Laurens_S> (reproducing error.....)
<Laurens_S> Z:\src>bzr log bzr+ssh://username@server/full/path
<Laurens_S> Connected (version 2.0, client OpenSSH_3.8.1p1)
<Laurens_S> SSH username@server password:
<Laurens_S> Authentication (password) successful!
<Laurens_S> Secsh channel 1 opened.
<Laurens_S> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<Laurens_S> Z:\src\>
<Laurens_S> I tried -Dhpss, didn't show anything more
<spiv> Laurens_S: -Dhpss puts more information in the .bzr.log file
<Laurens_S> ah :)
<Laurens_S> I'll try again
<spiv> ("bzr version" should report the location of that file)
<spiv> So, put the contents of the log file on pastebin.com
<Laurens_S> ah, I finally figured it out:
<spiv> I'm guessing it's something wrong on the server side, perhaps "bzr" is not on the PATH?
<Laurens_S> yes, that was indeed the case
<spiv> Heh, lucky guess :)
<Laurens_S> I set BZR_REMOTE_PATH to the correct location now
<Laurens_S> I thought I did that, but SET revealed that I messed up :
<spiv> Ah, right.
<Laurens_S> zbr_remote_path=/home/ls/local/bin/bzr is not really the same as BZR_REMOTE_PATH :)
<spiv> heh.
<Laurens_S> well, thanks for helping out :)
<spiv> You're welcome :)
<Laurens_S> now it turns out I forgot to do a bzr bind, bzr commit before leaving the house :)
<Laurens_S> anyway, thanks again, and have a good day y'all :) Loving bzr!
<Kinnison> lifeless: Has anyone come up with the answer for you for the traffic shaping?
<Kinnison> lifeless: If not, my recommendation is to use 'tc' but it's arcane and confusing, even for people who already know how to use it
<gus> I broke my branch :(
<gus> anyone know what this means:
<AfC> Try using gun tape. That'll fix anything
<gus> % bzr commit
<gus> bzr: ERROR: Cannot commit to branch BzrBranch6('file:///home/gus/debian/libapache-sessionx-perl/debian/'). It is bound to BzrBranch6('sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/'), which is bound to sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/.
<gus>  
<gus> its not real informative
<AfC> gus: Sounds like you don't have write permissions on the target branch, but I assume this used to work for you?
<gus> yes
<AfC> gus: anyone else committing to this branch?
<gus> it was a lightweight checkout, but I removed that and did a heavyweight checkout
<gus> nope, its all me
<fullermd> Er.  It's recursive.
<AfC> gus:  (ie, beware debian style group-per-user nonsense which can result in various users trampling permissions in a repo)
<gus> afc: its my laptop and home desktop - i don't think there are other users here
<fullermd> You've got a branch bound to itself.  That kinda doesn't work...
<AfC> gus: and as another aside, any particular reason you're using a bound branch ("checkout") instead of a full power branch?
<gus> I don't know, I'm not really a power bzr user
<Kinnison> gus: log onto mongrel, cd into /home/gus/archives/libapache-sessionx-perl/debian/
<Kinnison> gus: type bzr unbind
<Kinnison> gus then try again
<Kinnison> gus: As fullermd says, your remote branch is bound to itself, which is the complaint
<gus> works fine
<gus> interesting
<gus> before the unbind, it said this:
<gus> % bzr info
<gus> Repository bound branch (format: dirstate-tags)
<gus> Location:
<gus>   shared repository: /home/gus/archives/libapache-sessionx-perl
<gus>   repository branch: .
<gus>  
<gus> Related branches:
<gus>     push branch:
<gus>   parent branch: /home/gus/archives/libapache-sessionx-perl/upstream
<gus>  
<gus> where's the bit that tells me where its bound to?
<Kinnison> gus: oddness, it doesn't specifically say it was
<Kinnison> it should say checkout of branch: .....
<Kinnison> but then again, it was bound to itself, so who know how odd it could have gotten
<fullermd> My checkouts say "Repository checkout (format: dirstate-tags)"
<Kinnison> gus: fyi, in future, please use a pastebin like pastebin.ca or rafb.net/paste/ for anything more than a line or two
<gus> meh. I haven't touched these for ages, perhaps I typed something dumb once ages ago
<gus> kinnison: yep, sorry I'm being lazy.  me--
<fullermd> What version of bzr are you running?
<Kinnison> fullermd: oh true, repos will say that
<Kinnison> gus: and it does say "Repository bound branch" at the top
<gus> I now have bzr 1.0 at both ends, but these repositories were created / last-modified by a much older bzr version (I couldn't tell you how old)
<gus> anyway, thanks.  I can pretend I'm still an active debian developer now.  ;)
<Kinnison> If you have 1.0, consider using pack format for faster operation (make backups first obv.)
<Kinnison> I've found pack to be much faster when working with remotely bound branches
<Kinnison> But then again, I am odd :-)
<gus> heh.
<gus> as an aside: I had lots of trouble finding a way to convert a lightweight checkout into a heavyweight.  Is there some way of doing that 'in place'?
<fullermd> I think reconfig can do that.
<fullermd> At least in recent versions.
<gus> didn't seem to (at least in 1.0)
<fullermd> It's got --checkout in 1.0...
<gus> right, but both heavyweight and lightweight checkouts are checkouts, right?
<gus> or have I confused some terminology somewhere
<gus> I guess I want a bound branch or something
<fullermd> Unqualified 'checkout' implies heavyweight.
<gus> ah ok.  I'll give that a go next time.
<i386> lifeless: ping
<dgl_> hi, where can I find something really useful about bzr? I guess documentation at http://bazaar-vcs.org are not very clear.
<dato> dgl_: try http://doc.bazaar-vcs.org/
<dgl_> dato: I've already been there, sorry about that but I really don't think bzr has a complete documentation that can explain it at all .
<dato> explain it all in what sense?
<dato> what all? using should be well covered by http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<dato> usage
<dgl_> dato: I've been svn user since a couple of years ago and it has a clear workflow description. I know bzr has a lot of possible workflows, but none of them are really explained.
<dato> not really explained *where*? I haven't read the user guide myself, but the table of contents *hints* like as if they are explained there
<dgl_> dato: I've read it, it just superficially describes some workflows.
<luks> anything in particular that you think is missing there?
<dgl_> dato: I guess, as svn user, learn decentralized workflows is a little hard.
<dato> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style has the very basics, but honestly, there's not *much* more
<dgl_> dato: and there are some concepts that works little different, like branches, where in svn is just a copy
<luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch
<dato> dgl_: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#concepts
<dato> oh, what luks says is better
<dato> but using DAG in that section, eek
 * fullermd finds copies a buttload harder to understand.
<dgl_> gutsy uses bzr 0.9 and my local doc are a little bit smaller
<fullermd> 0.9?!
<dato> 0.90
<dato> dgl_: the docs got *really* polished for 1.0
<fullermd> Jeez.  Don't DO that to my poor brain...
<dgl_> sorry 0.90
<dato> dgl_: if you could read or download the online versions, I think it'd be very helpful
<dato> dgl_: most of it if not all will apply
<dgl_> dato: I'll read online version
<dato> great
<dgl_> dato: maybe I'll do some pinning to get 1.0
<dato> there ought to be backports for gutsy in bazaar-vcs.org/releases/debs
<zurgutt> Hi folks.  Is there gui for bzr, or some ide/editor with integration?
<dgl_> olive
<dgl_> zurgutt: olive is a gui for bzr
<zurgutt> thanks dgl
<smagoun> We have a bzr repository on a server. I'm interested in running
<smagoun> a script whenever someone pushes to that repo. Is there an easy way to do that?
<smagoun> (I want to run the script on the server side, and ideally don't want to install a plugin on every developer workstation)
<mwh_> well
<mwh_> if you're pushing over a dumb transport that sounds kinda hard
<smagoun> mwh_: I was afraid someone would say that. Polling the repo is the obvious solution then?
<mwh_> if it's bzr+ssh only then something might be possible
<mwh_> but, hm, probably not easy
<ndim> Meh. Google for "git to bzr conversion" and the first hit is titled "How To Convert Bazaar Repo to Git".
<LeoNerd> Use Tailor
<ndim> LeoNerd: Is http://bazaar-vcs.org/BzrForeignBranches/Git known to be broken?
<ndim> I'm looking for a one-off conversion. I have a few git branches based on old CVS versions of Mailman, and Mailman has since switched to bzr.
<LeoNerd> Dunno.. never seen it before. Try it :)
<ndim> Good :)
<LeoNerd> If it's just a oneoff conversion, do you care about history?
<LeoNerd> If not, it might be easier just to do an export/import snapshot, and forget history
<ndim> I care about the stuff I did.
<ndim> History-wise.
<ndim> It will probably be easier to merge 50 line patches than one 2000 line patch.
<ndim> divide et impera and stuff. :)
<luks> ndim: the converted branch probably won't help you much if you want to merge it to the current mailman bzr branch
<luks> revisions will have different IDs, files will have different IDs
<ndim> $ bzr branch mailman-2.1.7.cg mm-git2bzr-test
<ndim> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_output_one_line'
<ndim> luks: Uhm.
<luks> what does ~/.bzr.log say about the error?
<ndim> Sounds like I'm better off converting current mailman from bzr to git, rebase my git stuff on that converted thing, and then convert the merged thing back to bzr...
<luks> ndim: converting from git won't get you branch mergeable with trunk either
<ndim> luks: traceback in stgit.
<luks> oh
<luks> mailman-2.1.7.cg is a git branch?
<ndim> yupp.
<ndim> cogito, to be exact.
<ndim> bzr-git/stgit incompatibility.
<ndim> The conversion from git to bzr I could do as generating a few dozen patches and commiting them with bzr.
<ndim> That result would then be mergeable.
<ndim> As I'd start on the bzr side with real upstream's bzr repo.
<luks> ah
<dato> jelmer: any chance to look at #180128?
<dato> bug #180128
<ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
<jelmer> will have a look in the next few days
<dato> ok, no hurries, just thought I'd ask.
<jelmer> there's a couple of other bzr-svn issues I have to look at as well, and I prefer doing them in batches
<dato> very well
 * jelmer is in Samba-mode atm :-)
<ubotu> New bug: #181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] https://launchpad.net/bugs/181811
<jelmer> ddaa: btw, I made a couple of small fixes to your bzr-git branch
<ddaa> great
<jelmer> https://code.edge.launchpad.net/~jelmer/bzr-git/jelmer
<jelmer> fixes support for python2.4
<ddaa> jelmer: I do not plan to put any more work on bzr-git in the near future.
<jelmer> ok
<ddaa> feel free to own it
<jelmer> I'm not sure I want to :-)
<ddaa> well, it actually has the beginning of a useful test suite :)
<jelmer> I may end up owning it though, if I start using it for Samba
<muffinresearch> Quick question. Does anyone think it would be useful to have a shell script installer for mac that installs bazaar including all of the dependencies
<muffinresearch> Does anything like that exist already?
<jelmer> muffinresearch, I know there were some people working on it
<jelmer> muffinresearch, not sure what the status is though
<jelmer> phanatic: ping
<muffinresearch> I see this: http://www.nabble.com/Bazaar-OS-X-Installer-status-td14254776.html
<phanatic> jelmer: pong
<jelmer> phanatic: ^^
<phanatic> muffinresearch: there is already an installer available for leopard (bazaar 1.0)
<phanatic> muffinresearch: http://bazaar-vcs.org/Download
<muffinresearch> I don't have leopard
<muffinresearch> Presumably macports is kept fairly up to date.
<phanatic> indeed
<phanatic> that works fine as well
<phanatic> jelmer: i could even get bzr-gtk working with macports, it's pretty cool :)
<muffinresearch> The main reason is just providing a quick way for colleagues to get up and running with the latest version. I normally install from source myself
<muffinresearch> macports is probably the best option. I'll get someone to try that
<nebuchadnezzar> hello
<jelmer> hi
<nebuchadnezzar> I'm following the bzr upgrade in my debian SID and I see some new format, rich-root and rich-root-pack, I don't find documentation/specification about them.
<brianpeiris> hello
<brianpeiris> quick question, am I correct in assuming that bzr diff does not support UTF-16 ?
<jelmer> brianpeiris: AFAIK, yes
<jelmer> brianpeiris: you can however use it with external diff tools
<luks> but it will print utf-16
<brianpeiris> ok, explains the "binary files ... differ" message I was getting while trying to diff a UTF-16 sql script.
<luks> actually, it won't print anything
<luks> yeah
<luks> bzr checks if the file has nul bytes, and if yes it assumes it's binary
<brianpeiris> alrighty, thanks for the help.
<ubotu> New bug: #181842 in bzr "BZR_SSH environment variable is not explained in docs" [Undecided,New] https://launchpad.net/bugs/181842
<dgl> hi
<dgl> Can anyone explain me what are the differences between init and init-repos?
<jelmer> init creates a branch
<jelmer> init-repo creates a (shared) repository
<dgl> jelmer: ok, i've already read that, but what does it mean?
<dgl> basically you create a branch just few times and then start to 'branch' it, isn't it?
<jelmer> dgl: see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts for an explanation of branch and repository
<brianpeiris> @dgl, see also: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#repositories
<dgl> thanks, I will
<UbuntuStats> Hi - From now on #bzr will have statistics on ubuntuircstats.org (gouki)
<dgl> where is a nice place to create a shared repos at an ubuntu server?
<gouki> Here it is: http://ubuntuircstats.org/bzr.html
<gouki> Enjoy guys!
<ubotu> New bug: #181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Undecided,New] https://launchpad.net/bugs/181855
<dgl> where is a nice place to create a my mainline shared repos at an ubuntu server?
<beuno> dgl, Launchpad es where you create branches, but it doesn't support shared branches as far as I know
<beuno> I suppose, at the moment, it's meant for local use, to save space
<LarstiQ> depends on what you mean with shared
 * beuno waves at LarstiQ 
<LarstiQ> multiple people can push to branches on launchpad, provided they are part of the team owning the branch
<LarstiQ> beuno: heya :)
<dgl> beuno: I've got a server with ssh, I just want to use it as a shared repos
<LarstiQ> dgl: you're asking what a good location is to place public repositories?
<beuno> dgl, you want multiple people to be able to work on a branch, or you want multiple branches to use the same repo?
<LarstiQ> in a FHS kinda way
 * LarstiQ user /srv/bzr/<repository-name-here>
<dgl> LarstiQ: sorry, but I think I was not clear
<dgl> I was talking about filesystem
<beuno> dgl, that just confuses me more  :D
<dgl> beuno: LarstiQ's understood me
<beuno> ah, yes, he's very good at that
<dgl> beuno: I was asking about a nice place to create a shared repos at my server file system
<beuno> dgl, happy you got your answer  :D
<LarstiQ> dgl: it depends on the rest of your filesystem layout of course, /var/www/bzr/ is also not unthinkable :)
<dgl> LarstiQ: and /var/bzr?
<LarstiQ> dgl: not where I'd place it myself
 * LarstiQ thinks it fits best under /srv
<LarstiQ> dgl: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
<lifeless> /srv/bzr/www
<lifeless> hmm, maybe /bzr/www/srv/var/
<LarstiQ> lifeless: argh :P
<lifeless> no like?
<LarstiQ> you'd have to have a rather complex setup for that to make sense I think
<lifeless> ok, ok.
<LarstiQ> something like launchpad perhaps
<lifeless> /var/bzr/srv/www/
<LarstiQ> lifeless: are you pulling my leg again? :)
<lifeless> moi?!
<dgl> I just want to use sftp
<LarstiQ> lifeless: true true, I've never caught you doing it before.
<lifeless> maybe not on IRC; in person you have:)
<LarstiQ> hah! Now I did ;)
<lifeless> dgl: anything is fine; key things to think of is 'will it be backed up by your backup programme'
<dgl> lifeless: thanks
 * lamont looks around for a bzr god
<lamont> lifeless: you awake?  and are you a god? :-)
<lamont> if a user has read access to .bzr/* (and down), but lacks read access on bar/foo.c, how can I tell bzr to just ignore that little issue and keep right on going with its life?
<dato> heh
<lifeless> lamont: (True, True)
<lamont> lifeless: I see that you remember ghostbusters.
<lamont> now about bzr and bar/foo.c ....  any hope for me?
<lamont> lifeless: ^^
<lifeless> lamont: you can't
<jearl> \q
<lifeless> lamont: (in general). Bu perhaps you can give me more info ;)
<Peng> Nice, some random doofus clicked on one of my bundles because it's the only Google result for "JGR1my space". :\
<Peng> Googlebot also found a link to /yaygyosr.html in one of them.
<lifeless> rotfl
<Peng> Ooh, the "JGR1my space" search was from Mexico!
<lifeless> yay hung test :(
<LeoNerd> Hung-like-horse, or hung-like-Sadam ?
<Peng> Ouch.
<lifeless> I'll find out soon
<lifeless> hung like reading bytes that never came
<Peng> I got a "Connection reset by peer" after 3 minutes pushing 1 KB of changes over bzr+ssh. :D
<abentley> lifeless: Your patch to remove the need for ParentProvider.get_parents looks very strange.  The goal is fine, but please don't merge in current form.
<lifeless> abentley: good timing; I had just hit enter to push and submit
<lifeless> whats wrong with it ?
<abentley> It means that Graph.parents_provider is sometimes None.
<abentley> Sorry
<abentley> Graph.get_parents is sometimes None
<abentley> That's a public API
<dato> abentley: (when you have a couple minutes and if you don't mind, did you see my question about having send, when -r is specified, always bundle those revisions, even if they're in the submit branch?)
<abentley> It should always be a callable.
<lifeless> abentley: oh, that wasn't clear to me because its not defined explicitly
<abentley> You can deprecate it, or remove it entirely, but no one expects a method to sometimes be None.
<lifeless> so if I add
<lifeless> 'if self.get_parents is None: del self.get_parents' you're happy ?
<abentley> You mean Graph.get_parents would sometimes be defined, and sometimes not defined?
<lifeless> or I can write a regular get_parents method
<lifeless> well currently I can supply a ParentsProvider with get_parents = None
<abentley> I prefer either deprecate it, or remove it in all cases.
<lifeless> because the Graph class does not define any of what you are referring to
<lifeless> and we don't provide any thunking in either direction
<abentley> lifeless: You can, but that's an API violation.
<lifeless> abentley: how about I write Graph.get_parents and graph.get_parent_map, both in terms of each other
<lifeless> abentley: then the constructor can replace just one from the ParentsProvider
<abentley> Why would you write Graph.get_parents_map?
<abentley> Let's just standardize on ParentsProviders having that.
<lifeless> so that providers with get_parents still work - that is the point of deprecating that isn't it ?
<abentley> There are no providers with only get_parents.
<lifeless> let me rephrase; we appear to have a deprecation which is not really a deprecation - its not compatible. I'm happy to either turn it into a full break; or a real deprecation where the old code works. Your choice.
<lifeless> abentley: third party repositories will almost certainly be providers with only get_parents
<lifeless> which is public in that Graph.__init__ takes a public parameter.
<abentley> I have a slight preference for real deprecation, but I'd be fine with either.
<lifeless> ok I'll whip it up
<abentley> dato: That has already proven to result in horrible messes, and that's why there's a submit branch.
<abentley> However, if you want an override, that's fine.
<dato> override == option?
<abentley> Yes.  People have asked for that in the past, but they've never suggested how the commandline would work.
<dato> ok, I'll make a note, and possibly talk to you about it in the (near) future. now it'd be bed time for me.
<abentley> One way would be a second revision spec.
<abentley> Another would be an option that says --use-revision-spec-instead-of-submit-branch
<dato> (I guess I didn't realize the time it was when I brought up the subject, sorry. chao)
<abentley> But remember that a merge directive, is meant to convey the changes you want made.  That's what the -r controls.
<abentley> The revisions supplied are the ones necessary for other people to apply the those changes.
<abentley> For a cherry-pick, that is typically *more* revisions than the -r range includes.
<abentley> The submit branch should indicate which revisions everyone already has.
#bzr 2008-01-11
<lifeless>  http://www.linux-foundation.org/en/Net:Netem
<lifeless> http://www.linux-foundation.org/en/Net:Netem
<poolie_> lifeless, http://webkit.org/blog/108/yet-another-one-more-thing-a-new-web-inspector/
<mlh> there was a python magling app/library I mentioned on the slug list sometime ago.  I forget the name
<lifeless> magling?
<mlh> my mangle got magled
<TFKyle> mangling meaning obfuscation or something like symbol mangling?
<mlh> er neither really, network simulation of a sort.  Searching hasn't found anything.  Maybe I'm misremembering
<TFKyle> ah
<ubotu> New bug: #181927 in bzr "bzr-gtk broken in repo" [Undecided,New] https://launchpad.net/bugs/181927
<Peng> How does Bundle Buggy approval work?
<Peng> Some merge requests need two "bb:approve"s and some don't.
<Peng> Why?
<lifeless> all requests need two voters
<lifeless> some requests are from voters and thus have an implicit ingle initial approval
<Peng> Ahhh.
<Peng> That makes sense.
<Peng> Okies. :)
<Peng> Thanks.
<lifeless> np
<lifeless> its also in the developers guide IIRC
<ubotu> New bug: #181945 in bzr "bzr pull lp:upstart fails" [Medium,Confirmed] https://launchpad.net/bugs/181945
<ubotu> New bug: #181942 in launchpad-bazaar "bzr pull --remember fails with lp style url (dup-of: 181945)" [Medium,Confirmed] https://launchpad.net/bugs/181942
<Zyroth> Is there a tool that uses bzr locally for versioning but can also commit to an svn repos?
<Kinnison> You may be able to get somewhere with bzr-svn
<Zyroth> thanks
<IllX> Are there any good bzr videos out there? I just watched one from John Meinel and would enjoy to learn more
<IllX> searching for "videos" on bazaar-vcs.org pulls up some sort of badcontent file; doesn't seem like what I'm looking for
 * fullermd didn't know there were any videos...
<IllX> It's informal but very nice to have
<IllX> http://video.google.com/videoplay?docid=-7349765443983887725
<IllX> wish I could find more
<fullermd> They promised me the videos were all erased, and anyway the statute of limitations had expired.
<IllX> the rails guys have spoiled me I guess
<fullermd> Er.  I MEAN....
<Odd_Bloke> Rails is enough to spoil anything. ;)
<fullermd> Every time I look at ruby, I feel spoilt all right...
<Odd_Bloke> 'Tis the season to be trolly, trollollollolloll troll oll oll oll.
<fullermd> Gah.  Who's making a ruckus up on my bridge?!
<LeoNerd> <Picard> Get off my bridge!
<LeMec> hi! is anyone here using bzr-svn latest version?
<LeMec> by reading the announcement I got the impression that it no longer needs the python svn bindings patch
<Odd_Bloke> jelmer is the man to ask. :)
<LeMec> however, when I'm trying to run it (Mac OSX Tiger, Python 2.5.1, Bzr 1.1RC1, bzr-svn 0.4.6) I am getting this error: Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details.
<LeMec> do you know his timezone?
<LeMec> at least I know when to ask him :)
<fullermd> UTC+1 or 2, I think.
<LeMec> (based on the name he should be EU, but not sure)
<Odd_Bloke> I don't, I'm afraid.
<fullermd> But don't quote me on that.
<LeMec> #jelmer: can you please comment on my issue with bzr-svn? thanks
<AfC> Jelmer is his own IRC channel? Neat!
<dato> heh
<Odd_Bloke> jelmer implements RFC 1459.
<LeMec> :)
<Odd_Bloke> s/jelmer/Chuck Norris/
<fullermd> Oh, he's working on bzr-irc now?
<LeMec> I've rechecked the documentation... and I have bad news for me
<AfC> LeMec: did you have an opportunity to try the Subversion access case you are fighting on a different platform, say Linux? (if so, did it work there, making this a porting to Mac issue, or did it not work there either, making this a use of bzr-svn bug)
<LeMec> "At the moment, the svn plugin only works with
<LeMec> Subversion 1.5 (trunk)."
<LeMec> I currently have access only to a Win and a Mac machine
<LeMec> I have some VMWare Linux images somewhere but not close enough
<LeMec> maybe I am the laziest guy, but it looks kind of weird to require an unreleased svn version
<Odd_Bloke> It's going to be released fairly soon, I believe.
<LeMec> I mean... you usually don't like to stay on the cutting edge versions when working with your sourcebasse
<fullermd> Yeah, the release is right around the corner.  Just like it was last year this time.  And the year before...
<dato> LeMec: sometimes what you want to do is not possible at all with released versions...
<LeMec> maybe you are right
<LeMec> unfortunately I must confess that getting up to speed with Bazaar hasn't worked for me so far
<LeMec> :(
<fullermd> Well, in this case, he is; the python bindings in 1.4.x are totally b0rked.
<LeMec> I see
<fullermd> And the 1.5 release has been a month or two out for something like 18 months now   :|
<fullermd> It would be enough to drive me batty, if I used svn   ;)
<LeMec> unfortunately, for me this only means that one of the strongest Bazaar selling points is just out
<LeMec> I tried to resist so far... but it looks like I should try the remaining alternative (git)
<AfC> LeMec: You're writing off Bazaar because some other VCS is borked?
<LeMec> Afc: no, just because I cannot use it for my needs
<LeMec> I may be sounding harsh here (which is definitely not my intention) but
<LeMec> - Mercurial: has the easiest distro (for multi platforms), but is lacking the svn support
<LeMec> - Bazaar: has the svn support, but requires the user to pass through some weird hops
<LeMec> - Git: has the svn support, but it's support for different platforms is not quite good
<LeMec> and I definitely wanted to write its instead of "it's" :)
<AfC> "weird hoops"? Bazaar forces far less  behaviour than any of the other 3rd generation DVCS systems.
<Kinnison> may be weird for bzr-svn
<LeMec> Afc: that is your opinion and I am not gonna comment it
<fullermd> "Weird" is certainly my impression of the process.  Either (a) your packaging system ships patched bindings, or (b) you're in for a world of manual pain.
<dato> LeMec: it was just a misunderstanding, I think
<LeMec> unfortunately, I am not gonna install XCode 1Gb, compile things by my own and hope it works
<LeMec> moreover move to install on my system another "beta" product (svn)
<LeMec> (well, it looks like I'm pretty tired and my writing reflects it)
<LeMec> I just hoped I could grab something, install it and start working... that is what I was looking for
<AfC> LeMec: you're in the Bazaar project's channel saying bzr doesn't work. You could reasonably expect that people here might be interested in finding out what about Bazaar isn't performing correctly with an interest in either helping you use it better or fixing a problem with bzr if one is present.
<LeMec> I think I've provided all available data
<LeMec> if I missed anything I would be glad to provide more
<fullermd> No, he's in the Bazaar project channel saying that getting bzr-svn working requires a lot of hoop-jumping...
<LeMec> fullermd: in the past month I've discussed other aspects of bzr too
<AfC> Well, that's Subversion's fault for not having cut a release in forever, I should think. Not really something you can blame bzr for.
<LeMec> the bzr-svn is just the today theme... and I thought that bzr-svn even if a plugin is an important part of bzr
<LeMec> I apologize if this isn't the right place to discuss about it
<fullermd> It doesn't have to be something bzr can be blamed for, to make it a showstopper   :p
<AfC> point
<LeMec> Afc: I theoretically agree with you
<LeMec> but svn allown works for me, and it is the bzr to svn which is not
<dato> LeMec: it is the right place. I understand your frustation, but there's little more we could do.
<fullermd> If interfacing with svn is important, and doing so with bzr is a PITA, it doesn't matter whether it's bzr's or svn's fault.  It's still a "Well, let's try something else" moment.
<LeMec> moreover, I am not here to blame, but rather to get help and provide feedback
<dato> LeMec: short of having somebody with mac knowledge provide packages somewhere
<AfC> dato: I don't suppose we should suggest tailor
<fullermd> Which has been discussed a time or two recently.
<AfC> dato: (which is an abomination, but usually works for one time transformations)
<fullermd> Urg.  For a conversion, tailor would work OK.  For interaction, not so much.
<dato> AfC: I don't think he wants a one-time transformation
<LeMec> AfC: I have used tailor in the past
<jelmer> LeMec: hi
<LeMec> but bzr-svn selling point is the continuous integration
<LeMec> and not the 1-time improt
<LeMec> jelmer: hi
<LeMec> dato: that would be optimal; in a discussion with Martin Pool I have suggested this (I think my email finally got to the bzr mailing list)
<jelmer> LeMec: I'm afraid bzr-svn (and python-subversion) being hard to install on Mac OS X is a known issue,
<jelmer> there were some folks working on an installer
<jelmer> but I'm not sure what the status of that is
<duckx> Hy all
<LeMec> are you referring to Sylveszter? (sorry if I've misspelled the name)
<duckx> are nested tree ok ? I mean a bazaar tree in a bazaar tree ?
<jelmer> LeMec: yes
<duckx> Is there any doc on this
<LeMec> jelmer: I haven't heard back from him in a month :(
 * duckx : bzr stays my favorite vcs ;) 
<duckx> By the way, I use it to revision control all my conf on my servers ..
<jelmer> duckx: nested trees are an experimental feature, you'll need the dirstate-with-subtree format
<LeMec> jelmer: but can you please detail why is it difficult to get it working under Mac?
<duckx> Ha ok
<duckx> Thx jelmer
<LeMec> I mean afaik git has solved it somehow, and considering bazaar is python I would expect things to be a bit easier
<fullermd> duckx: Now, you can put one branch inside another and just treat them as two separate branches without any special support.
<fullermd> LeMec: git doesn't use the python bindings   :)
<jelmer> LeMec: git doesn't use python
<jelmer> LeMec: afaik it just invokes the svn binary
<duckx> Ok, I got my /etc bzrified and my /etc/apt/ bzrified too
<LeMec> jelmer: than why bzr-svn is not doing the same?
<duckx> in /etc bzr add /etc/apt is ok ?
<jelmer> LeMec: Because that's more complicated and slower
<LeMec> jelmer: if you know the bindings are the problem... then avoiding them would be the option
<jelmer> LeMec: the bindings are mainly a problem on the Mac
<jelmer> LeMec: Most Linux distributions ship with the patches included
<LeMec> jelmer: complicated and slower than not working?
<jelmer> LeMec: I don't have a Mac so I'm not entirely sure what the problem is with providing patched bindings for the Mac
<LeMec> I see... then the only thing missing is a prepared distro for the Mac
 * AfC waves to jelmer (who he rarely sees), dato, and fullermd
<AfC> night gents
<jelmer> g'night AfC
<Lo-lan-do> Hi all
<jelmer> hi Lo-lan-do
<Lo-lan-do> jelmer: If I may bother you... would it be possible to store the mappings between svn revs and bzr revs somewhere else than in properties?
<mwh> i guess i could try again to build on the mac
<mwh> won't be for a couple of weeks yet though :/
<Lo-lan-do> Commit messages are getting more and more unreadable as time passes and I commit to gforge's SVN through bzr : http://lists.gforge.org/pipermail/gforge-commits/2008-January/000798.html
<jelmer> Lo-lan-do, they could be stored in revision properties
<jelmer> Lo-lan-do, but that requires a subversion 1.5 server
<jelmer> Lo-lan-do, I've started some work on that in a separate branch earlier this year
<Lo-lan-do> Hmm.  Maybe it would simply be better to enhance the svnmailer then, so it only shows what has changed in the properties, rather than the old+new versions.
<jelmer> yeah, that's what we did for Samba
<Lo-lan-do> Do you know where I could find a patch?  Or if it was trivial enough that I could redo it?
<jelmer> we use a custom script, not svnmailer
<jelmer> svn://svn.samba.org/samba/hooks/commit-email.pl
<Lo-lan-do> Blah, current svnmailer already does the right thing.
<Lo-lan-do> "current" as in "currently released", not "currently installed on gforge.org" :-(
<Kinnison> Can bzr serve cope with multiple repos?
<Kinnison> I.E. can I do bzr serve --directory=/path/to/store
<Kinnison> where there is /path/to/store/repo1/branch1 /path/to/store/repo1/branch2 /path/to/store/repo2/branch1 etc.
<Kinnison> ?
<fullermd> AFAIK, 'server' doesn't serve repos, it serves a FS tree.
<fullermd> So anything underneath --directory is fair game.
<Kinnison> interesting, ta
<Lo-lan-do> jelmer: Another quick question: is it possible to easily get the svn revision number when I'm in a bzr-svn branch?
<jelmer> Lo-lan-do: not really
<spiv> Kinnison: fullermd is right.  Each smart request includes a relpath.  In your example "bzr branch bzr://localhost/repo1/branch1" would work fine.
<Lo-lan-do> Okay, I'll live without.
<jelmer> Lo-lan-do: There is an open bug about showing the svn revno in "bzr log", but that requires bzr changes
<jelmer> Lo-lan-do: you can always parse the revid :-)
<Lo-lan-do> True.  I'll write a wrapper around that.
<Lo-lan-do> Thanks for the idea.
<Lo-lan-do> bzr log --short --show-ids -r -1 | grep revision-id: | head -1 | awk -F: '{print $5'}
<Lo-lan-do> There :-)
<jelmer> :-)
<Kinnison> spiv: can the smart server pay attention to the hostname used to access it, or is that not part of the protocol?
<fullermd> I wish --show-ids were more granular...
<Kinnison> spiv: also, how trivial is it to access control it? I'm guessing bzr+http[s] is easier to access control, but I'm not sure about read vs write
<dato> Kinnison: there is something in contrib/ about access control
<dato> contrib/bzr_access,
 * Kinnison looks
<spiv> Kinnison: the hostname isn't part of the protocol
<Kinnison> dato: which contrib/ ?
<dato> bzr.dev's at least
<dato> oh
<spiv> Kinnison: contrib in bzr.dev, and probably 1.1rc1
<dato> I wonder why that isn't installed in the debian package
 * Kinnison bzr pulls
<rjek> Hi.  So I'm thinking about migrating from svn to bzr.  What's the best option for migrating my data (including history) to bzr, while at the same time rearranging the data?
<LeoNerd> Tailor ?
<jelmer> rjek: what do you mean by rearranging the data?
<rjek> I had considered it, I just wanted to make sure it was a sensible choice.
<rjek> jelmer: Well, the way projects and such are organised in the current svn repository is not ideal.
<Kinnison> spiv: would it be reasonable to assume that the smart protocol over http uses GET for read-only and POST for writing?
<fullermd> I don't think so.  I'm pretty sure it POST's everything.
<Kinnison> :-(
<fullermd> I think the lowest overhead suggestion I've seen was to use different configs for http and https, and allow writing and require auth on the latter.
<Kinnison> mmm
<Kinnison> rjek: would that be acceptable?
<rjek> It sounds like a hack.
<fullermd> Yeah, that's a side effect of it being a hack   :)
 * rjek grins.
<rjek> It'd be nice if it used GET: that'd give you the advantage that you could take advantage of web caches.
<rjek> (If-Modified-Since etc)
<fullermd> Doesn't work too well with the sort of things smart requests do.
<rjek> Does it not ask for the whole contents of a file occationally?  Of course, the output of CGIs could be cachable, so the parameters of the smart request could still be done in a GET and still be usefully cached.
<fullermd> A lot of them would be really hard to get that information for.  And then there's the limits on GET request size...
<rjek> There's a limit on the size of a request URI?
<fullermd> Oh, yes.
<fullermd> You probably don't see it much in practice, since IE's limit on URL length is lower than the RFC's or Apache's, but it's there.
<fullermd> (not that I'm bitter about that, or that it's ever cost me a half days work or anything, mind you)
<rjek> I thought it was something astronomically large (comparitively) like 16kB or something.
<fullermd> I think it's more like 2k.
<rjek> Right.
<fullermd> And sending around lists of revision id's can eat that up fairly quick.
<rjek> You need to encode it more efficently than using ASCII digits. :)
<fullermd> It's a URL; you encode LESS efficiently than ASCII digits after you escape all the necessary characters   :p
<rjek> I was assuming a revision id was a decimal number, and thus encoding it as a decimal number in ASCII wouldn't be as efficent as, say, encoding it in base 36 or something.
<fullermd> No, they're opaque text strings.
<rjek> Right.
<Kinnison> rjek: those are revno rather than revid
<dato> rjek: about your rearranging, it *sounds* as if you have several different projects in your svn repository, and want to rearrange *them*?
<rjek> dato: Both.
<dato> rjek: normally you'll create a different bzr branch for each project
<dato> rjek: and since they are normal directories, you can later arrange them (at the filesystem level) as you please
<dato> does that answer your question, or I misudnerstood you?
<rjek> I'm not entirely sure yet. :)
<rjek> I think it answers my question.
 * Kinnison struggles with the wsgi stuff
<dato> rjek: as for the conversion, if you can install bzr-svn easily (which it mostly is if you're on linux afaik), then I think that'd be the easiest way, converting one project at a time. if not, tailor... do you have branches of your projects?
<rjek> Very very few.
<rjek> (perhaps one or two.)
<dato> ok, afaik it works well as well, with bzr-svn.
<cory> I've been having trouble.  My commits typically never make it paste "Saving data locally - Stage 2/5", which is taking an incredible amount of time.
<rjek> OK, I'll look into that too.
<cory> Ok, things have magically resolved themselves.  Maybe I'm just impatient.  Never mind, then. :P
<Kinnison> Gah, this is hard
<Kinnison> I have a bunch of repos in /path/to/trees
<Kinnison> I set that as the base of the smart fcgi
<Kinnison> and then set /trees/ as the prefix
<Kinnison> but then a request tries to read /path/to/trees/trees/repo/branch/.bzr/branch-format
<Kinnison> which is just confusing as hell
<Kinnison> Anyone here dones the whole bzr as an fcgi thing?
<LeoNerd> Sounds like the sort of thing I'd do.. but I haven't
<spiv> Kinnison: there are some patches from me in http://bundlebuggy.aaronbentley.com/
<LeoNerd> Largely on account of not being able to find a webserver that will do FastCGI that doesn't suck piggie
<spiv> Kinnison: that fix bugs in the patch handling in this area
<Kinnison> patch handling?
<spiv> path handling.
<spiv> My fingers are too ready to type "patch" it seems :)
<Kinnison> which should I be looking for?
<spiv> http://bundlebuggy.aaronbentley.com/request/%3C20071214015112.GC14963@steerpike.home.puzzling.org%3E
<spiv> http://bundlebuggy.aaronbentley.com/request/%3C20071214011937.GA26039@steerpike.home.puzzling.org%3E
<spiv> Unfortunately, I really need to sleep now
<spiv> I hope that's of some help
<Lo-lan-do> Sleep usually helps
<spiv> Lo-lan-do: :)
<Odd_Bloke> When in doubt, sleep.
<Kinnison> spiv: so is this a client or a server issue?
<orospakr> What is Bundle Buddy?
<Kinnison> Okay, so I got it talking a bit
<Kinnison> only it can't think about branches in shared repos
 * Kinnison sighs
<Kinnison> I appreciate that bzr+http is a hack, but this is pitiful :-(
<dato> orospakr: an application to track pending merges in a project
<orospakr> er, s/buddy/buggy/
<orospakr> neat.
<Peng> How is bzr+http a hack?
<Kinnison> Peng: it's a vaguely stateful protocol (bzr smart protocol) being run over a stateless protocol (http)
<Kinnison> afaict
<Kinnison> anyway, time to drive to mother-in-law's
<Kinnison> byw
<RainCT> Hi
<RainCT> There is no "bzr cp" feature (like "bzr mv" but instead of moving the file, duplicating it, so having two different files with the same history), or?
<ubotu> New bug: #182040 in bzr "reconfigure form lightweight checkout to checkout don't pull tags from master branch" [Undecided,New] https://launchpad.net/bugs/182040
<hendrixski> Hey, I just saw on Mark Shuttleworth's blog that there's a bzr-eclipse plugin on the way.   Has anybody tried it, does it work well yet?
<Peng> RainCT: That is correct. No copying.
<Peng> RainCT: Because of how bzr's really great renaming is done, copying is not supported.
<Peng> RainCT: There's at least thought about doing it differently so copying can be supported.
<RainCT> Peng: Thanks for the information :).
<soul9> hi
<soul9> !help
<ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<soul9> !info server
<ubotu> Package server does not exist in gutsy
<soul9> :-)
<soul9> heh
<soul9> i would like to set up a bzr server
<soul9> i know it's distributed, but it'd still be nice
<soul9> i haven't been able to find anything about the setup
<luks> if you have a sftp server and a http server, you already also have a bzr server
<soul9> ok
<soul9> so there is no guide about this?
<soul9> i do think i have sftp (i do have ssh)
<soul9> but then what?
<dato> then
<Lo-lan-do> mkdir
<luks> then you just use it
<dato> you `bzr push` to a location in the server where the http server will serve it
<soul9> so if i do have sftp enabled
<soul9> i should be able to use an ftp client
<dato> eg. bzr push --create-prefix sftp://host/var/www/bzr/project/trunk
<soul9> to connecT?
<dato> or. bzr push --create-prefix sftp://host/~/public_html/project/trunk
<soul9> so with this way, i should use a shared useraccount if I want to work in team?
<soul9> or?
<dato> soul9: or make /var/www/bzr/project group-writeable, and create a group
<soul9> yeah
<soul9> 0o
<soul9> ok, so sftp works
<soul9> that way though, i need to create users
<soul9> with shell accounts..
<LarstiQ> soul9: or use an sftp server that doesn't require system users
<soul9> o
<soul9> that would definitely be nice
<Peng> bzr+ssh is speedier than sftp.
<Peng> That requires SSH logins for everyone though.
<Peng> And it requires bzr be installed on the server.
<soul9> yeah
<soul9> i think i'll just do sftp+http
<soul9> if i can find an sftp server that doesn't need system logins
<dato> with bzr+ssh, you can set the login shell of those people to a wrapper that just calls bzr serve with the appropriate arguments, I think
<soul9> yeah, like hg
<soul9> i don't like that though
<soul9> i can't find such an sftp server though
<dato> maybe LarstiQ knows of one
<soul9> LarstiQ: would you be so kind, if you know an sftp of the likes, to hint me with at least the name of it? :-P
<soul9> :-(
<LarstiQ> soul9: iirc spiv wrote one, let me look
<soul9> thx
<LarstiQ> soul9: can't seem to find it atm. Another option is chrooting your sftp server.
<soul9> ok
 * LarstiQ goes to bed
<soul9> night
<dato> LarstiQ: are you in EU?
<LarstiQ> dato: yes
<dato> ok, enjoy your sleep :)
<LarstiQ> dato: fever :/
<dato> aw. i wish you a prompt recovery!
<LarstiQ> dato: thank you, and now I really detach :)
<CardinalFang> Hi.  I have a repo that seems to have been "repo-init"'d with "--no-trees".  How can I change that default?
<dato> rm foo/.bzr/repository/no-working-trees, I guess
<dato> I can't recall that we have an UI to change it
<CardinalFang> Ah.  I figured there was a cooler way.  Thanks.
<Solarion> how do I make a branch have a new parent?
<Lo-lan-do> bzr pull --remember?
<Solarion> aaah, danke.
<jdahlin> Is pushing from a bzr-svn repository known to be slow?
<jelmer> jdahlin: What do you mean exactly? Pushing from Bazaar into Svn?
<jdahlin> jelmer, Oh. Yes, exactly that
<jelmer> Is this the first you're accessing the Subversion repository?
<jdahlin> I have a subversion repository with 6000 revisions which I branched off, but it seems to take a while to push the changes
<jelmer> jdahlin: What version of bzr-svn?
<jdahlin> jelmer, it's the first time I'm committing yes
<jdahlin> 0.4.2
<jdahlin> no, sorry. 0.4.5
<jelmer> Newer versions (0.4.6 in particular) do more efficient caching
<jelmer> in any case it will be a lot faster the next time you push
<jdahlin> Okay, sounds good.
<jdahlin> Is bzr push the normal way of merging back to the svn repository?
<jelmer> yes
<jdahlin> and bzr diff -r ancestor:svn://.. to get a diff?
<Lo-lan-do> (Phew -- I've been doing that for the last six months :-)
<jelmer> jdahlin: I usually use "bzr diff -rbranch:.." but I think ancestor should work as well
<jdahlin> I really hope it will be faster the next time, it's already been running for 20 minutes.
<jelmer> you may want to upgrade to 0.4.6
<jdahlin> oh, it just finished
<jdahlin> and it worked as it should!
<jdahlin> let me try to commit a second time
<jdahlin> Indeed, it seems to take quite a bit
<jdahlin> *of time
<jelmer> on the samba svn repository (>25k commits) it usually takes less than 10 seconds
<jdahlin> real	5m7.607s
<jdahlin> Let me retry with 0.4.6.
<jdahlin> jelmer, it's doesn't seem to be caching svn connections very well, it's connecting to the remote host every second or so
<jdahlin> Yes, my connection to the svn server is quite restrained
<jdahlin> real    5m46.833s
<jdahlin> jelmer, so, no speed improvements using 0.4.6
<jdahlin> second time with 0.4.6 brought it down to 2m19, getting much better
<LeMec> jdaklin: was it a large commit?
<LeMec> 5m sounds like a lot of time; or was is due to a weak connection?
<jdahlin> LeMec, no, it was a tiny commit
<jdahlin> LeMec, due to a weak connection yes
<jelmer> re
<jelmer> jdahlin: can you try running again with -Dtranport and see what sort of operations its doing?
<jelmer> it should be writing to ~/.bzr.log
<jelmer> jdahlin: 5 minutes is way more than it should be
<jelmer> after the initial cache, push to a svn repository is often faster than push to a native bzr repository for me
<jdahlin> jelmer, sure, but I'm down to 2:19
<jelmer> jdahlin: that's still much more than it should be, unless your connection is really really slow
<jdahlin> jelmer, here is the output of the relevant .bzr.log parts; http://rafb.net/p/V28F8H24.html
<jelmer> jdahlin: thanks!
<jdahlin> if I install python-curl I will get a certificate error
<jelmer> you can use svn+https:// rather than https:// to work around that
<jelmer> hmm, .bzr.log looks ok
<jdahlin> oh, let me try that
<jdahlin> it went pretty quickly the last time
<jdahlin> but I forgot to time it
<jelmer> it's not the amount of network traffic that will be problematic
<jdahlin> I think it's the number of roundtrips.
<jelmer> that's less than 50 I think, looking at this log file
<jdahlin> jelmer, check this out, a snippet from strace: http://rafb.net/p/8wwViQ44.html
<jdahlin> there's lots of socket/connect calls which shouldn't be there.
<jdahlin> real	2m13.438s
<jelmer> does using svn+https:// rather than https:// help?
<jdahlin> not significantly
<jelmer> the log says there should only be 4 TCP connections opened
<jelmer> all the other stuff is done by the svn library
<jdahlin> okay, so how can the svn library be told not open up so many connections?
<hsn_> !apt
<ubotu> APT is the Advanced Package Tool, which together with dpkg forms the basic Ubuntu package management toolkit. Short apt-get manual: https://help.ubuntu.com/community/AptGetHowto - Also see !Synaptic (Gnome) or !Adept (KDE)
<jelmer> jdahlin: I don't think there is a way to do that atm :-/
<jelmer> jdahlin: How many connect()'s are there in total in those 2 minutes?
<jdahlin> jelmer, let me check.
<jdahlin> jelmer, 78 calls
<jdahlin> and that's just for changing one file
<jdahlin> actually, some are dns lookups. It's only 73 to the remote host
<Lo-lan-do> How can I "bzr diff" a current branch to a previous version of another one?
<jelmer> jdahlin: 73 is still excessive. I wonder what's causing them; I'll see if I can reproduce it here.
<Lo-lan-do> Ah: Sorry, diffing arbitrary revisions across branches is not implemented yet.
 * Lo-lan-do makes a new copy of the remote branch
<jdahlin> jelmer, Yes. I am trying to figure out myself which call might be causing it
<Peng> Hey, one of my bzr bundles tops another popular Google search term:  'legal land description" Indiana  winamac
<ubotu> New bug: #182140 in bzr "bzr-svn interferes with bzr operation" [Undecided,New] https://launchpad.net/bugs/182140
 * Peng wanders off.
#bzr 2008-01-12
<ubotu> New bug: #182159 in bzr-git "Doesn't provide git working tree access" [Wishlist,Triaged] https://launchpad.net/bugs/182159
<gryc> is there any way to work around a 4 hour initial `bzr push` where the .bzr directory is about 15mb?
<jelmer> gryc: what format and transport are you using?
<gryc> I'm using bzr+ssh, with version 1.0 I believe
<jelmer> gryc: what format in 1.0 though?
<jelmer> packs or dirstate?
<jelmer> packs should probably be faster
<gryc> I have no idea, how do I check?
<gryc> argh, nevermind, I think it was my network's upload getting sucked dry >_<;
<gryc> but, along those lines, is there any chance of getting a transfer speed counter added onto the end of that ascii progress bar, or is that impractical?
<jelmer> I think there were plans for that
<jelmer> you can check the current format by running "bzr info"
<gryc> ah, "dirstate" then
<gryc> sorry to bug you, it was another machine on my network eating all my upload bandwidth...the push took 9 minutes after I yanked the offending machine
<jelmer> no worries
<jelmer> this is another good reason we need that improved progress indicator...
<lifeless> gryc: if all your bzr clients are 1.0 or newer, you can improve performance by doing 'bzr upgrade'
<gryc> lifeless: thanks, I'll check with the rest of the team on that :D
<sechastain> I have a question about tags
<sechastain> I see that I can create them and that I can diff in reference to them
<sechastain> but how do I branch from them?
<sechastain> and how do I check the tags in a remote repository and/or branch?
<sechastai2> ... no takers?
<ubotu> New bug: #182192 in bzr "While pushing, progress bar has no upload speed indicator" [Undecided,New] https://launchpad.net/bugs/182192
<lifeless> sechastain: I would guess at bzr tags URL
<lifeless> and use -r tag: to access them
<sechastain> yeah, I've been looking the past hour or so through at the code
<sechastain> there's a secret undocumented flag --directory
<sechastain> bzr tags --directory branch
<sechastain> any reason why we can't dump the --directory flag?
<lifeless> dunno
<lifeless> not a part of the code I've looked at
<sechastain> it's in builtins.py
<lifeless> however its not secret
<lifeless> bzr help tags lists it,
<sechastain> ?
<sechastain> man
<sechastain> crazy
<sechastain> I've read through that like 5 times
<IllX> in reading about bzrweb I the comment "Recently it was updated to support the Bazaar 0.15 API"
<IllX> being very new to bazaar I'm interested in what the 0.15 API is, but can't find a good starting point
<IllX> surely it must be the bzrlib core
<IllX> how do I know 0.15 is the current?
<IllX> ah, now that I've found the api docs I see .version
<IllX> :)
<fullermd> Well, presumably, the API from the 0.15 release   :p
<IllX> really
<IllX> the way I was reading it, it gave me the impression the API might run a different version than application
<IllX> I haven't yet got to calling .version so I wasn't sure
<IllX> that's a long way back from 1.0
<fullermd> Yeah.  The API's always shuffling in little bits and pieces, but most programs can usually go a number of versions one way or the other before hitting something that throws 'em.
<IllX> yeah
<acuster> jelmer, around?
<ubotu> New bug: #182258 in bzr "-r before:date:xxx produce error if branch don't have revisions after specified date" [Undecided,New] https://launchpad.net/bugs/182258
<dato> what is a mesh-merge?
<dato> (I'm getting no google love for this)
<fullermd> In what context?
<dato> it's in the "[MERGE/RFC] Merge prefers to use submit branch" thread:
<dato> > They might develop only *on*
<dato> > trunk, or in more of a mesh.
<dato> If they're doing mesh merging, they'll need to specify the merge
<dato> location every time anyhow.
<fullermd> Oh, working in some sort of full-mesh topology, where you're merging from arbitrary other people in no particular pattern, instead of working in a more star-ish setup.
<jelmer> acuster, hi
<acuster> hey jelmer
<acuster> We're working on geospatial data and thinking about versionning theory. Any chance you have a list of references
<acuster> something we could get started with? We have peculiar problems not faced by text code files but in general
<acuster> we will face the same core issues.
<AfC> acuster: as ever in IT, there's lots of theory, and then there's what's actually implemented. There is often a wide gulf between them, with implementation not infrequently outstripping or obsoleting "theory"
<AfC> acuster: as applied here, I'd have to guess that your best bet would be finding a tool that actually encapsulates the concepts you want and think about whether or not you could adapt the core differencing engine to your data form (as oppose to the current bias about deltas between revisions of text files)
<AfC> acuster: ... but that's got to be a fairly restrained (and in the case of bzr, reasonably well isolated) aspect of the tool
<AfC> Failing all that, I'd have a word with the people doing version control on video. That's a fairly well developed area, but most of it is proprietary and/or in-house.
<AfC> [where video == the footage for a movie on up to the video archive of CNN]
<jelmer> acuster: I don't have any references, sorry. All I know about versioning theory is from reading the source code of the various free vcs
<acuster> thanks both
<acuster> AfC: we actually use a lot of theory, a la Knuth, Computational Geometry, and numeric algorithms. I was hoping there was a body of knowledge developed so I didn't have to start from scratch on this area as well
<acuster> so far to go before getting back to real science...
<brilliantnut> hi.
<brilliantnut> I was waiting for Bazaar 1.1, which the calendar said would be out on the 11th..
<brilliantnut> does anyone have any input on what happened?
<jelmer> not sure, haven't read anything about it recently
<jelmer> the release manager for 1.1 would be the best person to talk to
<jelmer> I'm not sure who it is though :-/
<brilliantnut> The google calendar entry was created by Martin Pool,
<brilliantnut> any idea what his irc nick is?
<jelmer> his IRC nick is "poolie"
<brilliantnut> jelmer: would you also happen to know what timezone 'poolie' is in? as in appropriate hours to find him online?
<jelmer> I expect he'll be online again in about 30 hours, maybe earlier
<jelmer> he's in Sydney
<brilliantnut> cool, thanks for the help, jelmer.
<brilliantnut> c ya
<RainCT> Hi
<RainCT> Does the version of bzr in Gutsy support tags?
<dato> RainCT: yes
<dato> RainCT: but you have to pass --dirstate-tag to `bzr init` for it to work
<dato> RainCT: or for existing branches, `bzr upgrade --dirstate-tags`
<RainCT> Yes I just did that, but I wasn't sure if it would break the branch for the other developers (I'm using the latest bzr from Hardy). Thanks
<RainCT> is there any reason why it is disabled by default?
<dato> when a new format gets introduced, we normally wait a few releases before making it the default
<dato> so, for example, dirstate-tags was made the default in 0.91
<RainCT> ah :)
<RainCT> so now if I commit & push it will also upgrade the copy in Launchpad, or what do I have to do?
<dato> you have to
<dato> bzr upgrade sftp:// ...
<dato> upgrade --dirstate-tags
<dato> if you just upgrade with hardy's bzr, it'll upgrade to a version not supported by < 0.92
<RainCT> I did a   bzr upgrade --dirstate-tags
<dato> very well. now that for launchpad as well.
<RainCT> bzr upgrade bzr+ssh://rainct@bazaar.launchpad.net/%7Efreevial/freevial/trunk/ --dirstate-tags    ?
<dato> try that, but I think upgrade over bzr+ssh does not work (didn't use to), so if it gives you an error, use sftp instead
<RainCT> okay. the copies that the other developers have will be updated when they pull then?
<dato> they will have to run upgrade themselves first
<dato> pull will tell them
<dato> bzr: ERROR: Tags not supported by BzrBranch5('file:///tmp/b/x/foo/'); you may be able to use bzr upgrade --dirstate-tags.
<RainCT> ok. thanks for your help!
<dato> you're welcome
<RainCT> dato: uh.. is it normal for LP to be still updating after half an hour?
<dato> sadly, yes... depending on the size of your branch
<RainCT> is there some way to see how much longer it will take, or abort it?
<jelmer> neither I think
<Lo-lan-do> Hmm.  graph-ancestry isn't as good as bzr-viz :-/
<Lo-lan-do> http://www.placard.fr.eu.org/~roland/tmp/superpatch.png
<radix> wow, yeah.
<radix> well then, hooray for bzr viz? :)
<jelmer> blame graphviz (-:
<Lo-lan-do> Compare to http://www.placard.fr.eu.org/~roland/tmp/Capture.png :-)
<brilliantnut> ?help
<Peng> What's up?
<RainCT> dato: LP is still updating..... shouldn't this rather be a bug? :P
<Lo-lan-do> jelmer: Is it possible to follow several SVN branches with bzr-svn?
<Lo-lan-do> http://pastebin.com/d2876a514
<Lo-lan-do> Seems that the history isn't preserved across branching :-/
<Lo-lan-do> Hm.  Only the ones created through "bzr svn-push", apparently.
<jelmer> Lo-lan-do: not sure I understand the question
<jelmer> two non-bzr revisions in Subversion with the same changes don't have the same identity
<Lo-lan-do> In my pastebin, I branched (using svn) trunk to branch1, then I started using bzr on them both, but they seem unrelated bzr-wise.
<jelmer> hmm, that seems wrong
<jelmer> can you paste the output of svn log -v ?
<Lo-lan-do> http://pastebin.com/d34a6b6c8
<jelmer> yeah, that's definitely a bug
<jelmer> please file one. I think it's specific to "bzr missing"
<Lo-lan-do> So it's supposed to work?
<jelmer> yes, it's supposed to show you:
<jelmer> You have 2 extra revisions:
<Lo-lan-do> (I may have to tell clients that it's supposed to work :-)
<jelmer> commit on branch1
<jelmer> started branch1
<jelmer> You are missing one revision(s):
<jelmer> commit 4 on trunk (after branching)
<jelmer> Lo-lan-do: clients as in business clients?
<jelmer> 'evening bialix
<Lo-lan-do> Yes
<bialix> jelmer: 'evening
<bialix> 1.1 is delayed?
<jelmer> bialix: we think so, but I haven't seen any news about it from Martin
<brilliantnut> isn't that a common question today?
<bialix> um?
<brilliantnut> I was asking the same thing a couple of hours ago.. I wanted to move our code from CVS, and we're waiting for 1.1
<bialix> your're using windows?
<brilliantnut> me? yes...
<brilliantnut> umm...
<bialix> because otherwise bzr 1.1rc1 is good enough, IIUC
<brilliantnut> I could reboot into linux, if you like.. :-P
<bialix> no, IIRC there is one pending patch required for Windows for 1.1
<brilliantnut> hmm... our server is going to be on linux, but 12/13 members of our dev team are on windows, so we have to wait for the 1.1 release yet.
<bialix> and last time I moved from CVS  I used cvsps-import plugin, but it works for me only on Cygwin
<brilliantnut> hmm.. no problems there, we've tried that out on 1.0, and worked like a charm.
<bialix> you're planning to use smart-server?
<brilliantnut> yeah, we're planning to use bzr+http with ldap authentication on http, but we ran into some issues when trying that out with 1.0, and there was (at that time) a server and client pending which would fix the specific issues that we were facing... we checked again with 1.1rc1, but we still have that problem.
<bialix> is this patch helps to you: http://bundlebuggy.aaronbentley.com/request/%3C20080108055207.GA9962@steerpike.home.puzzling.org%3E ?
<brilliantnut> hmm, not sure.. but don't think so.
<Lo-lan-do> jelmer: Sent, thanks
<brilliantnut> hmm, so you're saying this is the only patch pending since 1.1rc1?
<bialix> brilliantnut: hmm. if this patch does not help, then what is your problem actually?
<bialix> brilliantnut: I'm not sure actually, but looking at the page http://bundlebuggy.aaronbentley.com/ I don't see anything windows-specific and targeted to 1.1
<bialix> luks: 'evening
<luks> hey
<bialix> how are you?
<luks> little bit busy lately :/
<bialix> I sent you mail recently. asking about sip and compiling new C++ code in QBzr
<luks> yep, sorry for not replying
<bialix> My little research leads me to conclusion that I need full Qt
<luks> it needs full pyqt install for 'setup.py build'
<luks> but it should be still usable without compiling anything
<bialix> yeah? I don't try it yet without compiling
<luks> I've kept the python code for now
<bialix> I build sip myself, but then it say it need pyqtconfig or something similar and then I'm gave up
<jelmer> what's this sip thing I keep seeing in relation to qbzr? It's not the voip protocol, is it?
<bialix> no :-)
<bialix> it's like a SWIG but Qt-oriented
<luks> sip is the tool to generate python bindings for c++ libraries
<jelmer> ah, nice
<luks> more or less like swig, but without the pain :)
<bialix> luks: I'm not sure about last point :-)
<luks> pyqtconfig is part of the pyqt installation
<luks> it's probably not included in the binary installe
<luks> r
<bialix> yeah, but to building pyqtconfig I need qmake
<luks> right
<bialix> and I don't find where I can just download it without full Qt
<luks> you can use the binary installer for qt, but you need the full devel setup to build pyqt
<luks> but as I said, building the c++ code is not required for now
<bialix> seems overcomplicated for me
<luks> it isn't easy to get it running on win, I know
<bialix> luks: working from sources without compiling is working for me
<luks> I'm planning to write the diff view in c++, because currently is scrolls very slowly
<luks> after that, it probably won't work without compilation
<bialix> I understand
<brilliantnut> bialix: I'm sorry, I think I missed your response to my last message if there was any... my net connection is a bit flaky.. :(
<bialix> here is backlog http://bzr.arbash-meinel.com/irc_log/bzr/2008/01/bzr-2008-01-12
<brilliantnut> thanks.
<bialix> I'm asking you about your problems with 1.1rc1
<brilliantnut> oh, apparently my connection went down earlier than I thought..
<brilliantnut> bialix: no, I don't think I can find the specific patch that we were waiting for on that page right now.. but it had something to do with using bzr+http specifically
<brilliantnut> bialix: even currently, we have been able to make bzr:// work, and http:// work, but not bzr+http://
<brilliantnut> then again, maybe we didn't try hard enough this time yet.. :-P we're waiting for 1.1 before spending a night on it.. ;)
<bialix> you need to ask spiv or vila about bzr+http
<bialix> I'm just build win installers
<rjek> OK.  Anybody with any bzr-svn fu?
<rjek> rjek@necrosis:~/bzr$ bzr branch svn://svn.rjek.com/rjek/public/colloquy/trunk
<rjek> bzr: ERROR: /rjek/public/colloquy/trunk is not a valid Subversion branch path.
<rjek> similar error without the /trunk
<Rashomon> Hi all. I'm wondering if you know of any good web-based bzr viewer? (like git-web for example)
<Peng> Rashomon: Loggerhead, webserve, bzrweb.
<Rashomon> Peng:  Do you prefer any one before the other?
<Peng> Rashomon: Never used 'em. :D Loggerhead is the most advanced but also very heavyweight (TurboGears).
<Peng> Well, I dunno if the most advanced part is true.
<Peng> But I think of it as the primary viewer.
<rjek> What's TurboGears?
<Peng> rjek: Major Python web framework.
<jelmer> rjek: try removing ~/.bazaar/subversion.conf and trying again
<rjek> jelmer: OK.
<rjek> jelmer: OK, that managed it.
<rjek> Ta.
<rjek> Although now there's another problem.
<rjek> Recently, the svn depot was rearranged slightly, and the place I'm trying to branch was svn mved
<rjek> bzr appears to only have history since that move.
<Kinnison> Oh well, that's a pity
<Kinnison> bzr_access in contrib/ can never work
<rjek> Rather than including history all the way back.
<Kinnison> the SmartSSHClient
<Kinnison> the SmartSSHClientMedium will always pass --directory=/
<Kinnison> sux
<jelmer> rjek: that may be right. You will have to readjust the branching scheme bzr-svn uses
<rjek> Is it possible to tell bzr to branch an svn depot at a specific svn changeset number?
<rjek> jelmer: I have no idea what that means, much less how to do it.
<rjek> Basically, the trunk used to be in /colloquy/ and it was svn mved to /rjek/public/colloquy/trunk/
<jelmer> rjek: what do you mean with "depot" ?
<rjek> Sorry, perforce terminolgy that's less typing than "respository" :)
<rjek> depot == respository
<Kinnison> or even repository
<jelmer> ahh
<fullermd> I keep my code in a resplendatory.  It makes it look more important.
<rjek> heh
<jelmer> rjek: for help about branching schemes, see "bzr help svn-branching-schemes"
<rjek> Certianly better than a suppository.
<rjek> Yes, I read that
<jelmer> :-)
<fullermd> Well, that's why I don't use svn, see...    ;)
<jelmer> fullermd: bzr has repositories, too :-)
<rjek> jelmer: I read it, and still have no clue.
<rjek> For example, I don't understand why it isn't already working, which puts me in a poor position to fix it.
<jelmer> rjek: the branching scheme determines what paths in the svn repository bzr will consider to be branches
<fullermd> Yeah, but it doesn't have suppositories, and that's the important thing.
<jelmer> rjek: originally it was set to the default /trunk, /branches/*, /tags/*
<rjek> jelmer: Right.  So how do I tell it the svn mv from /foo/ to /rjek/public/foo/trunk is such a branch?
<jelmer> rjek: it's now probably set to /jek/public/colloquy/trunk
<jelmer> rjek: it will have to consider both /trunk and /jek/trunk/colloquy/trunk branches
<rjek> There was no /trunk
<Kinnison> hmm, no jam :-(
<rjek> And there still is no /trunk
<jelmer> /colloquy/trunk then
<Kinnison> jelmer: I think you and rjek are talking at cross-purposes
<jelmer> rjek: try running "bzr svn-branching-scheme --set <repository-url>"
<rjek> jelmer: There was no /colloquy/trunk
<Kinnison> I think he must have run svn mv .../colloquy .../rjek/public/colloquy/trunk
<jelmer> and then make sure both the original and the new branch paths are listed there
<jelmer> Kinnison: ah, ok
<rjek> Yes.  /colloquy was moved /rjek/public/colloquy/trunk/
<jelmer> rjek: so just make sure /colloquy and /rjek/public/colloquy/trunk are listed there
<rjek> listed where?  In what syntax?
<jelmer> each on a single line
<jelmer> when running "bzr svn-branching-scheme --set <svn-repository>"
<rjek> I'm still completely lost.
<jelmer> have you tried running "bzr svn-branching-scheme --set <svn-repository>"?
<Rashomon> one more question. when you are using sftp to checkout or commit stuff to your server, I take it that you use some sort of pubkey? If I need to specify a specific username, how do I do that?
<rjek> I don't understand what that will do yet.
<jelmer> rjek: it edits the list of paths in the Subversion repository that bzr-svn will consider branches
<rjek> ah right, it opens an interactive editor.
<jelmer> rjek: Since Subversion has no notion of branches itself
<rjek> That looks more promising.
<Odd_Bloke> Rashomon: sftp://<user>@<server>/<path>
<Rashomon> alright, that was easliy solved ;)
<Rashomon> Odd_Bloke: So, if I want to make sure my own commits are sent to the server right when they're done, is that done by the bind command?
<rjek> jelmer: That appears to be doing the right thing.  Ta.
<Kinnison> jelmer: now you've fixed rjek's problem, fancy fixing mine? The bzr+ssh protocol always passes --directory=/ which means that contrib/bzr_access is useless and it's the one thing which is currently making bzr a viable possible switch for someone I know
<Kinnison> jelmer is God tonight, and hopefully can do no wrong :-)
 * Kinnison crosses his fingers
<jelmer> Kinnison: sorry, I'm afraid I'm not as godlike as I would like to be in that area..
 * jelmer has a look at bzr_access
#bzr 2008-01-13
<Kinnison> then look at bzrlib/smart/medium.py
<Kinnison> and tell me how on earth bzr_access could ever work
 * Kinnison pouts prettily at jelmer
<Odd_Bloke> Kinnison: Presumably if you're using bzr:// and not bzr+ssh://, IIR this problem correctly.
<Kinnison> bzr_access is explicitly for bzr+ssh though
<Odd_Bloke> Then I don't recall this problem correctly. :p
<Odd_Bloke> Sorry. :(
<Kinnison> :-(
<Kinnison> bzr:// uses a tcp connection
<Kinnison> which is fine if you can trust the network between you and the server
<Kinnison> sftp:// is slow, lacks remote hooks, but works for untrusted networks at the expense of needing a unix user per person who can access trees
<Kinnison> bzr+ssh with bzr_access had promise, but has turned out to be useless
 * Kinnison sighs
<ubotu> New bug: #182469 in bzr "Bazaar has encountered an internal error: exceptions.MemoryError: " [Undecided,New] https://launchpad.net/bugs/182469
<ubotu> New bug: #182477 in bzr "bzr crarshing when trying to commit to the APT repository" [Undecided,New] https://launchpad.net/bugs/182477
<MWinther> Eeey... How do I enable bzr support in emacs?
<Verterok-laptop> MWinther: I don't use emacs, did you look: https://launchpad.net/vc-bzr ?
<MWinther> Verterok: Oh, thanks... I missed the instructions in the comments.
<Verterok-laptop> np, glad to help ::D
<Lo-lan-do> Hi all.  I'd just like a confirmation: private branches can be rebased, but as soon as they're made public they should only merge and pull, right?
<dato> yeah
<Lo-lan-do> Out of curiosity, what happens if I rebase a branch that someone else has already branched?
<jelmer> Lo-lan-do: yes; other than for bzr-svn (which can only track lhs history) there shouldn't be much reason to use rebase
<jelmer> s/which/because it/
<jelmer> Lo-lan-do: Next time they pull they will get a branches diverged error
<jelmer> Lo-lan-do: and if they merge afterwards, the rebased revisions end up twice in "bzr log"
<Lo-lan-do> Oh.  Right, I'll refrain then :-)
<dato> one use case is for right before pushing
<dato> if you notice you're diverged, you rebase and push
<Lo-lan-do> I see.
<Lo-lan-do> Say, is the LCA merge algorithm the default in 1.1?
<Lo-lan-do> I've read it's the bee's knees, so if it's really better I guess I should replace --weave with it in my scripts?
 * rjek wonders idly if there's a bzr-cvs.
<rjek> I suppose it's more of a faff due to the lack of changesets.
<Lo-lan-do> rjek: The website says there isn't
<Lo-lan-do> (I wondered the same thing yesterday)
<rjek> I just want to import another project's source tree into mine.  It'd be nice to have history, but it's not essential.
<Lo-lan-do> I'd suggest cvs2svn then bzr-svn
<thumper> rjek: it is possible to import CVS to bzr using launchpad
<thumper> rjek: if it is open source
<rjek> thumper: It is - it's on sf's CVS server.
<rjek> I only want to make a handful of changes to the source stored in CVS for my own purposes, it's more about reproducability than version control tbh.
<thumper> rjek: luanchpad uses cscvs to import cvs to bzr
<rjek> Does cscvs have advantages over cvs2svn?
<thumper> rjek: I don't really know that much about it
<thumper> rjek: except cscvs goes from cvs -> bzr
<thumper> rjek: rather than cvs -> svn
<rjek> Well, yes - there's an advantage in removing one of the steps, clearly.
<thumper> I'd be curious to see how cvs-svn, then bzr-svn works
<rjek> But I know bzr-svn does a good job.
<rjek> So if cvs2svn does a good job, you'd hope the output would be high-quality.
<thumper> rjek: one of the things that cscvs does is it tracks CVS changes
<thumper> rjek: rather than a one-off conversion
<rjek> That might be more useful, tbh.
<rjek> (ie, that *is* an advantage I would be interested in.)
<rjek> thumper: What's involved in getting Launchpad to track a CVS repository for me?
<thumper> rjek: https://help.launchpad.net/VcsImports
<rjek> Ta
 * rjek mutters at Launchpad.
<rjek> Apparently, optional fields are compulsory.
<thumper> rjek: instead of muttering, file a bug :)
<rjek> I wish to use Launchpad for the minimum amount of time I can get away with :)
<thumper> rjek: why?
<thumper> rjek: best to move this conversation to #launchpad
<rjek> I generally find it hateful.
<dlee> I'm realizing I'm sort of swimming upstream here... trying to find a nice way to at least convert, if not actively track, cvs to bzr; but we have about 40 projects in cvs on a FreeBSD system with people using Windows CVS clients to check in and manage Windows projects.  The projects contain mostly Windows text but also some binaries.
<rjek> I'm told cscvs is the way Launchpad does it.  I'm also told Tailor, once set up, can nicely do incremental imports.
<dlee> I believe bzr *always* checks in/out exactly what you send in:  Check in text from windows, check out CRLF no matter where you are.  But cvsps-import gets LF only from CVS in all cases I've tried, so cvsps-import can't currently manage the conversion because all checkouts would be LF-only even under Windows...
<dlee> Does anyone know if cscvs (which I hadn't heard of until now) could help with this at all?
<lifeless> dlee: so the limiting factor here is we haven'timplemented line ending translations
<dlee> rjek:  I've used Tailor to some good effect with CVS (it *will* do CRLF properly it seems), but in my experience, it fails to notice CVS tags, so they don't show up on the Bzr side.
<lifeless> dlee: the 'right way' to convert your repository is to convert it in binary form and then use line ending translation to get the text files to be checked out as text files on windows
<dlee> lifeless:  Could be thought of that way.  Could also be said that the limiting factor is Windows insists on an annoying EOL translation. :P~~~
<lifeless> well, older macs have different EOL to unix and windows
<lifeless> so its a general problem
<dlee> But anyway... I'd be fine with putting CRLF in Bazaar so everything on the Bzr side checks in/out with no translation... unless (I) someone knows a reason against that, or (II) I can't find a solution before Bzr implements such translation
<lifeless> I think you will have to hack up a solution - editing cvsps for example
<dlee> lifeless: point.
<dlee> lifeless:  I tried hacking cvsps-import but not cvsps itself.
<dlee> lifeless:  Isn't it true though that, if I check in text on Windows, it becomes CRLF inside the Bazaar branch?
<dlee> My reason for thinking it would be best to get things in as CRLF and then not need translation is, mostly, that I thought that is what will automatically happen for new projects we do anyway.
<lifeless> currently bzr just stores the bits untranslated
<lifeless> so if your editor makes CRLF, you get CRLF
<lifeless> I meant hacking cvsps-import actually ;)
<dlee> Right... so in my mind at least, adding CRLF translation won't really help us here unless it happens before we kick off the whole CVS-to-Bazaar conversion, because currently, all projects either will by default, or must for consistency be made to, be stored as CRLF internally in Bazaar.
<dlee> My knowledge of Python remains limited, but my last experiment there was to try using universal_newlines.  I suspect subprocess.popen.communicate() (if that's the right object hierarchy) of quietly converting CRLF to LF.  Cygwin could also be doing it for pipes though it doesn't for output redirection I guess.
<lifeless> well
<lifeless> cvs will ahve everything stored in LF at the moment
<lifeless> there used to be flags for this in the cygwin environment
<dlee> I suppose the next shot I'd have is to pass all cvs/co output through an output-to-file, read-from-file sequence, and see if that preserves line endings.  But I have a better idea that I don't know how to do:
<dlee> (I do have MSDOS endings set in Cygwin, yet all this still happens)
<dlee> Better idea, if it can be done:  Add a cvsps-import flag that makes it convert to CRLF on CVS files that do not have -kb set.  Sound?
<dlee> I like this better because it's OS-independent, and I could mass-convert all 40 projects on the same fbsd system where the CVS repos are. :)
<lifeless> -kb isn't a historical setting IIRC
<lifeless> if it is then sure
<lifeless> hmm, actually paging it in - it is
<dlee> Sorry... if you're doing serious work, don't swap on my account. :-)  But the help is sure appreciated.
<lifeless> I think thats a reasonable short term strategy
<lifeless> the downside is that when bzr gets this natively all your text files will see a full-file diff
<dlee> If/when bzr includes LF translation, won't we need a way to convert existing branches to an internal standard too?  The best I can imagine is svn-like properties, where you flag a file as one ending type or another to make Bzr (I) standardize it internally and (II) spit it out according to the given type.  Not sure whose project endings are though...
<dlee> Scenario:  Under Windows, I check in text.txt and word.doc.  They are both stored without translation--text.txt as CRLF and word.doc as what it is.  If I check out on Unix, I get the same--CRLF and doc.  Then native ending support comes in...
<dlee> If what you're saying is true, I'd see a full file diff on those then too, even though I hacked nothing.  And I think it's inevitible, unless we deal with the branch conversion as a sort of upgrade-type thing.
<dlee> those == text.txt
<dlee> Hmm...I guess internal conversion is optional as long as flagging a file as specifically CR, CRLF, or LF forces (I) output (co etc.) translation and (II) input-time translation to ending type detected in existing branch copy.  I imagine it'll be done though as input-time translation to specified type, and *maybe* output-time also.
<lifeless> we have  wiki page about it
<lifeless> bzr line ending something or other - google FTW
<dlee> lifeless: looking...
<igc> morning
<dlee> lifeless:  Not finding it...but I'll table all this until I do so you don't have to say a lot of stuff I should already know.
<lifeless> http://bazaar-vcs.org/LineEndings
<mtaylor> is there a good internal API doc anywhere for bzr?
<mtaylor> or is poking through the code the best way to get a handle on things?
<lifeless> there are api docs
<lifeless> on the web
<lifeless> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html
<lifeless> though I think thats an old copy, google isn't finding the newer one for me
<mtaylor> lifeless: and that's just generated from pydoc stuff, right?
<lifeless> I use 'pydoc foo' a lot
<mtaylor> so the same info as in the docstrings
<lifeless> yes, though it is richer than pydoc cause it hyperlinks
<mtaylor> well right... but it doesn't have an overview of like "a bundle contains a ... " or whatever
<lifeless> mtaylor: there is also doc/developers/
<mtaylor> lifeless: hm. maybe I'll look in tere
<mtaylor> I'm working on adding bzr support to reviewboard
<mtaylor> and I'm getting tired of reading source
<mtaylor> :)
<lifeless> e.g.
<lifeless> http://doc.bazaar-vcs.org/latest/developers/bundles.html
<lifeless> http://doc.bazaar-vcs.org/latest/developers/bundle-format4.html is probably what you are working with
<mtaylor> lifeless: ah... yes, this looks like more what I'm looking for
<mtaylor> lifeless: so, while I'm bugging you - if I have a branch and a bundle - the bundle contains a list of file ids and a list of revisions that go with the file ids
<mtaylor> lifeless: so I should be able to get a path of the file for a revision based on revision id and file id
<lifeless> have you looked at the bundle buggy code? it has to do everything you are doing
<mtaylor> lifeless: yeah - I was just about to start walking throught that
<lifeless> bundles are not yet directly usable aas branches; they have to be installed somewhere, then you can get a revision tree of the revision the bundle introduced (or a delta, for cherrypick bundles)
<mtaylor> I guess my question is... the bundle buggy code seems to merge_directive.install_revisions(branch)
<mtaylor> ah
<mtaylor> ok, that makes it much clearer
<mtaylor> I was trying to think of a bundle as usable like a branch
<mtaylor> ok
<mtaylor> sweet. thanks!
<mtaylor> lifeless: so if I get a Branch, and then install the revisions of the bundle into the branch, I haven't actually applied that bundle yet, right?
<mtaylor> abentley: hey - I added some patches to a local bundlebuggy to support multiple branches - are you interested in them ?
<abentley> Interested?  Sure.  What do they do?
<mtaylor> abentley: so that I can configure a local repository containing more than one branch
<mtaylor> and then bb can match a merge directive to the branch it belongs with
<mtaylor> so you can manage more than one tree with one bb
<mtaylor> should I send them to you directly? or to the bzr.dev bundlebuggy?
<abentley> Directly to me, please.
<mtaylor> ok
<lifeless> abentley: oh hey!
<abentley> lifeless: Hi.
<lifeless> abentley: I was looking for you a few minutes back; I've just mailed about BreadthFirstSearcher and fetch
<lifeless> abentley: how do you feel about me modifying the searcher to not return ghosts (including the start revisions if they are absent)
<abentley> I don't see anything yet...
<lifeless> literally just sent
<abentley> lifeless: well, my gut says that's the wrong place to be filtering out ghosts.
<abentley> I see it now.
<lifeless> I've had a poke around, and couldn't see any use case for it. ParentProvider needs to return ghosts; I don't think breadth first searching does,.
<lifeless> because breadthfirst searching is already hiding ancestry and topological order details
<lifeless> it could for instance return (next_revs, next_ghosts) if you like
<lifeless> that would be an api break I guess, so next_with_ghosts() or something for api transition
<abentley> lifeless: I think we should be including ghosts in our APIs except where it's clear that they must not be present.  Otherwise, we are likely to get bugs related to hiding ghosts, and never know it.
<abentley> Bug due to using ghosts when they should be ignored will be much more visible.
<lifeless> this is one
<abentley> And it's pretty visible, right?
<lifeless> I agree with your point; however bfs is discarding data
<lifeless> it knows what rev ids are ghosts
<lifeless> it needs to propogate that information
<mtaylor> abentley: sent
<lifeless> or else we end up doing double-queries
<abentley> lifeless: Propogating that info is completely reasonable.
<lifeless> What do you think of the changed return value I suggest ?
<lifeless> (or new on a new method)
<abentley> mtaylor: got it.
<abentley> lifeless: That would be fine on a new method, but I think the default method should just return revision_ids, ghost or not.
<lifeless> I'd like to deprecate next() I think if I add a new method unless there is a good reason for having two query interfaces
<abentley> Well, I'd like to include ghosts by default.
<lifeless> they will be included
<abentley> Won't they be split into a different group?
<lifeless> yes
<abentley> I think that ghosts should be not split into a separate group by default.
<lifeless> I think that once we have identified the ghosts we should keep the separate
<abentley> I think that operations should only be paying attention to whether a revision-id is a ghost if this data is relevant to the operation.
<lifeless> because otherwise we are forcing roundtrips on other parts of the code; or making other parts of the code be filtering when they should not
<abentley> Your proposed API would encourage people to do next()[0] even when ghosts should be included, because 95% of the time there aren't any ghosts.
<lifeless> I think you are creating a source of performance / correctness bugs for users of that interface
<abentley> I have not proposed anything that would damage performance.
<lifeless> I explained above how it hurts performance
<abentley> Your explanation suggests a misunderstanding of what I'm saying.
<lifeless> anyhow, I'll do as you desire because my need will be met by the new method
<abentley> If you want an API that splits out ghosts, fine.
<abentley> But don't deprecate the old one.
<abentley> Because it's worse for people to ignore ghosts when they should not than to pay attention to ghosts when they should not.
<lifeless> I understand your motivation and agree in principal; on this particular API I think you are wrong.
<lifeless> anyhow, -> doing the new method now.
<lifeless> in particular returning the start revision ids for a search when they are absent from the repository is really hard to work with
<lifeless> and thats just the special case of ghosts
<lifeless> abentley: so I have a separate request; I want to modify next() to return StopIteration if the start revisions are all ghosts
<lifeless> abentley: I don't have to, but please think about that
<abentley> Why?
<lifeless> because I spent the greater part of an hour while writing the pack fetch logic to handle that case; its sufficiently confusing as an api that there is a 5 line paragraph explaining code that uses it
<abentley> But now you'll have an API that splits out all ghosts.
<abentley> So callers that don't want ghosts won't get any.
<lifeless> yes, and I'll use that; I'm thinking of users of next, if people that want to use it do so
<abentley> That seems like an inconsistency in the API.
<poolie> hello
<abentley> If you ask for 5 ghosts and 1 non-ghost, you get all of them listed, but if you ask for 6 ghosts only, you get nothing?
<lifeless> you're right I guess, I'll just write the more usable api I need and leave it at that. It feels wrong to have an api that discards information which is relevant to its callers is all
<abentley> Btw, one client that wants to keep references to ghosts is Graph.heads
<abentley> poolie: Hi.
<poolie> hello
<poolie> welcome
<abentley> Thanks.
<lifeless> abentley: it does?
<abentley> Sure.  We can't assume a revision isn't a head if we don't know its derivation.
<lifeless> we can't assume it is either; I would expect us to signal that to the caller
<lifeless> hmm, this means that we'll generate inconsistent last-changed revisions for baz imports, just in reverse order to how we used to do it
<abentley> If the revision itself is a ghost, but is not reachable from candidate heads, it must be a head.
<abentley> We may wind up with some false heads if some descendant is a ghost.  I don't think we can avoid that.  But we can know whether the ghost revision itself is a head.
<lifeless> the if the revision is /not/ a ghost, but is not reached, and we encounted ghosts, we cannot tell if it is a head or not, unless it reached the other heads
<lifeless> if the revision is a ghost, it is not a head if it is reachable from some other head
<lifeless> so yes we have to consider ghosts in heads(), but we need to know within heads() which are ghosts and which aren't to know whether to say 'head', or 'indeterminate'
<abentley> lifeless: agreed.
<lifeless> we can avoid ending up with false heads if our api is allowed to signal that it could not determine the answer. Which any ghost handling api must be able to do
<lifeless> this is ok, it just means that we're not finished with heads()
<abentley> Which is pretty reasonable since I implemented heads by accident :-)
<abentley> mtaylor: these key lengths you're proposing don't seem to have any basis in specs.
<abentley> for example, bug ids are URLs, and I don't think there's any length limit on URLs.
<abentley> Even IE can do 2048-char URLs.
<Peng_> Apache can limit URLs. I once got a 400 Bad Request error or something for a 13,000 char URL.
<lifeless> squid limits to 4K at the moment, we're working on raising that
<abentley> Peng_: Sure.  But does the spec say anything?
<lifeless> its not limited
<mtaylor> abentley: yes... that's one of the things I wanted to talk to you about... is there a place I can find what those lengths should look look?
<mtaylor> look like, rather?
<abentley> Well, URLs have no length limit.
<abentley> I don't think email address do either, but I haven't checked as carefully.
<mtaylor> ah, I suppose if I read the next line in your response. :)
<mtaylor> ok. well then it might be a good idea to remove the lenght limit and introduce an artificial primary key there then
<ubotu> New bug: #182715 in bzr "Graph.heads() gives false heads sometimes" [Undecided,New] https://launchpad.net/bugs/182715
<mtaylor> as using a blob as a primary key is usually a really inefficient thing
<abentley> mtaylor: That's why I've been slow responding to your first patch.
<mtaylor> oh, did I send one already?
 * mtaylor has a dead brain this week
<mtaylor> I'll see if I can rework that
<abentley> mtaylor: if the column is indexed, it shouldn't matter, should it?
<mtaylor> no, it shouldn't
<mtaylor> it's just that normally seconary indexes will contain a copy of the primary key so it knows how to point to the right row
<mtaylor> so with a really big primary key, you wind up copying that data too much
<abentley> So with variable-length keys, do you still pay a penalty when the keys are small?
<mtaylor> not necessarily - that's sort of db engine specific
<mtaylor> but in this case, elixir is making that column a blob
<mtaylor> and most dbs have really bizarre implemenations of blobs at best
<mtaylor> and in this case, mysql doesn't allow a blob as a primary key unless you specify a prefix length on the primary key
<rjek> branch-format: Unable to handle http code 401: Unauthorised
<rjek> Tsk.
<abentley> Well, I'm in favour of using artificial keys-- makes for cleaner URLs.  But I can't say I'm looking forward to adding migration code.
<mtaylor> hehe
<mtaylor> no
<mtaylor> I was justing thinking that myself
<mtaylor> I'll see if I can get it working and then send you a new patch
<abentley> Also, renaming dev.cfg is okay, but I would prefer that it continue to specify SQLite.
<abentley> Probably I should roll config.ini into the TG config system.
<abentley> That way we can stick all the local configuration in there.
<abentley> including databases and web paths.
<abentley> Also, I don't think "tree" is the right term for branches.
<abentley> Also, erroring if the target_tree is not going to work on bzr.dev-- *lots* of people don't set target_tree correctly.
<abentley> Also, please don't comment-out code.  We have a VCS, so just delete it.
<abentley> We can always get it back if we want.
<abentley> Also, you've got '/buggy' in a lot of places where it shouldn't be.
<abentley> So I think the idea is an improvement, but there's some work needed on the implementation.
 * abentley heads out for groceries
<lifeless> abentley: ok that patch is sent in
#bzr 2009-01-05
<igc> lifeless, poolie: I'd like to put a patch up for per branch rules again
<igc> I'm thinking of a .bzr/branch/rules file that doesn't propagate
<igc> ala branch.conf
<lifeless> so some questions
<igc> Does that sound ok?
<lifeless> a) why not put it in branch.conf
<igc> I'll look into that
<igc> I suspect formatting might be an issue (but it might not if we agree to allow nested sections)
<lifeless> and sure, it sounds ok; presumably you need wt5 to use it, but you may be able to get away without a new branch format object as its not affecting historical data
<lifeless> (I honestly prefer new objects every time, but I get the objection folk have to that)
<fullermd> If it really affects the WT primarily, why put it in .bzr/branch/?
<lifeless> fullermd: that was my next question :). But I can come up with an immediate use case - checkouts
 * fullermd doesn't follow.
<lifeless> igc: so here is a thing to think about
<lifeless> igc: consider a loom, or a git-branch-style setup
<fullermd> .bzr/checkout/ is always there (at least, unless there's no WT, in which case rules don't mean anything anywho)
<lifeless> igc: 'bzr switch foo' - that will have to backout-gone-and-apply-new rules
<igc> lifeless: yeah, good point
<igc> if it were .bzr/checkout/rules, that wouldn't be the case right?
<lifeless> igc: I think the root of the concerns I had about version-propogating rules derives from this basic thing; these transformations are inherently local to the tree object
<lifeless> but the proposed design really started/wanted to treat them as something related to the project - which we have no effective abstraction for
<lifeless> igc: right, .bzr/checkout/rules would keep a constant ruleset during 'bzr switch'
<lifeless> (in the absence of any other places for rules to be sourced)
<igc> lifeless: I expect tree-specific rules to override those in .bazaar/rules
<lifeless> igc: .bazaar/rules is constant for a single invocation though. I was referring to e.g. .bazaar/locations.conf based rules
<lifeless> (which is another case of trying to allow rules to be included in normal config files0
<lifeless> hmm, I didn't mean to sidetrack things
<lifeless> getting a non-propogating tree-working-with-rules thing that people can use today++
<igc> lifeless: thanks for the feedback. So I think we're agreed that .bzr/checkout/rules would be a step forward without causing obvious problems down the track?
<lifeless> igc: myself, I have a directory with all my trees for project X
<lifeless> igc: so *I* would want, until we have a good answer for 'project' to configure them in locations.conf
<igc> fullermd: implicitly knowing "the rules" just seemed the bzr way
<lifeless> igc: its where I configure email settings and default push locations
<lifeless> igc: which are the other project-wide settings I work with today
<igc> lifeless: I think we greatly under-utilise locations.conf as a feature of our product
<fullermd> One way to choose which problem to cause is considering the knock-on effects of each choice.
<fullermd> Like, if you plunked it in branch.conf, it could be used to try and force a resolution of the "allow per-branch config that propogates" chewtoy.
<lifeless> igc: I agree we want to end up with just knowing the rules, as much as possible
<igc> from memory, I originally proposed rules inside nested sections of branch.conf and locations.conf (and it got knocked back). Perhaps it's worth reconsidering that. I still have the branch supporting nested sections. :-)
<lifeless> lunchtime, got some chores to run too, back in a bit
<igc> fullermd: yes
<jml> remind me, how do you change the branch location of a working tree?
<jml> say you've renamed the branch and want the tree to point to the new location
<spiv> jml: "bzr switch" maybe?
<jml> spiv: it raises errors about the old branch not existing
<spiv> Hmm, I thought I saw patches about that bug a while back.
<spiv> The crappy way is to edit .bzr/checkout/something
<igc> Hmm - I'm talking crap. My nested sections stuff was related to defining shell hooks, not rules, it seems
<jml> spiv: there doesn't seem to be a reconfigure either.
<jamesh> perhaps switch could do something sensible if the working tree's basis revision existed in the new branch?
 * Peng_ finally deletes old .pyc files. When was bzrlib/plugins/multiparent.py removed? :P
<Peng_>  /renamed/whatever
<fullermd> Oh, heck, not even a year ago.
<jml> spiv: I filed https://bugs.edge.launchpad.net/bzr/+bug/313898
<ubottu> Error: <Bugtracker.plugin.Launchpad instance at 0x865470c> bug 313898 not found
<fullermd> Try bug 285055 and bug 308798
<ubottu> Launchpad bug 285055 in bzr "switch --force on lightweight checkout connects to original remote branch" [Medium,Fix committed] https://launchpad.net/bugs/285055
<ubottu> Launchpad bug 308798 in bzr "Unable to switch lightweight checkout when it's parent branch is renamed" [Undecided,New] https://launchpad.net/bugs/308798
<spiv> jml: thanks
<igc> abentley: can you bounce BB please if you're around?
<jml> how would y'all feel about a bzr command that opened a branch's web page in Launchpad in the user's default browser?
<beuno> jml, it would make me cry of joy
<AfC> jml: we don't use Launchpad, so I wouldn't notice.
<jml> cool. I'll file a bug and say I'll mentor it (and maybe jfdi later)
<jml> beuno: https://bugs.edge.launchpad.net/bzr/+bug/313916
<ubottu> Ubuntu bug 313916 in bzr "Command to open a branch's web page in Launchpad" [Undecided,New]
<AfC> jml: now. If the branch metadata carried general notions like "our home page is $x, and our bug page is $y, etc" then a "Command to open a branch's web page" would be superlative.
<jml> AfC: yeah, I mention that on the bug.
<AfC> jml: otherwise it's just another feature that makes people think that Bazaar is only for people who work at Canonical.
<AfC> [as evidenced by the FUD in the latest GNOME VCS thread]
<AfC> [but a) we're going to lose that one, and b) who cares, so that's not a very good example. The point holds, though]
<jml> AfC: the bug metadata is already there... it just has lousy APIs and not much in the way of command line access
<AfC> jml: I would define that as "not actually there" then, but {shrug}
<jml> (o for a thousand days to hack)
<AfC> indeed
<AfC> but the sun is out, and it's 30â, so forget hacking. I'm going to the beach.
 * igc lunch
<rockstar> If I deleted a file in one branch, and in another branch it was moved, how do I resolve the conflict when I merge that other branch, so that the file is deleted?
<lifeless> rockstar: if it was just moved it shouldn't conflict, if it was moved and edited then the edit will cause a conflict. Just remove it again
<rockstar> lifeless, I can't because the file doesn't exist...
<lifeless> rockstar: bzr st
<rockstar> Ah, bzr resolve <path/to/file> worked.
<rockstar> Path conflict: <deleted> / tools/run_debug.py
<rockstar> lifeless, ^^
<lifeless> markh: btw with bugs
<lifeless> markh: you don't need to make things invalid on bzr, you can just edit the task to say its for bzr-gtk only
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> brisbane core has some networking implications
<lifeless> do you have a branch working on generating a stream
<lifeless> for push and pull
<spiv> I do, for push.
<spiv> http://people.ubuntu.com/~andrew/bzr/streaming-push (it's a loom)
<lifeless> cool
<lifeless> are there docs on the wire format you're putting together? I'd like to collaborate on that early
<lifeless> also, have you looked at what git does to determine the objects to include in its wire transfers?
<spiv> lifeless: hmm, no docs yet, although it's still in flux a bit.
<spiv> lifeless: it's more-or-less a series of bencoded tuples of the attributes of the ContentFactory objects returned by get_record_stream
<spiv> And no, I haven't looked at what git does.  Or rather, I've looked a bit, but I didn't manage to locate any clear docs on the subject so I went and did something else :)
<lifeless> ok, well to figure out anything git does I've found reading the source the best way
<spiv> I don't suppose you have a bzr mirror of the git source handy? ;)
<lifeless> nope
<lifeless> what about the actual delta content
<lifeless> uhm
 * jelmer has enough knowledge about the git wire protocol now that he's implemneted it :-)
<lifeless> let me be more precise in a couple of ways
<lifeless> jelmer: what I want is the algorithm for determining objects-to-include and objects-we-can-use-deltas-against
<spiv> jelmer: I take you used the source to learn about it?
<lifeless> jelmer: if you could write that up that would be great
<jelmer> lifeless, that's two different processes
<jelmer> basically what happens is:
<lifeless> jelmer: things like is it chatty, does it assume cheap heads-lists, does it use the reflogs and so on
<jelmer> -> server sends list of HEADs it has
<jelmer> <- client sends "want <rev>" for each <rev> it wants to end up with
<lifeless> jelmer: this is push or pull use case?
<lifeless> jelmer: also is this full duplex or back and forth on each item
<jelmer> then the client starts sending "have <rev>" for the ancestors of its local heads, until the server confirms it has one of those revisions
<jelmer> lifeless, this is pull
<jelmer> lifeless, it's full duplex
<jelmer> so the client may see one of the acks from the server too late, but that's not a problem as sending a couple more "have <rev>"s is way cheaper than spending a roundtrip on each revision
<lifeless> breadth first traversal I presume
<jelmer> yup
<jelmer> after this process, the server sends the complete contents of a .pack file that can be written to disk immediately
<lifeless> and it does this per-local-head or all-in-parallel? if its all-in-parallel, does it trim when a particular head is reached
<lifeless> or just keep going until all have had revs reached
<lifeless> or until any-rev is reached?
<lifeless> [I can rephrase this as - whats the algorithm, as opposed to the mechanics:P]
<jelmer> all-in-parallel
<jelmer> it obviously stops sending "have <rev>" for the ancestors of a particular head as soon as the server has confirmed it knows about a particular head
<jelmer> it obviously stops sending "have <rev>" for the ancestors of a particular head as soon as the server has confirmed it knows about a particular *ancestor* of that head
<lifeless> doesn't it need to know all ancestors? I mean, consider a:[b,c]
<lifeless> if the server says it knows b, and we want a (but don't have a) that doesn't imply that the server has c
<lifeless> erm bad example. a:[b,c], b:[d,e]
<jelmer> yes, it needs to know all ancestors
<lifeless> want: a
<lifeless> anyhow, this is not surprising, its what I thought it did :)
<lifeless> the key differences to bzr are server-state-is-accrued and full-duplex
<jelmer> yeah, it's not rocket science but it is a really fast protocol
<lifeless> these are only rev ids though right, it doesn't recurse into dir objects at this stage
<lifeless> it infers those when building the pack
<lifeless> ?
<jelmer> lifeless, yes
<jelmer> lifeless, same for what to delta against what
<lifeless> secondly, I thought git had thin packs for pull and push
<jelmer> what are thin packs supposed to be?
<lifeless> which were *not* written verbatim to disk but instead expanded to meet the normal assertions about pack content
<lifeless> they are packs which have deltas external to the pack
<jelmer> lifeless, ah, right
<jelmer> lifeless, but at least as far as I can tell, those can exist in regular git packs as well
<jelmer> and if not, we have a dulwich bug :-)
<lifeless> oh also the HEADS list is something we try not to do, because that list can be _big_
<lifeless> no, they are not meant to exist in  regular git packs
<jelmer> lifeless: sorry, it's the list of refs in the case of git, not the list of heads
<jelmer> I don't think there's an easy way to find all heads in git even, short of scanning the repository (much like bzr)
<lifeless> jelmer: ah goo
<lifeless> *good*
<lifeless> so thats name:revid?
<jelmer> basically, yeah
<lifeless> ok
<lifeless> spiv: back to our discussion
<jelmer> hth
<lifeless> jelmer: it was useful
<lifeless> jelmer: still not clear on the logic for whats assumed held by the client for thin packs
<jelmer> lifeless, what do you mean with held by the client?
<jelmer> lifeless, what sha1-objects are held by the client?
<lifeless> jelmer: if you wanted to dig that up it would be interesting. (imagine a local repo with alternate A pulling from repo B - a thin object reference that is in A and not local would require another network op to fix the thin back  (see git-index-pack --fix-thin).
<spiv> lifeless: so, the current struct I send for a record is (sha1, record.storage_kind, record.key, parents, build_details, record.get_bytes_as(record.storage_kind))
<spiv> lifeless: jam has asked that I add the compression parent to that, for obvious reasons.
<jelmer> lifeless, "alternate A"?
<jelmer> lifeless, there is no such thing as ghosts
<lifeless> jelmer: look up git alternates - stacked repos
<lifeless> spiv: well compression information should be specific to the compressor
<spiv> Right, that would be ideal.
<lifeless> I think you should refresh your memory of http://www.kernel.org/pub/software/scm/git/docs/technical/pack-format.txt at some point soon
<lifeless> just as a reference
<lifeless> e.g. we don't need the sha1 in this stream, its dead space. We can sha the entire stream for integrity checking
<lifeless> what are the build details?
<spiv> record._build_details for 'knit-*' records, otherwise blank (signified by an empty tuple).
<lifeless> spiv: have you looked at group compress
<spiv> Not recently.  It's probably about time I refreshed my memory.
<lifeless> ok
<lifeless> basically
<jelmer> lifeless: As far as I can tell there's no particular special-casing for alternates so that would indeed require another network op
<lifeless> label:
<lifeless> sha1:
<lifeless> CONTENT
<lifeless> rinse and repeat, thats the entire format
<jelmer> lifeless, not entirely, the delta'ed entries don't have a sha1
<spiv> Basically the serialisation at the moment is pretty simple-minded, it just dumps out the attributes so that it's easy for the remote side to construct an equivalent object.
<lifeless> it will not fit at all well into what you seem to be proposing
<lifeless> spiv: yeah, thats what we did last time, and why I want to engage on this early ;)
<jelmer> nm, I thought you meant the separate entries
 * jelmer gets some sleep
<lifeless> first suggestion I'd make is that your current bencode tuples be marked as substreams - a pathological case if you like (only one element)
<lifeless> but that would allow a number of group compress streams to be embedded
<spiv> So, which things are constant for all records, and which can vary?
<lifeless> each of which contain N actual texts
<spiv> (key, sha1, record_kind), and everything else depends on record_kind?
<lifeless> nope, a step up
<lifeless> stream = [substream ...]
<lifeless> substream = gcstream | knitstream | weavestream
<lifeless> knitstream = [bencode tuple ...]
<lifeless> gcstream = to be discussed (does it support parent meta-data, or is that forced up a level, etc)
<lifeless> weavestream = a weave verbatim
<spiv> Ok, although that doesn't fit 100% neatly with the get_record_stream API.
<lifeless> it should fit perfectly
<lifeless> (the intent of get_record_stream is to be a least-assumption API, not to reflect what is in a wire byte sequence)
<spiv> Ok.
<spiv> I was thinking about stacking, but I guess that's handled by the caller of the repo(s), not the repo itself.
<lifeless> that was one of the problems with the prior network stream - it was setup to fit the knit api
<lifeless> but the knit api was random access and quirky
<lifeless> I'm not sure how stacking fits in here
<jml> is there a way to do 'bzr log -r(tag:foo+1)..'
<lifeless> after:/
<lifeless> ?
<lifeless> dunno
<lifeless> spiv: so the fact there are knitstreams as subelements wouldn't be exposed by the api
<jml> nope
<spiv> There's no "after:" rev spec.  There's before:, but that's easier to define.
<spiv> I guess after: might be well-defined in the context of a particular branch.
<lifeless> spiv: as for the individual text record, sha1: is redundant IMO, we should be aiming to regenerate the text as we receive it to determine the sha1, to prevent bad data being sent to us
<spiv> lifeless: right, taking bytes off the network and turning them into a stream is straightforward there.  But taking a stream and turning it into bytes seems less neat to me.
<lifeless> spiv: which is supported by the record stream API (None for sha1)
<spiv> Probably you just peek at the first record to figure out what sort of (sub)stream to serialise.
<lifeless> well
<lifeless> a stream->bytes adapter would be nice
<lifeless> I imagine it would start with an empty output stream
<lifeless> then start eating records and outputting them as bytes, with record-storage-kind adapters to do things like eat all the records of a weave but output just the weave
<lifeless> [though weaves are a bad example because they just generate FullTextContentFactory objects, as I wanted 'works' not 'optimal'
<lifeless> ]
<lifeless> git-pack-records, for reference, holds a little metadata about every object, then decides based on that how to retrieve it and how to include it
<lifeless> (e.g. to just copy it, or to extract and redelta, etc)
<lifeless> concrete example though, in gc, record.get_bytes_as(record.storage_kind) -> nonsense-data
<lifeless> so, I started at 730 this morning, I'm going to call it now ;)
<lifeless> gnight poolie spiv igc jelmer etc etc etc
<igc> night lifeless
<spiv> lifeless: g$timeofday
<igc> time to hit the review Q
<igc> if anything is particularly important in there, let me know
<DBO> you know what would be great, if bzr was psychic enough to know I was idiotically pushing to the wrong branch...
<nDuff> DBO, so write a plugin offering mind-reading functionality. It's Python, right? -- there's probably a module for that.
<DBO> yeah...
<DBO> i should... but if we are going to read minds
<DBO> we'll have to use lisp
<jamesh> DBO: it'll tell if you're pushing to a diverged branch.  You want something more than that?
<DBO> jamesh, mostly I am just noting that due to the wonderful way bzr remembers branches (really, I do love it), i often push to the wrong branch after a merge
<DBO> or when i mean to merge =P
<DBO> its really just me being stupid and coming to share a bit of feedback with you guys
<DBO> i do have a real question though
<DBO> is it launchpad or bzr that is god awfully slow for pushing and pulling?
<lifeless> DBO: mainly bzr, its getting fixed
<DBO> lifeless, mind sharing whats going wrong, just for the curious
<jml> btw, I read something on python-dev that said Bazaar was "experimenting" with a time-based release process.
<jml> I chuckled a little.
<spiv> jml: we even inhale!
<jml> spiv: :D
<jamesh> jml: maybe in a few years we'll find out if it was a worthwhile experiment
<vila> hi all and happy new year
<igc> hi vila!
<spiv> vila: g'evening.
<soren> How do I change the parent branch url? I used to just do "bzr pull" in one of my local branches, but I've moved the branch on launchpad, and I can't seem to figure out how to get my local branch to cope with that.
<spiv> soren: "bzr pull --remember NEW_URL"
<soren> *facepalm*
<soren> Of course.
<soren> spiv: Thanks!
<igc> spiv, vila: are you received mailing list emails this afternoon?
<igc> seems to be blocked somewhere?
<vila> igc: hmm, last one seems to date back 7 hours ago...
<igc> vila: thanks - so it's probably not me or my ISP then. :-)
<vila> igc: but I got mail from lp 2 hours ago
 * igc dinner
<igc> night all
<Keybuk> err, why is "bzr shelve" simply throwing away things and not actually shelving them?
<Keybuk> abentley: is bzr shelve broken?
<abentley> Keybuk: Not in my experience.
<Keybuk> I do bzr shelve, it puts changes in "id 4"
<Keybuk> then bzr shelf ls says
<Keybuk> Patches on shelf 'default': None
<Keybuk> (and then seems to leave the checkout locked)
<Keybuk> bzr	1.10-1~bazaar1~intrepid1
<Keybuk> bzrtools	1.10-1~bazaar1~intrepid1
<abentley> The shelf command is from shelf1, and the shelve command is from shelf2.
<Keybuk> err?
<abentley> You want "shelve --list"
<Keybuk> bzr: ERROR: no such option: --list
<abentley> Are you sure you said shelve --list, not shelf --list ?
<Keybuk> yup
<abentley> Ah.  --list is in not supported by 1.10.  It'll be in the next release.
<Keybuk> does shelve do something different now then?
<Keybuk> where does it stash the changes?
<abentley> Keybuk: Yes, shelve is much more thorough now.  It stores the changes in .bzr/checkout/shelf
<Keybuk> as patches still, or as a branch?
<abentley> Keybuk: as a serialized TreeTransform.
<Keybuk> I'll pretend I understood that so I look smart ;)
<abentley> Keybuk: Essentially, as a delta-compressed working tree.
<Keybuk> if you unshelve and there are conflicts, does it still throw the whole thing away? :p
<abentley> No, when you unshelve, it does a merge.
<abentley> bbl
<Keybuk> \o/
<NfNitLoop> *sigh*
<NfNitLoop> after I branched from a svn trunk...
<NfNitLoop> someone had the bright idea of making part of that trunk read-only.
<NfNitLoop> which makes merging back into it... non-trivial.
<NfNitLoop> This place does not grok version control.
<LeoNerd> I just did 'bzr shelve' in an svn checkout without realising it, and ... I'm quite surprised it actually works
<jelmer> LeoNerd, integration ftw (-:
<LeoNerd> indeed
<beuno> jelmer, Loggerhead 1.10 landed in Jaunty. You rock, thanks
 * jelmer hugs ubuntu autosync
<seb_kuzminsky> i think there's a bug in bzr-email
<seb_kuzminsky> i think it does not honor post_commit_difflimit=0 like the docs say
<seb_kuzminsky> emailer.py line 119
<seb_kuzminsky> i get empty commit emails when i set it to 0
<seb_kuzminsky> i'll just set it to 100000 for now
<beuno> poolie, ping
<burak575> hi, i made a mistake and a file is corrupted, how can i get last commit of just this file?
<beuno> burak575, bzr revert -r -1 path/to/file
<burak575> beuno: thanks i am gona try it :)
<burak575> it worked thanks again
<beuno> np
<camason_> hi guys. I've been working as a private branch, and I'd like to make this a shared repo. I created a repo with init-repo. How do I now push all of the history of the branch to this repo?
<fullermd> Is the repo above the branch?
<camason_> repo is in /srv/bzr/myrepo    project is in /development/projects/myproject
<fullermd> Mmm.  Are you wanting to move your working location over to that new spot?
<camason_> no I want to keep working in /development, but have that bound to /srv/bzr/myrepo so that I can use that as a centralized repo
<camason_> I work like that with another project, but its been like that since day one. I'm wanting to move this over
<fullermd> So, what you're wanting to have, is a branch in /src/bzr/myrepo/whatever, that you have a checkout of in /dev/projects/whatever.
<camason_> I suppose so. But its a repo created with init-repo
<fullermd> Well, /srv/bzr/myrepo/project/whatever then; doesn't change anything substantial.
<fullermd> So what you need are actually 2 things; first, you need a branch at that new place, and second, you need your old place to become a checkout of it.
<fullermd> The first you can do with push; just push the existing branch to the new path.
<fullermd> (or use 'branch' to do it from outside; either way)
<camason_> isn't a branch different to a repo?
<fullermd> Yeah, but you've made the repo already, right?
<camason_> yeah
<fullermd> So the new branch (whether it be push-made or branch-made) will use it.
<fullermd> Other than making a repo, you pretty much never do anything that refers directly to it; it's implicit.
<camason_> well I did bzr push /srv/bzr/myrepo
<camason_> and bzr status shows that my working area is a checkout of the repo
<camason_> but the file size of the repo is too small to have any history in it
<fullermd> Well, it's not technically an error to have a branch colocated with a shared repo, especially if it's no-trees.
<fullermd> OK, let's back it all up.  Can you pastebin an 'info' output of both locations?
<camason_> oo i forgot the no-trees bit
<fullermd> No big deal.  That just sets a default.
<fullermd> You can use 'remove-tree' to whack the WT you don't need.
<camason_> brb 2 mins going to get on main pc
<CaMason> that's better
<CaMason> right so my /srv/bzr/myrepo shows shared repository: . repository branch: .
<fullermd> So, yeah.  That's a little unusual maybe, but it's valid.
<CaMason> i can just delete this repo and start again
<CaMason> I just want a centralised repo that I can access via SFTP from many machines
<CaMason> and unbind when I have no interwebs :)
<Peng_> FWIW, to make a repository no-trees, just touch .bzr/repository/no-working-trees (and for the reverse, delete it)
<CaMason> Perhaps someone can explain this workflow to me. In SVN, I would make a repository, and that would contain my branches. So how would I achieve that with bazaar, and what happens when I create / delete branches?
<fullermd> In svn, the repository has significant semantic meaning.  In bzr, it doesn't.
<CaMason> right, I'm getting confused at the difference between a repository and a branch
<fullermd> There's no semantic difference between having 15 standalone branches in /srv/bzr/myproject/, or having a shared repo in /srv/bzr/myproject/ with 15 repo branches.
<fullermd> It just saves space and I/O.
<CaMason> ok, so how does a 'repo branch' differ from a standalone 'branch' ?
<nDuff> CaMason, it stores data in the repository -- and thus doesn't have duplicate data stored between it and any other branch in that repo -- but that's under the hood; from a user perspective they're *exactly* the same
<fullermd> All branches have a repository; that's where the revisions are stored.  Standalone branches have their repository internally; repo branches use an external shared repository (which presumably is also being used by other branches)
<CaMason> right ok this makes more sense
<fullermd> (this is a slight lie, because some side effects can leak through the abstraction, but it's near enough that you can ignore them)
<CaMason> Perhaps an example would help here. I basically have multiple clients, with multiple projects
<CaMason> so I have /srv/bzr/clients/myfirstclient/
<CaMason> then myfirstclient will have multiple projects. So each 'project' would be a shared repository?
<fullermd> That would be one way to do it.
<nDuff> CaMason, so if /srv/bzr is a repository, and you push from the branch at /srv/bzr/clients/myfirstclient/project1 to a server that client owns (for instance), they get only the bits they own..
<fullermd> And probably the best way.
<fullermd> You could have one repo for client.  Or one repo for all your clients.  Or one repo for all your bzr stuff.
<nDuff> CaMason, ...and the above is how I personally would do it, were fullermd (who knows better than me) not advising otherwise.
<fullermd> Or, the other way, one repo per branch (e.g., a bunch of standalone branches).  There's not necessarily a right way.
<fullermd> However, you probably don't have much (or any) shared code between projects.  So, spanning projects with one repo probably doesn't gain you anything.
<CaMason> ok. I've probably still got my SVN hat on somewhat
<luks> one repo for everything is maybe not a good idea for locking reasons
<CaMason> no, none of the projects will share any code
<luks> if multiple users are going to push to that
<nDuff> CaMason, oh -- if they don't share any code, then there's no need to have shared repos.
<fullermd> And some operations will necessarily scale to the size of the repo, so a single huge repo for everything may have some performance implications.
<nDuff> CaMason, ...but if you're going to have different branches of any given project, you *will* want to have those branches within the same repo -- makes branching much cheaper (in both space and time)
<fullermd> I tend to have approximately a repo per project.  It lets me keep things nice and organized.
<CaMason> right. So for a particular project, I may want to 'branch' the code off to work on two lines simultaneously
<CaMason> so how do I branch that differently to a normal 'branch' procedure?
<fullermd> Having a repo per branch (bunch of standalone) wastes a lot of space and I/O.  Having repos spanning projects gains very little, so...
<nDuff> CaMason, it's just a normal branch, as long as the path you're branching into is under the repo directory.
<fullermd> No differently.
<CaMason> I see. We're making progress :)
<fullermd> When you make a new branch /some/where, it will look and say "Hm, is there a shared repo at /some/where?  If so, use it.  If not, is there one at /some?  Use it.  If not, is there one at /?"
<CaMason> I see :)
<fullermd> And when it runs out of parent dirs to check, and hasn't found one, it makes a standalone branch.
<fullermd> Now, this means that if you have a branch in a repo at /some/where/repo/branch/, if you move that branch to /some/where/branch/, things will blow up, because it can't find its repo anymore.
<CaMason> right
<fullermd> But if you move it to /some/where/repo/extradir/branchfoo, it'll still work just fine, because it finds the repo at ../../
<fullermd> (UNLESS you make a repo in extradir too, in which case it'll find that repo, but it doesn't have the revs branchfoo wants, in which case it'll blow up too)
<CaMason> makes sense
<fullermd> But you don't tend to run into situations like that, because you hardly ever make one repo inside of another, or move branches in and out of repos with mv.
<CaMason> ok, does this first part make sense then: http://pastebin.com/m2d6df460
<fullermd> Why rich-root?
<fullermd> svn conversion?
<CaMason> no idea :o I read it somewhere in the docs
<CaMason> I don't need it?
<fullermd> Well, if you don't have need for rich root support, you should probably steer clear of it, just to make everything simpler.
<CaMason> ok will do :D
<fullermd> bzr-svn conversions are the main source of need for rich roots ATM.
<CaMason> ok. ignoring completely
<CaMason> so just bzr init-repo --no-trees ?
<fullermd> Other than that, it looks like a good set of steps.
<CaMason> just another question that may or may not add complication
<fullermd> As Peng_ mentioned above, remember that --no-trees or its complement doesn't tie you down forever.  You can remove trees from a branch, or add a tree to the branch, or even [manually, bleh] change the repo's setting.
<fullermd> It just gives you the default action.
<CaMason> ok that's cool
<CaMason> a 'project' will contain 2 (or more) parts.. the graphics & design, then the php code, then [..others]
<fullermd> (of course, with a 'central' repo that you don't work directly in, you probably don't want trees anyway, so that would be right)
<CaMason> I'd like to version all of that also. So, would you suggest creating the repo under project/ and then having 2..n branches for each of those elements?
<CaMason> or would you create a repo for each 'section' of the project? I'm thinking that the design may need to be 'branched', and is not related to the php code
<fullermd> I'd stick with one repo for the project.
<fullermd> I think the gains from splitting smaller are tiny, and it just adds management headache.
<CaMason> ok. and is there any way I could isolate those 3 sections within the repo?
<fullermd> You can make extra dirs.
<CaMason> wont that matter?
 * CaMason takes off his SVN hat
<fullermd> $REPO/graphics/trunk and $REPO/code/trunk, where the trunk's are both branches, but {graphics,code} are just plain directories.
<CaMason> ok this is great
<fullermd> No, because bzr would check ../, see that it's not a repo, and then check ../../ and find the repo.
<fullermd> (or any arbitrarily deep nesting if you want)
<fullermd> Having the single $REPO also lets you make, say, a $REPO/rewrite/graphics and $REPO/rewrite/code branch pair, if in some usage it's more convenient for them to be direct siblings.
<CaMason> so how about managing branches for each of those sections.. say code/branch1 and code/branch2
<CaMason> sure that makes sense also
<fullermd> It's pretty freeform; however makes sense for your project.
<fullermd> And you can rename inside the repo without breaking things; if you had a $REPO/code branch, but decided to change it to $REPO/code/trunk (with code being just a dir), you could do that with mv.
<CaMason> I may be speaking at a conference in April about version control benefits, and I'm liking the flexibility of bazaar (even though i've only just started using it)
<fullermd> (you'd have to update any branches that had the old location saved of course, but...)
<CaMason> ok, so I branched code/trunk to code/branches/branch1... I made some changes, then I integrated the branch back into the trunk (question for another time). I now have no need for the branch1 working copy to exist, but I'd like to keep the hisrotical data
<fullermd> If you merged it into trunk, all the historical data is in trunk's history.
<fullermd> (merges don't just "roll up" all the changes; they preserve all the historical revisions)
<CaMason> so I can rm -rf branches/branch1 ?
<fullermd> If it doesn't need to exist independently anymore, yah.
<CaMason> or is there something 'tidier' I should do here?
<fullermd> Branches are basically just pointers into the history, saying "This is my latest revision".
<CaMason> no it doesn't need to exist independently, but I'd like to be able to grab a copy of that branch1 at a given state sometime in the future
<CaMason> I guess all of that info would be stored in the repo
<fullermd> So if that latest revision is merged into another branch, you could recover it from there if you had to (well, branches may have local config that doesn't exist elsewhere, but that doesn't usually matter)
<fullermd> Well, it doesn't hurt anything to leave branch1 sitting there, so if you expect to have need for it in the future, sure, just let it lie.
<CaMason> makes sense.. but at least I'm not leaving it there for fear of losing the history
<fullermd> A branch (since the history is all off in the repo) uses something like 8k of disk space.  I doubt it'll bankrupt you.
<fullermd> And remember the mv.  You could mv it to $REPO/code/branches/LEGACY/branch1 or something to "get it out of the way"
<CaMason> that's cool
<fullermd> (or any other location of your choice; just so long as it's under $REPO)
<CaMason> k, so how about this scenario. I have my working copy (bound to my repo on a server somewhere). I now want to make a 'branch' of this trunk. Do I do this on my working copy, or on the repo?
<fullermd> It depends on whether it's a branch you want to have in the repo, or just locally.  Either way works fine.
<CaMason> it would be a branch to store in the repo
<fullermd> If it's a long-lived branch that several people will be working on, you'd probably want that in the repo.
<fullermd> If it's something you're going to work on for a few hours, then merge in and be done with, it can be easier to just do it locally.
<fullermd> I'd say 90% of my branches don't get put in the central repo, because they don't last very long, and I'm the only one working on them while they're alive.
<CaMason> ok, so if I just want to make a quick branch over lunch to try out a new feature, a local branch would be cool, and then merge back into trunk if it's successful
<fullermd> And if they do turn out to live long and get other people working on them...   well, then, I can just move them into the repo, like you're doing with your trunk right now in this example.
<fullermd> Yah.  The distributed nature of bzr means that a repo isn't a boundary like in svn; moving revisions in and out of and between repos is S.O.P. in bzr.
<CaMason> ok one last hurdle if you would be so kind
<CaMason> I have made a repo under /srv/bzr/clients/myclient
<CaMason> i then created myproject/code/trunk within that
<CaMason> how can I then move my current branch (which hasn't lived in a repo yet) to that location?
<fullermd> Well, you probably want that 'trunk' to be the branch.
<fullermd> So `bzr branch $CURRENT_LOCATION /srv/bzr/clients/myclient/myproject/code/trunk`
<CaMason> ah so I need ot make the 'trunk' a branch
<CaMason> I seeeee
<fullermd> Well, you don't _have_ to.  I just presume that's what you want.
<fullermd> ('branch' doesn't like its destination already existing)
<CaMason> you're right
<CaMason> Branched 31 revisions in 1 second, lol
<lifeless> jelmer: hi
<CaMason> now I should bind my old location to this repo?
<fullermd> Yah, use bind or reconfigure to turn it into a checkout.
<CaMason> "Tree is up to date at revision 31"
<CaMason> looking goood :D
<CaMason> Thanks for holding my hand through that fullermd; it's very much appreciated. You've probably saved me hours
<fullermd> Well, the world has way too few of 'em.  I'm doing my part for the environment   :)
<CaMason> I had a great experience in #wordpress the other day... I asked a question to see if there were any recognised patterns for solving this particular problem..
<CaMason> "Go learn PHP"
<fullermd> Well, there probably aren't many people here who would dream of saying that   ;)
 * fullermd says, as he works on PHP code in a bzr branch...
<CaMason> in other news... I got a blue screen of death when trying to use bzr to checkout a branch over SFTP. I was on vista x64
<CaMason> Bazaar 1.9
<CaMason> I hadn't tried a branch over SFTP before and I'm too scared to try again :)
 * fullermd guesses that "bzr does that sometimes if it detects you're not running ubuntu" wouldn't be a well-received response   :p
<lifeless> CaMason: that suggests a network driver bug to me
<CaMason> :o
<lifeless> the check code you got should help diagnose it
<lifeless> of course, its closed source, so you can't fix it
<lifeless> :)
<CaMason> well I couldn't see any events in my system log either
<CaMason> but I Set the option to prevent vista auto rebooting on a BSOD
<fullermd> Maybe your OS heard that somebody generated a fake SSL cert, and extrapolated that to a belief that both MD5 and network crypto are totally broken, so it crashed to protect you.
<CaMason> sounds about right of MS
<CaMason> I'll update my network driver, then update bazaar, then try again
<poolie> hello
<CaMason> although I can access SFTP servers without issue using other apps
 * CaMason does a huge Windows update
<jelmer> lifeless, moin
<poolie> hello jelmer, happy new year
<jelmer> hey Poolie
<jelmer> thanks, happy new year :-)
<lifeless> hi jelmer
<lifeless> so thin packs
<lifeless> see git-index-objects - it cannot index a thin pack
<jelmer> right, dulwich would have to get rid of any ref-delta's during fetch
<lifeless> it requires --fix-thin to be passed when you invoke it
<lifeless> secondly, there is still the question about how git is sure that a external ref in a thin pack is possessed by the client
<lifeless> does it e.g. grab an arbitrary parent tree take that path in that tree and external ref against it?
<jelmer> lifeless, the delta base can be anything that causes a small delta
<jelmer> as far as I understand it
<lifeless> jelmer: well, I've dug deep into this code myself
<lifeless> but I haven't got an answer to this yet
<lifeless> jelmer: it can't be a text the client doesn't have though, by definition
<james_w> doesn't it use anything it can infer the client has from what the client told it it had?
<jelmer> lifeless, sure, but it can be any text that is part of one of the revisions the client has
<lifeless> yes, but this is something that could be very expensive to determine, if e.g. it tries to reuse the delta
<jelmer> lifeless, and the server knows what those revisions are (or rather, knows the tips of the revision tree with those revisions)
<lifeless> or perhaps for that one it doesn't try to reuse
<lifeless> so let me rephrase my question
<lifeless> I don't want speculation: I'm totally capable of doing that, I want the algorithm used.
<lifeless> "one of" is unusably vague for deciding what we can learn from it, unless it really is a random choice
<nDuff> hmm
<nDuff> the head of client-side development just stepped into my office and indicated he's looking at switching SCMs (right now that side of the company is a p4 shop)
<lifeless> I'm interested in this to make sure we've learnt as much as possible about what actually makes git fast, vs what people *claim* make it fast
<lifeless> nDuff: Here's one we prepared earlier!
<nDuff> ...the tricky requirement for them is good integration with Visual Studio.
<mamat> hi, how can i disable bzr-notify from starting up automagically??
<nDuff> they have a nontrivial number of win32/.net developers.
<lifeless> I'm not sure where the current win32 stuff is at, we did have a visual studio soc project a couple years back
<jelmer> mamat, In the GNOME session dialog
<jelmer> lifeless, This is not speculation, it's based on various things I've read in the git source code / docs / mailing list
<mamat> jelmer: thx! you just saved 10Mb of my poor ram
<aogail> Hello all.
<aogail> I've got a curious problem.
<lifeless> jelmer: ok, perhaps you can describe it in more detail then: how does it choose which text, and what set are the candidates, and how does it keep that set small or does it not bother keeping it small
<jelmer> lifeless, have you read /data/jelmer/git/Documentation/technical/pack-heuristics.txt ?
<aogail> I have a branch that has a changeset whose timestamp is "2008-12-30 13:24:25 -0800". However, when I run "bzr cat -r 'date:2008-12-30 13:24:25'" I get the contents of the file from *before* that change.
<fullermd> aogail: It stores sub-second resolution, so unless you committed it at 25.000000 seconds...
<mtaylor> lifeless: http://rafb.net/p/J9b2qs84.html
<aogail> fullermd: Well, here is the interesting thing: The earliest date I can pass that returns the contents of the file as of the changeset, is '2008-12-31 08:32:32'
<fullermd> Which would be the timestamp of the next rev?
<lifeless> jelmer: /data?
<jelmer> lifeless, uhm, obviously I mean Documentation/technical/pack-heuristics.txt in the git sources
<aogail> No, the timestamp of the next rev is 2008-12-31 10:28:19
<jelmer> (but yeah, /data - that's unencrypted while /home is encrypted)
<fullermd> Just go ahead and spoil all my guesses, whydoncha...
<aogail> :)
<lifeless> jelmer: yes, and I grok that code
<fullermd> I'm out of guesses.  I know that date: has in the past been shown to be pretty rough-edged and in need of some smoothing love.  So I'd guess it could well be "something weird about how date: works".
<lifeless> jelmer: so one possible implementation is that there are a set of external objects available for packing against that are not going to be emitted
<lifeless> mtaylor: note 't' vs 'T'
<mtaylor> lifeless: yup
<mtaylor> lifeless: but it was successful in the first command
<lifeless> mtaylor: you're on windows?
<mtaylor> lifeless: no, that's from a friend
<lifeless> mtaylor: they are on windows
<mtaylor> lifeless: yes
<netdur> can bzr use ftp instead of sftp?
<jelmer> netdur, yes
 * mtaylor doesn't understand that choice, but whatever
<lifeless> mtaylor: file('foo', 'wt').close(); file('FOO', 'rt').read()
<lifeless> mtaylor: will work on windows without error
<lifeless> mtaylor: we're integrating code at the moment to deal with this more gracefully than the current way of just assuming its a unix file system with quirks
<mtaylor> lifeless: I'm mainly just curious here - but why doesn't the bzr status pick up the file?
<Peng_> netdur: SFTP is better, of course.
<netdur> jelmer: thanks
<aogail> Hmm. Well, the reason I'm trying to make this work is that "bzr diff" sticks timestamps in the header rather than revnos -- and the tool I'm using wants to retrieve the full contents of the old version of the file. Is there a way to tell "bzr diff" to put a revno or revid in the diff? (I can modify the tool to work with that instead.)
<netdur> Peng_: would use sftp if my web host supports it
<Peng_> netdur: Yell at them about it. :)
<lifeless> mtaylor: because of two things; firstly the unknown is unknown because its not versioned or ignored in the name with T, which is what the OS reports to listdir()
<netdur> for $30 a year? they would just kick me out
<Peng_> Heh.
<mtaylor> lifeless: AHA! that makes sense
<fullermd> aogail: Well, it probably Should(tm) put that info there anyway.  So now all you need is somebody to bug to implement it   :)
<lifeless> mtaylor: secondly, the file that was added, with the lower case t, is not reported as missing, because it was not present in the basis, its been added-and-missing in the current tree, so you don't see 'missing: ...Test...'
<lifeless> sorry, missing: ....test...'
<lifeless> nDuff: perhaps a mail to the list? I know there is interest in good vs integration
<lifeless> nDuff: or just to me/Martin if you want to keep it low key
<aogail> fullermd: Heheh, sounds good. Time to start hacking. ;)
<aogail> Thanks.
<jelmer> lifeless, so from how I understand it the set of external objects available to delta against is just that set of objects that are part of the revisions the server knows the client has
<lifeless> jelmer: thats a O(history) set though, so I find the idea of it precalculating that hard to accept, but if it doesn't its expensive to calculate text IN revisions
<jelmer> lifeless, true
<netdur> when I branch via ftp, will bzr upload everything or just the diff?
<netdur> hum, am messing things
<netdur> say, I did branch, then added something new then branched again to the same place
#bzr 2009-01-06
<lifeless>  netdur I'm not sure wat you are saying ;)
<netdur> I guessed so!
<netdur> :(
<netdur> sorry
<nDuff> whoa -- InconsistentDelta: An inconsistent delta was supplied involving '<PATH>', '<ID>' \n reason: The entry was considered a rename, but the source path is marked as absent.
<nDuff> ...where the PATH and ID refer to a file which was under a directory I was trying to rename, but not anything that a rename should have been issued on standing alone.
<spiv> nDuff: hmm, I don't think we've seen that before.
<spiv> nDuff: You're on windows, IIRC?
<nDuff> spiv, no; a bunch of other developers here are on win32, but I'm very much not.
<nDuff> spiv, notably, I'm using bzrlib directly (and did the move using wt.move()), so there could well be a usage error.
<spiv> nDuff: drat; I was speculating that it might be a case-insensitive fs issue.
<spiv> Ah, it might well be a usage error then.  I'm not overly familiar with those APIs.
<lifeless> nDuff: reproducable?
<lifeless> nDuff: what bzrlib version
<nDuff> lifeless, happens every run. 1.10rc1
<lifeless> nDuff: if you create a fresh checkout?
<lifeless> (there was a bug quite a while back with dirstate, it is possible but unlikely that you are suffering from the confusion that bug could introduce)
<nDuff> lifeless, this is during the commit process (from my test suite, so a new branch is made every invocation); can't check out what isn't committed yet.
<lifeless> ok
 * nDuff looks for a pastebin
<lifeless> are you able to try invoking bzr?
<nDuff> lifeless, I'll need to comment out the test suite's tearDown bits that delete the tree on each run to inspect manually; will do...
<lifeless> nDuff: or replace the wt.move call with system() ?
<nDuff> lifeless, I'm quite sure that the mv is happening on the underlying filesystem when I call wt.move() -- otherwise a check I'm doing before the commit would fail.
<lifeless> nDuff: oh, this is occuring when you do the commit?
<nDuff> yes.
<lifeless> are you moving one file or many?
<nDuff> one
<lifeless> try using wt.rename_one
<lifeless> move is hmmm odd
<lifeless> if that works its a bug in move and you have a workaround
<nDuff> ahh; this gives a much more useful exception
<nDuff> ...blerg, the useful exception was just because usage between move and rename_one differs; fixing that, it's back to the same issue.
<lifeless> ok
<lifeless> its a commit issue then - can you get a backtrace for where its being raised from
<lifeless> [probably a commit issue]
<lifeless> uhm, can you add a call to wt._check() before your commit
<nDuff> http://pastebin.ca/1300603
<nDuff> sure, doing that...
<nDuff> the _check() call is uneventful.
<lifeless> well that means that the dirstate thinks there is nothing wrong
<lifeless> so...
<lifeless> its either a bug in update_basis_by_delta
<lifeless> or
<lifeless> a bug in the delta generation from commit
<lifeless> is this the only operation made to the tree?
<nDuff> ...going into the directory (after disabling cleanup), a "bzr status" showed the working tree out-of-date, but "bzr update" completed successfully.
<nDuff> the only operation during that commit, correct.
<lifeless> the out of date is because the update failed
<lifeless> can you:
<lifeless> bzr branch -r -2 . /tmp/foo
<lifeless> cd /tmp/foo
<lifeless> bzr mv whatever whatever [reproduce]
<lifeless> bzr commit -m "make it blow up"
<nDuff> doesn't blow up from the command line.
<lifeless> ok
<lifeless> uncommit; revert
<lifeless> python
<lifeless> import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('.') ...
<lifeless> t.lock_write()
<lifeless> t.rename_one | move
<lifeless> commit
<lifeless> (see if that makes it reload)
<nDuff> works fine that way too. Could multiple WorkingTree instances made against the same directory during the course of operation interfere with each other in some way?
<lifeless> they shouldn't
<lifeless> that would be a bug too :P
<lifeless> how many commits are done in the tree?
<nDuff> 3 in total
<lifeless> so its plausible that you have t1, do a commit, make a t2, do a commit, then use t1 to do a third commit ?
<lifeless> bzr is meant to be totally safe here, but I guess a bug is possible :P
<nDuff> I've reworked that logic a few times, and while there *is* a case where I can get a different kind of breakage, it's pretty clear that old wt objects are being thrown away.
<nDuff> ...oh.
<nDuff> Let me take a little sillyness out of my commit routine...
<nDuff> ah hah!
<nDuff> so -- this being an early 0.0.x version, I had some extra paranoia in the commit routine, where I completely removed and recreated the tree just before commit.
<lifeless> really
<nDuff> two different data models -- one in-memory, one on-disk
<lifeless> I'm smirking :)
<lifeless> It is a bug that you managed to get bzr to be unhappy
<lifeless> if you wanted to file a script to trigger it, I'd be delighted to look at fixing it.
<nDuff> *nod*; I'll see about doing that.
<nDuff> lifeless, heh -- turns out the rename/move call isn't actually necessary to get this result.
<lifeless> :>
<lifeless> remember that bzr has an inode abstraction
<nDuff> https://bugs.launchpad.net/bzr/+bug/314251
<ubottu> Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [Undecided,New]
<lifeless> nDuff: fun, thanks
<lifeless> nDuff: do you need me to poke at this right now, or are you right?
<nDuff> lifeless, a fix would be convenient (inasmuch as I could keep leaning on the same crutch for not getting consistency of my on-disk and in-memory models right), but the Right Thing is to squash any such bugs anyhow. :)
<lifeless> nDuff: oh sure, its just latent-vs-actual
<lifeless> I suspect a bug in add TH
<lifeless> add TH
<lifeless> bah
<lifeless> add to be honest
<nDuff> lifeless, ...taking the crutch out will make a huge difference in performance anyhow; this is just the impetus I needed to actually *do* it.
<nDuff> ...so no hurry on my account.
<lifeless> If I can be nosy, what are you creating?
<nDuff> lifeless, a revision-controlled hierarchial datastore, backending into bzr for the SCM-ish workflow functionality.
<lifeless> interesting
<lifeless> you may find the brisbane core temporal hash table interesting
<nDuff> hrm; looks like I might need to find a coworker with ACM membership to read up on that.
<lifeless> heh this is something we've been working on
<lifeless> http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core/
<lifeless> the bzrlib.chk_map module is the guts, and bzrlib.inventory.CHKInventory shows it being used to store inventories
<nDuff> doesn't seem accessible at the moment.
<lifeless> nDuff: try again :P
<lifeless> also its a bzr branch, you can just pull from there which won'y hit the web ui, which frankly, is suffering from the very things brisbane-core is aiming to fix
<wofl_> hey, i was wondering about interoperability, i am currently looking for hopefully just one version control system for me, which will allow me to connect with others using git, mg, cvs and svn, as transpatent as possible. how are bzr's import and export capabilities?
 * igc lunch
<lifeless> wofl_: they are good, native interop with svn, beta native interop with git and hg, a solid cvs convertor
<poolie> wofl_: pretty good; we can import from all of them, and for all except cvs can either export to them, or treat them as foreign branches
<lifeless> wofl_: also we support the fast-export streaming standard
<poolie> jinx
<wofl_> cool, how is the git and hg support coming?
<lifeless> well good, they are beta :)
<wofl_> and does the cvs converter mean i have a local cvs branch where i sync over and then commit from there?
<lifeless> its one way, we can import from cvs, but don't have a good answer for exporting to cvs
<lifeless> you could use tailor for that, which is a 3rd party generic tool
<wofl_> for the export?
<lifeless> yes
<lifeless> time for me to call it a day; 8 hours+ done
<poolie> night lifeless
<vila> hi all
<poolie> hello vila
<poolie> happy new year
<igc> hi vila
<vila> happy new year bzrers :)
 * igc dinner - night all
<garyvdm> ping vila
<vila> garyvdm: pong but lunch time here what's up ?
<garyvdm> vila: I want to ask some questions about tests I'm writing for my no working tree bzr-upload branch. Later is ok
<vila> garyvdm: back
<garyvdm> Hi vila
<garyvdm> I'm trying to write some tests for my no working tree branch. To be honest - I'm very inexperienced with writing tests.
<vila> garyvdm: ok, np, we all started there you know
<garyvdm> So I want to check I'm approaching things the right way,
<garyvdm> I'm testing the intended workflow - not just upload from a branch with no working tree.
<garyvdm> I.e. I'm pushing to the remote location, and then uploading from the remote location.
<garyvdm> This is also easier because I can just inherit from TestUploadMixin, and override do_full_upload and do_incremental_upload
<vila> hmmm, I see your problem
<vila> I don't think you can do better right now, but the test framework (in the plugin) targets a more usual setup
<garyvdm> Now there are some test which are not applicable: test_no_upload_when_changes, and test_no_upload_when_conflicts
<vila> In fact you were the first to realized the WT wasn't needed
<vila> garyvdm: I think the tests need to be refactored anyway, so don't spend too much time on that part, just override the tests you don't want to be applied with custom versions raising TestNotApplicable
<vila> We'll refactor later and having more examples will make that eaiser
<garyvdm> Ok - thats easy.
<vila> Try to review where the docs (string and user) may be misleading regarding the ambiguity about having a WT or not
<vila> Remember that we plan to add a better chmod bits support which *requires* a WT
<garyvdm> Ok - Last question: what bits would you intend on modifying with chmod?
<garyvdm> That would need to come from the wt?
<vila> garyvdm: hehe, good question for which I wait for feedback from unknown (to me) use cases
<vila> AIUI that's mainly g+w for some directories
<vila> maybe a+w in some cases...
<garyvdm> Sorry - whats a+w?
<garyvdm> and g+w?
<vila> writable by group or writable by all
<garyvdm> Ok
<vila> You're on windows ?
<garyvdm> Right now I'm on Ubuntu - But I am subjected to windows alot.
<garyvdm> And I have clients using bzr-upload that are on windows
<vila> Ok, I think the chmod bits are less relevant when the targeted *server* in on windows but I lack experience there to be sure
<garyvdm> Yes - chmod does not exist on windows.
<vila> The use cases that were reported were for upload directories needing to world writable so that people can upload photos or pictures etc
<vila> I don't know how that's handled on a windows server
<garyvdm> It has a very different permissions structure, and no executable bit.
<LarstiQ> one thing I've seen happen
<LarstiQ> a file that needed +x set on the server, but development was done on windows and the bit never got set
<garyvdm> This is a plugin that allows you to set the +x bit on windows.
<vila> LarstiQ: ouch, I'm not sure we even have a way to force that on windows...
<vila> garyvdm: thks for the speed-light answer :)
<LarstiQ> good :)
<garyvdm> https://launchpad.net/bzr-x-bit
<tsdh> Hi.  I downloaded a shared repository as tar.gz and now I have project/{branches,tags/trunk}/.  But those directories are empty except the .bzr directories.  How do I populate them out of the metadata in .bzr now?
<beuno> tsdh, if I remember correctly, bzr checkout .
<LarstiQ> yes, bzr checkout
<LarstiQ> but you need not have the working trees in the same location as the branches
<tsdh> Sounds good, I'd say.  And it seems to do something...
<tsdh> Oh, a progress bar appeared.  Thanks.
<Ollie|> hey
<Ollie|> trying to see the changes in a specific version so i do bzr st -r4
<Ollie|> but it just shows the current status as if the -r4 wasn't there
<Ollie|> just wondering i have got the argument wrong
<beuno> Ollie|, bzr log -v -r4
<Ollie|> beuno: nice :)
<fullermd> Ollie|: stat compares two things.  With -r4 you're only giving it one, so it assumes the other (compares r4 against your working tree).
<fullermd> Ollie|: Try "bzr stat -r3..4" or "bzr stat -c4"
<Ollie|> fullermd: thanks
<salty-horse> hi. can someone please rationalize the image dimensions on http://bazaar-vcs.org/Workflows ?
<rexbron> james_w: I wrote a responce to your code review, have you had a chance to read it?
<james_w> rexbron: I don't have a strong opinion which way round the profiles should be specified currently
<james_w> the one other consideration that just popped in to my head is that it should probably migrate to using bzr's config files, in which case having a single header for all profiles would be less likely to cause collisions
<rexbron> james_w: that would be something to investigate further. I do not know what exactly you mean by use bzr configfiles, as I would think it would be better to have plugin seperate from that
<james_w> ~/.bazaar/locations.conf etc.
<jelmer> hi Mario (x2)
<Torne> I've deleted a branch i didn't mean to, in a shared repository. Is there any way to recover the committed revisions from taht branch? presumably they are still there :)
<Peng_> Torne: You could use bzrtools's "bzr heads" command.
<Peng_> Torne: Then, um, "bzr init", and "bzr pull . -r revid:...".
 * Torne tries that :)
<Torne> possible complication: the branch in question was a loom
<Torne> heads doesn't list it, only the two branches i've not broken. *tries --all*
<Torne> aha, there it is
<Peng_> Ehh, I don't know about the loom though.
<Peng_> I don't know how they're stored.
<Torne> i don't care if it breaks the loom nature of it as long as i get the changesets back
<Torne> the top patch on the loom didn't exist anywhere else so i need those deltas :)
 * Torne pulls it to see what happens
<Torne> yup, that's recovered the revisions
<Peng_> Cool.
<Torne> it's lost the loom nature of it, but it has the revisions from each thread stacked on top of each other
<Torne> thanks!
<Torne> so, hm. a related question: if you have branches in a shared repository, is there actually a way to delete a branch that *will* throw away all the data for its revisions? :)
<Peng_> Not really.
<Peng_> I mean, you could create a new repo, pull everything but those revisions into it, and then switch them out...
<Peng_> I don't know of any better ways.
<Peng_> IIRC there *was* a plugin to delete revisions, but I don't know its status.
<Torne> heh, it's ok
<Torne> i weas just curious :)
<Torne> i have my code back; disk space is cheap :)
<Torne> Bye! :)
<enigma42> hm...I'm getting an error with the latest trunk of bzr-svn 0.5
<enigma42> bzr: ERROR: exceptions.ImportError: cannot import name ForeignRepository
<jelmer> enigma42, you need bzr.dev to run bzr-svn 0.5
<enigma42> jelmer: Oh, OK. Due to the recent foreign repo stuff?
<jelmer> yeah
<enigma42> So, that foreign repo stuff will be in bzr 1.11 when it comes out?
<jelmer> yep
<enigma42> jelmer: OK.
<enigma42> jelmer: I have a couple of bugs for you, so I'll see if I can get them into the bug tracker today.
<jelmer> enigma42, cool, thanks
<enigma42> jelmer: I just want to test with the latest code to make sure they haven't been fixed already. :-)
<enigma42> Are the bzrtools in "bzr.dev"? or somewhere else?
<enigma42> nevermind. I think I just figured it out... http://bazaar-vcs.org/BzrTools
<Kobaz> how would i list revisions that have not been pushed to a remote repo
<beuno> Kobaz, bzr missing
<Kinnison> bzr missing --mine-only <optional remote branch>
<Kobaz> k
<Kobaz> nifty
<nDuff> re https://bugs.launchpad.net/bzr/+bug/314251 -- if I'm understanding correctly, when we re-add with the same ID at a new location, we need to set the type of the old ID to 'r' if it had been 'a'. Correct?
<ubottu> Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed]
<Goundy> hi
<Goundy> there's no open source bzr web front-end ?
<Peng_> Loggerhead?
<Peng_> Along with bzrweb and bzr-webserve.
<Goundy> ow Ã´O
<Goundy> Peng_ man I really sux.... I tried to find out something using google but all I get is links to messages to mailing lists...
<Goundy> thanks man
<Peng_> :)
<Goundy> Peng_ bazaar is so good man !
<Goundy> I really like it !
<Peng_> You shouldn't direct the credit to me, but yes, it is. :D
<Goundy> Peng_ I can't stop saying that :/
<Goundy> I told everybody how much I like bzr...
<dwt> hey there
<dwt> I frequently see parts and info about subtree support in bzr
<dwt> but googling and searching the wiki doesn't seem to bring up any real documentation about that
<dwt> could you point me to a site?
<Peng_> dwt: Try searching for "nested trees". It's been experimental for ages; not much has been happening.
<Peng_> dwt: Here's one page: http://bazaar-vcs.org/NestedTrees
<dwt> ahhh
<dwt> thats why I didn't find anything with "subtree"
<dwt> what is the eventual goal of this development?
<dwt> We use svn:externals extensively at work - and nested trees kinda sounds like it could be something like this
<dwt> (even though svn:externals are pretty broken in and on itself)
<Kobaz> what's wrong with svn:externals ?
<dwt> To us it's hard to switch them between trunk / a branch/tag and specific revision
<Kobaz> ah, yeah
<fdv> uhn.. when binding / updating (bzr-svn), local changes made while unbound will be "extracted" and become a diff. Are they then actually removed from the history as well?
<jelmer> fdv, yes
<jelmer> fdv, that's not specific to bzr-svn btw
<headlessagnew> jelmer: A couple days ago you helped me out with bzr-svn, and downgrading to 0.4.x worked on that machine.  On another OSX machine I keep getting "setup.py is already versioned" where setup.py is a file in the repository.  This happens on OSX, SVN 1.5.5, with both 0.4 and 0.5 branches of bzr-svn, on both case sensitive and case insensitive filesystems.  Any ideas?
<fdv> no, just providing context
<fdv> that's sad
<jelmer> fdv, the changes end up as a pending merges so their history is still kept, just not part of the history of the current working tree
<fdv> I got an error while updating, and my changes vanished
<jelmer> fdv, what sort of error?
<jelmer> headlessagnew, when do you get that error?
<fdv> jelmer: bzr: ERROR: No such file: ('161254@6226825f-cf0a-0410-9073-f4040cba89582...', 'svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:161254')
<headlessagnew> jelmer: during a branch or checkout into an init'd repo with --rich-root-pack.  It downloads (I believe) the entire history, then I'm nto sure where it dies because the output gets cleared.  (Is there a swithc ot preseve output?)
<fdv> ... being an existing path, with / replaced with %2F
<jelmer> headlessagnew, this is with the same repository?
<fdv> I cleverly reverted, in the blissful belief that my changes were safe and sound in the history :p
<headlessagnew> jelmer: yup, same thing if i do branching or checking out of trunk/branch/tags
<jelmer> fdv, this is with 0.4.16?
<fdv> uhm, no, 0.4.15dev0
<fdv> the updates are so frequent it's hard to keep up :)
<headlessagnew> jelmer: it fetches all the revision info, determines changes, and then on "copying revisions" it dies with the error.
<jelmer> headlessagnew, what I mean is, is this the same repository that you were working on last time?
<headlessagnew> jelmer: Yes, it is, but a different OSX machine.  I have made changes to the repo via bzr-svn, but only commits -- no renames or moves.  Additionally, I haven't made any new directories (branches or otherwise) since then, with either svn or bzr-svn.
<jelmer> headlessagnew, did you change this particular file at all?
<headlessagnew> jelmer: I thought I hadn't, but yes, in fact I did.  And I made that change with bzr-svn.
<jelmer> headlessagnew, which version of bzr-svn ?
<headlessagnew> jelmer: i made the change with 0.4.16, and on machine #2 i have tried with both 0.4.16 and 0.5rc1
<headlessagnew> (there was an indication in a bug tracker than a problem like this was fixed in 0.5)
<BUGabundo> hi
<BUGabundo> what's up with bzr-beta-ppa team??
<igc> morning all
<Emmanuel> Hi
<Emmanuel> I am starting using bazaar and i have a pb ( i am using it on Vista and ver1.10 ). I get the following error message : "bzr: ERROR: Could not acquire lock"
<Emmanuel> Any idea what goes wrong
<nDuff> Emmanuel, does the break-lock command help?
<nDuff> Emmanuel, typically that kind of issue means some previous command failed while holding the lock -- well, that or there's someone else doing something to the tree concurrently so you need to keep your hands off it. :)
<Emmanuel> nDuff , let me try
<Emmanuel> It is actually my initial push
<Emmanuel> seems a little bit better
<BUGabundo> what's up with bzr-beta-ppa team??
<Emmanuel> it made it work thx, thx guys
<nDuff> glad to hear
<poolie> hello all
<nDuff> ...hrm; looks like the dirstate fails validation just before the commit failure in https://bugs.launchpad.net/bzr/+bug/314251. Does that make the dirstate getting into a bad state "the real bug" and the commit failure expected under the circumstances (thus, NOTABUG)?
<ubottu> Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed]
<nDuff> poolie, howdy
<poolie> hello nDuff
<lifeless> nDuff: yes
<nDuff> lifeless, I'm curious, btw, that the wt._check() calls we put in when you were walking me through diagnosing this didn't catch the prior issue then; does wt._check() not check the dirstate?
<lifeless> nDuff: it does
<nDuff> odd, then.
<lifeless> nDuff: WT4's self._validate, called by check, calls self._dirstate.validate()
#bzr 2009-01-07
<nDuff> oh -- I'll hazard I put the check in at the top of my commit() method, *before* the paranoia bits. *sigh*.
<lifeless> that would explain it
<nDuff> ...so -- while I can edit it, I don't think I have access to close that ticket. Should I modify it to refer to the dirstate issue, or let someone with appropriate access close it and file a new/better ticket?
<lifeless> that ticket is fine
<lifeless> I don't believe in churning bug reports, just editing them to be clearer ;)
<nDuff> so, part of what I don't grok here -- if we store 'a' entries for things which are deleted in the current working tree, why does DirState._get_entry(0, fileid_utf8=file_id) return (None, None) when called from DirState.add(), rather than the entry indicating that the deleted file is absent?
<lifeless> well 'a' is absent
<lifeless> but the row can only go entirely if the name,id pair is not present in any tree
<lifeless> so _get_entry could be the cause of the bug here, but I haven't looked into the bug in detail myself
<nDuff> ...oh.
<lifeless> so the add should be changing the 'a' to 'd' or 'f' rather than adding a new row
<nDuff> just read through _get_entry, and its explicit behavior is to return (None, None) on 'a' cases... which makes sense for add()'s normal behavior, but makes it impossible to tell whether something is being introduced for the first time or "undeleted" (possibly in a new location)
<lifeless> there are other helpers IIRC, lower level
 * nDuff realizes that the first sentence of his last line could have been read as imperative... s/^just/I just/
<mrooney> How might I un-add a file that I added accidentally? I don't want to remove the file, just un-add it from VC
<lifeless> mrooney: bzr revert file
<nDuff> mrooney, bzr rm --keep
<mrooney> lifeless: I can try that, I haven't committed yet so I wonder what revert will do
<lifeless> mrooney: revert because you want to put it back to the state it had before
<jelmer> does Bazaar still use the Launchpad blueprint system?
<lifeless> sporadically
<lifeless> jelmer: so, what is the trunk for bzr-svn these days?
<lifeless> jelmer: I don't think I've ever understood how you manage it :)
<jelmer> lifeless, lp:bzr-svn
<jelmer> lifeless, that points at 0.5 at the moment
<jelmer> I've removed trunk because it kept confusing people
<lifeless> have you merged my threadsafe and is_locked patches?
<Peng_> It's not thread-safe?
<lifeless> Peng_: well, it triggered thread safety asserts in sqlite when I made loggerhead work on svn directly
<Peng_> Ehhm, I hope bzr-svn never comes into play on my Loggerhead install then.
<jelmer> lifeless, yeah, those have long been merged
<lifeless> well, it only would if you did e.g. bzr checkout --lightweight svn://... and then pointed logerhead at that
<lifeless> jelmer: ok, I'll pull overwrite
<Peng_> Alright.
<lifeless> Peng_: its not having bzr-svn installed, its using loggerhead to examine svn repositories directly :)
<lifeless> Peng_: and as jelmer says, the patches are emrged
<Peng_> :)
<jelmer> ok, I registered the duck-branches spec, will expand it a bit more tomorrow
<lifeless> jelmer: what we mainly do is discuss on the list
<lifeless> and send patches to doc/developers/ describing things agreed on
<jelmer> lifeless, yeah, I'll post it there when I've expanded it a bit more
<jelmer> it's a bit too sparse right now, seems pointless to bore the list with it before necessary
<lifeless> well, discussion can be about concepts not actual prose :P
<lifeless> I find sending in prose too early results in a very static, early-framed discussion
<jelmer> it's already been discussed a bit earlier
<jelmer> it's basically a follow-up of my local-branches plugin
<lifeless> ok
<lifeless> that was while I was away I think
<jelmer> Yeah, I think so
<jelmer> lifeless: it basically implemented local branches (git-style branches, if you will) by adding .bzr/branches/ and symlinking .bzr/branch to one of the branches in that directory
<lifeless> spiv: oh, that reminds me, make sure your stream fetch stuff supports sending/requesting many start points. Repository.fetch doesn't - and that is a bug
<spiv> Many start points?
<lifeless> yeah
<lifeless> think multipush
<spiv> I think I know what you mean, but let's make sure I do :)
<jelmer> moin poolie
<spiv> Right.  multipush would want to transmit many heads.
<lifeless> well they may not be heads :P but tips, yea
<spiv> lifeless: oops, right.
<spiv> At the moment I'm just working on the stream of records to push, so not (yet) changing the negotiation/calculation of which records.
<spiv> But that goal is worth keeping in mind, thanks.
<igc1> spiv: re your --no-plugins patch, why is this line needed?
<igc1> args = ['--no-plugins'] + args
<lifeless> jelmer: did the url-syntax for colocated branches disucssion get finished?
<spiv> igc: just refreshing my memory
<poolie1> with no context i'd guess it's so that they're not loaded inside a subprocess bzr
<spiv> igc: so that subprocesses spawned by the test suite don't load plugins.
<poolie1> :)
<spiv> igc: which makes sense if you ran "bzr --no-plugins selftest ..." in the first place.
<spiv> igc: maybe not so good if you didn't pass --no-plugins to the original process...
<igc> spiv: but why is that line unconditional?
<spiv> For lack for a good condition ;)
<spiv> I think ideally it'd be "if <selftest was run with --no-plugins>:", but I'm not sure there's a good way to spell that.
<jelmer> lifeless, no, that's still an open issue (in the spec as well)
<lifeless> looms want this
<lifeless> spiv: bzrlib.plugin.SOMETHING
<jelmer> (duck-branches are colocated branches, btw)
<jelmer> hmm, colocated is actually a pretty good name for these things...
<poolie1> i think colocated is good
<poolie1> i think calling them threads might be good, if it doesn't cause too much confusion with looms
<poolie1> or twigs :)
<poolie1> jam, if you're still here
<poolie1> spiv wants to change bdecode so that it decodes list types as tuples
<poolie1> for easier use with keys
<lifeless> jelmer: why not just use the current find_branches() api ?
<jelmer> lifeless, that's what I mean
<jelmer> lifeless, it doesn't know about colocated branches though (yet)
<lifeless> well you talk about a new container object
<jelmer> lifeless, isn't find_branches() supposed to find all branches under a particular directory, not just the colocated ones?
 * igc lunch & off for the afternoon - see everyone tomorrow
<lifeless> jelmer: yes
<jelmer> lifeless, so that seems to make it very hard to iterate over all colocated branches without opening those branches *and* all non-colocated branches under the dir
<lifeless> fair enough
<lifeless> anyhow, I need to think on it a bit I suspect
<lifeless> I'd like to get the url thing sorted
<lifeless> that is key to making things better IMO
<jelmer> Yeah, the URL bit is important to resolve, though I don't think the decision there will influence the rest of the spec very much.
<Peng_> beuno: FWIW, I think your Loggerhead ideas sound very interesting, as long as the interface for the JavaScript-impaired is still decently usable.
<beuno> Peng_, I will promise to do my best  :)
<beuno> ideally, LH would be cheap enough to open up to googlebots and the likes
<beuno> so I do want to expose as much information as possible
<Peng_> beuno: I do open mine up to Googlebot. :P
<beuno> Peng_, that's why you're my favorite  ;)
<Peng_> :D
<hotdog0031> AssertionError: no parent entry for: Trip back east/DDSCF0001.JPG in tree 0
<hotdog0031> HALP
<hotdog0031> seems to have deleted the parent folders without removing what was inside
<lifeless> interesting
<lifeless> is that on commit? what version of bzr do you have?
<hotdog0031> No, that's on bzr check, which is why I'm rather panicked at the moment. I have bazaar 1.6.1 right now- the one shipped with ubuntu. Should I try with a newer one?
<lifeless> hotdog0031: that will be checking the local tree on disk I think. Can you do:
<lifeless> python
<lifeless> import bzrlib.workingtree
<lifeless> t = bzrlib.workingtree.WorkingTree.open('.')
<lifeless> t._check()
<hotdog0031> No handlers could be found for logger "bzr"
<hotdog0031> strange.
<lifeless> ok
<lifeless> can you file a bug please
<lifeless> with the output from check - and from ~/.bzr.log for the check - just delete that file before running check
<lifeless> don't panic though, I would be amazed if you have managed to get bzr to record something unusual in the history of your project
<lifeless> oh also, if you have enough disk space handy you could do this to test:
<lifeless> bzr branch . /tmp/clean; cd /tmp/clean; bzr check
<hotdog0031> Ok. Thank you for your help, lifeless.
<Leefmc> Question: I have a branch, and a working directory. Now i have made a 2nd branch to test some code, but how do i change my working directory from branchA to branchB?
<nDuff> Leefmc, I think "bzr switch" (from the loom plugin) should do that.
<lifeless> nDuff: switch is builting now
<Leefmc> originally i got my working directory by checkout out branchA, but if i try to checkout branchB it gives me an error about .bzr already existing, etc.
<Leefmc> nDuff: I need a plugin just to change branches?
<lifeless> Leefmc: just 'bzr switch branchB'
<lifeless> Leefmc: no, its in bzr core
<Leefmc> ah, k
<Leefmc> ty
<lifeless> the loom plugin extends the switch command to work with looms as well
<Leefmc> Interesting, is it a bug that if you switch to a branch which has 0 revisions (no commits yet) that bzr leaves all the code from the previous branch in your working directory?
<lifeless> Leefmc: did it output anything at all?
<Leefmc> lifeless: In regards to the switch? iirc, yes
<lifeless> Leefmc: I'd guess it errored in fact:)
<Leefmc> lifeless: I did it multiple times, its not a singularity
<lifeless> Leefmc: sure
<Leefmc> lifeless: At first i thought it was not working as i had assumed, because it was not removing the code from the previous branch. But then i made a commit to branchB and then everything worked fine. No problems really, just noting the fact :)
<lifeless> Leefmc: uhm, file a bug ? :P I've not got anywhere near enough info at this point to say if its a bug thoough
<lifeless> it may be refusing to operate or something
<Leefmc> Boy i love DVCS'
<Leefmc> what did i do before them..
<Leefmc> now i refuse to even work without them :D
<nDuff> yay!
 * nDuff has a working patch for his current pet bug.
<nDuff> (well, working for the single, simple test case he's running against right now, anyhow)
<poolie1> which one?
<poolie1> and congrats
<nDuff> bug 314251
<ubottu> Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed] https://launchpad.net/bugs/314251
<nDuff> happened across it by doing something really stupid yesterday, then realized today that I could hit it through less-contorted use cases.
<poolie1> i thought that might be it
<poolie1> well done
<lifeless> time for me to call-the-day in a few minutes poolie
 * fullermd hopes this one is called Barbara.
<lifeless> well its more 'gee our early history was dirty'
<lifeless> my repo appears to have some significant differences in the early-early-early merge output results. I smell weave glitches that I've never repaired
<lifeless> so I've been migrating branches across to bzr.dev 'clean' versions :P
<poolie1> ah good
<poolie1> we're looking at streaming rpc requests
<lifeless> cool
<lifeless> well, I'm off see you tomorrow
<lifeless> oh, I updated groupcompress to the 1.10 apis
<lifeless> tests pass but thats about all I'm sure of :)
<poolie1> oh, are you?
<poolie1> off to see me tomorrow i mean
<lifeless> metaphorically
<lifeless> I meant, I'll be here working tomorrow :)
<nDuff> is selftest expected to run clean on bzr.dev? I'm seeing some errors which look like they shouldn't have anything to do with my patch.
<lifeless> nDuff: we use pqm, so yes selftest runs clean
<nDuff> ...hrm, that's odd... oh, I think it may be testing my installed plugins.
 * nDuff reruns with --no-plugins.
<lifeless> yes it will be
<fullermd> I know I've always had a couple trivial failures.
<fullermd> But it's been forever since I ran it.
<poolie1> andrew and i are just talking about whether streaming code should expose the chunking to the client/server
<poolie1> ie is it a stream of bytes that happen to be chunked, or is it a stream of chunks with possibly meaningful semantics
<nDuff> Is it OK if I do a blackbox test case for this, or is it strongly preferred that it be aware of/inspect the dirstate innards?
<poolie1> one in workingtree_implementations would be nice
<poolie1> but blackbox would be better than none
<nDuff> ahh; I hadn't seen workingtree_implementations
<spiv> Hmm, I thought at some point the *_implementations directories were going to be renamed per_*.
 * nDuff sends his patch off into the wild blue yonder^Wmailing list.
<nDuff> Should a new version of a patch be sent to the ML in a new thread or as a reply?
 * nDuff doesn't know if bundle-buggy (or accepted etiquette) is particular about such things.
<Peng_> nDuff: Replies work.
<nDuff> Peng_, thanks.
<vila> hi all
 * fullermd distracts vila with a pink elephant and rifles through his pockets for loose change.
 * vila search online dictionaries for "rifles through his pockets for loose change" 8-/
 * vila feed its own pink elephant in th mean time
<fullermd> How do you kill a blue elephant?
<mwhudson> with a blue elephant gun?
<fullermd> Pfft.  Take all the fun outta it, why doncha   :p
<mwhudson> just practising my regression to child hood
<fullermd> Well, that's what we have version control for.
<fullermd> bzr branch -rgrade:3 ...
<fdv> is bzr upgrade (from rich-root-pack to 1.9-rich-root) a heavy / slow command, and are there significant benefits of doing it?
<fdv> wow, shelf doesn't map to shelve anymore. that was.. surprising
<asabil> fdv: according to a mail from the mailing list, upgrading is very fast
<fdv> asabil: great, thanks!
<asabil> fdv: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/50718/match=upgrade
<Oli``> Trying to figure out why my files aren't showing up on my server. I've done (all locally): bzr init; bzr add; bzr push bzr+ssh://address/dir; bzr bind bzr+ssh://address/dir; bzr commit -m "init"
<luks> what files are you expecting to show up?
<Oli``> there is a new /dir directory on the server (and it has its own .bzr dir) but apart from that, it's empty =\
<Oli``> I've got half a dozen files added locally
<luks> that's the way it works
<luks> you can run "bzr checkout ." on the server and use the push-and-update plugin to keep it up to date
<Oli``> I'm trying to push the files onto the server...
<luks> but having a working tree is rarely a good idea
<luks> er, I eam working tree on a server
<Oli``> checkout!
<Oli``> that's what I was forgetting!
<vila> looks like PQM is blocked again... that's so 2008... I thought that upgrading bzr there had solved the issue but obviously not :-/
<fullermd> vila: It's still confused from the leap second   :p
<Emmanuel> Hi, i am using bzr 1.10 and everytime i first push a repository on a network shared i get "bzr: ERROR: Could not acquire lock" , any idea what i do wrong?
<rocky> what's everyone's favourite way to mirror (pulling-only) an hg branch into a local bzr branch these days?
<rocky> bzr-hg looks non-updated
<jelmer> rocky: fast import is probably the best choice at the moment
<jelmer> I hope to update bzr-hg at some point, but bzr-git / bzr-svn have more priority for now
<Jc2k> jelmer: :)
<Jc2k> when bzr-darcs ;)
<jelmer> hey Jc2k
<jelmer> bzr-darcs would be interesting :-)
<fullermd> Eek.
<fullermd> That's probably more dangerous than the LHC.
<jelmer> In particular, given that they have no particular ordering of history and we do
<jelmer> fullermd: LHC?
<Jc2k> large hadron thingy
<fullermd> Yah.
<fullermd> The thing that'll open a large rift in space-time and let face-eating dragons in to destroy the world.
 * jelmer fears that if he ever starts on bzr-darcs he'll end up rewriting bzr in haskell
<fullermd> Or rewriting haskell in python.
<jelmer> fullermd: haskell >> Python >-)
<fullermd> That's why it's a challenge   :P\
 * awilkins rewrote Haskell in Haskell and it disappeared up it's own bottom
<enigma42> Greetings all.
<enigma42> If I'm using bzr-svn 0.4 on some clients and 0.5 on others, is the metadata from 0.5 going to confuse the 0.4 clients?
<jelmer> enigma42: yes
<jelmer> enigma42: confuse in the sense that they will not be able to parse that metadata and will probably ignore it
<igc> morning
<seb_kuzminsky> "bzr shelve foo.c" is giving me a new error:
<seb_kuzminsky> bzr: ERROR: This tree contains left-over files from a failed operation.
<seb_kuzminsky>     Please examine /home/seb/work/bioserve/bionet2.bzr/trunk/.bzr/checkout/limbo to see if it contains any files you wish to
<seb_kuzminsky>     keep, and delete it when you are done.
<seb_kuzminsky> this is with 1.10
<seb_kuzminsky> all other bzr commands (up, diff, commit, etc) all work fine
<seb_kuzminsky> the limbo dir is empty
<seb_kuzminsky> i remove limbo, and it complains about pending-deletions/ in the same place
<seb_kuzminsky> that's also empty
<seb_kuzminsky> when i remove pending-deletions, it recreates limbo and complains about it, and leaves behind a lock...
<lifeless> are you on windows?
<lifeless> also, I'll brb grabbing food
<seb_kuzminsky> this is on intrepid
<seb_kuzminsky> see you after food ;-)
<seb_kuzminsky> if i break the lock, then remove both limbo and pending-deletions, it complains the file i'm trying to shelve is not versioned
<seb_kuzminsky> but bzr log and i both think it is  ;-)
<jam> lifeless: ping
<jam> seb_kuzminsky: You need to remove both limbo and pending deletions at the same time
<seb_kuzminsky> i tried that ^^^
<jam> ah, I missed the final part
<jam> so... is the file versioned? Are you sure the name is correct? was it recently added, etc?
<seb_kuzminsky> it's in the repo, the name is correct
<seb_kuzminsky> it's got a couple of commits on it, as shown by "bzr log"
<jam> seb_kuzminsky: what does "bzr st" say about it?
<seb_kuzminsky> modified:
<seb_kuzminsky>   hab/alsa/cb-stream-subscription.c
<jam> oh, are you in "hab/alsa" directory and just giving "bzr shelve cb-stream..." ?
<seb_kuzminsky> oh, shelve works if i do it from the checkout root
<seb_kuzminsky> yes
<jam> I think there may have been a bug in 1.10 where 'bzr shelve' didn't handle relative paths properly
<jam> I'm pretty sure that is fixed in bzr.dev
<jam> and 1.11rc1 is this Friday
<seb_kuzminsky> ok great!
<seb_kuzminsky> yay for short development cycles!
<seb_kuzminsky> thanks bzr guys!
<beuno> seb_kuzminsky, you can use the bzr nightly PPA if you want bzr.dev in a nice package
<nDuff> Friday? hmm...
<seb_kuzminsky> right-o, i think i'll do that
 * nDuff wonders if his patch [bug#314251] is likely to make it through the review/merge cycle in time.
<Haffi___> Hi
<lifeless> jam: pong
<Haffi___> if there are a few people in separate locations (some using Windows, some Linux) working with a few python files, is bazaar a good choice as a vcs?
<beuno> Haffi___, it's a fantastic choice
<Haffi___> beuno: Should I keep the files on a server and let the users access them via SSH/sFTP?
<igc> nDuff: I'll take a look today if lifeless or someone else doesn't
<beuno> Haffi___, yeap, that's probably the best way to do it
<Kobaz> what's the plugin that you can select individual blocks of a file to be part of a commit
<Haffi___> beuno: OK, thanks. I think the five minute tutorial pretty much covers this then!
<beuno> Haffi___, awesome. Let us know if we can help with anything.
<Haffi___> beuno: Thanks very much, this seems like a very friendly community
<Peng_> Kobaz: bzr-interactive, IIRC
<Peng_> Kobaz: But you can also shelve and unshelve the changes. (bzrtools, and now built-in)
<poolie> hi
<beuno> hiya poolie
<poolie> hello
<jam> lifeless: it looks like vila was able to wedge pqm again by submitting a branch from lp
<jam> As near as I can tell, it finished with "success" but then hung, as it hasn't started processing the rest of the queue
<lifeless> jam: have you grabbed a LOSA?
<jam> I don't even know what one is
<lifeless> spm/mthaddon etc
<jam> Though I've seen the acronym before
<spm> jam: we're wonderful people :-)
<mthaddon> speak for yourself
<spm> wedged pqm? chasing.
<spm> herb and myself are wonderful. mthaddon is simple *AMAZINGDUDEs!*
 * fullermd would campaign for a new job title if he were a losar...
<mthaddon> hey, we campaigned hard for that job title...
<lifeless> jam: while I can fix, I'm kindof a second-tier for pqm; if they can fix it they should: because they do nice things like logging issues, maintaining the machines etc
<jam> sure
<spm> jam: is unwedged. vila may(?) need to resubmit 'Rev 3924: (vila) Fix 313498...'
<jam> Though I thought you might be interested in the fact that vila has repeatedly wedged things by submitting branches from lp
<spm> talented?
<fullermd> PQM doesn't like htpp:// branches?
<james_w> it's got a childish mind and just giggles when it sees one
<jam> fullermd: that would be hhtp, vila doesn't do htpp :)
<fullermd> I think I'll claim "I knew that", and merely mismistyped it...
<Haffi___> Hi, I'm having some trouble with publishing my branch via sftp, I guess this is not strictly a problem with bazaar because I get the error message: Connection refused
<Haffi___> Does anyone know of a way to circumvent this?
<beuno> Haffi___, what command are you running to push the branch?
<luks> well, the first obvious question is: is there a ssh/sftp server running?
<Haffi___> luks: Yes, and I have checked the dependencies, they are all there
<Haffi___> I can access the server remotely, but not from inside (if that makes sense to you)
<beuno> Haffi___, what command are you running to push the branch?
<spiv> "Connection refused" sounds more like a network configuration issue than a software dependency issue.
<nDuff> Haffi___, you should have the SFTP URL using an address you can use at the ssh command line
<Haffi___>  bzr push --create-prefix sftp://haffi@[my_ip]/~/Code
<nDuff> Haffi___, ...if you can't use the address you're trying to deal with from inside your network [a NAT issue, maybe?], then you should work with your IT folks to get an address you *can* use from where you're working.
<Haffi___> nDuff: Yes, I'll have to check that out. This is actually just a server running in my home :)
<mwhudson> grar
 * beuno -> home
<mwhudson> when will bzr info bzr+ssh://.. not say
<mwhudson> Repository branch (format: unnamed)
<Haffi___> Sorry you guys, I was just using the wrong IP address
<Haffi___> should of course have used the internal one instead of the external one...
<NfNitLoop> Hmm.  So someone decided to make a portion of SVN /trunk read-only (because it has been relocated to another repository).
<NfNitLoop> I figured, fine... I'll just bzr co http://svn/trunk; cd trunk; bzr merge ../mybranch; bzr rollback read-only-dir;
<NfNitLoop> I bzr commit; to my local repo, make sure that no files in read-only-dir were changed in that revision...
<NfNitLoop> then try to bzr push back into svn/trunk.
<NfNitLoop> But I get an error message regarding accessing some file in read-only-dir.
<NfNitLoop> I'm assuming, to set some svn:prop on it?
<NfNitLoop> any way to avoid that?
<NfNitLoop> (oops.  'revert', not 'rollback'.  sorry, been touching SQL)
<Haffi___> One more question for you guys; if the branch is published via SSH, should I make an account for every user that is working on the files or can they all use the same username?
<nDuff> Haffi___, just from a sysadmin best-practices perspective, it'd probably be better to make separate accounts -- that way you can revoke just one user's access if someone is fired / leaves the project / whatever, without needing to distribute a new password
<nDuff> Haffi___, that said, nothing about bzr inherently dictates one policy or the other.
<NfNitLoop> Oh, Google had my answer for me:  bzr dpush
<Haffi___> nDuff: Thanks, there are only three of us working on this, so if bazaar doesn't care if there are many people using one username then that is simpler for me :)
<Haffi___> nDuff: Well, then again, it's impossible to track who did what...
<spiv> You can also use the script in contrib/bzr_access to limit access of particular SSH keys.
<nDuff> Haffi___, if everyone is well-behaved and sets their identities through "bzr whoami", that information will be attached to the changesets
<spiv> Even better, if everyone is *really* well-behaved their revisions will be gpg-signed.
<nDuff> spiv++
<Haffi___> nDuff: Oh, that's nice. I thought the ssh/linux username was used for that
<nDuff> Haffi___, I'm presuming that they're doing the actual work on their own, remote systems, running "commit" there, and just pushing up to the central server; their identity on the system where they did the commit is attached to that commit, wherever it may be pushed later.
<fullermd> And if everyone is poorly-behaved and fakes their whoami identities, the system account that added the revs isn't stored anywhere so it wouldn't matter anyway.
<spiv> Haffi___: it'll default to username@hostname if it isn't set explicitly -- but the whoami info is only used when generating a revision, which wouldn't be happening on a remote system anyway.
<Haffi___> nDuff: Your description is quite accurate...
<NfNitLoop> Hrmm.   Even dpush is failing...
<NfNitLoop> SubversionException: ("CHECKOUT of (file in read-only-dir) : 403 Forbidden
<NfNitLoop> why would it need to be checked out?   it's already been 'bzr pull'ed into the local repo, and no local changes exist...
<enigma42> jelmer: Does bzr-svn look at the "bzr:*" properties for the most recent revision, or does it look at the value of the properties in past revisions?
<enigma42> jelmer: A related question: Is there a clean way of removing all the bzr metadata from an existing svn repo and starting over?
<Haffi___> Hi again, just a silly question. I have created a test project, added some files, edited some and commited the changes. When I try to branch from another computer I just get an empty folder but not the contained files. What am I doing wrong?
<beuno> Haffi___, did you run "bzr add"?
<Haffi___> beuno: yep
<Haffi___> on  the server that is
<beuno> Haffi___, are you pushing to the other PC, or branching?
<Haffi___> I'm trying to fetch the newest versions of the files to the other computer
<beuno> Haffi___, so you're running "bzr push"?
<Haffi___> yes, I ran that command on the server
<beuno> Haffi___, pushing to a remove location doesn't create a working tree (the actual files), it just creates the repository (a .bzr directory)
<beuno> if you branch *from* it, you will get the files
<beuno> also, if on the server you run "bzr checkout .", it will create the working tree for you
<beuno> bare in mind that it won't update the working tree every time you push
<Haffi___> it says that the .bzr file exists
<beuno> Haffi___, maybe it's just "bzr checkout"
<beuno> I forget  :)
<Haffi___> that actually gave the same results...
<NfNitLoop> haha, yes.  just 'bzr checkout'
<NfNitLoop> `bzr checkout .` says to check it out ... into the current directory.
<Haffi___> Ok, I went into another directory and ran bzr checkout ../Code (where the files are). I just get an empty folder
<lifeless> Haffi___: what does 'bzr log ../Code' show?
<Haffi___> lifeless: nothing
<lifeless> Haffi___: you haven't committed, or you haven't pushed
<Haffi___> Ok, let's say I'm on my PC. I create a project (bzr init), I add a file, I edit it, run bzr add, and run bzr commit. Then I push this project via sftp to my server. with 'bzr push --create index sftp://...'
<Haffi___> *--create-index
<Haffi___> then I check the server to see which files are there, and there's just the directory, no files
<Haffi___> Can anyone spot what I'm doing wrong?
<NfNitLoop> Haffi___: you're doing nothing wrong.
<NfNitLoop> when you push over (S)FTP or HTTP...
<NfNitLoop> bzr doesn't construct the "working copy" of your files, because that would double (or more) the network traffic required.
<NfNitLoop> all it does is update the revisions in the .bzr directory.
<NfNitLoop> now if you bzr branch from that sftp location to your local computer, a working copy will be created on your local filesystem.
<NfNitLoop> If you *want* a working copy on the server, you can ssh to the server and do 'bzr checkout .'
<NfNitLoop> (in that dir)
<nDuff> Haffi___, it creates a .bzr directory that contains everything you pushed; it's all there, but hidden.
<spiv> In short: "bzr push" pushes branches, not working copies.
<Haffi___> yep, I noticed that
<nDuff> Haffi___, folks can branch or checkout from it, so you should be all good.
<NfNitLoop> Haffi___: the nice bit is that the .bzr directory is compressed, so it's smaller than a working copy too. :)
<Haffi___> Ok, now it works
<Haffi___> Well, I can go to sleep then :)
<Haffi___> Thanks you guys, this is an excellent community, very friendly and helpful.
#bzr 2009-01-08
<lifeless> I'm friendly and helpful? damn, must have had enough caffeine
<fullermd> And you have a pleasant outlook, too.
<abentley> jam: ping
<smoothice> Is there any way a bazaar branch can be pushed over SSH to a folder on a web server that is being served by Apache and have coders be able to run the branch directly over Apache?
<NfNitLoop> smoothice: Yep!
<NfNitLoop>  it does that by default.
<smoothice> NfNitLoop: it does? I just tried...
<NfNitLoop> just do:   cd yourrepo; bzr push sftp://yourserver/path/to/web/dir/
<fullermd> Yes.  You push over SSH to a folder on a web server that is being served by Apache and coders will be able to run the branch directly over Apache.
<NfNitLoop> smoothice: then have someone bzr branch http://yourserver/path/to/that/dir
<smoothice> ok
<smoothice> I added index.php to the repository and then pushed... although it isn't showing up in my sftp client or apache either...
<NfNitLoop> smoothice: by default, it only creates a .bzr directory, not a working copy.
<NfNitLoop> and your web server may hide .hiddenDirectories
<smoothice> So... how do I make it make a working copy?
<fullermd> Do you mean "run the 'branch'", or "run the branch"?
<smoothice> What's the difference?
<NfNitLoop> executing 'bzr branch', or executing the code within that branch.
<NfNitLoop> fullermd: I think he means run 'bzr branch'.
<fullermd> You can use checkout to make a WT on it.  Later pushes won't update it, though.
<fullermd> I think he actually means executing the code within the branch.
<fullermd> e.g., bzr push as a deployment mechanism.
<NfNitLoop> oh.   smoothice: which is it? :)
<smoothice> I'd like to be able to run the latest revision using Apache
<fullermd> Which it isn't.  If you actually have ssh (not sftp) access, you can use the push-and-update plugin to hack around it.
<fullermd> There's also a bzr-upload plugin; I'm not sure of the details of how it works or what server-side support it needs.
<smoothice> So in other words it isn't possible?
<fullermd> Well, those are two mechanisms that can probably give you the same end result.
<fullermd> 'push' qua 'push' won't do it, no.
<smoothice> alright
<smoothice> The upload plugin seems fairly straightforward to install...
<NfNitLoop> Or, if you have ssh access, just ssh to the web server and do a 'bzr pull'.
<fullermd> I _think_ the upload plugin does all the work client-side, and just needs a transport (like sftp) to blat the files on the server.
<smoothice> Yeah
<fullermd> The rest of the options (like push-and-update, what NfNitLoop just said, and various other related permutations) all rely on having bzr server-side.
<smoothice> I have a vps... so I was just finding out the best way for me to keep track of this PHP project I'm working on while also being able to run it directly.
<fullermd> Well, for me, my VCS basically never has anything to do with my deployment mechanism.  So, if you ask _me_ the best way, it would be "nothing to do with bzr".  That may be less helpful if you aren't me though  :p
<smoothice> yeah... I'm not using it for deployment though... this is my private apache server and deployment is on shared hosting somewhere else..
<fullermd> Well.  It [sounds like it's] still a deployment question, just not the ultimate deployment.
<smoothice> yeah... ok :)
<smoothice> well thanks for your help; I guess bazaar won't work this time around :)
<fullermd> Or it could be just a setup/move, in which case ignore me  :)
<fullermd> Oh, it works great for the VCS part.  With the mentioend accoutrements, it can roughly do the deployment side.
<fullermd> Whether that roughly is apparently smooth or really rocky would depend on details of just how you end up doing things.
<smoothice> alright
<fullermd> (and there are better people around than me to ask about them; I just know that they exist and seem to work well for some people)
 * nDuff wanders off to Nuclear Taco Night; will check email for any feedback on the patch now and again, but latency on revisions will be significant.
<lifeless> nDuff: thanks for doing the patch
<lifeless> nDuff: enjoy your tacos
 * igc lunch
<mwhudson> spiv: hello
<mwhudson> spiv: this looks a little odd to me:
<mwhudson> ^[..>>> bzrlib.branch.Branch.open('http://bzr.malept.com/bazaar-overlay')
<mwhudson> b = _
<mwhudson> RemoteBranch(http://bzr.malept.com/bazaar-overlay/)
<mwhudson> >>> b = _
<mwhudson> >>> b._ensure_real()
<mwhudson> Traceback (most recent call last):
<mwhudson>   File "<stdin>", line 1, in ?
<mwhudson>   File "/usr/lib/python2.4/site-packages/bzrlib/remote.py", line 1362, in _ensure_real
<mwhudson>     if self.repository._real_repository is None:
<mwhudson> AttributeError: 'KnitPackRepository' object has no attribute '_real_repository'
<mwhudson> >>>
<mwhudson> does it look odd to you?
<spiv> Yes.
<spiv> Which bzr version?
 * spiv hmms
<spiv> RemoteBzrDir.find_repository() returns a non-RemoteRepository.
<spiv> That seems... bad.
<spiv> Oh, hmm!
<mwhudson> spiv: hope you're having fun, i have to disappear :)
<spiv> mwhudson: so I think it's a server config issue
<spiv> (that the client doesn't handle gracefully)
<spiv> mwhudson: there's a smart server at /bazaar-overlay but not /
<spiv> So there is no accessible RemoteRepository for that RemoteBranch
<spiv> mwhudson: is there a bug about this?
<lifeless> groupcompress works again
<lifeless> lp:~lifeless/+junk/bzr-groupcompress
<bob2> yay
<lifeless> wow
<lifeless> I'm seriously inclined to just revert the "BzrVsGit" change
<lifeless> igc: ^ what do you think
 * igc reads it
<mlh> That they have a use TortoiseGit is not irrelevant for lots of people
<lifeless> thats true
<lifeless> its not really appropriate to have a git biased page on the bzr website
<lifeless> neutral is ideal
<lifeless> the lp integration stuff wasn't about generic public hosting; there are other public hosting sites that lp for bzr
<mlh> yeah the rest of the stuff seems unduly uhm
<mlh> whats the word? contentious?
<spiv> mlh: "citation needed", perhaps ;)
<lifeless> biased :) that was the intent expressed by the changelog of the author
<mlh> geez unsubscribe him/her
<mlh> "This make the bazaar guys fall their jaws." ?!
<lifeless> they are also wrong
<lifeless> as what they reference has no relationship to disjoint repository merges
<lifeless> I think this is a case of an uninformed advocate going nuts
<igc> I agree that most the changes don't actually improve the accuracy/usefulness of the document
<nDuff> lifeless, I don't think enjoying the tacos is quite the point at Nuclear Taco Night; I think it's more watching the new people trying to actually eat one. :)
<mlh> fall their jaws -> sounds like an attempted translation from German maybe of 'make their jaws drop'
<igc> For example, bound branches are more than just commit+push
<lifeless> poolie has already done one revert
<igc> the reference to http://cournape.wordpress.com/2008/10/30/going-away-from-bzr-toward-git/ adds value I guess
<igc> most of the rest seems to miss the original points being made
<lifeless> igc: I'm not sure it does; its not entirely accurate as a blog, and well there are plenty of folk posting in both directions
<poolie> so
<lifeless> jml: btw, 'bzr help commit' can show you stuff about commit.
<poolie> i'm not saying it was all wrong, but i'm not interested at the moment in picking through it to correct it if he's basically trying to bias it
<jml> lifeless: noted. :)
<igc> lifeless: agreed on both fronts, but the blog article was pretty balanced I thought, if not fully accurate
<igc> poolie: thanks for the revert
<igc> nDuff: just posted a review of your patch BTW
<nDuff> igc, thanks
<lifeless> gnight
<fullermd> Ouch, my jaw!
<mwhudson> spiv: only https://answers.edge.launchpad.net/launchpad-bazaar/+question/56078
<spiv> mwhudson: ta
 * fullermd mutters.
<fullermd> Does it bug anybody else that 'reconfig' isn't a builtin alias?
<spiv> fullermd: it hasn't yet.
<spiv> fullermd: I mean, it hasn't bugged *me* yet
<spiv> fullermd: but now that you've planted the idea in my brain, perhaps it will ;)
<fullermd> Hm.  Does it bug anybody else that you're not sending me certified checks?  Also a pony?   8-}
<spiv> fullermd: ok, those definitely aren't bugging me :)
<fullermd> What a cruel, heartless world   :(
<fullermd> OK, let's pretend I don't know python.  What's the difference between @classmethod and @staticmethod, and why would they differ on methods that are apparently called in exactly the same way?
<spiv> staticmethod isn't passed the class.
<spiv> i.e. staticmethod is basically a function that exists in a class's namespace rather than a module's namespace.
<fullermd> Ah.
<fullermd> Got a minute to explain why the difference in a specific place to me?
<spiv> Sure.
<fullermd> reconfigure.py.  @static to_checkout vs. @class to_lightweight_checkout
<fullermd> (and a number of other @static's and @classes, but those are right next to each other.
<fullermd> I guess the klass(bzrdir) is SORTA the same as Reconfigure(bzrdir)?
<spiv> fullermd: it's the same in the absence of subclassing, yeah.
<fullermd> Is there some reason to prefer one over the other?  And/or do you know of a reason there's the inconsistency across the methods there?
<spiv> And given that the Reconfigure class isn't subclassed, nor intended to be AFAICT, there's not really any reason to prefer classmethod over staticmethod (or vice versa).
<fullermd> So it's probably just "however $WHOMEVER felt like writing it"?
<spiv> The reason why you'd use classmethod generally is if you expect subclasses to matter.
<spiv> E.g. a .empty_clone method might make sense as a classmethod.  It doesn't depend on instance state, but you expect a to get back an object of the same class, not the base class.
<spiv> (But it's a shame there's no way to say "this is a method that is only on a class, not on an instance", and vice versa)
<spiv> Well, I guess there is the latter.
<spiv> fullermd: so yeah, I think with that code it's "whatever $AUTHOR felt like".
<spiv> That module/class is a bit weird, IMO.
<spiv> I'm not sure why Reconfigure.to_checkout and/or Reconfigure(...).to_checkout were chosen as APIs rather than module-globals.
<fullermd> I'm getting that feeling.  But I figure it's more the interface between me and the code...
<spiv> My guess is there's a minor amount of premature generalisation there.  It's not a big deal.  Just pretend the @*method functions are module globals, basically.
<fullermd> It does seem pretty abstract.
<vila> hi all
 * fullermd waves at vila.
 * vila waves back
<igc> hi vila - some more reviews for you today. Hope they help.
<vila> igc: They always do !
<fullermd> Furrfu.
<fullermd> Y'know that feeling you get, when you think "Hey, I can fiddle with reconfigure for 10 minutes before I go to bed"?
<fullermd> Yeah.  It don't work like that.
<igc> night al
<igc> all, that is
 * fullermd hopes that's right.
<fullermd> I don't feel confident I understand all those corners in Reconfigure   :|
<jelmer> moin
<nDuff> hrm; Branch(local_src_path).sprout(local_tgt_path, stacked=True) is failing with TypeError: sprout_read_locked() got an unexpected keyword argument 'stacked'
<fz> how do i add keyword support to bazaar?
 * nDuff switches to using BzrDir.sprout(), and all is well.
<nDuff> fz, wait a few months.
<nDuff> fz, seriously, though, there's ongoing work that's prerequisite to keyword support which will be going in as part of the EOL translation support.
<nDuff> fz, out of curiosity, what's your use case?
<EarthLion> bzr st
<EarthLion> removed:
<EarthLion>   concrete/blocks/autonav/ added:
<EarthLion>   blocks/autonav/
<EarthLion>  bzr mv --after concrete/blocks/autonav/ blocks/autonav/
<EarthLion> bzr: ERROR: Could not move autonav => autonav: concrete/blocks/autonav is not versioned.
<EarthLion> i don't see what it means there
<EarthLion> it is version as it shows that it has been removed
<EarthLion> the help for bzr mv tells me that --after is used --after        Move only the bzr identifier of the file, because the file
<EarthLion>                  has already been moved.
<EarthLion> which is exactly this situation
<EarthLion> anyone have any ideas why this would be saying this?
<fz> nDuff: I'm moving from svn to bzr and just go used to having the keywords, I don't really have a need for it :)
 * nDuff makes a much belated trek home and to bed.
<EarthLion> doh
<awilkins> EarthLion: The doh because you've realised that the file has been removed from the inventory so it's not versioned anymore?
<awilkins> EarthLion: I would rather like "--after" to notice that, I ran into it yesterday
<EarthLion> awilkins: doh because i couldn't seem to get it to work
<EarthLion> awilkins: could you define what you mean by inventory?
<awilkins> "The list of files that Bazaar currently cares about"
<awilkins> Have you uncommitted to get to this point?
<EarthLion> yes
<awilkins> The commit has implicitly removed the file from the inventory because it was missing
<awilkins> That implict removal is not undone by the uncommit
<awilkins> So you have to revert the file before you move it
<EarthLion> yep
<awilkins> There was a plugin for auto-move-stuff somewhere
<vila> pqm is playing with my nerves... now it seems my submissions are just ignored (at least when they were wedging it I knew they were taken into account...)
<vila> let's summon the LOSAs...
<vila> spm, mthaddon: Is pqm reachable by mail right now ? (and thanks for un-blocking it this night)
<hsn_> itsnt there some work in progress for speedup bzr check operation? it is slow - about 10k revision/hour
<awilkins> markh: Ping?
<vila> looks like pqm is back, thanks $WHOEVER
<jam> nDuff: ping
<vila> :-/
<vila> I rejoiced too early, pqm receives my submissions and... drop them on the floor ? I get no feedback, neither success nor failure :-/
<vila> spm: ping
<vila> jam: do you know how to contact some LOSA other than spm ?
<jam> mthaddon is another one to contact, but they are the only 2 that I know of
<vila> Same here ;-/
<vila> Was I blacklisted ? :-)
<vila> I even change my public branch from lp to http...
<jelmer> is anybody else seeing their info() output being printed to stdout when running the testsuite?
<jam> vila: Are you sure you aren't sending from a loom or 1.9 format branch?
<jam> I *thought* they upgraded the PQM's bzr to support 1.9, as statik asked me if that was okay a while back
<jam> But the times I've seen "drop on the floor" were generally because of not recognizing the source format
<vila> jam: I'm still in pack-0.92 /branch6 for my integration branch
<jam> jelmer: IIRC we only use "note()" in bzrlib, but I see in trace.py "info = note"
<jam> Otherwise, no I generally don't see it.
<vila> RHAAAAA, put my lp URL back and it's accepted 8-(
<jam> jelmer: In bzrlib.tests.TestCase.setUp we call _startLogFile() which calls "push_log_file()" though I think those are only for mutter()
<jam> hmm... I haven't really tracked down the code that is supposed to suppress it
<vila> jelmer: where are these info() calls ? In the test or in the code ?
<jelmer> even run_bzr() causes output on stdout for me
<jelmer> jam: ah, so maybe I'm just not running that anymore
<jam> jelmer: so part of the bzrlib.tests.TestCase setUp is supposed to suppress writing to stdout/stderr etc
<jelmer> jam: thanks, that was indeed the problem
<danser> I guess the answer is 'no', but does bzr have a function like 'svn propset svn:mime-type text/html' for serving a file with an html mime type on launchpad?
<jelmer> danser: no, sorry
<danser> jelmer: ok, no need to apologise :-)
<jam> danser: Launchpad explicitly doesn't allow exposing a lot of file types
<jam> because it doesn't want to be used as a generic hosting site
<jam> eg, upload a project with all of your images, and then refer to it from your website, making LP use the bandwidth
<danser> sounds logical to not support that indeed
<vila> jelmer: I just landed a patch on bzr.dev that allows writing credential stores as plugins
<jelmer> ah, cool
<vila> an example for '.netrc' is provided, you should be able to write one for svn
<vila> let me know if you need help
<jelmer> thanks, will do
<vila> We may at least be able to handle those 401 errors :)
<LarstiQ> will this help with when authentication.conf has the right credentials, but bzr-svn tries to use the (missing) svn credentials?
<jelmer> LarstiQ: bzr-svn should already be trying to use authentication.conf
<LarstiQ> jelmer: then I guess I should file a bug
<jelmer> LarstiQ: please do :-)
<vila> LarstiQ: This will help when svn itself knows the credentials and can provide them to bzr (i.e. authentication.conf will be able to say: for these sections, ask svn)
<LarstiQ> vila: hmm
<jam> vila: ping
<vila> jam: pong
<jam> Hey vila, I'm trying to smooth out some of the rough edges of stacked branches
<jam> mostly because I'm going to try dogfooding LP, and right now it is pretty painful to just do "bzr push"
<jam> The first thing I was going to do is fix it from re-opening the connection multiple times
<jam> And I wanted to check with you how you were testing that sort of thing.
<vila> bzrlib.tests.commands (there is a TODO about renaming it)
<jam> Is it only possible to test at that level?
<jam> For example, I know that doing Branch.open(really_a_stacked_branch) connects 2 times
<jam> (ATM, doing "bzr push lp:///" connects 4 times for a new branch)
<vila> You can use the ConnectionHookedTransport in transport_util I think to test at lower levels but...
<vila> .. no but, the idea is that it register itself as 'hooked:' so that you always get the right king of transport (and ensures you don't escape from the scheme (at least that's the idea)
<vila> s/king/kind/
<vila> no more king since 1789 on this side of the sea
<vila> But if you set up a stacked branch it should be quite easy to simply do the same kind of tests that already exist
<vila> The painful part is using pdb  since they are nearly blackbox tests the output is redirected...
<vila> ahhh, I knew I left some instructions:
<vila>         # Note: uncomment the following line and use 'bt' under pdb, that will
<vila>         # identify all the connections made including the extraneous ones.
<vila>         # import pdb; pdb.set_trace()
<vila> at the end of transport_util
<vila> jam: so basically you write a nearly blackbox test, set the breakpoint, find the offending connection, add possible_transport in the call chain and you're done :)
<kfogel> Has anyone seen a bug like ths before?  http://paste.lisp.org/display/73293
<vila> kfogel: It looks like you didn't commit the last time you merged so diff reports the pending merges
<kfogel> vila: a-yup
<kfogel> thx
<kfogel> vila: still getting it through my head that "sync me up with mainline" is a commit like anything else
<vila> kfogel: It still occurs to me from time to time :
<vila> kfogel: It still occurs to me from time to time :)
<jam> vila: just as an aside, you may like this command:
<jam>         import traceback
<jam>         traceback.print_stack()
<jam> It is essentially "bt" from pdb, but without actually stopping for pdb
<vila> jam: yummy ! Add that to the comment ;-)
<jam> I never saw the comment other than what you pasted here :)
<vila> bzrlib.tests.transport_util.py
<kfogel> This keeps throwing me: 'bzr send -o -' shows me a bundle for the change(s) I just made, but my log messages are not (humanly) visible in the bundle.  Is this expected?
<Peng_> kfogel: Yes.
<kfogel> Peng_: Do you happen to know if it's a deliberate design decision or just the way things fell out?
<kfogel> (It seems odd that bzr shows the diff but not the log message.)
<Peng_> kfogel: Sorry, I don't know why the bundle format was designed that way. The docs might.
<Peng_> kfogel: If you just want to diff against another branch, I'm sure there are better ways...
<vila> kfogel: the diff is targeted at reviewers, you're supposed to add your own cover letter and that's not the same intent at the commit messages
<kfogel> vila: *nod*
<vila> kfogel: I share your feeling though, now that you mention  it, the commit messages may help write the cover letter
<kfogel> Yeah, can see that one both ways.
<kfogel> I agree a cover letter is necessary!  But once I've read the cover letter, I usually want to read the log messages.
<kfogel> Or rather,
<kfogel> A better way to say that is: I *never* want to read a diff without also reading its log message.  Period.
<kfogel> :-)
<kfogel> (Well, perhaps that's exaggerating a bit, but only a bit.  It has to be a truly trivial diff for me not to want to see the log msg along with it.)
<vila> bunble buggy presents the commit messages: http://bundlebuggy.aaronbentley.com/project/bzr/request/<4966598F.8040109%40arbash-meinel.com> for example
<kfogel> vila: that's good
<kfogel> vila: but your earlier point is exactly what's happening to me right now -- my own commit message would have been helpful for writing the cover letter.
<spm> vila, jam, there are 3 LOSAs: mthaddon, herb and myself. fwiw...
<vila> herb ! The missing one ! :-)
<vila> spm: what are your TZs ?
<spm> vila: West coast USA, East cost USA, East coast Australia respectively. So pinging me at 2.30am isn't likely to get an immediate response :-)
<vila> spm: Now I know :-)
<spm> heh :-)
<vila> kfogel: so try 'bzr log -rsubmit:.. --short'
<kfogel> vila: thx
<jam> spm: well, mthaddon wasn't directly here, and I hadn't heard of herb before. Besides, we still got a response :) (just a bit later)
<spm> jam: heh
<nDuff> jam, ACK
<nDuff> ...pardon the latency, was sleeping.
<jml> jam: thanks for the Branch.open patch!
<jam> nDuff: sleep is for the weak :) At least, sleeping when I'm awake is.
<jam> I was just hoping for some more background on your patch, but I worked it out. And its been merged.
<jam> jml: Did you see the follow up? (Which fixes other cases for 'bzr push' at least?)
<jml> jam: yeah. it's great.
<jml> jam: one step closer to the day when pushing up no revisions takes about as long as an SSH connect :)
<vila> jam: Looks like my review and your followup crossed on the wire, I think my vote (and remarks) still apply or you want a re-review ?
<vila> jam: rhaa, you reply just arrived
<vadi2> How can I convert an svn repository into a bzr one? "bzr svn-import <svn location>" does not seem to work.
<Peng_> vadi2: Define "does not seem to work".
<spiv> vadi2: what error does it give?  (paste it into http://rafb.net/paste)
<vadi2> http://rafb.net/p/BCVXV790.html
<vadi2> It performs the import successfully, without an error, however the repository created is rather empty. While the real svn one has data in it
<Peng_> vadi2: It doesn't create working trees by default. Run "bzr co" inside a branch.
<vadi2> aha :)
<jml> when's 1.11 due out?
<igc> jml: rc today
<jml> igc: cool.
<poolie> igc, would i be right in thinking the best hg->bzr converter is through fastimport, and that it should be pretty solid on both sides?
#bzr 2009-01-09
<igc> poolie: I think so.
<igc> poolie: the hg-fast-export converter may have a few issues but I believe its working well enough for most people making the switch
<fullermd> igc: Should I follow the pattern of the others and have matching API and blackbox tests for that 'not supported'?
<fullermd> (or just one or the other)
<igc> fullermd: whatever abentley did
 * igc looks
<fullermd> Mmm.  I didn't see an obvious pattern in the other tests.  I did matching pairs for the two success and two failure cases.
<igc> fullermd: just blackbox will do I think
<fullermd> 'k.  I'll submit an update a bit later.
 * fullermd scampers off for a bit.
 * igc lunch
<fullermd> 'k, updated patch in.
<mi3> hello, could I ask a question?
<spiv> Of course.
<mi3> Let's say I want to separate my branch into two separate branches, because I'm splitting it into separate projects, complete with separate license restrictions.  This means that the resulting branches should contain no trace of files from the other one.
<mi3> Let's say I create two branches from my branch, and from each one I remove the files that belong in the other one.
<igc> bbl
<mi3> How could I remove history so files removed in each are not recoverable from that one?
<spiv> At the moment, bzr doesn't have any way to remove some files from your branch history.
<spiv> You could possibly use the rebase plugin or filter a fastimport dump to generate a new history without those files.
<mi3> I also looked into bzr split, but it seems that wouldn't help me in this situation, correct?  It seemed to just reconfigure where the base of the tree is but other files' history is still in the new repository
<spiv> Right, bzr doesn't really have any facility for modifying history, basically.
<mi3> hmmm I might have a look at the rebase tool, thanks for pointing it out to me
<spiv> You're welcome.  I don't think it's going to be easy to do what you want, unfortunately.
<mi3> Looks complicated.  I suppose the other option for me would be to start anew with the new project, ie don't worry about transferring across history for the files I'm pulling out under new license.
<spiv> Right.
 * fullermd has mentally meandered from time to time around the idea of building a grammar to describe history modifications...
<mi3> ok thansk
<spiv> You could at least use "bzr add --file-ids-from ../original-branch"
<spiv> Which would at least keep the filename -> file-id mappings the same, which might make attaching more history later a bit easier.
<mi3> ah yep I see
<mi3> So merging between them in future might be easier
<spiv> Yeah.  But if you're completely stopping work on the old history and switch completely over to the new one, it's probably a pretty marginal benefit.
<mi3> yeah.
<poolie1> lifeless: ping to make a 1.11 branch please
<lifeless> spm: uncommitted changes to pqm-config on balleny.
<lifeless> *spank*
<lifeless> poolie1: done
<poolie1> thanks
<spm> lifeless: indeed. ta. Were they mine (implied by the spanking)?
<lifeless> spm: well, not mine so losa
<spm> heh. oki, will throw to the others for review and commit.
<spm> actually - not a lot of point in review - it's been running for a month and a half....
<spm> thanks lifeless! iz committed.
<lifeless> poolie1: I've shoved the lca thing in canonicaladmin
<poolie1> hero
<poolie1> maybe you should just write a simple leave/expense system as a bzr plugin? :)
<spm> python: import lca-expense
<spm> ... actually now I think on it. I'm sure there's an emacs key binding already for lca expenses.
<lifeless> ciao
<poolie1> bye
<El_Guille2> hola
 * spiv -> weekend...
<fullermd> Is it just me, or is 'help revisionspec' lying?
<fullermd> ``while "bzr diff -r 3647..3649" includes the changes done in revisions 3647 and 3648, but not 3649.''
<fullermd> (I hate the rest of that paragraph anyway, because it's perpetuating thinking of emergant properties as special cases, but...)
<vila> hi all
<El_Guille2> hi vila
<poolie1> fullermd: it's correct
<poolie1> ah
<poolie1> no, you're right, it's wrong!
<poolie1> and confusing
<fullermd> Yeah.  That part I quoted is wrong.  Other parts are at least partly wrong.  And the whole thing is a bit eye-crossing.
<fullermd> The closed-vs-open range distinction made me take a mental fault to page in the terminology.
<fullermd> And then when you do, you realize that its use of precise terms like that is imprecise, since the diff range isn't open, it's half-open.
<fullermd> Very confuzzling   :(
<poolie1> it's the other way around
<fullermd> Mmph.  See what I mean?  That's a meaning of the term I didn't even have in my brain.  When I think half-open, it doesn't imply which half.
<fullermd> Anyway.  You wanna just fix it?  It seems to trivially correct that it would be ridiculous for me to work up a patch and submit it...
<poolie1> can you send a patch, i'm in the middle of something...
<fullermd> 'k
<poolie1> specifically rolling 1.11rc1
<fullermd> Don't roll it too tight.
<Peng_> Congrats on the release (candidate). :)
<fullermd> Sent.
* poolie1 changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11rc1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<vila> poolie1: ping
<poolie1> hi vila
<BUGabundo> hi guys
<BUGabundo> $ bzr branch lp:gwibber  -Dhpss
<BUGabundo> Permission denied (publickey).
<BUGabundo> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<BUGabundo> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x27056d0>
<BUGabundo> means anything to anyone?
<fullermd> --> Permission denied (publickey). <--
<BUGabundo> I know! but what that is mean?
<BUGabundo> launchpad permission changed?
<BUGabundo> or did my key expire?
<fullermd> That you don't have your key set up on LP (or you're trying to use a different key)
<BUGabundo> how do I check what key am I using with brz branch?
<fullermd> It should just use whichever ssh will grab.
<BUGabundo> can you help me debug it, please?
<luks> try: sftp -v YOUR_LP_USERNAME@bazaar.launchpad.net
<fullermd> I don't really know how to offhand.  I've only got one private key.
<BUGabundo> http://paste.ubuntu.com/102634/
<BUGabundo> is it any helpful fullermd, luks ?
<luks> it means that neither of the keys matches https://launchpad.net/~bugabundo/+sshkeys
<BUGabundo> I only have 1 sshkey
<BUGabundo> its the same for years
<luks> you have at least two in ~/.ssh :)
<BUGabundo> let me check just to be sure!
<BUGabundo> yeah just one private and one public key in there
<BUGabundo> AFAICT
<luks> no, two private keys
<luks> one RSA and one DSA
<BUGabundo> ahh
<BUGabundo> I have an RSA
<BUGabundo> 7a:0b:6f:40:da:92:69:30:fe:24:94:37:b7:67:e9:9f
<BUGabundo> B767E99F
<luks> well, does the public key you have there look like https://launchpad.net/~bugabundo/+sshkeys ?
<BUGabundo> 1024D/A1784EBB
<BUGabundo> oh wait
<BUGabundo> messing SSH keys with GPG
<BUGabundo> I have an expired DSA
<BUGabundo> on my ubuntu@BUGabundo.net key
<BUGabundo> could be it!
<BUGabundo> just re-did the import key process and got : The key B905F0C5B1924A9BA8F77E5A6398A34BA1784EBB has already been imported.
<BUGabundo> bah
<BUGabundo> could a name change cause this prob luks?
<BUGabundo> mine is .ssh/id_rsa.1.pub and not .ssh/id_rsa.pub
<luks> you need a matching private+public key
<BUGabundo> fixed!
<BUGabundo> some how the key got renamed!!!!!!
<BUGabundo> should I file a bug ?
<luks> a bug where?
<BUGabundo> maybe gnome-keyring (2.25.4.1-0ubuntu1) jaunty; urgency=low
<BUGabundo> got an update today!
<luks> heh, jaunty
<BUGabundo> ehehe
<BUGabundo> luks by the way... do you know what's up with bzr-beta at LP PPA?
<luks> no, sorry
<BUGabundo> getting 404 for a week
<BUGabundo> filed here https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/315398
<ubottu> Launchpad bug 315398 in gnome-keyring "ssh key renamed (possibly) after upgrade" [Undecided,New]
<Lo-lan-do> Hi all
<Lo-lan-do> beuno: I think you might be interested in the first patch in http://bugs.debian.org/511295
<Lo-lan-do> It relates to #305985 in Launchpad
<eleftherios> is there something lik Trac for bazaar other than the bzr trac plugin?
<eleftherios> something that I can install on my server, not hosted elsewhere
<LeoNerd> "Something like FOO that isn't FOO" <== you'll have to explain what FOO-likeness you want
<eleftherios> LeoNerd: an alternative to Trac that also works with bazaar and isn't offered only as a hosted service.
<LeoNerd> Trac does a -lot- of things.. is it just the source browser you wanted?
<LeoNerd> Or bug trackign / tickets / wiki / ...
<eleftherios> LeoNerd: bug tracking, tickets and source browser
<eleftherios> timeline
<eleftherios> would be nice
<fdv> the new unshelve commands (not bzrtools) fails with 'bzr: ERROR: No such file: None', same as reported in https://bugs.launchpad.net/bzr/+bug/309097, does anybody know if there's any other way of looking at the "shelf" and retreiving what's there as e.g. a patch?
<ubottu> Launchpad bug 309097 in bzr "bzr unshelve fails with "No such file: None"" [Undecided,New]
<fdv> right :)
<vila> bzr shelve --list ?
<fdv> vila: nope, not in 1.10
<fdv> that one's omitted
<vila> fdv: Oh yes, you have to upgrade to 1.11 ;-)
<asac> hi
<fdv> vila: which, incidentally, is still not out :)
<asac> bzr-git ... can i use that for production yet?
<fdv> vila: and I need svn-integration
<asac> i dont need full support. just want to track a single git branch read-only
<vila> fdv: 1.11rc1 release this morning :) (Or a few hours ago, depending on your TZ)
<fdv> ooh
<vila> fdv: But anyway, sheve --list couldn't make it in 1.10 and that's really what you want...
<fdv> well, yes and no, I guess, as I want the contents of the patch-sets as well
<fdv> actually, that's what I want
<fdv> hm, maybe try 1.11 locally and see if it
<fdv> ...'s able to unshelve for me
<vila> To see the shelf content I think you want 'bzr unshelve --dry-run <SHELF_ID>'
<fdv> vila: yes, but that fails with the above error :p
<vila> fdv: Oh sorry, I don't use shelve myself :-/ Looking at the code, a shelf-id seems do be of the form shelf-([1-9][0-9]*)...
<fdv> vila: it apparently finds the correct patch set
<fdv> as it reports the message I input
<fdv> but it fail :p
<fdv> fail_s_
<fdv> crap, same error with 1.11
<fdv> so the contents are presumably broken
<fdv> :(
<fdv> vila: but thanks for the tip :)
<vila> np
<beuno> Lo-lan-do, thanks
<Lo-lan-do> beuno: Speaking of loggerhead, how can I know whether caching is used?
<beuno> Lo-lan-do, it should create a sqlite db in /tmp
<Lo-lan-do> I see.  Any reason not to use the cachepath config entry?
<beuno> Lo-lan-do, ah, right, if you use start-loggerhead instead of serve-branches, it does
<beuno> for the next release, I'm planning on adding a config file for serve-branches so we can get rid of start-branches all together
<Lo-lan-do> I use serve-branches.
<Lo-lan-do> Oh, maybe I misunderstood.
<beuno> right, so serve-branches doesn't use the config file at all
<Lo-lan-do> Okay.
<beuno> it will use *a* config file(s) in the next release  :)
<Lo-lan-do> But yes please, do get rid of start-loggerhead :-)
<beuno> heh, will do!
<Lo-lan-do> Do you use a lot of features from YUI ?
<beuno> not at the moment, but we will more and more
<beuno> I have a few branches that start using it heavily
<beuno> but most of the current javascript is still mootools, so I need to migrate code over
<Lo-lan-do> It's just that I also submitted bugs.debian.org/511286, which is a patch to use the YUI provided by the system.
<Lo-lan-do> And the system currently only provides 2.5, so I wondered whether that would risk breaking because you use more recent features.
<beuno> Lo-lan-do, I suspect that libjs-yui isn't going to be YUI3
<beuno> right, 3.x and 2.x are incompatible
<Lo-lan-do> Damn.
<beuno> yeah :/
<Lo-lan-do> I did some testing which seemed to work, but I don't know what YUI is used for so I didn't know what to test.
<beuno> in general, we're going to be following YUI3 on the cutting edge
<beuno> so as they release new versions, we will probably update the code
<beuno> Lo-lan-do, it works because the current code doesn't use YUI at all in trunk   ;)
 * Lo-lan-do grumbles about shipping copies of external code
<awilkins> cd
<Spads> I have a question about config files in-tree:  I have a default config file that I maintain with sensible defaults.  When I do a checkout, I often need to change this file for local development.  If I ignore the file in development, the .bzrignore gets mingled, and if I don't ignore it I just know I'll end up doing something dumb like publishing my database password.  How can I safely avoid transmitting conf file changes without telling the other ...
<Spads> ... branches to ignore this file?
<Spads> So far I've just been grumbling and doing very selective commits on my development branches, but I just know I'll slip up at some point.
<kumi> I usually maintain a separate .template file for that type of thing
 * awilkins was just about to say that
<kumi> and remove the live config file from version control
<Spads> hmmm.  Part of the point of having the defaults is that the app Just Works when you run it
<awilkins> I also implement this by having the app read both user settings and the defaults
<awilkins> And having user settings mask defaults
<awilkins> You can then still have a user config file that you ignore but edit the defaults
<Spads> hmm, I was really hoping for a bzr solution
<Spads> I mean, i've gone through ways I could change the app, and I'd rather not
<Spads> since the behavior of this config file comes from upstream tools
<awilkins> You're asking for a way to version the file, but not version the file - I think that's a bit much to ask of a version control system :-)
<beuno> Spads, what I do, is add the file the first time with example values, commit, ignore
<Spads> beuno: and what do you do if you need to update the defaults?
<beuno> then, we you want to re-structure it, commit it explicitly
<Spads> aha
<Spads> okay that sounds like a good way to go about it.
<beuno> of course, that won't update the other branches
<beuno> because it's ignored
<Spads> oh
<Spads> well it's defaults
<awilkins> erm... even if you ignore it, it will still notice changes if it's in the inventory
<Spads> awilkins: from a merge or pull?
<awilkins> ignore only prevents new files being added implicitly
<Spads> ah
<Spads> I see
<beuno> awilkins, ir tracking changes to it
<beuno> s/ir/or
<beuno> hrm
<awilkins> beuno: No, ignore does not stop it tracking changes
<beuno> you can't ignore a committed file...
<awilkins> beuno: It only prevents "bzr add" adding it to the inventory
<awilkins> You can ignore patterns that correspond to inventoried files but it will warn you
<beuno> yeap yeap, I was wrong
<awilkins> And those files continue to be tracked
<beuno> Spads, so, 2 options AFAIK:  1. use configfile.example, 2. use a Makefile and have those files ignored by default
<Spads> Sad.
<awilkins> The only solutions to this AFAIK involve i) Being careful with commits (using shelves, looms, and discipline) - that always failes
<Spads> awilkins: yeah, basically that's where I'm at.
<awilkins> ii) Not versioning live config files
<awilkins> (in source, anyway
<awilkins> People version /etc and the like, but that's deliberate
<Spads> what if in my devel version I did a bzr rm --keep first
<awilkins> The file will stick around. If it's ignored, it won't be added to the inventory automatically. Changes will not be propagated to downstream branches
<awilkins> Because they won't be versioned at all.
<Spads> I think this may be the safest way to do this then
<Spads> rm --keep it in production and development branches, and ignore it
<Spads> if that propagates to published branches, no harm no foul
<Spads> easily repaired
<Spads> no launch codes problems
<fdv> are there anybody around who knows the merge / unshelve code?
<phinze> our dept switches to bzr today (!)
<phinze> so i may be around asking stupid questions :)
<mathrick> hiya
<mathrick> bzr is awfully slow to start up
<mathrick> bzr st on a non-repo takes at least 1.1s, after bzr and all is in the cache
<mathrick> hg st on the same dir takes 0.7s cold and 0.07s hot :(
<beuno> mathrick, what plugins do you have installed?
<mathrick> beuno: sec
<mathrick> http://pastebin.com/m5700f537
<beuno> mathrick, try the same without SVN
<mathrick> beuno: indeed, down to 200ms
<mathrick> still 2x slower, but it's much better
<beuno> :)
<mathrick> now, why is bzr-svn so slow?
<beuno> I'm sure if you run it with --no-plugins or something, it will take even less
<beuno> loading plugins takes a bit more time
<beuno> I think svn tries to open the branch even if it isn't svn
<mathrick> yeah, I've had a couple of bugs because of it already
<mathrick> beuno: surprisingly, it takes 500ms with --no-plugins
<mathrick> somehow ENOACCESS on ~/.bazaar/plugins is faster
<beuno> mathrick, that is suprising
<mathrick> ...and if I remove it, instead of chmod 000, it goes up to 700ms
 * mathrick files bugs
<jam> hey phinze, great to hear it
<ronny> yo
<ronny> LarstiQ: sup?
<LarstiQ> ronny: almost done with the flu
<LarstiQ> ronny: you?
<ronny> laptop half broke
<LarstiQ> ugh
<ronny> ok otherwhise
<ronny> but strugling with bzr again
 * LarstiQ tests his brain
<LarstiQ> yes, I seem to be able to think again :)
<ronny> i still cant find a good idea to map bzr's idea of repo -> directory branch to anyvc
<ronny> the model needs to fit well with git and hg
<LarstiQ> right, I see.
<ronny> going around in cycles atm, but i need support for repo/branch creation, as well as bzrs "unique" view on pull vs merge
<ronny> its more fun to play around in prolog
<LarstiQ> ronny: shouldn't pull/merge decompose easily over all three considering allowing/disallowing auto ehm, something with forward?
<ronny> LarstiQ: on git/bzr you can just pull without merge
 * LarstiQ suspects bazaar giving meaning to the left parent to be more of an issue
<ronny> eh git/hg
<LarstiQ> ronny: even when diverged?
<ronny> yup
<ronny> it will just make multiple heads
<LarstiQ> oh
<ronny> same goes for monotone
<LarstiQ> just make a new branch?
<ronny> that would be messing with the users directory setup, kinda unacceptable, guess i'll just have to error out
<LarstiQ> is the the on disk result of what anyvc does important?
<LarstiQ> or will all interaction go through anyvc anyway?
<ronny> LarstiQ: never ever implicitly mess with users stuff
<LarstiQ> ronny: I don't see hg/git being different here than bzr conceptually
<ronny> LarstiQ: also bzr is the only one that merges from a remote
<ronny> in git/hg you are in a workdir repo, pull in stuff, then merge heads
<ronny> in bzr you merge from the remote side
<ronny> (which might occasionaly be a local branch in the same repo, but still a different dir
<LarstiQ> right
<ronny> and thats a BIG difference to deal with
<LarstiQ> if anyvc manages the collection of branches, what is wrong with adding a new one to the collection?
<ronny> its not expected to happen implicit
<LarstiQ> but didn't the user explicitly say "anyvc-pull"?
<ronny> yeah
<ronny> but pull != make me a new branch
<ronny> i guess i'll have to make pull error out just like bzr pull errors out on that case
<LarstiQ> ronny: if you want a unified working, I think it needs to be
<LarstiQ> hg/git pull is more like that than bzr pull on a branch
<ronny> LarstiQ: from my point of view it would be unacceptable behaviour to create just another branch dir in the repo
<LarstiQ> they operate on repositories instead of branches
<LarstiQ> ronny: if the user is aware that is what is going to happen, why is it unacceptable?
<ronny> the 3 of them do not expose it in the fs, so its ok
<LarstiQ> as long as you don't stomp over existing stuff
<ronny> i  guess i can add a fetch operation that combines pull/merge for git/hg and does a merge for bzr
<LarstiQ> can git/hg just pull on one branch?
<LarstiQ> and error on divergence?
<ronny> they dont error on divergence
<LarstiQ> ronny: you need some clearly defined semantics :)
<ronny> yeah, guess i'll make up some logic
<ronny> hmm
<ronny> LarstiQ: its a tricky hell (
<ronny> i'll cook up some prolog things to define the semantics and proof them
 * LarstiQ has no prolog experience
<ronny> prolog rocks
<ronny> http://ronny.uberhost.de/2009/1/7/how-to-mimic-sql-in-prolog <- my most recent toy
<ronny> it took ages to get the operators right
<ronny> but its cool :)
<LarstiQ> sql in prolog? dude :)
<ronny> just the syntax
<ronny> i want to add a dml/ddl and do some analysis + a pseude-query-optimizer
<ronny> dml = data-modeling-language (ie create *), ddl = data-definition-language (ie insert/update *)
 * LarstiQ nods
<ronny> hmm
<LarstiQ> ronny: does this have any impact on sqlalchemy?
<ronny> no idea, probably not
<cr3> can I branch over http on launchpad?
<luks> yes
<ronny> LarstiQ: hmm, another weird thing will be monotone
<ronny> they have repo + branches together (even unrelated branches) and the workdir is just refering to the repo
<LarstiQ> ronny: how is that different from hgit?
<ronny> LarstiQ: you have n workdirs for each repo, not just one
<ronny> the repo is a sqlite db
<ronny> neat, powerfull and slow as hell
<LarstiQ> so you have n workdirs, each refering to the _entire_ repo and having b heads?
<ronny> LarstiQ: each workdir refers to a revision in the repo
<LarstiQ> can you commit in a workdir?
<LarstiQ> (I hope so)
<LarstiQ> if so, it automatically moves to the new revision? And leaves all the other workdirs where they were?
<ronny> LarstiQ: yup, pretty much like that
<verterok> jelmer: ping
<verterok> Hi all!
<jelmer> verterok: pong
<mathrick> jelmer: bzr-svn makes bzr startup horribly slow
<verterok> jelmer: maybe this is of your interest :). Bug #290711
<ronny> yo jelmer
<ubottu> Launchpad bug 290711 in bzr-xmloutput "bzr-xmloutput memory leak?" [Undecided,New] https://launchpad.net/bugs/290711
<ronny> sup?
<mathrick> is there any plan to fix that?
<jelmer> mathrick: are you sure? Last time I checked the majority of the startup time was in the launchpad plugin
<mathrick> ronny: doesn't that multi-workdir system of theirs cause problems? What problems does it solve, anyway?
<jelmer> hey ronny
<ronny> mathrick: monotone#s multi-workdir system causes no problems
<ronny> jelmer: having some issues mapping bzr to anyvc
<jelmer> verterok: that's a known bug fixed in 0.5
<ronny> differences in the pull/push/merge concepts due to the lack of multiple heads
<verterok> jelmer: oh, great!
<mathrick> ronny: but if you move one workdir, the others will have automatically diverged. That sounds like a recipe for disasters
<jelmer> verterok: it would only happen by constant trying to open a location as a branch though
<jelmer> ronny: what do you do for e.g. svn?
<verterok> jelmer: yes, the xmlrpc-service stays in memory and accept commands just like the CLI
<mathrick> jelmer: I'm not sure anymore
<verterok> jelmer: so it open the branch each time :/
<ronny> mathrick: but its ok, you just use them like branches
<mathrick> ronny: oh, so workdirs have their own heads?
<ronny> mathrick: there is basically no real difference in usage to a bzr repo with directory branches
<mathrick> if so, calling them workdirs is misleading
<ronny> mathrick: workdirs just point to revs
<ronny> the revs are in the shared repos
<mathrick> sure, but "workdir" for me is files on disk, not anything directly related to any repos or revs
<ronny> jelmer: no repo support for svn, it cant deal with most things, and there is no reliable way to deal with branches/tags
<jelmer> ronny: So fwiw, I've been working on multi-head support in bzr
<jelmer> ronny: for now, you should be able to just always report a single head
<ronny> yup, however i cant yet use the pull;merge workflow
<ronny> i guess i'll map it to fetch for now
<ronny> (what git/hg do for combined pull/merge
<kumi> Hi folks, I'm finding bzr abnormally slow. I have this modest branch with 299 revisions, and I recently moved the remote server to a new location. I setup the new ssh keys and so forth, and tried a test push (a tiny change.) It took 15 minutes!
<kumi> Then I committed another tiny change, and pushed again. This time it only took a few seconds.
<kumi> What's going on?
<kumi> Does bzr detect a new location and scan through the entire remote branch history, or something like that?
<Peng_> kumi: Nothing odd should happen if you change the push location. My only guess is that you pushed to the wrong location, so it had to upload everything. (Anyway, I'm going AFK now. Sorry I couldn't really help.)
<Peng_> kumi: Oh! If it's a large branch, or you're on a horribly slow internet connection, it may have decided to pack the repository, which would involve downloading and re-uploading a potentially significant amount of data.
<Peng_> kumi: (I mean, it'll pack it occasionally no matter the size of the repository or speed of your connection, but if it's small and you have a fast connection, it shouldn't take long...)
<Peng_> kumi: So anyway, I'm going to change my guess to "the repository was packed". It's just a coincidence that it happened when you moved servers.
 * Peng_ goes AFK
<Jc2k> jelmer: yo
<Jc2k> jelmer: i just cobbled together a front end for difflib.SequenceMathcher that emits the git delta opcodes used in packs
<kumi> Peng_: thanks for the info. I actually just copied the .bzr from one server to another, and didn't do anything else. the repo is very small.
<kumi> How can I tell if a repo is packed? my local one reads:
<kumi> repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)
<kumi> I guss that means it's packed? Can I unpack it, somehow?
<kumi> *guess
<kumi> Nevermind, pushing is quick now, and I don't plan to change push location again any time soon
<fullermd> Er, if the branch were in a repo on the old server, and you just copied its .bzr, it DID have to push all the revs...
<enigma> Hm...I'm seeing a strange bzr-svn error using 0.5
<enigma> bzr: ERROR: exceptions.AssertionError: Empty parent 'dfe-mon/branches' added, but child 'dfe-mon/branches/foo' wasn't added !?
#bzr 2009-01-10
<enigma> jelmer: I just added a bug for that AssertError I saw: https://bugs.launchpad.net/bzr-svn/+bug/315666
<ubottu> Ubuntu bug 315666 in bzr-svn "AssertError: Empty parent added, but child wasn't added" [Undecided,New]
<kumi> fullermd: but I thought if a standalone tree had all of the revisions stored in .bzr? And when I copied it to the remote server and checked the log, all of the revisions were there...
<kumi> - if
<fullermd> Well, if it was standalone, then yes.
<seb_kuzminsky> hi folks, is there an up-to-date ppa for bzrtools and bzr-svn?
<seb_kuzminsky> i'm on intrepid
<seb_kuzminsky> the bzr ppa has really out-of-date bzrtools packages, and the bzrtools lp project doesnt have its own ppa
<seb_kuzminsky> oh i see, the nightly ppa has bzrtools
<seb_kuzminsky> never mind me...
<seb_kuzminsky> hm, but the bzrtools .deb in the nightly bzr ppa reports version 1.10 (using "bzr plugins"), and then complains it's older than the bzr .deb, which is 1.11rc1:
<seb_kuzminsky> 0 seb@water /home/seb/work/bioserve/bionet2.bzr/subtopic/client/watcher>  bzr shelf ls
<seb_kuzminsky> Plugin "Bzrtools" is not up to date with installed Bazaar version 1.11rc1.
<seb_kuzminsky> There should be a newer version of Bzrtools available, e.g. 1.11.
<seb_kuzminsky> Patches on shelf 'default': None
<Leefmc> I think i found a bug.. or workflow problem with bzr.. and would like an explanation of it. If i run a test and pastebin in it, can anyone review my actions?
<Leefmc> http://dpaste.com/107341/ someone please check it out. Its annoying because it wont let me create a new branch and switch to the newly created branch..
<El_Guille2> hola
<El_Guille2> has someone used bazaar for web sites ??
<verterok> El_Guille2: take a look to the bzr-upload plugin
<El_Guille2> yeah .. i did xD
<El_Guille2> it is gonna make my life much easier
<ziroday> Hi, how can you see bzr's progress on branching?
<ziroday> Hi, I keep getting 104 errors when trying to do bzr branch lp:do
<j^> how does the loggerhead serve-branch --user-dirs option work?
<rysiek|pl> hi guys
<rysiek|pl> I cannot seem to find a definite answer to this:
<rysiek|pl> can a branch hold other branches? or, can a repo hold other repos
<fullermd> Depends on what you mean by "hold".
<fullermd> You can put a branch underneath another branch, and a repo underneath another repo.  But that doesn't forge a link between them.
<rysiek|pl> /path/to/repo1/somedir/repo2/branch
<rysiek|pl> so that I could bzr clone /path/to/repo1
<fullermd> You can't clone a repo in the first place.
<rysiek|pl> AND bzr clone /path/to/repo1/somedir/repo2
<rysiek|pl> AND bzr clone /path/to/repo1/somedir/repo2/branch
<rysiek|pl> simply put, I need finer-grained control over what can be cloned/checked-out
<fullermd> Certainly you could put a branch underneath another one, and clone either one.  But grabbing the outer won't grab the inner; the outer doesn't know anything about it, other than as an unversioned directory inside it.
<rysiek|pl> ah
<fullermd> Eventually, nested tree support will redefine some of that.
<rysiek|pl> well, that defeats the whole purpose of it
<rysiek|pl> thing is, I have a project that uses as it's core another bzr-versioned project
<rysiek|pl> the idea was to have: project-branch/ and project-branch/core
<rysiek|pl> so that changes in project-branch/core can be bzr merged upstream
<rysiek|pl> but bzr clone project-branch gets the whole deal, along with project-branch/core
<rysiek|pl> and... project-branch is only a mere branch inside a wider meta-project's repo
<fullermd> The only way that would work right now would be if you actually merged core into project-branch.  And then those revs couldn't be directly merged upstream, they'd have to be cherry picked.
<rysiek|pl> right
<fullermd> What you want there is by-reference nested trees.
<rysiek|pl> I assume something like project-repo/core-branch and project-repo/project-branch
<fullermd> And that's a "someday" feature.
<rysiek|pl> would work as expected? i.e. bzr cloninig project-repo would get me both branches
<fullermd> You can't clone a repo.  Only a branch.
<fullermd> Shared repositories aren't semantic units in bzr.
<rysiek|pl> ah
<rysiek|pl> so there would be no single operation on the repo I could perform to get all the branches within?
<fullermd> Not built into bzr, no.
<fullermd> There's no way to ask a repo "what branches do you have"; it doesn't know.
<rysiek|pl> so, what's the point, actually, in creating a repo, instead of a "dumb" directory with branches within?
<fullermd> It saves space and I/O, since you only have one copy of common history.
<fullermd> If you've got two branches that aren't related, of course, you don't save anything.
<rysiek|pl> right
<rysiek|pl> thanks, that got a lot things cleared-up
<fullermd> There's a command 'branches' in bzrtools that looks under a dir and tries to list all the branches there.
<fullermd> But it does it by walking the dir tree and asking each dir "Hi there, are you a branch?"
<fullermd> (works pretty much the same whether you're scanning a repo, a bunch of standalone branches, a dir tree with 5 different repos in it, etc)
<rysiek|pl> I've found a plugin or two that more or less do what I need
<fullermd> There's been talk about a scmproj plugin (or some name like that) lately, which could help.
<rysiek|pl> but come to think about it, those nested trees would be awesome
<fullermd> Yeah.  The feature would be perfect, if it were done   :)
<fullermd> scmproj (AIUI) gives you something similar, with a little outside help.  I could be wrong though; I'm not watching it too closely.
<garyvdm> Hi - Is there a way to check if there is a working tree in a remote location?
<garyvdm> Unfortunately BzrDir.has_workingtree allway raises NotLocalUrl weather there is a working tree or not.
<garyvdm> Note: I do not intend to open the working tree remotely. I'm actual want to check that it is not there.
<wekt> Is there a more up to date package source for Debian Lenny?
<maxb> Get packages from experimental and rebuild?
<beuno> http://arstechnica.com/news.ars/post/20090107-dvcs-adoption-is-soaring-among-open-source-projects.html
<vadi2> Hello. Is it possible to see the history of a specific file only, not the whole branch?
<luks> bzr log <file>
<vadi2> I see, thanks
<gutworth> why does cmd_missing have to lock the branches twice?
<gutworth> it does so in the cmd_missing class and in bzrlib.missing.find_unmerged
<LarstiQ> did it drop the first lock by then?
<gutworth> no
<kumi> related to vadi2's question: is it possible to see the history of a specific file that existed previously, but is deleted in the tip revision?
<Ambro> hello i am a web developer and i am new at version control systems
<Ambro> i am uploading a website, i use bzr-upload plugin and it is working but i have two different files locally and remotely
<Ambro> there is a mysql conection php file lets say conection.php
<Ambro> but they are different ....  how should i use bazaar in this case ???
<luks> I'd suggest to not version them
<luks> version the default configuration in a different file instead
<luks> e.g. config.php.default is versioned, config.php is always local and not versioned
<Ambro> that would be just deleting the files from bazaar right
<Ambro> deleting and keeping them of course ...
<luks> yes
<luks> maybe somebody has a different idea, but this is what works for me
<Ambro> ok thanks i'll try that
<ronny> LarstiQ: any quick idea for running anyvc tests with different bzr versions?
<LarstiQ> ronny: you need to have different versions of bzrlib in the python path
<ronny> hmm
<ronny> i wonder if i can make up a test-rerunner that runs the testsuite once per vcs + version and collects the results
<ronny> combined with a setuptool to set those up
<Ambro> bzr-upload remembers only one old location and not the last i used
<Ambro> how can i get it to remember a specific location ???
<Ambro> or maybe i'll just use an alias ..
<james_w> Ambro: bzr upload --remember <location>?
<Ambro> thanks
<Ambro> can i get it to remember the password ?? .. i tried putting it in the remembered location but it asks me for it again
<ronny> LarstiQ: btw, i finally found a way to correctly abstract bzr
<LarstiQ> ronny: oh?
<ronny> LarstiQ: i have 3 basic entities - repo, branch, workdir
<ronny> they will be in arbitar relations from 1:1 up to n:m
<ronny> and they can be located together
<LarstiQ> ronny: heh, that is exactly what the bazaar concepts are too
<LarstiQ> so you're modelling bazaar 1:1 then
<ronny> no
<ronny> branch/workdir relations are different
<LarstiQ> how do they differ?
<ronny> workdirs may not have a single asociated branch
<ronny> in monotone it can be arbitrary
<LarstiQ> ah yes
<LarstiQ> do they need to be tied to 1 repo though?
<LarstiQ> or does that not matter
<ronny> and in git/hg the model of workdir=repo + n branches fits
<lucypher> Hi, is there any way I can keep (777) permissions of a folder?
 * LarstiQ nods at ronny
<ronny> as for darcs, repo=workdir=branch
<ronny> so its like a standalone bzr branch
<ronny> workdirs/branches will have "tags" they may be movable/fixed and local/distributed
<treeform> hi am having problems doing bzr co on a 512mb server because it taken 100% of memory and swap (about 1.5GB - kernel)
<treeform> is there a way to get around this kind of memory usage?
<treeform> i will try to copy the .bzr part and bzr co from that, i think i did that once and it worked
<Peng_> treeform: What version of bzr? Memory usage tends to get better over time.
<treeform> 1.8
<Jaearess> Does anyone have experience with setting up a Bazaar shared repository with Redmine? When I point Redmine to my Bazaar repository, it tells me "The entry or revision was not found in the repository" and the error "bzr: ERROR: Not a branch: /path/to/my/repository/.bzr/branch/" shows up in my Apache logs. I know Bazaar is working fine because I've had Redmine working with a single branch before.
<luks> maybe it can only work with branches?
<RAOF> Is that error verbatim?  If so, it looks like there's a little configuration you need to da :)
<Jaearess> No, it's not verbatim. The path in Redmine is correct, I just took it out of the error message.
<Jaearess> If it's only capable of working with branches, is there a way of doing multiple branches per project (sub-branches or something)?
<Jaearess> Since Redmine will only take one repository per project I mean. If it can only work with a branch, is there a way to work with multiple branches inside that one branch? (So there could be a development branch, stable branch, releases, etc.)
<Peng_> This sounds like more of a Redmine question.
<Jaearess> Okay, I've tried finding out there and got to response at all, so I was hoping someone here could help. Thanks anyway.
<Jaearess> No repsonse, rather.
<Pete_> Hello.  Can anyone help me get loggerhead to work on apache?  I have it running on the localhost:80, but cant get it to work when someone types in : http://bzr.website.com
<Pete_> To be clear i have gotten it to show up using mod rewrite to force everything to localhost:8080... however, loggerhead seems to screw up and displays links for files as localhost:8080, disregarding the mod rewrite
#bzr 2009-01-11
<speakman> hi folks!
<speakman> I'm having this common webdevelop issue with bzr. A few users to commit to a central repo. There's still no authentication within Smart Server right?
<Peng_> Right.
<speakman> Another issue with this web developing (actually php), is there any "proper" way to get the remote working tree updated when committing?
<Peng_> speakman: There's a bzr-push-and-update plugin. If you're using checkouts, I dunno if it would work.
<speakman> But then it will be required on all clients?
<speakman> Isn't there a post-commit hook to be used on the server side for such things?
<Peng_> ...Possibly.
<speakman> How about the bzr+http approach, will it work with simple htdigest for auth?
<Peng_> I'm sure you could set up http auth in your web server.
<speakman> And is there any reason not to use the mod_wsgi with bazaar? No howtos seems to cover that setup.
<Peng_> It might be difficult to secure though..
<Peng_> speakman: Eh. It's probably just that nobody's written the documentation.
<speakman> Easy as that. :)
<Pete_> Hello.  Can anyone help me get loggerhead to work on apache?  I have it running on the localhost:80, but cant get it to work when someone types in : http://bzr.website.com
<james_w> are you using ReverseProxyPass?
<james_w> oh
<james_w> you're using mod_python and apache directly?
<Pete_> i want to just use apache
<james_w> ok
<Pete_> or do w/e is needed to just get it working
<Pete_> lol
<james_w> can you access it at "<your ip>:80" ?
<Pete_> no
<Pete_> but.
<Pete_> if i go terminal and use lynx, i can
<james_w> using the IP address?
<james_w> or using the domain name?
<Pete_> one sec ill put it in pastebin
<Pete_> http://pastebin.com/d676f76c7
<james_w> oh, 8080?
<Pete_> ya, sorry it was a typo earlier
<james_w> you said 80 before
<james_w> ok, so it sounds like you are not using mod_python, but running loggerhead by another method, is that correct?
<Pete_> i suppose
<Pete_> what is the mod_python way  of doing it?
<james_w> I'm not positive you can
<Pete_> i was just running serve_branches from the directory i wanted to start the branches in
<james_w> I assume you can
<james_w> ah, ok
<Pete_> oh ic
<james_w> if you want to keep using serve-branches then look for a ReverseProxyPass tutorial
<james_w> I think that's what you need to use
<Pete_> sorry, im also learning the whole server apache thing. :( sorry for the lack of knowledge there
<Pete_> earlier
<Pete_> i was able to get it to work by using a Proxy and mod_rewrite
<Pete_> but it only worked halfway, half of the links would show up as localhost:8080/filename and not work....
<james_w> hmm
<Pete_> http://pastebin.com/m6f350e95
<Pete_> that is the apache config file i used
<james_w> there may be a serve-branches option to change what those links are generated as
<Peng_> Pete_'s nick is really confusing me. D:
<Pete_> --host=USER_HOST      Host Loggerhead should listen on.
<Pete_> would that be my ip or the url?
<Pete_> Ugh, and now when i try using the --host=bzr.petederemer.com option i just get an error: socket.error: (98, 'Address already in use')
<nDuff> Pete_, I don't have the loggerhead source handy, but by convention the default should be 0.0.0.0, ie. to listen on all interfaces.
<nDuff> Pete_, it sounds, though, like something else may have the port open.
<Pete_> nDuff: i got it working. now i just have to figure out how to get http://173.45.224.235:8080
<Pete_> to show up as bzr.petederemer.com
<nDuff> Pete_, is doing a redirect from http://bzr.petederemer.com/ http://bzr.petederemer.com:8080/ unreasonable?
<nDuff> (if so, you certainly do have other options, but it's the easy/quick/cheap approach)
<Pete_> nDuff: i would like to keep it cleaner
<Pete_> i think my iptables are blocking port 8080, so im opening those up right now
<nDuff> ...hmm, it's using paste... doesn't Paste support WSGI?
<Pete_> what is wsgi?
<nDuff> a protocol for communication between webservers (say, Apache) and webapps.
<Pete_> well hot damn
<Pete_> any tips on using it? or should i just hit the website straight up
<nDuff> ...actually, looking at the README, looks like the preferred deployment approach is still mod_proxy...
<nDuff> ...given that that's what the devs prefer, I'm surprised you were having trouble with redirects.
<Pete_> what readme are you seeing this in? the one i looked at was like 10 lines long :(
<nDuff> you *were* using a ProxyPassReverse directive, right?
<Pete_> http://pastebin.com/m6f350e95
<Pete_> i tried that
<Pete_> but had very very limited succes
<Pete_> but had very very limited success
<nDuff> err, the README.txt in the loggerhead source directory I'm in is 117 lines per "wc -l".
<nDuff> ...and has an explicit section "SERVING LOGGERHEAD FROM BEHIND APACHE"
<Pete_> err, that file did NOT look lliek the one i read
<Pete_> :(
<nDuff> http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/1.10/annotate/head%3A/README.txt
<Pete_> Now im really mad... the different documentation wasted several hours of my time :(
<Pete_> i think i read the readme in the debian package
<nDuff> ahhh
<Pete_> apparently, a very silly thing to do. haha
<Pete_> ok thanks ill read and let you know if  i have any issues
<Pete_> thanks!
<Pete_> nDuff: http://pastebin.com/d4eea86df  i am now getting access forbidden errors :(
<nDuff> Pete_, do you have any Allow clause applying to that Location?
<Pete_> nDuff: Not that I know of.  but i dont have a deny either?
<nDuff> Pete_, right -- so you're relying on default behavior. Smart (from a security perspective) default behavior for any server is to not allow access to anything unless it's been explicitly granted.
<Pete_> nDuff: ah, didnt know that, will allow it right now
<nDuff> Pete_, ...that said, the default Order deny,allow makes things which don't match either directive permitted (while Order allow,deny does the reverse)
<Pete_> nDuff: the location here is the location relative to the site right?
<Pete_> nDuff: or is it the location of the folder im trying to serve?
<nDuff> The former.
<nDuff> If you were talking about a location on-disk, you'd be using a Directory section, not a Location one.
<Pete_> http://pastebin.com/d45f286ca
<Pete_> still having issues :(
<nDuff> Pete_, erm, I meant for you to put those directives in the Location clause, not in a separate Directory clause
<nDuff> Pete_, my apologies if I was unclear.
<Pete_> nDuff: oh
<nDuff> ...my comment about "if you were talking about a location on-disk" was explaining *why* you're putting them in a Location clause rather than a Directory one, as when you're proxying something from a local service, it's not coming off a disk as far as Apache is concerned.
<Pete_> ah, i see
<Pete_> http://bzr.petederemer.com/ , still getting getting a service temperary unavailable
<Pete_> rather now im getting
<Pete_> nm just took a minute
<Pete_> :-D
<Pete_> nDuff: one issue. now if i click on a link it takes me to another subdomain for some reason :(
<Pete_> http://pastebin.com/d55c13e3a
<nDuff> Pete_, using it from here it looks fine.
<nDuff> Pete_, can you describe very specifically how to reproduce?
<Pete_> nDuff: click on the cs350hw link
<Pete_> nDuff: it takes you to afrolegs.com
<nDuff> Pete_, it brings me to http://bzr.petederemer.com/cs350hw/files... I don't imagine you'd be using an ancient browser that doesn't provide a Host: header?
<Pete_> nDuff: Google Chrome...
<nDuff> well, that's certainly not the problem, then...
<nDuff> ...hang on, I'll try from my Windows VM.
<nDuff> nope, I can't reproduce it here using Chrome either.
<Pete_> nDuff: wtf?!
<Pete_> ie does it fine
 * nDuff remembers Chrome having a take-a-screenshot feature, but doesn't remember where it is.
<Pete_> its chrome 2.0
<Pete_> i dunno if that matters...
<Pete_> but still thats just gay
<nDuff> Pete_, that *is* bizarre. Can you reproduce it with other browsers?
<Pete_> nDuff: Nope
<Pete_> well this is REALLY strange
<Pete_> but clearing thee cache worked
<Pete_> im not sure why it was cached like that to begin with though...
<Pete_> lol
<Pete_> thanks sooo  much!
<nDuff> Glad to help.
<Pete_> nDuff: i still cant believe that i wasted a week because the debain readme was incomplete
<wekt> What does LP error message mean?
<wekt> "Series head on sane-backends has no branch associated with it"
<avuton> How do I check the version of a remote repository without checking it out
<phanatic> avuton: bzr revno remote_address
<avuton> Aah, thanks :)
<avuton> hrm, that isn't working on http://bazaar.launchpad.net/~lottanzb/lottanzb/
<avuton> Says it's not a branch
<luks> because it's not a branch
<luks> the currect url is bazaar.lp.net/~USERNAME/PROJECTNAME/BRANCHNAME
<luks> you are missing the last part
<avuton> Oh, sorry, I'm so infamiliar with bzr
<luks> no, this is about launchpad, not bzr
<sender> hi, can anyone help me installing bzr on my debian box?
<sender> aptitude show bzr gives me: Version: 0.11-1.1 - is this up to date?
<phanatic> sender: that's a very old version
<sender> phanatic, tx.. thought so :/
<phanatic> sender: this page should help you a bit: http://bazaar-vcs.org/DistroDownloads
<sender> tx, seen that.. trying to use backports.org now, it gives me a  GPG error ..
<sender> "The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EA8E8B2116BA136C"
<sender> rather different problem.. any idea how do i fix this? :)
<phanatic> you should be able to override that somehow. not sure how :/
<sender> phanatic, this did it: apt-get install debian-backports-keyring.. thanx! off now exploring bzr :)
<phanatic> sender: that's great, have fun! :)
<sender> phanatic, shoot i'm now at Bazaar (bzr) 1.5 .. am i missing out with this version (1.10 most recent, right?) is this advanced enough or do you reckon that i compile from source?
<phanatic> sender: i think 1.5 is still pretty old, so my advice would be to do a manual install (you can remove it later pretty easily)
<sender> phanatic, ok I'll try this, will be a first
<Sonderblade> is there something like git-svn for bzr that works really well?
<LarstiQ> Sonderblade: bzr-svn
<davidstrauss> lol
<asabil> Sonderblade: and it works better :p
<asabil> (it is only annoying sometimes when the bzr and bzr-svn versions don't match)
<Sonderblade> good to know, git-svn is very nice and if bzr-svn is even better, then i'm happy
<thumper> morning
<lifeless> hi
<Sonderblade> bzr diff is kind of slow, i thought it only operated on local data?
<RAOF> It does, yes. It needs to hit the disc a bit, though.
<RAOF> lifeless: What sort of debug information would be useful for a "bzr search displayed a bunch of binary data and messed up my terminal character map" bug?
<Sonderblade> a lot it seems
<Sonderblade> in git, diff, log and blame are instanteous but take a long time in bzr
<RAOF> Some of that is the different type of output; bzr log shows the topological log, rather than the list of commits in chronological order.
<RAOF> Some of that is python overhead.
<RAOF> Perhaps some of it is an outdated repository format, or old bzr?  I don't find the diff time obnoxious.
<Lo-lan-do> Speaking of which (I havent whined about it for quite some time)... is there work done on the reduction of the startup time?
<Sonderblade> on the same repos, "bzr log | less" takes 7 seconds but "git log" less than one second
<ronny> hmm
<RAOF> Right. "git log" doesn't have to walk the repository in the same way "bzr log" does.
<RAOF> In return, you get what is IMO more useful output.
<ronny> LarstiQ: i had to change the abstraction, now i need repo<>workingset<>branch<>workdir
<Sonderblade> RAOF: in this case it is not the "walk" that is taking the time, both repos are just one long svn HEAD branch
<RAOF> We have, at this point, reached the limit of my bzr-internals knowledge.  Are they both native repositories, or is it an bzr-svn/git-svn thingy?  That might make a difference.  Maybe.
<Sonderblade> one is bzr-svn, the other is git-svn
<lifeless> so I have a ew queued questions I see :P
<lifeless> *few* queued...
<lifeless> Sonderblade: bzr diff slow - should be < 1 second across the board for working tree diffs; for historic diffs it will be slower (potentially radically slower) though that is being worked on
<lifeless> RAOF: pointer to a repo and a search that does it would be best
<lifeless> RAOF: patch that fixes it better still
<Sonderblade> lifeless: historical diffs?
<lifeless> Sonderblade: diff -r x..y
<lifeless> Lo-lan-do: not much happening on startup reduction at the moment
<lifeless> Lo-lan-do: various folk have done analysis of what makes it slow; seems to be most accurately summarised as 'python;
<Lo-lan-do> :-/
<lifeless> Sonderblade: gits raw extraction speed is extremely fast; I'm actually analysing exactly what at the moment; I suspect its a combination of less copies (e.g. use of mmap) and the IO ordering of packs which is pretty good (we tend to have more recent revisions at the end of the pack not the fount; this is a limitation in current storage not a design goal)
<lifeless> Sonderblade: so when you say diff is kind of slow; are you talking milliseconds or seconds or ... ?
<lifeless> Lo-lan-do: more specifically it appears to scale with codebase size
<LarstiQ> lifeless: a bit higher up:21:51:07 < Sonderblade> on the same repos, "bzr log | less" takes 7 seconds but "git log" less than one second
<Sonderblade> lifeless: i'm talking 7-10 seconds for bzr blame on a single file
<lifeless> LarstiQ: thats log not diff
<lifeless> Sonderblade: you said "
<lifeless> 07:43 < Sonderblade> bzr diff is kind of slow, i thought it only operated on local data?
<lifeless> "
<lifeless> Sonderblade: did you mean blame?
<Lo-lan-do> lifeless: I see.  There was talk of only loading the required modules, on demand, though.  Did that happen?  Would it help much?
<LarstiQ> lifeless: though, I'm sorry, I'm not in the best of states atm
<Sonderblade> lifeless: ALL operations are that slow, bzr blame, diff, log..
<Sonderblade> they are "subversion slow"
<lifeless> Sonderblade: thats unusual; blame *should* be pretty fast, status, diff, commit should be near instant
<Jc2k> Sonderblade: did you bzr co or bzr branch from subversion?
<lifeless> Sonderblade: could you pastebin 'bzr info' - feel free to sanitise urls
<Sonderblade> Jc2k: bzr checkout
<Sonderblade> i was told bzr-svn worked very well:)
<lifeless> Sonderblade: oh, in which case its svn slow cause its still doing svn on every operation
<lifeless> Sonderblade: because you've told it you want to act like a svn client
<lifeless> Sonderblade: run 'bzr unbind'
<Lo-lan-do> I don't think bzr blame runs svn.
<Lo-lan-do> Nor do bzr diff or log.
<lifeless> Lo-lan-do: elimination of variables
<Lo-lan-do> (Or maybe I've got a secret wireless card in my laptop that works even when in a train in a tunnel)
<lifeless> Lo-lan-do: (and there is a release that does, it looks up the master ranch for the branch nickname)
<Sonderblade> lifeless: i did checkout all revisions of the svn repos which took a really long time so i don't understand why it should act like svn?
<Sonderblade> this is my bzr info: http://pastebin.com/m7ef9bc53
<sportman1280> hello again.  How do i import a svn repository into bzr 11RC1?
<Lo-lan-do> sportman1280: bzr branch svn://foobar/trunk
<sportman1280> Lo-lan-do:  what if it is a https page that requires login?
<lifeless> Sonderblade: nothing alarming there
<lifeless> Sonderblade: did you try unbinding?
<lifeless> Sonderblade: 'time bzr st' would be useful for me
<lifeless> Sonderblade: also are you running bzr packaged or from source?
<sportman1280> Lo-lan-do: and i get a unsupported protocol for "svn://websitename.com"
<Lo-lan-do> Then first do an "svn ls https://foobar/", then "bzr branch https://foobar/trunk" will reuse your SVN credentials.
<Sonderblade> lifeless: bzr unbind did not help
<Sonderblade> lifeless: time bzr st -> 0m0.337s
<lifeless> what does bzr inventory | wc -l output
<Sonderblade> lifeless: bzr --version -> 1.3.1 from ubuntu hardy
<Sonderblade> lifeless: bzr inventory | wc -l -> 537
<sportman1280> Lo-lan-do i still get an  unknown protocol for url
<Lo-lan-do> Try svn+https then
<Lo-lan-do> You did install bzr-svn, right?
<sportman1280> Lo-lan-do i still get an  unsupported protocol for url
<sportman1280> bzr-svn wont install with 1.11rc1
<lifeless> Sonderblade: https://launchpad.net/~bzr/+archive
<sportman1280> bzr-svn says it requires a build of bzr less than 1.8
<lifeless> Sonderblade: has bzr 1.10 in it
<lifeless> Sonderblade: this has had about 8 months of folk optimising it :P
<Sonderblade> lifeless: yes but i'm not using latest ubuntu, 1.3.1 can't be so old can it?
<lifeless> bzr 1.3.1 2008-04-09
<Sonderblade> bzr can't be very mature yet if an 8 months old version is to old
<lifeless> sportman1280: there are newer releases of bzr-svn too
<Lo-lan-do> sportman1280: I guess you need to find a more recent version.  Like 0.5.
<lifeless> Sonderblade: uhm its not too old; its had performance improvements and you seem to have a performance issue
<sportman1280> Lifeless: where can i find a built one?
<Lo-lan-do> Built for what?
<sportman1280> Lo-lan-do: i386
<lifeless> Sonderblade: we can sit down and analyse why you're having a performance issue, and hope its not one thats fixed; -or- we could as a start point get the current release
<Lo-lan-do> What distribution?
<sportman1280> Lo-lan-do: the ppa beta doesnt have it
<sportman1280> Lo-lan-do: ubuntu intrepid
<Lo-lan-do> Try the one in Debian experimental.
<Sonderblade> lifeless: ok, i'll recompile it from source and will try again
<Lo-lan-do> (Or just grab it from upstream into your ~/.bazaar/plugins, there's no compiling required)
<lifeless> Sonderblade: huh! you don't need to do that
<sportman1280> Lo-lan-do: oh i didnt realize there was no compiling
<lifeless> Sonderblade: just add that PPA to your apt sources and ubuntu will track it
<lifeless> sportman1280: intrepid has bzr-svn 0.4.13-2;
<sportman1280> lifeless: which doesnt work with 1.10
<lifeless> sportman1280: cause intrepid shipped 1.6.1
<sportman1280> lifeless: it apparently only likes bzr 1.8 or less
<sportman1280> lifeless: i was getting an error when importing
<sportman1280> lifeless: it was an invalid character '\'
<sportman1280> lifeless: and would terminate
<lifeless> sportman1280: how did you install 1.10 ?
<sportman1280> lifeless: i installed the 1.11rc1 from the bzr beta ppa
<lifeless> sportman1280: ah, we don't build bzr-svn in the beta ppa
<lifeless> perhaps we should
<sportman1280> Lo-lan-do: the plugin isnt being detected when i put it in the plugins file
<lifeless> sportman1280: anyhow, I would just use the released ppa, which has bzr-svn included in it
<sportman1280> lifeless: yes please do. they conflict and it actually removes any bzr-svn u have installed
<sportman1280> lifeless: but that bzr-svn doesnt work
<sportman1280> lifeless: because it conflicts with bzr 1.10.
<lifeless> sportman1280: in the release ppa?
<sportman1280> or anything higher than 1.8
<sportman1280> https://launchpad.net/~bzr/+archive
<lifeless> sportman1280: yes
<sportman1280> yep it conflicts
<lifeless> +COMPATIBLE_BZR_VERSIONS = [(1, 10, 0)]
<lifeless>  
<lifeless> sportman1280: looks fine to me; I would wager breakfast that you were using the beta ppa which *will conflict*
<sportman1280> lifeless: gah. apparently i cant read
<sportman1280> lifeless:  Thanks lifeless and Lo-lan-do. Hopefully i dont get an error this time importing it
<sportman1280> lifeless: cuz then i really have no idea what to do haha
<lifeless> sportman1280: well if an import fails file a bug please
<sportman1280> there was a bug filed when i looked
<sportman1280> but its been there since 2007 i think so theres little hope of it being fixed
<sportman1280> :(
<kumi> Hi guys, I pulled an upstream revision into a standalone tree, and the working tree is now 1 revision behind the tip of the branch.
<kumi> What command will tell me what files will change when I use "bzr up"? Or which command will give me a diff of the changes that "bzr up" will perform?
<Lo-lan-do> kumi: bzr diff ../upstream --new .
<kumi> Lo-lan-do: thanks. But what if I don't have read access to upstream?
<kumi> (I mistyped earlier, I didn't pull from upstream, I pushed from upstream)
<Lo-lan-do> Then you won't be able to update anyway :-)
<kumi> hm, maybe I'm not wording things right
<Lo-lan-do> Oh, no, it's just that I didn't read you correctly.
<lifeless> kumi: bzr diff -r -2..-1 probably
<Lo-lan-do> I'm actually wondering about the same question from time to time.
<lifeless> we really sould add that ree: revspec
<lifeless> *tree:*
<kumi> Lo-lan-do: me too, I stumble upon this on occasion
<Lo-lan-do> lifeless: Also probably a "upstream:" revspec or so, for use in "bzr missing"
<Lo-lan-do> (For bound branches)
<Lo-lan-do> Currently, one has to do bzr info, paste the "bound_location" out of that, and do a bzr missing $that_url, which is a bit cumbersome for the equivalent of "svn status -u"
<lifeless> Lo-lan-do: parent:
<Lo-lan-do> Won't that ignore the new revisions on the parent side since the last update?
<lifeless> Lo-lan-do: no, why would it?
<igc> morning
<Lo-lan-do> I'm probably mixing with ancestor:
<Lo-lan-do> And I'm still on 1.5, where there's no parent:, I guess it was added later.
<Lo-lan-do> Ah, yeah, the changelog for 1.6 has :parent.
<mwhudson> what's the story with my non system bzr trying to load plugins from the system location?
<Wurblzap> Hi all -- I'm getting "No such file" on an initial init-repo using sftp. I can mkdir using sftp manually, though... Can you give my some pointers?
<spiv> mwhudson: that's the intended behaviour, I think.
<mwhudson> even if BZR_PLUGIN_PATH is set?
<mwhudson> also, just no
<mwhudson> it seems nuts
<LarstiQ> it can have it's use, but I agree it's often more annoying
<mwhudson> i guess i can avoid it by calling load_plugins with just the paths i want
<mwhudson> i wonder if this is why bzr trunk fails tests when run against launchpad trunk...
<lifeless> Wurblzap: -Dtransport may add more detail to .bzr.log
 * Wurblzap tries
<lifeless> Wurblzap: other than that I suggest filing a bug
<Wurblzap> -Dtransport literally doesn't add anything (identical logging). Server logs don't shed light either. Unfortunate...
<lifeless> Wurblzap: oh, what url are you using
<Wurblzap> A private one, lifeless... What details do you need?
<lifeless> basically do you have a dedicated directory, or is it in your home dir, if its in your home dir, do you have ~ in the url
<lifeless> e.g. sftp://HOST/~/INMYHOMEDIR
<lifeless> or sftp://HOST/ABSPATH
<lifeless> are the syntax for sftp urls in bzr
<Wurblzap> It's in a home dir, lifeless. There's no ~. It's sftp://user@hostname/path/from/homedir/subdir/
<lifeless> add /~
<Wurblzap> All right, that sounds promising, lifeless
 * Wurblzap tries
<Wurblzap> All right, no error msg... Let's see what happened on the server
<Wurblzap> Yeah, lifeless, this seems to have done the trick. Thanks a lot!
<mwhudson> spiv: i think this behaviour means that if you have an old bzrtools installed in the system location, bzr.dev's tests will fail
<mwhudson> (because of the blackbox tests of shelve)
<markh> do I still have time to make doc changes and brand tbzr and still have them make 1.11?
<lifeless> I'd say so
<sportman1280> hello.  i am getting the following error. is there anyway around it?bzr: ERROR: Unable to convert Subversion path loud-lintian/trunk/testset/filenames/files/'\  because it contains characters invalid in Bazaar.
<sportman1280> Can anyone help?
<lifeless> sportman1280: bzr doesn't permit every single possible character in file names
<lifeless> in particular '\' isn't permitted
<sportman1280> lifeless: how do i get around this if i am trying to import an svn?
<lifeless> (as well as \r, \n, \x00)
<lifeless> I don't know
<lifeless> you could fastexport it and write a awk filter for the fastexport stream
<lifeless> bzr can import fastimport streams
<sportman1280> what is fastexport a google search isn't really showing me much.  to much random in the results
<spiv> You could probably filter that file out of an svnadmin dump of the repo too.
<lifeless> http://bazaar-vcs.org/BzrFastImport
<spiv> I've no idea if that'd be better/worse or easier/harder than the fastexport option.
<lifeless> note that lintian has changed its repo to remove these files now
<mwhudson> as is almost always the case
<mwhudson> it makes the restrictions a little frustrating for my vcs-imports hat :)
#bzr 2010-01-11
<igc1> morning all
<poolie> hello igc1
<poolie> igc1, maybe we could do a blog post together about news in explorer some time?
<igc> hi poolie
<igc> poolie: that would be good. I'm pretty close to calling it 1.0beta fwiw
<poolie> igc: re the 'evaluation' thread, how about if i make init warn you when it's making a standalone repository?
<poolie> or maybe even fail, would that be too harsh?
<poolie> i guess init and branch would need to do this
<lifeless> I believe init-repo reports the format of what it made today.
<lifeless> making init do the same wouldn't be horrible; and you could fold that in reasonably tastefully I suspect
<igc> poolie: I'm yet to see that email sorry. Ask me again later today :-)
<poolie> np
<lifeless> poolie: another example of the project-priority != dev priority mismatch: for doc folk, sorting some doc bugs to high and low may be very useful, even if for the project all doc bugs are low.
<lifeless> poolie: I'm starting to think personal[inc teams]-annotation of bugs would be a really useful feature.
<poolie> mm
<poolie> yes
<lifeless> e.g. the launchpad-bazaar folk could annotate the bugs they care about as critical etc; bzr devs could choose to see that, or ignore it.
<poolie> yes i see
<lifeless> it would give you the 'I care about this bug' thing you like to do too. mmm could perhaps trial by having the doc team tag with doc-high, doc-low etc
 * igc lunch
<lifeless> time to pickup my passport
<Kamping_Kaiser> :)
<distatica> Is the diff utility that is called by qdiff specific to bzr? It's an excellent tool, and I'd love to use it elsewhere besides bzr repos.
<spiv> distatica: to be precise, it's part of the qbzr plugin for bzr.
<distatica> Yeah, that's what I'm thinking.. is there any way to run it on it's own?
<spiv> distatica: I haven't looked closely at the source, but it's probably not too hard to take that part and make a standalone program of it.
<distatica> What language is that stuff written in? do you know?
<spiv> distatica: although for non-bzr diffing I'd probably use an existing graphical diff tool like meld.
<distatica> The part i would probably be working with.
<spiv> distatica: Python
<distatica> oh, then I have a hope in hell. :)
<distatica> never tried meld, will check it out. So far the best tool I have used is the qbzr one.
<spiv> distatica: basically all of bzr and its plugins are Python.  (There are some optional C and Pyrex extensions for speed, but you wouldn't need to touch those for this.)
<distatica> I had heard that it was python, but wasn't sure. I'm glad for that, Python is a good language.
<distatica> meld looks pretty good too, thanks
<spm> spiv: Ooo. Ta! meld is *nice*. been using kompare myself, meld looks that little bit better. ta x 2.
<spiv> spm: heh :)
<spm> the big win was the in each line highlight of the differences. some of our changes in configs can have (not pointing fingers at PQM, much) horrible regexs. and picking up the diff can be... hard. :-)
<distatica> Pretty decent, I don't know if it's quite up to the qbzr version, but it's good anyways.
<shakaran> Hi, how I can count the added/removed lines between 2 commits?
<RAOF> âbzr diff -r$OLD..$NEW | diffstatâ would work.
<shakaran> RAOF: thanks, works perfect!
<poolie> spiv, igc, lifeless, hi
<poolie> (and anyone else) can you please test installation of bzr from karmic-proposed
<poolie> if it works ok, please comment on https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626
<ubottu> Launchpad bug 437626 in bzr "[sru] exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,Fix committed]
<spiv> poolie: done
<poolie> thanks
<poolie> spiv, excuse my bad memory, but did you do something generic about hiding exceptions during cleanup
<poolie> and if so what?
<poolie> i'd like to use it in bug 423015
<ubottu> Launchpad bug 423015 in bzr-svn "svn-import raises KeyError on large repository" [Undecided,New] https://launchpad.net/bugs/423015
<spiv> poolie: see the bzrlib.cleanup module
<poolie> thanks
<spiv> poolie: also either one of my unreviewed merge proposals ;)
<poolie> :)
 * spiv -> afk for 10 minutes
<ChrisMorgan> I created my branches in a shared repository, but now I'm into another problem; I have branches for [company].[module] and [company].clients.[whatever], but I really need a basic one for just [company] so I can put my __init__.py file in there - can I do that without causing trouble determining which branch things belong to?
<lifeless> ChrisMorgan: sure
<ChrisMorgan> How about if I create a new file in one of the subdirectories which has its own branch - will it show up as 'unknown' in the parent branch?
<ChrisMorgan> It's saying 'unknown' for the sub-branches... ignore?
<lifeless> igc: I really wish you could explain how heavyweight checkouts != bound branches - it confuses the hell out of me when you say that
<lifeless> ChrisMorgan: up to you
<ChrisMorgan> Or can I do something with join/split stuff?
<ChrisMorgan> I'm confused :-)
<lifeless> ChrisMorgan: what are you trying to do
<ChrisMorgan> I have a parent directory squiggle.  There is a repository in it.  There are lots of branches in subdirectories, squiggle/foo, squiggle/bar, etc.  There would be no need to have a branch in squiggle, except for the fact that Python requires a file __init__.py... so I need another branch in squiggle.
<ChrisMorgan> However, bzr status squiggle then goes not knowning about foo and bar
<ChrisMorgan> Upps, got to go now, I'll stay in the room though if you can help me? :-)
<lifeless> if foo and bar are branches bzr st shouldn't mention them.
<lifeless> are you sure they are branches?
<lifeless> you might try pastebinnning the command + output.
<igc> lifeless: well I did try to explain the differences in https://lists.ubuntu.com/archives/bazaar/2010q1/065891.html
<poolie> spiv: big one approved
<spiv> poolie: thanks!
<igc> poolie, lifeless, vila: wrt my disable plugin patch, should I remove support for an explicit path and just support 'disable' (or '') for disabling them?
<lifeless> igc: I would be happiest if you just did disable for now
<lifeless> vila and I can try to get what poolie is concerned about in strasbourg
<poolie> (phone)
<igc> lifeless: so the feature you and vila are working on will miss 2.1?
<lifeless> igc: I'm a) sick, and b) working on dx-team stuff, and then lca and then strassbourg
<igc> lifeless: I really don't need the path stuff but my patch might be a stop gap until your stuff lands?
<igc> lifeless: but I personally only care about disabled vs otherwise
<lifeless> igc: I know that your path stuff won't help any of the use cases I've seen for automated stuff in this area
<lifeless> igc: so I'm not sure who it would be stop-gapping for
<igc> lifeless: only someone with a plugin both system installed and locally installed - picking the former over the latter
 * vila needs to bring his car to the garage and will be afk for ~1 hour
<vila> igc: but regarding plugin stuff, as said in my mail, 1) using config vars is not a good idea, 2) using PZR_PLUGIN_PATH to disable is not trivial and I'm not working on it right now
<poolie> igc, i don't have any strong objection to being able to set the path there
<poolie> i'll look at the patch again
<poolie> spiv, how about just always logging cleanup failures?
<poolie> oh
<poolie> nm, i misread it
<lifeless> poolie: vila and I have concerns though. Can we land igcs disable-only version of the patch ?
<poolie> does that exist now?
<poolie> i think vila's final comments in https://code.edge.launchpad.net/~ian-clatworthy/bzr/411413-plugin-disable/+merge/16719 are reasonable
<poolie> however incremental improvements are also good
<lifeless> igc has implied that it did in the past or is at least trivial to get to.
<igc> poolie, lifeless: I don't have a version yet that does disable only. It's a one line code change I suspect.
<igc> poolie, lifeless: tweaks the doc changes in my patch is the larger part if that's the direction to go
<igc> tweaking
<lifeless> poolie: quick call?
<igc> poolie, lifeless: the broader Q was a conceptual one: should I 'remove' functionality from the patch given there's no alternative likely soon?
<igc> wrt specifying an explicit plugin when multiple are installed
<ChrisMorgan> lifeless: yep, they're branches alright, but with no commits yet - should I commit to them?
<poolie> lifeless: sure
<ChrisMorgan> lifeless: bzr init-repo foo, bzr init foo/bar, bzr init foo, bzr st foo: unknown: bar/
<ChrisMorgan> Commit an unchanged revision to foo/bar and st foo still shows unknown bar
<ChrisMorgan> I also tried the split / join --reference stuff as at http://wiki.bazaar.canonical.com/NestedTreesDesign#creating-a-nested-tree and I'm still getting the unknown status on bar
<lifeless> ChrisMorgan: don't touch split/join
<lifeless> ChrisMorgan: its not production ready
<ChrisMorgan> OK, I was just testing it as that was what was detailed in the page.
<ChrisMorgan> I figured it wasn't ready seeing as it didn't work :P
<lifeless> ChrisMorgan: you probably want to do bzr ignore ./bar
<ChrisMorgan> OK then.  Or I could resort my structure... thinking about it more I don't need the clients stuff in the main branch... I'm not going to want to be able to `import myproj.clients.whatever`...
<ChrisMorgan> So I think I'll actually separate it one level more in the repository.
<ChrisMorgan> Thanks.
<ChrisMorgan> Uh... can I "uninit"?
<igc> poolie, vila, lifeless: I've replied to vila's comment on my patch now
<ChrisMorgan> I've run init-repo and init in the same directory, can I go back to just the repo rather than the branch as well, or should I just scrap all my .bzr directories and start clean again?
<lifeless> ChrisMorgan: if you delete .bzr/branch and .bzr/checkout then you'll have what bzr init-repo created
 * vila back
 * igc dinner
<bialix> hello all
<bialix> igc is here?
<lifeless> 19:26  * igc dinner
<lifeless> 19:28 -!- bialix [n=chatzill@163-106-113-92.pool.ukrtel.net] has joined #bzr
<bialix> thanks lifeless, and hi
<lifeless> hi :)
<mathrick> hiya, I have a repo (my thesis) where I started some work (library bindings) which I now want to split out into a standalone branch. But I don't want the intial commits to the thesis files to show up in the bindings' history
<mathrick> the commits look like that: 1..3 thesis, 4.. bindings
<mathrick> so in essence I want to remove commits 1..3 from the history
<mathrick> what's the best way to do that?
<mathrick> the changes are textually independent, and all bindings work happened in a subdir I bzr split out
<bialix> fast-import-filter
<mathrick> bialix: thanks, lemme try that
<ChrisMorgan> lifeless: thanks, I got my repository and branches all set up properly again... I think I'm happy with it this time and think it'll do all that I want :-) (Though if I could version the contents of a SQLite, MySQL or PostgreSQL database with Bazaar I'd be even happier...)
<mathrick> bialix: that worked fine, cheers
<lifeless> ChrisMorgan: bzr can do it; doesn't make it a good idea :)
<ChrisMorgan> How can it do it?
<lifeless> bzr add foo.db; bzr commit.
<ChrisMorgan> The /contents/ of the database... not the database!
<lifeless> sqlite foo.db dump > foo.dump; bzr add foo.dump; bzr commit
<ChrisMorgan> Still not automatic :-)
<ChrisMorgan> I suppose SQLite can have hooks... I wonder what that would really do to performance.
<ChrisMorgan> Ghastly idea, isn't it :D
<mathrick> ChrisMorgan: that's why people invented backups
<mathrick> do a periodic snapshot and version that
<ChrisMorgan> I know... it really would simplify my task though if I could use Bazaar to version the contents of a database...
<ChrisMorgan> Ah well, I'll sort it out somehow :-)
<mathrick> ChrisMorgan: you could make a hook that took a snapshot before commits, but it'd presumably make commits slow
<ChrisMorgan> Problem is it's the other way round I want it - someone does something on the website (something that matters, i.e. in the admin section) and it goes and exports that and commits to bzr, and a way then to do the converse with pulling, take a diff and apply it somehow to the database.
<ChrisMorgan> I think I'm dreaming a rather far-fetched dream.  I think I'll have to be satisfied with django-reversion at the moment.
<mathrick> ChrisMorgan: in this case, what you really want is a full-fledged plugin
<ChrisMorgan> Something like that.
<ChrisMorgan> A way to version the contents of a database.
<ChrisMorgan> Clearly every table being versioned would need to have a primary key.
<ChrisMorgan> How hard do you think it'd be?
<ChrisMorgan> Do you think it'd be reasonable and possible?
<ChrisMorgan> I imagine I'd need to learn a lot about Bazaar first.  For the moment I think I'll get on with other facets of my product.
<ChrisMorgan> I'm sure it would be fascinating to do.  I'll see if I ever get to it :-)
<ChrisMorgan> Goodnight now.
<rubbs> ok, I know this is easy, but I can't seem to find it. I branched from a machine on my LAN, but now I want it to pull from lp:bzr. How do I change the parent branch?
<maxb> pull --remember
<rubbs> cool, thanks. I knew it was something rediculously easy
<squeeky> Hi kids. Using the 2.01 Mac package from the website, fresh install, I try to bzr branch or init and score "bzr: ERROR: '/Volumes/Data' is not a working copy
<squeeky> So what went wrong?
<Peng> Ick, the most recent revision of bzr.dev caused conflicts with 2.0.
<squeeky> It was labelled as "stable".
<vila> fullermd: ping
<vila> squeeky: Pend refers to the dev version, not related to your problem, can you pastebin your $HOME/.bzr.log ?
<squeeky> any pastebin of choice?
<vila> !paste
<ubottu> For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<squeeky> http://ubuntu.pastebin.com/m5a8c668e
<Peng> What the hell, pastebin.com? Why not paste.ubuntu.com?
<squeeky> I should empasise that /Volumes/Data is the working parent directory to the one I was trying to bzr init/branch
<Peng> squeeky: I suspect you have an .svn directory sitting somewhere.
<Peng> squeeky: ls /Volumes/Data/.svn and /Volumes/data/whatever/.svn
<squeeky> What does this have to do with the price of tea in china?
<Peng> squeeky: bzr-svn
<squeeky> ummm, okay, wasn't using that. Can't bzr just not pay attention to .svn folders in a parent?
<LeoNerd> How else would it know you were in a svn checkout, though?
<Peng> squeeky: You are using bzr-svn.
<LeoNerd> bzr implements a prettymuch-complete frontend to working on svn checkouts/WCs/etc...
<squeeky> what
<squeeky> so... it's a piggyback scm?
<LeoNerd> No...
<LeoNerd> bzr has its own native formats of course.
<LeoNerd> It -can- use svn -as well-
<LeoNerd> You can use the bzr command as a frontend to a number of different repository/wc formats, including svn, git,...
<LeoNerd> Since you have the bzr-svn plugin loaded, it's looking for .svn directories, in case you're trying to use it on a svn checkout
<squeeky> ugh.
<LeoNerd> I find it very useful... Being able to  bzr log10  in a svn checkout, or  bzr shelve  it
<LeoNerd> It actually makes svn almost useable
<squeeky> I generally don't mix scm's. But whatever, it's fixed now, thanks Peng.
<LeoNerd> If you're not wanting to use the bzr-svn stuff.. then.. uh.. just don't load the bzr-svn plugin :)
<LeoNerd> Heh.. we have a bizarre mix of cvs/svn/bzr at work.. I like not needing to remember which command is which. I just type "bzr whatever".. and it all works out
<squeeky> meh, it's fossil for internals, git for stuff that tentatively gets public OS release, svn/cvs/bzr for patching other people's stuff.
<maxb> I find it pretty annoying when bzr-svn kicks in when I'm not actually in a svn wc
<maxb> It would be better if it didn't search up for .svn, since .svn doesn't require that
<fullermd> vila: Hmmwhat?  I didn't do it, I swear.
<jam> abentley: are you around?
<jam> I'm trying to sort out bug #494269
<ubottu> Launchpad bug 494269 in bzr "tree transform cannot change root id" [Medium,Confirmed] https://launchpad.net/bugs/494269
<jam> And trying to understand what TT should be doing
<jam> I *think* it should be allowing the tree root to be added, but at apply time it should verify that there is only one
<jam> (the delta I'm looking at shows the new root added at the beginning, then all paths are renamed into that new location, then the old one is removed.)
<kiko> hey there
<kiko> say I have a tree that contains as a subdirectory a copy of bzr
<kiko> is there a way of updating that subdirectory to a more recent version of bzr and retaining some commit history information?
<kiko> a copy of the bzr source IYSWIM
<luks> that question doesn't make sense to me
<jam> kiko: so you have a tree, such that in one subdir you also have a version of the bzr source
<luks> how it updating bzr in conflict with retaining history?
<maxb> Could you elucidate "retaining some commit history information" ?
<jam> is that correct?
<kiko> luks, let me trivialize it
<jam> if you used stuff like "bzr merge-into"
<jam> to create it
<kiko> launchpad contains a subdirectory called lp-buildd
<jam> then in the future you should be able to "bzr merge $BZR"
<jam> and it should mostly JustWork
<kiko> lp-buildd is actually managed as a separate branch
<kiko> by lamont
<jam> (lp:bzr-merge-into, btw)
<kiko> can I merge the changes in lp-buildd into the launchpad tree
<kiko> with bzr-merge-into?
<jam> kiko: I assume you want to bring the lp-buildd code into the launchpad codebase in a subdir
<fullermd> I think you're asking the other way around from what merge-info is for.
<jam> bzr-merge-into should do a decent job of that, IIRC
<maxb> IIUC, yes if they already share ancestry. Otherwise, an initial delete and re-merge would be required.
<jam> If you are trying to split it out
<kiko> jam: they don't share any history
<jam> then you can split it out and play tricks with 'bzr add --file-ids-from"
<jam> kiko: unfortunately, *today*, without the same file ids, we can't link up the changes
<kiko> gotcha
<abentley> jam: I believe that was one of the things my proposed changes to nested trees fixed.
<abentley> jam: I agree that TreeTransform should delay tree shape sanity checking until the transform has been completely specified.
<C-S> I get the following bug: bzr: ERROR: exceptions.AttributeError: 'tuple' object has no attribute 'encode'
<C-S> any idea?
<abentley> jam: I would do that in find_conflicts
<jam> C-S: any backtrace?
<jam> C-S: Something is getting a tuple that is expecting a string
<C-S> yes there is quite some backtrace, can I post it somewhere?
<jam> !paste
<ubottu> For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<C-S> jam: http://ubuntu.pastebin.com/d7752a537
<C-S> ubottu: thank you
<ubottu> You're welcome! But keep in mind I'm just a bot ;-)
<abentley> jam: see fixup_new_roots in transform.py in http://bazaar.launchpad.net/~abentley/bzr/nested-trees
<jam> abentley: thanks for the pointer
<C-S> jam: any ideas?
<jam> C-S: can you paste "bzr status" before the commit?
<jam> I'm wondering if it might have something to do with a symlink, et
<jam> etc
<C-S> jam: http://ubuntu.pastebin.com/d125d8417
<C-S> jam: or with Umlauts in file names?
<C-S> jam: I now deleted all .bzr directories and restarted.
<C-S> jam: Even after adding one .tex file it crashes
<jam> C-S: what does "bzr plugins" list?
<C-S> jam: http://ubuntu.pastebin.com/d5abcf59f
<jam> C-S: you could try "bzr commit --no-plugins" but that doesn't seem to be it
<jam> certainly this doesn't seem to happen to me, since I've been committing without probs for a long time
<C-S> jam: that gives a different error:
<C-S> jam: bzr: ERROR: No repository present: "file:///..."
<jam> C-S: so are you in a subdirectory of a git repo?
<C-S> jam: hmm let me check
<jam> (I don't know that bzr-git implements proper commit
<jam> commit-to-git support)
<C-S> jam: this was it! It works again after deleting the .git folder in the main directory.
<C-S> jam: it would be could to give a nice bug report
<jam> C-S: so I think this is a bug in bzr-git, you can mention something about 'commit in git working dir fails', and include the traceback
<jam> I'm guessing that the GitCommitBuilder.record_iter_changes is working differently than we think it should
<jam> either that or GitTree.iter_changes() is working differently
<jam> what is weird is that it seems to be a mix of WorkingTree4 (which is a bzr regular tree)
<jam> so I don't really understand why it was confused
<jam> C-S: steps to reproduce would also be appreciated
<C-S> jam: I'll file the bug. Thanks again.
<maxb> Is there any way to hook bzr to discover all branch modifications? Such as might be needed to implement an automatic backup system?
<maxb> In particular, I want to know about operations that don't change the tip of a branch - e.g. tags
<mathrick> abentley: are pipelines meant to provide a similar functionality to git rebase's patch reshaping, or is that different?
<abentley> mathrick: No, they're meant to be an alternative to rebasing.  For similar functionality, see bzr-rewrite.
<kiko> jam, btw, you could provide the licensing information for bzr-merge-into.. ;-)
<mathrick> abentley: oh, I didn't see rewrite on the plugins page
<jam> kiko: __init__.py clearly states GPLv2, but I can add a COPYING.txt if it makes you feel better
<mathrick> abentley: but pipes can still result in retroactive history changes, right?
<kiko> jam, no, I meant on launchpad :)
<jam> ah
<mathrick> how does that play together with published branches?
<abentley> mathrick: bzr-rewrite was formerly called rebase, and that name is still used on the plugin page.
<abentley> mathrick: pipes cannot result in retroactive history changes.
<jam> kiko: done
<jam> not entirely sure why it matters
<mathrick> abentley: so what's the result of adding a patch to an earlier pipe and pumping it?
<abentley> mathrick: It's as though you did a merge and commit in the later pipe.
<mathrick> oh
<mathrick> so it'll be visible to someone reading patches?
<jam> abentley: the tests I can find in transform are about moving a root directory, I'm trying to test adding a new one and removing the old one completely
<jam> abentley: does this look valid: http://paste.ubuntu.com/355157/
<jam> (It currently fails trying to rename the cwd, but I want to know that I'm on the right track first)
<abentley> jam: That looks like a reasonable change.  You're probably right that we haven't tried to handle that directly in the TT before.  I'm pair programming at the moment.
<jam> abentley: sure, I don't mean to bother you too much, but I don't really know how the TT code is supposed to hang together everywhere
<mathrick> abentley: I'm very interested in a tool that'd let me reshape changes logically for reviewers, but I sort of can't see how pipelines help with that if they're basically merges
<mathrick> (also, take your time if you're busy right now, it's not urgent)
<jam> mathrick: you may want to look at http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
<jam> which doesn't explicitly use pipelines
<jam> though you could do something like that for the individual branches
<mathrick> jam: yeah, I don't want to lose the history if possible, but I'd like to be able to submit a logical view of the end result. Lemme just read through that
<jam> mathrick: it is how I did it, at least
<jam> basically, you could use threads/pipelines for each of the new branches created
<jam> however in *my* case, I wanted a DAG of branches, not a simple stack
<mathrick> loom was unusable for that scenario
<jam> though probably not critical
<mathrick> since the threads stack in the wrong direction
<jam> both pipelines and loom think in terms of a stack
<jam> though you can "up-thread; bzr revert"
<jam> or use "bzr switch" to change threads without merging
<jam> mathrick: wrong direction?
<mathrick> hmm, I might be mixing up two different scenarios
<mathrick> jam: I know I hit that at least once, when I wanted to keep a change that wouldn't get pushed upstream when merging, but which'd sit on top of other changes (ie. editing config files to match your local dev setup without touching the deployed config)
<mathrick> that doesn't work, because of how changes flow through the loom
<mathrick> IIRC, there were also similar issues when you tried to use looms for reshaping, but I'd have to rethink that from first princinples again, I'll read your post first
<otto_sange> help question: when I run the command $ bzr branch lp:valo-cd
<otto_sange> I get the error:Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<otto_sange> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
<otto_sange> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n"
<jelmer> otto_sange, hi
<otto_sange> one guy at #launchpad suggested I'd ask here. Maybe it is a locale problem.
<maxb> What is your local bzr version?
<otto_sange> My system: plain Ubuntu 9.10, fresh bzr installation from main, clean conf, python 2.6
<otto_sange> Bzr version 2.0.0
<otto_sange> system locale Finnish
<jelmer> otto_sange: I can't reproduce the problem here - what is your locale set to?
<otto_sange> LANG=fi_FI.UTF-8 to be specific
<jelmer> otto_sange: It seems to work fine with that locale as well
<otto_sange> although the locale thing is just a guess. I'd expect there would be more about this on Google if all Finnish users suffered from it..
<otto_sange> Any other ideas?
<otto_sange> running -v does not give any extra info
<jelmer> otto_sange: I'm out of ideas at the moment, but spiv might have more ideas - I think he should be around soon.
<jelmer> spiv: ^
<maxb> jelmer: About those bzr-svn "inconsistent details in skipped record" warnings - I had a look at what the code was actually comparing and it seems to be complaining about one side of the comparison being a tuple, the other a list. Does that mean anything to you?
<jelmer> maxb: We've had problems with that in the past as well
<jelmer> maxb: I guess bzr is a bit more strict now in various places
<jelmer> maxb: I'm happy to see bzr-svn adjusted to use whatever bzr uses
<maxb> I should stick a "raise" in there and see where it explodes, I guess
<maxb> On another matter, I don't suppose you have any magical debugging tips for figuring out why bzr-svn would go into an infinite loop trying to detect svn tags on a particular repo?
<maxb> private, unfortunately
<otto_sange> jelmer: I need to get some sleep now. If anybody comes up with ideas, drop me a line at otto (a) sange.fi so that I could start contributing to a Launchpad project some day... Thanks!
<poolie> jam, hi, shall we chat?
<jam> sure poolie
<jelmer> otto_sange: Will do
<jelmer> maxb: -Dtransport is usually quite helpful
<maxb> I'll give it a go
<jelmer> maxb: Also, SIGQUIT is your friend.
<maxb> ah
<jam> jelmer: I think the check needs to be less strict. We can hit that internally as well
<jam> some apis return [] for parent_ids, some return ()
<jam> both should be allowed
<jam> I don't know how I've triggered it before, but I most certainly have, without bzr-svn
<jelmer> jam: Most things seem to rely on tuples, e.g. knits will bail out if you try to add the same text twice with the parents as a list
<maxb> ooi, what are the strings containing four numbers? -->     ('21277 252 0 333', ((),)) ('76755 252 0 333', ([],))
<maxb> Indeed, it looks like the tuples are the "existing" and the lists the "new" in my case
<spiv> Drat, missed otto_sange.
<thumper> spiv: do you know?
<thumper> spiv: I was talking to him on #launchpad
<thumper> spiv: he did leave an email address :)
<spiv> thumper: yeah, just sending mail now
<spiv> thumper: but no, it's a mystery to me.
<thumper> :(
<maxb> Is there a document with a typical/recommended layout for working with a shared repository, multiple branches, and a lightweight checkout?
<rubbs> maxb: I don't think there is a document for that, but I'd say you could do this:
<rubbs> ./shared_repo/
<rubbs>             /branches/
<rubbs>                        /branch_a/
<rubbs>                       /branch_b/
<rubbs>             /lw_co/
<rubbs> just an idea
<maxb> I'll practice a bit :-)
<spiv> rubbs, maxb: probably more common is ./repo/branch_{a,b,...} for the branches, and ./work (outside the repo) for the checkout.
<lifeless> I do
<spiv> rubbs, maxb: that said, it'll just as well either way.
<rubbs> ah, that's a good point
<lifeless> ./project/branches
<spiv> s/it'll/it'll work/
<lifeless> ./project/working
<maxb> ah... a good point, it had not occurred to me that it could be outside.
<lifeless> e.g. bzr/trunk, bzr/foo bzr/bar bzr/working
<lifeless> and working is a lw checkout of e.g. trunk
<mathrick> okay, so empirically, it seems that pipelines work sorta backwards if you want to use them to reshape changes: earlier pipes in the pipeline will have the logical view, whereas the last one will have the original changes
<jam> abentley: the way the code is written, if you add a new root but do *not* delete the old root, things still work (fixup_new_roots always removes the old root if there are any new ones.)
<jam> should I add a check that self._new_root in self._removed_content ?
 * mkanat is working on the final touches of the CVS->bzr migration for upstream Bugzilla, for the next few days.
<mathrick> jam: hmm, interesting post that, but what does submit: really mean in those branches?
<mathrick> more generally, how can I find out what branch is submit: for the given tree?
<jam> mathrick: Are you talking about the blog post?
<mathrick> yep
<jam> At *this* point, I would make submit: be the dev branch, and use launchpad's "this change depends on this other branch"
<jam> at the time I did that code
<jam> that feature was not present
<mkanat> mwhudson: Going to start on the loggerhead stuff today! :-)
<mathrick> jam: Ã¦h, I don't understand what you're talking about :)
<jam> mathrick: the submit branch is always 'trunk'
<jam> IMO
<mwhudson> mkanat: woo
<jam> it just happens that one branch depends on another landing to get a nice diff of the changes
<mathrick> jam: and if I don't set it up specially, what becomes submit? And how can I check what is submit at any given point?
<jam> mathrick: bzr info submit: ?
<mathrick> ahh
<mathrick> right
<jam> I set up a default submit in locations.conf
<lifeless> moin
<jam> morning lifeless, I hope you're feeling better
<lifeless> over the worst I think; coughed up lots of plugins w/some blood and can now breath properly ;)
<lifeless> no fever today
<lifeless> s/in//
<lifeless> jam: you might like testrepository
<lifeless> jam: it should be windows friendly
<jam> lifeless: I saw your post, looked interesting
<ChrisMorgan> bzr co http://code.djangoproject.com/svn/django/trunk/ django-trunk is failing (yes, I've installed bzr-svn, and got it working on another repository) :-(
<ChrisMorgan> It asks for username and password, which I leave blank, and then says 'bzr: ERROR: Not a branch: "http://code.djangoproject.com/svn/django/trunk/".'
<ChrisMorgan> replacing bzr with svn makes it work fine
<mkanat> Is there a way to enforce, on the repo/branch side, that nobody can check in without setting whoami?
<lifeless> use bzr+ssh:, and write a plugin that hooks branch pre_tip_change that checks for e.g. localhost in the host part of the author of new tips
<mkanat> lifeless: Awesome, thanks.
<mkanat> http://bzr.mozilla.org/
<mkanat> Nothing really in there yet, though.
<mkanat> lifeless: For something better than that, is there a way to make sure that committer is actually the person committing?
<mkanat> lifeless: The SSH accounts are email addresses, if that helps....
<lifeless> mkanat: sure, ssh sets an env variable or whatever
<lifeless> cross check that
<mkanat> lifeless: Right, great idea. Thanks. :-)
<lifeless> you can raise TipChangeRejected (or anything if you want) to signal the error - TCR gets tunnelled nicely though.
<mkanat> Cool.
 * mkanat has never written a plugin, so this will be new territory.
<abentley> jam: That sounds reasonable.
<poolie> hi abentley
<poolie> hi spiv?
<abentley> poolie: hi
<poolie> ChrisMorgan: please open a bug and paste the number here
<ChrisMorgan> In bzr-svn?
#bzr 2010-01-12
<jelmer> ChrisMorgan: this is caused by bzr probing for the smart server
<ChrisMorgan> ?
<ChrisMorgan> That went over my head :-)
<ChrisMorgan> Just agree that it didn't work :P
<spiv> ChrisMorgan: when bzr sees a http:// URL, it'll first try POST to $url/.bzr/smart with a smart server request.  jelmer is saying that for some reason this probe is preventing bzr-svn from being able to do its own probe and take over.
<ChrisMorgan> Shall I put that in my bug report or let you two comment it?
<spiv> ChrisMorgan: (maybe the server is rejecting the bzr smart server probe with a slightly unusual HTTP response code, or something like that)
<spiv> ChrisMorgan: well, please file a bug if you haven't already
<spiv> ChrisMorgan: we've have a few along these lines before, no need to paste my generic explanation into the bug :)
<ChrisMorgan> https://bugs.launchpad.net/bzr-svn/+bug/506196
<ubottu> Launchpad bug 506196 in bzr-svn "SVN checkout failing with empty authentication details" [Undecided,New]
<spiv> ChrisMorgan: you may be able to workaround it by prefixing svn+ to the URL?
<ChrisMorgan> Works.
<spiv> (Or perhaps by prefixing nosmart+ come to think of it...)
<ChrisMorgan> I'll leave you to comment that addition then.  I've already posted mine.
<ChrisMorgan> Nevertheless, it's still a bug :-)
<ChrisMorgan> If it works with svn it should work with bzr :-)
<ChrisMorgan> Thanks though, I really wanted all the information so I can revert to Django 1.1 if I needed to while off-line
<spiv> Thanks for reporting the bug :)
<ChrisMorgan> SVN is slow... now I've made it to revision 500/7768...
<spiv> Yeah, it's not really designed to send you the complete history :)
<ChrisMorgan> For some things I'd just want a lightweight checkout, this time I do really want it all.
<lifeless> I thought someone already maintained a django bzr collection of branches
<ChrisMorgan> Over 2000...
<ChrisMorgan> I have heard of it... I dunno
<ChrisMorgan> It's been used for benchmarks
<igc> morning
<poolie> ChrisMorgan: it might help if you attach the log from running
<poolie> bzr co log+http:/otauhaotnhu
<poolie> if you haven't already
<jfroy|work> jelmer: have you had a chance to look at that new bzr-svn exception I'm hitting?
 * igc lunch
<idnar> is there a better way to change a commit message than uncommit + commit?
<fullermd> There's not a simpler way for simple cases (that I know of)
<fullermd> Any 'better' way would be functionally equivalent in the end, anyway.
<idnar> I guess I mean "easier" ;P
<idnar> anyhow, no big deal
<spiv> idnar: easier in what way?  Open an editor with the old commit message I guess?
<idnar> something like that
<spiv> It'd be nice to have something like that, maybe commit --redo or something.
<spiv> uncommit's useful for more than just changing the commit message, of course.
<idnar> or even just avoid the risk of including uncommited changes or whatever
<idnar> ironically, darcs has a command (amend-record) that lets you include additional changes but doesn't let you change the patch name
<jam> poolie: I like the new "always report if it came from a user-defined source" version
<poolie> thanks, sent
<poolie> jam, i think our patch-landing latency is improving for developers as well as new contributors since mooloolaba
<poolie> which is good
<poolie> no room for complacency though
<poolie> can someone help me work out where to write a test for bug 456077?
<ubottu> Launchpad bug 456077 in bzr "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [Medium,In progress] https://launchpad.net/bugs/456077
<poolie> or maybe it doesn't really need one
<lifeless> poolie: sure
<lifeless> so what do we want, a ui.note when getting a stream with a different format?
<poolie> i guess in per_interrepository
<poolie> yes
<poolie> well,
<poolie> more broadly, when the fetch is going to be noticeably slow
<lifeless> so the stream interface is tested on repository, not interrepo
<lifeless> and thats where the code would live, so I'd write the test there.
<lifeless> as for 'when it will be slow' - there isn't a guaranteed metric for that.
<poolie> and will all fetches go through the stream interface?
<lifeless> so to me that means writing per-case tests.
<lifeless> poolie: all the bzr <-> bzr ones do now
<lifeless> it was one of the major achievements spiv and I had last year
<lifeless> concretely we expect getting a revision-delta style stream to be painful on non-CHK repositories
<poolie> ok, so you could possibly override InterRepository, but that's not actually expected to be done
<lifeless> svn/git/hg fetches do that
<lifeless> they provide specific optimisers at the moment I believe.
<poolie> i wonder if a warning is useful there
<lifeless> they could move to using the streaming interface at some future point.
<poolie> probably not
<lifeless> possibly it is, but it won't help mysql:)
<lifeless> and the place to put it would be in the SVN or whatever InterRepo class anyhow, I think.
<poolie> well, i was thinking of putting it in the base interrepo class
<poolie> but, as you point out, that is no longer where the variation is
<lifeless> fetch.py does this
<lifeless> :
<lifeless>             source = self.from_repository._get_source(
<lifeless>                 self.to_repository._format)
<poolie> yes i see
<lifeless> but its the repo _get_source that will actually know its going to be slow.
<poolie> so we have a StreamSource or RemoteStreamSource locally
<lifeless> specifically
<lifeless> in repository.py
<poolie> and i guess that can give the warning...
<lifeless> _get_inventory_stream
<lifeless> there is a bunch of logic that may call into
<poolie> ah yes
<lifeless> self._get_convertable_inventory_stream
<lifeless> that *that* function is the one that does the hard work.
<poolie> and that's not overridden in the remote case
<lifeless> note that with fetch from bzr+ssh, this code block will execute on the smart server.
<lifeless> but you can use the current 'stderr shows on the client' 'feature' to let users see the warning anyway, for now.
<poolie> hm
<lifeless> poolie: right, nothing is overridden in the remote case; the entire object is proxied
<poolie> the comment on get_convertable... says "the source is using CHKs" but this actually seems to cover all different-format cases?
<lifeless> yes
<poolie> thanks very much
<lifeless> np
<poolie> do you recall if the deprecation warning patch landed already?
<lifeless> sorry no
<poolie> i guess this won't work over bzr+http or tcp until we have a way to remote ui operations
<lifeless> if you were willing to bump the stream format
<lifeless> you could do a step towards the progress-in-streams stuff I've speculated on
<lifeless> and include a substream of type 'warning'
<poolie> mm
<lifeless> on push operations the RemoteStreamSink would see that and show it locally, on pull operations the StreamSink would get it from the network and show it.
<poolie> alternatively we could make sure the logic runs on the client
<poolie> but that seems a bit messy
<lifeless> you'd have to duplicate it - cause it to run twice
<poolie> right
<lifeless> and you wouldn't know about config or environment on the server, so you'd be guessing
<poolie> so
<poolie> i guess we could make the client give this warning if it receives a stream of inventory-delta?
<poolie> regardless of why the server decided to send that?
<lifeless> yes
<lifeless> specifically you'd want to make the Sink do that, if its not running inside a server, and RemoteSink to do it if it observes it going past.
<lifeless> its a little crude, but it will do
<poolie> do you think that's better?
<poolie> it seems possibly better to me
<lifeless> I think it will work now, as a stderr output would. It would work in tcp and http as you noted, so thats better
<lifeless> OTOH deltas can be very fast chk<->chk so perhaps there will be some false positives in the future.
<poolie> i'd kind of rather deal with the false positive
<poolie> s
<lifeless> then do that :)
<lifeless> if there are are any
<Peng> Isn't there some bug about dirstate when you upgrade to a rich-root format?
<Peng> Should I...do something, or is it fine?
<lifeless> Peng: nada
<Peng> it's fine?
<Peng> jelmer: ping
<poolie> so, u
<poolie> um
<poolie> fetching from 2a into 1.14-rr does seem to use InterDifferingSerializer
<poolie> which does not seem to use streams
<poolie> or, not in a  straightforward way
 * poolie looks
<lifeless> oh, locally?
<lifeless> I'd check with spiv at this point.
<lifeless> spiv: ^
<lifeless> I was fairly sure that even that remnant had been dropped, but apparently not.
<spiv> Hmm.
<spiv> It's only used for local fetches.
<spiv> See InterDifferingSerializer.is_compatible, it returns False if either side has a URL starting with file:///
<spiv> (And only if the serializers differ, etc.)
<spiv> Somewhere, possibly just a mailing list thread, there's a list of things we need to fix to be able to drop IDS completely.
<spiv> IIRC it was progress indication and worse speed/memory for local fetches (although the speed/memory was partially addressed?).
<Peng> erk, now I can't unping him.
<poolie> spiv actually it's false if either of them is not local
<poolie> but iswym
<poolie> so it seems that we need a warning in both ids and streaming
<spiv> Yeah.
<spiv> IDS is duplication, after all.
<poolie> so
<poolie> i'd like to add blackbox tests to make sure i'm actually covering the right things
<lifeless> poolie: well, I'd really be inclined to write tests close to the code
<lifeless> poolie: but I know we have differing opinions on this ;)
<poolie> to me the risk here is not so much that my call to warning is wrong
<poolie> but that the code is not reached at all
<poolie> as it was not in my/our first attempt
<poolie> therefore i want an integration test that checks that
<poolie> spiv, i'm going to merge 2.0 back to trunk, which will carry some of your cleanup changes
<poolie> just so you know
<doctormo> i'm having some trouble threading bazaar when gtk is running... without the threading bzr works but locks up gtk, but with threading bzr hits Branch.open(remote_branch_url) and doesn't do anything afterwards in that thread.
<doctormo> doesn't even end.
<spiv> poolie: sure
<spiv> poolie: I think you'll find that the cmd_annotate change from 2.0 can be discarded, but that the test that is added ought to be kept.
<poolie> oh ok
<poolie> that conflicted
<poolie> why should it be discarded?
<spiv> The command_cleanup branch included the cmd_annotate fix, but using add_cleanup rather than try/finally.
<poolie> it looks like an improvement, trunk still does it without cleanups
<spiv> The change in trunk was the try/finally for the tree lock IIRC.
<poolie> but we want to end up with it using cleanups in trunk, don't we?
<spiv> poolie: right; I mean discard the 2.0 version and keep it as it is in trunk :)
<spiv> doctormo: hmm
<spiv> doctormo: I doubt most of bzrlib is threadsafe
<doctormo> spiv: AWOS: don't use threads it won't work?
<spiv> doctormo: so your gtk program can use threads, but you should take care to only call bzrlib from a single thread.
<poolie> oh i see
<doctormo> spiv: OK, I think I may be able to wrangle the mental image, I think it's changing the ui outside the thread.
<lifeless> spiv: our own server is multithreaded
<spiv> lifeless: yeah
<lifeless> doctormo: bzrlib should be pretty safe as long as you only use a given object from the same thread.
<lifeless> doctormo: so you can use two threads, or N, but don't pass a (say) Branch opened from one thread to another thread.
<spiv> lifeless: but we don't share objects between threads...
<spiv> lifeless: it's simpler just to say "don't use multiple threads" :P
<spiv> lifeless: but you're right.
<lifeless> spiv: yes, I'm trying to rephrase what you said in a slightly less restrictive way ;)
<doctormo> lifeless: Don't use threads unless you know how to control leaks.
<lifeless> doctormo: uh, I think thats a very different statement ;)
<lifeless> for all that it may be wise
<Peng> lifeless: I can't land things in bzr-loom.
<lifeless> Peng: aren't you in ~bzr yet?
<Peng> lifeless: No.
<Peng> lifeless: About once a month you suggest it, but then none of us (including me) follow up. :)
<lifeless> you can now
<Peng> lifeless: Cool, thanks. I'll land it.
<lifeless> and you're now in ~bzr. welcome to the firehose
<Peng> :D
<StevenK> Peng: Are you the same Peng that hangs around in #linode, too? :-)
<Peng> StevenK: Yes.
<igc> bbl
<chrispitzer> i want to check out from a bzr branch, but I don't want the new working copy to be a bzr repo - just a working copy.
<chrispitzer> I think there's a command for this...
<chrispitzer> but I can't find it
<ChrisMorgan> chrispitzer: I think you want a lightweight checkout then.
<Peng> chrispitzer: You don't want a local copy of the history? You're looking for "bzr checkout --lightweight" or "bzr branch --stacked", depending on whether you want a checkout or branch.
<ChrisMorgan> bzr co --lightweight
<chrispitzer> thanks
<lifeless> chrispitzer: note that this will be very slow over the internet
<vila> hi all
<ChrisMorgan> lifeless: but only for things like log, annotate, etc. Diff shouldn't take longer, commit will take just as long.  That's right isn't it?
<lifeless> ChrisMorgan: no
<lifeless> diff will take longer
<lifeless> commit will take longer
<ChrisMorgan> For a checkout?
<lifeless> a lightweight one, yes
<lifeless> diff on a heavyweight one shouldn't be affected
<ChrisMorgan> Particularly though, why will diff take longer?  Doesn't a lightweight checkout still have the latest revision?  What would need to be looked at in the network?
<spiv> ChrisMorgan: a lightweight checkout doesn't have its own copy of the original version to compare to
<lifeless> commit on a heavyweight one will be slightly affected
<spiv> ChrisMorgan: it has to fetch that from the repository, so diff will be slower if the repository is not local.
<lifeless> ChrisMorgan: say your round trip time is 100ms
<ChrisMorgan> So it's not like an SVN checkout.
<spiv> ChrisMorgan: rigth
<spiv> right, rather
<ChrisMorgan> I thought lightweight made it that way.
<ChrisMorgan> OK.
<ChrisMorgan> stacked branch is the same then I presume?
<spiv> Well, it's like SVN only more extreme :)
<lifeless> ChrisMorgan: diff on a lightweight checkout will open the branch ~(600ms) and repository ~(400ms) before doing anything locally
<lifeless> ChrisMorgan: so thats about a second of overhead, before you consider the cost of getting out basis files where a difference is detected
<spiv> Stacking will at least keep some of the repo locally.
<ChrisMorgan> And why, oh, /why/ do you have "lightweight" checkouts and "stacked" branches if it's the same thing?
<lifeless> ChrisMorgan: lightweight makes it roughly like CVS checkouts
<spiv> But stacking isn't really designed for this case (yet).
<ChrisMorgan> I'm not really familiar with CVS... I tried it once for some Drupal work and haven't got over the shock yet.
<spiv> ChrisMorgan: it'd be nice to collapse them, but at the moment they serve different needs
<lifeless> ChrisMorgan: stacked branches can diverge
<spiv> ChrisMorgan: there's a huge thread on the mailing list on (broadly) this topic atm :)
<lifeless> ChrisMorgan: checkouts can't(*), so they aren't really the same thing at all.
<ChrisMorgan> Yeah, but is the only difference between a checkout and a branch that the first is bound?
<lifeless> the only difference between 'bzr checkout oo' and 'bzr branch oo' is that the former binds to the source whereas the latter sets the parent to the source
<lifeless> checkout --lightweight doesn't create a local repo at all and replaces the local branch object with a branch reference pointing at the source
<poolie> hi vila?
<vila> poolie: hey !
<poolie> vila, i think we're meant to talk
<vila> poolie: yup, I started the day with a crashed desktop (and was lucky enough to reboot the host only after suspending the guest...) but things seem to be ok now
<bialix> hello all
<lifeless> win 38
<lifeless> hi bialix
<bialix> hey lifeless, what's 38?
<igc> hi bialix!
 * igc dinner
<bialix> hi Ian
<spiv_> bialix: the number of the irssi window he failed to switch to (he meant to type /win 38)
<bialix> btw, igc, I've update explorer translation template
<doctormo> I'm still having odd problems with threading, could a kind person look over the code quickly and see if they spot any dumb mistakes?
<doctormo> http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/nautilus-groundcontrol.py from line 162 to 175
<doctormo> and http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py the entire file is probably of interest.
<aquarius> bzr's launchpad plugin doesn't, currently, help with the creation of new projects, and I'm looking at hacking on it so that it does so. Was this left out for a reason?
<spiv> aquarius: no, and we'd welcome improvements to the plugin
<spiv> aquarius: (originally it was because Launchpad didn't have launchpadlib when the plugin was created, just a couple of XML-RPC methods)
<aquarius> ah, cool.
<aquarius> atm, all my small projects live in my svn server, because setting up a launchpad project is a pain by comparison with typing four svn commands :)
<aquarius> but typing "bzr lp-new-project projectname description" in a folder to make it an LP project would get over that hump quite nicely
<lifeless> aquarius: this may involve hacking on lp
<aquarius> lifeless, really? launchpadlib lets me create projects, I think?
<lifeless> dunno
<lifeless> coverage of exposed apis can be pretty hit and miss
<aquarius> should do. if it doesn't I shall whine mightily at leonardr :)
<aquarius> if I've got a plugin in the system plugins folder and a plugin with the same name in my local plugins folder, the local one will override the system one, yes?
<lifeless> mtaylor: you really should release a new pandora build if you're talking on it.
<lifeless> mtaylor: the version I packaged in debian is way old now
<lifeless> aquarius: ywa
<jszakmeister> bialix: Hi!  I have a quick question about scmproj...
<bialix> heya jszakmeister! sure
<jszakmeister> How do you work on a local branch and merge the result back in?
<bialix> merge locally and then push
<bialix> maybe I misunderstood your question?
<jszakmeister> Let's say I have a trunk of library that's in the workspace created by scmproj...
<jszakmeister> I want to create a branch of trunk for that library, make the change, and get it reviewed by the team.  Does scmproj support that sort of workflow?
<bialix> Usually we're creating new alt for this, and put new branch under that alt
<bialix> then merging 2 alts when ready
<bialix> but alts is half way to deprecation
<jszakmeister> That's what I thought. :-)
<jszakmeister> Do you envision some other way of doing this?
<bialix> instead of alts you may want to use just new branch of project config
<bialix> but today alts are still supported
<bialix> and sometimes they are much easier
<bialix> I'll remove alts once I will have new layout format with snapshots ready
<jszakmeister> I had that thought as well.  But the one project I'd like to use it for is massive.
<jszakmeister> I'd rather not have a whole second tree, if I can avoid it.
<bialix> new branch of project config is much closer to what nested trees should be
<bialix> jszakmeister: in the past I've tried to create something like bzr-colo now
<bialix> today I'd suggest using bzr-colo plugin
<jszakmeister> I saw that on the list... looks interesting!
<bialix> I've played with it yesterday and it really in good shape
<bialix> despite version 0.0.1
<bialix> I'm not sure yet I will want to provide tight integration with colo in scmproj
<bialix> jszakmeister: if you have only branch for one component then I'd use alts today, publish your branch on the server for review, then merge alts
<bialix> to merge alt from server you need: bzr pcmd "merge {BRANCH_URL}" --alt XXX -i your_library
<bialix> there --alt XXX will be your alt (corresponding to your new branch)
<jszakmeister> Yeah, but I don't want to head down a path thats going to be deprecated.
<bialix> look at http://bialix.com/scmproj/docs/howto.html
<bialix> http://bialix.com/scmproj/docs/tips-n-tricks.html
<jszakmeister> I'd rather say "we can't do that right now" instead.
<bialix> hmm, it's so strong for me
<bialix> s/so/too/
<jszakmeister> :-)
<jszakmeister> The backend is actually in Subversion, so they have other choices.
<bialix> you're underestimate the power of pcmd
<bialix> oh
<bialix> I don't see the full picture of yours
<jszakmeister> They have everything in a Subversion backend, and have been using externals to manage the tree.
<jszakmeister> But it's a PITA.
<jszakmeister> Plus, the backend is old (before SVN had merge tracking)...
<doctormo> I'm going to bed now, thanks for the help before, although the problems remain I'm sure it's a simple fix.
<bialix> bzr-externals?
<jszakmeister> It'd be nice to switch them to Bazaar and bzr-svn, but we don't *have* to
<jszakmeister> That was the next one on my list to examine. :-)
<jszakmeister> The nice thing about scmproj is pcmd
<jszakmeister> and the fact that you can run operations on everything.
<jszakmeister> So, bzr-colo... works for more than just trying to get colocated branch support for one "project"?
<jszakmeister> I thought, from the name, it was really just trying to handle multiple branches of the same project.
<bialix> bzr-colo provides git-style workflow
<bialix> multiple [feature] branches of the same project
<jszakmeister> Yeah, that's what I thought... which is very nice!
<jszakmeister> I just need something more along the lines of scmproj for the other projects though.
<bialix> along the lines?
<jszakmeister> Sorry... I should use better English: "something like scmproj"
<bialix> no, that's me
<bialix> well, scmproj is nice when you have set of loosely related components
<bialix> or when you have common library for several projects
<jszakmeister> That's exactly our case.
<bialix> I have no experience with svn:externals though
<jszakmeister> Be happy that you don't. :-)
<bialix> just read the docs
<bialix> :-)
<bialix> lol
<bialix> but I mean maybe I'm lack some knowledge
<bialix> the good thing about small company/startup is that you can choose any vcs you want
<bialix> but you have to admin it yourself too
<jszakmeister> :-)
<bialix> jszakmeister: I'm planning to add some tips about merge in scmproj
<bialix> or maybe I should finally implement it as separate command
<jszakmeister> That would be great (either one!)
<bialix> there is enough special cases user have to care
<jszakmeister> I completely missed the merge docs the first time around
<bialix> your position re alts is very strong, I did not expect people can get it this way
<bialix> thanks for feedback!
<jszakmeister> You're welcome!
<bialix> if you have any suggestions or more question: I'll be happy to hear them
<bialix> today my own experience drives the development of scmproj, but I can miss some other POV
<jszakmeister> I'm actually trying to write a few things down, but I believe I will have some suggestions for scmproj.
<vila> testr failiing doesn't seem to be implemented despite being mentioned in README.txt
<vila> Of course that the one I was interested in :D
<spiv> vila: failing to fail is still a failure, right? ;)
<vila> spiv: yes, I'm whining about failing to sucessfully fail :)
<vila> err, wrong channel for my remark about testr >-)
<lifeless> well, it will get my attention :P
<lifeless> #testrepository if you want the 'right channel'
<bialix> hi vila
<vila> hi bialix
<quicksilver> supposing bzr+ssh://remote-a and bzr+ssh://remote-b are two different branches which share 99.9% of their revision history.
<quicksilver> and they're large enough that they're slow to branch afresh.
<quicksilver> and I already have a local branch of remote-a
<quicksilver> what's the quickest way to get a local branch of remote-b?
<fullermd> Is your local branch of remote-a in a shared repo?
<RAOF> quicksilver: Have remote-a branched in a shared-repository (initialised with âbzr init-repoâ) and then branch remote-b into the same repo.
<quicksilver> fullermd: no, but if that's the right answer then in future I will arrange for it to be so :)
<RAOF> I'm pretty sure you can reconfigure remote-a to be in a shared repository.
<fullermd> Well, you could fudge without it.  But you'd be wasting near double the space, from 2 copies of the history.
<fullermd> Yes, you can.  init-repo a repo around it, and use 'reconfigure' to move its history into it.
 * fullermd sprinkles a few more pronouns into that sentence just for kicks.
<RAOF> Metasyntactic variables FTW!
<quicksilver> fullermd: cool.
<quicksilver> does 'bzr info' show when you've done it right, I.e. when it is using the shared-repo properly?
<fullermd> It does.
<quicksilver> OK. I bzr init-repo . to create my first shared repo.
<quicksilver> then I bzr branch bzr+ssh://remote-a remote-a to populate it with the first branch
<quicksilver> and it freezes only a second or so in, saying:
<quicksilver> [#########|          ]    103KB   100KB/s | Fetching revisions:Get stream sourc
<fullermd> Well, you already have the first branch locally, don't you?
<quicksilver> oh, it's unfrozen
<quicksilver> was a good 60 seconds though
<quicksilver> fullermd: yes, I do. I was faking a clean start to (a) make sure I understood the process and (b) as a basis for explaning it to colleagues
<fullermd> I've been trying to fake a clean start for years, but I haven't managed to burn all copies of the....
<fullermd> Uh...
<fullermd> Nevermind.  Didn't say anything.
<quicksilver> :)
<quicksilver> I think some kind of insect is trapped inside the bzr process now. chk:chk it's going.
<quicksilver> perhaps a baby bird.
<fullermd> That's the buzzer.  Hence the name.
<fullermd> chk:chk means there's a small sliver of paper stuck between the hammer and the bell.  You probably need to empty out the bit bucket.
<quicksilver> OK, the results are in.
<quicksilver> a clean branch of one of these branches took 4m30
<quicksilver> the first branch into a shared-repo took 13m56
<quicksilver> but then a subsequent branch (a similar but different branch) took 45 seconds
<quicksilver> definitely better
<quicksilver> that's quite apart from the disk space savings, which were pretty close to the 'ideal' 50%
<quicksilver> but to be honest disk space isn't what I care about
<quicksilver> it's branch time.
<fullermd> Yeah.  But they go hand in hand.
<quicksilver> and making a new local branch took only 4 seconds
<quicksilver> (mind you it only took 23 seconds without shared repos)
<quicksilver> only takes 5 seconds to branch something which was previously local into the shared repo
<quicksilver> bit suspiciously fast that ;)
<quicksilver> Hmm. Trying transfer another previously local branch in has pushed a python process up to 2.2G resident
<quicksilver> that doesn't sound very good.
<quicksilver> and eventually died with Python(31106) malloc: *** mmap(size=1268281344) failed (error code=12)
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<quicksilver> I'm not sure I believe this is working right
<quicksilver> It's not downloaded 100M for this branch, which is basically everything.
<quicksilver> that doesn't seem like the shared-repo bit did its stuff
<quicksilver> could it be a problem that the remote formats are all pack-0.92?
<persia> Out of sheer curiosity, if I just want a copy of the source, ought I expect bzr branch ${foo} or bzr export ${foo} to generate less network traffic?
<lifeless> persia: often branch
<lifeless> though export has been improved a lot in 2.1
<lifeless> export will read less, but do more roundtrips before 2.1
<lifeless> [proportional to tree size]
<persia> Interesting.  Thanks.  I had wondered about using export as a super-lightweight branch for review and delete, but I think I won't do that :)
<quicksilver> OK. I can't even 'bzr upgrade' this particular branch in place
<quicksilver> I conclude this is somehow a 'corrupted' branch.
<lifeless> quicksilver: I'm going to sleep now, but I suggest yous tart giving details
<lifeless> quicksilver: as I can't infer anything from the comments you've been making, and corruption is extremely rare
<quicksilver> lifeless: well the details are only just beginning to come clear to me.
<quicksilver> We have many branches of one basic codebase.
<quicksilver> One of them, it turns out, is behaving anomalously.
<quicksilver> On the server its' 300M whilst the others are 100M (I don't know if this is relevant, but it's odd)
<quicksilver> and any attempt to 'branch' it causes a python out-of-memory error.
<quicksilver> I also have a local copy on this machine, which is a couple of months old
<quicksilver> although I presumably downloaded that successfully at the time, any attempt to branch that branch locally gives the same error.
<quicksilver> and any attempt to 'bzr upgrade' it to a more modern format, same error.
<quicksilver> ok, I got the uploader of that branch to push a fresh copy, and I managed to branch that fresh copy
<quicksilver> but it took ages (maybe that's just consistent with the weirdly inflated size) and there is something odd about it
<quicksilver> Standalone tree (format: unnamed)
<vila> quicksilver: try 'bzr info -v', unnamed means you're using an unusual combination
<vila> do the same for the remote branch
<vila> if the repository formats are different, it's likely the slowness is due to the on-the-fly conversion
<quicksilver>        control: Meta directory format 1
<quicksilver>   working tree: Working tree format 6
<quicksilver>         branch: Branch format 6
<quicksilver>     repository: Packs containing knits without subtree support
<quicksilver> vila: how would I have "got into" an unusual combination? And how do I get out of it again?
<vila> well, using a shared repo is one way
<quicksilver> I did briefly experiment with shared repos
<quicksilver> bt I'm not using one here
<vila> ok (bzr info should tell you anyway)
<quicksilver> and as I remarked earlier, 'bzr upgrade' crashes in this branch.
<vila> that's bad, what does 'bz check' says ?
<vila> s/bz/bzr/
<quicksilver> running it now...
<quicksilver> seems to take a little while
<vila> that's expected
<quicksilver> ok I'll let you know when it's finished, and eat a sandwich
<quicksilver> vila:   3927 revisions
<quicksilver>   3468 file-ids
<quicksilver>    330 inconsistent parents
<vila> yup, that's bad enough, do 'bzr reconcile'
<vila> sorry if you already reply to that but what bzr version are you using ?
<quicksilver> vila: 2.0.2 on the server 2.0.1 on my client
<vila> ok, not the latest but good enough
<vila> any reason to keep using 0.92 as your repo format ?
<quicksilver> (although the developer who created / pushed this apparently broken branch is only on 1.13.1
<quicksilver> (and we have another developer who is also on 1.13.1
<quicksilver> but they could both be told to upgrade.
<maxb> quicksilver: To clarify, it's an 'unnamed' format because it's pack-0.92 repo/branch combined with Bazaar 2's tree format. bzr 2.x likes to give you the latest tree format even if it doesn't fit into one of the canned names which for {repo, branch, tree} combinations.
<quicksilver> maxb: *nod* interesting.
<vila> that would allow you to use 2a which will be more compact and faster across the network too
<quicksilver> vila: I had been thinking about upgrading the repo format
<quicksilver> vila: in fact it was this train of thought I had
<quicksilver> "Hmm should use bzr better, let's learn about shared repos and upgrade our repo formats"
<quicksilver> I was following that train of thought and experimenting with some of our branches when I discovered this broken one.
<quicksilver> reconciliation only took 3 minutes. That's a relief.
<vila> both should make a significant difference, but upgrading to 2a requires a 'bzr  check; bzr reconcile' anyway, so you're on the right track :)
<vila> redo 'bzr check' to be on the safe side :)
<maxb> Requires? Or just a sensible precaution?
<vila> precaution
<quicksilver> the branch size has doubled again
<quicksilver> from 300M to 600M
<vila> check you /bzr/reposiroty/obsolete_packs
<vila> s/you/your/
<vila> rhaa, .bzr/repository/obsolete_packs content, gee
<quicksilver> I ran bzr check in another branch
<quicksilver> one which, as far as I knew, was fine.
<quicksilver> it also has the same 330 inconsistent parents
<quicksilver> yup. 278M in obsolete_packs.
<quicksilver> personally I still think it's suspicious this branch is 3x as large as the others
<vila> at least...
<vila> yeah, but 3x is better than 6x
<quicksilver> it does have quite a few changes relative to the others, but not *that* many.
<vila> err, I mean, it shoudn't be 3x
<quicksilver> I am in the process of re-running bzr check
<quicksilver> vila: OK, it now passes bzr check.
<quicksilver> (which took 6 minutes to run)
<quicksilver> but it's odd that even the branches I consider "OK" have the same inconsistent parents.
<quicksilver> I'm going to try to bzr upgrade this branch now I think
<vila> you want to run 'bzr reconcile' in all these branches
<quicksilver> yes, I see that
<quicksilver> so what does inconsistent parents mean? A problem has been lurking which by luck hasn't bitten us before?
<quicksilver> and now in this branch for some reason it's biting us
<vila> most probably, it's hard to say for sure from here :-/
<vila> It could also be unrelated, IIRC there was several weird cases were you could end up with inconsistent parents, not all of the same gravity
<quicksilver> well if bzr upgrade works now, where it didn't work before, then I guess I have "fixed" something"
<quicksilver> if not, then it's still broken.
<quicksilver> and I still wonder what event in branch history made the size triple
<quicksilver> if needs be, I'll binary chop the revisions
<vila> you can try eyegrepping 'bzr log -n0 -v'
<vila> It could be some binary file...
<vila> We had a case where someone embedded a whole $DVCS_TOOL repo during several revisions, modified at each revision... ended up with quite a big repo
<quicksilver> nervously watches Python's resident size increase
<quicksilver> last time it hit 2G and then died with a malloc error
<vila> quicksilver: well, 2.1 includes some related fixes you may want to try...
<quicksilver> vila: do I need to bzr reconcile on ther server and also get everyone to bzr reconcile on each client?
<quicksilver> (that or pull clean branches, presumably)
<vila> yup
<vila> depending on your experiences you may prefer one way or the other, it depends on too many things to have  single answer
<quicksilver> vila: slight reluctance to use beta versions in production, but if you strongly advise it I'd follow your advicee.
<vila> if you end up with smaller repo and that people use shared repos, you may end up downloading it >1 times
<quicksilver> OK, there she goes.
<quicksilver> python resident space > 2G
<quicksilver> malloc failure coming shortly.
<quicksilver> Python(31916) malloc: *** mmap(size=759209984) failed (error code=12)revisions
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<vila> something fishy is going on here, first the 3x increase, now the > 2G mem footprint, that's really really far from the 100M size you're mentioning :-/
<vila> does that come with a traceback ?
<quicksilver> no, in fact, in didn't even kill python
<quicksilver> it just printed that message
<quicksilver> its RSS has dropped to a more "reasonable" 400M and the upgrade claims to still be running
<vila> wow, let it run then !
<quicksilver> ah, eventually
<quicksilver> Python(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions:
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<quicksilver> bzr: out of memory
<quicksilver> I think the long pause was actually the process of freeing enough memory to print the error message :-/
<quicksilver> no traceback I'm afraid.
<quicksilver> vila: I have a plan to try to branch an old revision which doesn't have the problems and then successively pull forward, how does that sound?
<vila> good, as long you can identify the faulty revision...
<quicksilver> vila: further clue.
<quicksilver> or is it
 * quicksilver tries to get facts straight
<maxb> What exactly is an 'inconsistent parent'? What's it inconsistent with?
<quicksilver> I was able to "bzr branch bzr+ssh:/remote-bad-branch bad-branch
<quicksilver> I was then also able to "bzr branch bad-branch bad-branch-copy"
<quicksilver> but since I did reconcile I can't even do that
<SamB_XP> maxb: what is the exact error you're getting ?
<quicksilver> I can't even locally copy the branch with bzr branch
<quicksilver> before the reconcile, I could, and it only took 30 seconds or so to boot.
<maxb> SamB_XP: None, just interested in understanding more about bzr's guts
<SamB_XP> well, where did you see the term then?
<quicksilver> in my report, SamB_XP
<SamB_XP> ah.
<quicksilver> when I bzr check'ed my odd branch.
<SamB_XP> I was puzzled about why maxb had asked about a single consistant parent -- I've only ever heard it in the plural before
<SamB_XP> er. *inconsistant
<quicksilver> OK, I have confirmed by double-checking.
<quicksilver> I can locally branch the un-fixed branch
<quicksilver> but locally branching the 'fixed' (reconciled) branch gives the out of memory error.
<quicksilver> use a DVCS for 4 years and never encounter a single problem, but when I hit a bug, boy is it a painful one :-/
<quicksilver> vila: OK, I found a sufficiently old branch not have the 'size inflation'.
<quicksilver> vila: guessing that might be related, I'm going to reconcile + upgrade from this old revision and see how that goes.
<vila> and from a complete branch, did you see anything suspicious in the following revs (with 'bzr log -n0 -v') ?
<quicksilver> I'm currently use a bash for loop to give me a copy of every intermediate revision
<quicksilver> so I can see where the size inflation is
<vila> ok
<quicksilver> the bzr log -n0 was rather long to look at...
<CaMason> I've got a branch which I've been using as my 'trunk'. To move this to a different physical location, can I just move the repo?
<rubbs> CaMason: best way is to just branch it to the new location then delete the old one.
<rubbs> CaMason: I knoticed that the actual repo (on my windows machine) wouldn't work if it wasn't in it's old path for some reason.
<CaMason> ok. That maintains all of the branch history yes?
<rubbs> but if I branched it and deleted the old one it worked.
<rubbs> yes
<CaMason> sounds good
<quicksilver> vila: OK. Using an old branch revision which doesn't suffer the size inflation, the sequence check/reconcile/upgrade worked.
<quicksilver> vila: so I am inclined to consider the size inflation to be related to this bug, somehow
<vila> that would be really weird
<quicksilver> vila: I note taht format 2a does seem to be about 1.5x larger than pack-0.92
<quicksilver> is that expected?
<quicksilver> I don't really mind.
<vila> larger ? Certainly not, check /obsolete_packs again
<quicksilver> right. roger that.
<quicksilver> looking good.
<quicksilver> about 80% the size?
<quicksilver> 20% smaller, i.e.
<quicksilver> now I'm going to try to pull into this "good" branch from the other
<vila> 20% smaller is a bit deceiving but still smaller, we've seen more savings
<vila> quicksilver: do that on a copy if you don't mind :)
<vila> I thought you made several branches to identify the size inflation ?
<quicksilver> yes, I have many many branches
<quicksilver> and yes, I made a copy :)
<quicksilver> in fact, I did this check/reconcile/upgrade experiment on revision 896
<quicksilver> I started that *before* I learn that revision 915 was the last revision not to suffer size inflation.
<vila> ok
<quicksilver> so what I'm doing now is, (in a copy) pulling into my upgraded 896 from 915
<quicksilver> that went fine, apparently.
<vila> so what's in 916 ?
<quicksilver> unfortunately it's a massive merge
<quicksilver> 39 merged revisions
<vila> how many files ? Any binary ?
<quicksilver> yes there is a binary file in there. It's 1.3 megabytes
<quicksilver> (and a few smaller binary files) (and many many text files)
<quicksilver> I believe this is about to crash
<vila> 1.3M is not big, search for > 50M
<quicksilver> Python process up to 1G resident and climbing.
<vila> amazing
<quicksilver> pretty sure there are no files that big.
<vila> any chance to publish these branches ?
<quicksilver> not really :(
<quicksilver> 4 years of private code history.
<quicksilver> two python memory errors but the bzr pull is still running so I'll let it try.
<vila> quicksilver: still using 2.0.3 ?
<quicksilver> 2.0.1 in fact
<vila> quicksilver: trying with bzr.dev is worth it I think, try pinging jam to get his opinion though he made most of the memory fixes
<jam> morning vila
<vila> magic....
<jam> no opinions here
<jam> :)
<jam> let me read
<vila> morninbg jam
<quicksilver> vila: well knock me down with a feather
 * vila stop chewing while typing
<jam> you guys have been chatting for a long time...
<quicksilver> vila: despite two scary looking memory errors, the bzr pull has succeeded.
<jam> care to summarize?
<quicksilver> jam: painful out of memory errors doing certain operations with a particular branch
<vila> yup, quicksilver is encountering memory errors (no traceback, direct from python) while pulling 0.92 branches
<quicksilver> jam: including: errors when branching, errors when merging, errors when trying to 'bzr upgrade'
<vila> that's with bzr-2.0.1.
<jam> quicksilver: no traceback even with -Derror?
<jam> (and nothing in ~/.bzr.log ?)
<quicksilver> jam: comparing my branches en-masse, these errors seem to be co-incident with the repository size on disk jumping from 100M to 300M at a particular revision
<vila> <quicksilver> Python(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions:
<quicksilver> and I don't believe there is a good reason for the size jump; I don't think we added then deleted a 50M binary file or anything of that nature.
<jam> quicksilver, vila: allocating 691MB in a single shot?
<quicksilver> yes.
<quicksilver> other errors with slightly different numbers
<vila> no, more like 200M
<vila> haa, the malloc hyes
<jam> quicksilver: 64-bit machine?
<quicksilver> e.g.
<quicksilver> Python(32408) malloc: *** mmap(size=1267761152) failed (error code=12)
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<quicksilver> Python(32408) malloc: *** mmap(size=759758848) failed (error code=12)xts:texts
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<quicksilver> jam: core2, so technically yes, but running OSX 10.5, so in practice I believe it counts as 32 bit.
<jam> quicksilver: just run 'python' and see what it says
<quicksilver> note that those two errors I just pasted occurred during a bzr pull which appears to have succeeded!
<jam> I'm not sure about mac, but on Windows I get:  [MSC v.1500 32 bit (Intel)]
<quicksilver> it spewed out that malloc stuff but still ran to completion.
<quicksilver> Python 2.6.4 (r264:75706, Nov 12 2009, 09:19:07)
<quicksilver> [GCC 4.0.1 (Apple Inc. build 5488)]
<quicksilver> not much help there.
<jam> quicksilver: import sys
<jam> sys.sizeof(1)
<jam> sorry
<jam> sys.getsizeof(1)
<jam> 12 == 32-bit, 24 == 64-bit
<quicksilver> 12
<quicksilver> vila: so, that bzr pull which appeared to succed, has jumped the repo size to 470M (from 80M)
<vila> bam 400M
<quicksilver> vila: admittedly some more crap has appeared on obsolete_packs which I could remove, but there is still 250M in packs
<vila> so 170M increase
<quicksilver> yes, or roughly 3x
<vila> and that's with your upgraded branch right ? So 2a format ?
<quicksilver> 80->250M is quite consisten with the 100M -> 300M I had in pack-0.92
<quicksilver> yes, this is with 2a format
<quicksilver>  find . -size +1000 | xargs ls -lh
<quicksilver> the only files > 500K are one 500K jpeg and a few .pack, .cix, .tix files
<vila> quicksilver: that may not be enough, you may have to bisect in the merge revisions
<quicksilver> in particular, one killer .pack of 192M and one of 55M
<vila> but those are in .bzr not committed in your branch right ?
<quicksilver> right
<quicksilver> there are no large files in the working tree
<vila> quicksilver: it's really weird to see the same size increase in 0.92 and 2a that use very different conpressions algorithms
<quicksilver> (that jpg of 500K is the largest)
<quicksilver> I'll knock up a script to bisect all the merge revisions
<vila> in the mean time, 'bzr log -r-2..-1 -n0 -v' may be less huge
<vila> than it was for the whole branch
<rubbs> isn't there a bisect plugin already?
<rubbs> I've used it before
<jam> rubbs: there is
<quicksilver> Im' not actually going to bisect
<quicksilver> I'm lazy
<quicksilver> I'm just going to branch ever intermediate revision and look at the disk spaces they use
<jam> vila, quicksilver: well, if you are versioning binary files like .jpg, it isn't like we can get tremendous size improvements
<jam> quicksilver: are you running from source?
<quicksilver> jam: I don't think the binary files are the issue here
<jam> I just want to check that you built the extensions
<quicksilver> they are small and change rarely.
<quicksilver> I'm running from macports, which kind-of-source
<jam> The 2a pure-python compressor doesn't do nearly as good of a job as the C version
<vila> jam: a review of https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 will be highly appreciated
<jam> quicksilver: I think it compiles extensions, though
<vila> jam: but the size increase was there for 0.92 too...
<jam> vila: so I think he has more data
<jam> but the question is how much should it increase
<jam> quicksilver: the loop over pull is often a good indicator
<quicksilver> what do you mean?
 * vila needs to reboot, bbiab
<quicksilver> jam: of course it's only a hunch that the weird out of memory errors I have seen are related to this sudden lurch in repo sizes.
<quicksilver> jam: but we have many many branchs, some live, some dead, and we use bzr a lot
<quicksilver> and it's just on one particular branch that we have this strange issue
<quicksilver> ...and that's the branch with the inflated repo size.
<jam> quicksilver: there are a few different ways it could happen, old code or new code
<jam> the new format hasn't been super-tuned for memory performance during pack
<jam> it is better for getting data out, commit, etc
<jam> but 5x the size of the largest file wouldn't suprise me
<jam> that doesn't quite explain 1GB that you pasted earlier, though.
<quicksilver> understood, but as far as I know there are no large files.
<jam> Python(32408) malloc: *** mmap(size=1267761152) failed (error code=12)
<quicksilver> unless you think a 500k jpg is large?
<jam> quicksilver: no I'm talking 100+MB files
 * quicksilver nods
<quicksilver> ok well there's another python memory error
<quicksilver> looks like I may have found the precise revision that causes it
 * quicksilver reviews changelog for that revision
<jam> vila: personal impression, 'bzr resolve' is a bit confused as to what it wants to be, and it is hard for me to give a clear-cut answer for it
<quicksilver> it is also odd that these memory errors can occur but the branch still succeeds
<jam> quicksilver: that is quite surprising to me as well
<jam> I do believe that the OS is the one reporting the error
<jam> and not python
<jam> but if the OS is not returning NULL on a bad malloc
<jam> something is weird
<vila> right, but what about the rest ? I said to poolie this morning that 1) I targetting 2.2 so no hurry, but no review means I'm stuck 2) I'll try to do a summary mail about the main aims of this work but that mp is just a first step
<jam> quicksilver: http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/malloc.3.html
<quicksilver> HAHAHA
<jam> You might look at setting one of the ENV vars
<quicksilver> ok, so it looks like part of this is myfault
<quicksilver> or at least one of my developer's faults :P
<jam> quicksilver: what's up?
<jam> (custom plugin?)
<quicksilver> there is a 691 megabyte text file in this revision
 * vila bets for a bzr branch committed into the branch
<quicksilver> (which he deleted in the next revision)
<vila> haaaaaaaaaaaaaa
<jam> well, that explains the bloat :)
<quicksilver> and it *probably* explains the bugs too
<quicksilver> in that that was probably causing out of memory errors all over the shop.
<jam> quicksilver: well it explains why we would try to malloc a huge range
<jam> I'm not sure why it succeeds but complains about malloc, etc.
<vila> quicksilver: time to teach about 'bzr uncommit' in cases like this
<jam> vila: and it would be good to have a "bzr nuke-this-frickin-file"
<quicksilver> so, what is the most efficient way to change history?
<vila> quicksilver: history being immutable, you can't just take that revision out of the repo, you'll have to recreate that branch with
<jam> quicksilver: rebase
<vila> quicksilver: yeah bzr-rebase, jam finishes my sentence :)
<jam> I think it is called "bzr-rewrite" as the plugin name
<jam> but "rebase" or "replay" would be the commands you'd want
<quicksilver> that will let me replay a bunch of revisions, including their commit messages, leaving out some detail?
<quicksilver> http://wiki.bazaar.canonical.com/Rebase ?
<vila> quicksilver: https://launchpad.net/bzr-rewrite
<vila> but yes, that's the idea
<jam> quicksilver: yeah, the plugin changed names
<jam> well sort of
<jam> I don't think he has finished migrating
<jam> because debian hasn't changed his package name
<jam> so I think you have to "bzr co lp:bzr-rewrite rebase"
<jam> which is... odd :)
<quicksilver> there is a bzr-rebase 0.53 in macports
<quicksilver> the description at http://wiki.bazaar.canonical.com/Rebase does not suggest to me it can actually change revisions
<quicksilver> sounds like it just changes tree shape
<quicksilver> (I've changed tree shape in the past by carefully chosen back-and-forth merges)
<jam> quicksilver: the idea of rebase is "take a commit that looks like X, and create a new commit with the same delta, but applied to a different base"
<jam> So the idea is that for the branch where he added and removed the file
<jam> you would rebase the commit after removing the file
<jam> onto the commit before adding the file
<jam> note that it requires rebasing all revisions that follow
<jam> which is... unfortunate
<quicksilver> ah, so you "coalesce" the two revisions which add+remove the file into one
<quicksilver> which makes the file vanish from history entirely
<quicksilver> and then you have to replay the rest of history after that.
<jam> quicksilver: right
<quicksilver> the first part I could do easily enough by hand.
<quicksilver> the annoying part is replaying history
<jam> yep
<quicksilver> especially if I want to maintain the merge shape
<quicksilver> although, bzr bundle is enough to maintain commit messages isn't it?
<quicksilver> no, bzr bundle will have a note of the missing revision
<quicksilver> and complain it's not there.
<quicksilver> in fact I can't see how do to this by hand.
<quicksilver> in a way which preserves the merge points with external revisions
<quicksilver> (of which there are many)
<jam> quicksilver: I believe you can rebase --include-merges
<jam> but yeah, it is quite tricky to do by hand
<quicksilver> well I'm installing bzr-rebase now
<gerard_> hey all, any reason for the terminal window you get when launching Bazaar Explorer on windows?
<quicksilver> jam: OK I've installed bzr rebase, I've read the bzr rebase documentation, and I still don't understand what I'm supposed to do. I don't see how to tell it to ignore/coalesce the bad revisions.
<jam> gerard_: lack of developer time to get rid of it :)
<jam> it isn't terribly hard, but I ran into version compatibilty problems when i tried
<jam> (py2.6 + pyqt4.5 + py2exe didn't like to play well together)
<jam> it shouldn't be hard to fix as those seem to have gotten sorted out
<gerard_> jam: ah ok
<gerard_> it might just annoy me enough to get rid of it
<jam> gerard_: Quick note, you want to set up a 'py2exe' target in bzr's setup.py that uses "window = ['bzr-explorer.py']"
<jam> and then implement a bzr-explorer.py that is running the equivalent of "bzr explorer $ARGS"
<jam> I can give some more help if you want to work on it.
<jam> it is something I would *like* to get to, but not enough tuits yet :)
<quicksilver> I see no alternative but to work carefully up through the revision history and re-apply partial diffs, being sure to re-merge wherever there was a merge
<vila> quicksilver: I never used it myself but I was almost sure it was included in bzr-rewrite, jam, could I be confused with something in bzr-fastimport instead ?
<quicksilver> we surely can't be the first people to ever need to change history in this way ;)
<jam> quicksilver: I don't know what 'bzr replay' or 'bzr rebase' supports. I know there is an "include-merges" flag.
<gerard_> jam: thx, I'll keep that in mind, I might have some time tonight
<quicksilver> jam: yes, I see the merge options, but I don't see how to start it off by saying "pretend this bit never happened"
<vila> quicksilver: Be also aware that the branch you are re-building should become the reference and that no-one should merge a poisoned branch into it...
<gerard_> bye
<quicksilver> vila: yes, need to expunge all poisoned branches.
<quicksilver> vila: but first I need to build a good one
<quicksilver> I wonder if a careful bit of shelving is enough
<jam> quicksilver: so create a branch that is just before the add
<jam> then tell bzr-replay to replay the revision just after
<jam> or create a branch just after
<jam> bzr uncommit
<jam> bzr  rm bad-file
<jam> bzr commit -m "new rev without bad file"
<jam> then bzr replay everything after that
<jam> (or rebase)
<quicksilver> right. That makes perfect sense.
<jam> the specific syntax isn't great, and I'm never quite sure whether rebase is "apply this to that" or "apply that to this"
<quicksilver> bzr rebase takes a branch as its only parameter
<jam> quicksilver: doesn't it take --revision (-r) as well?
<jam> vila: quick question
<jam> for Copyright headers
 * vila afk for ~ ok
<jam> when would you collapse to 'range' notation?
<jam> would you collapse 2007, 2008, 2009 or only at 2007, 2008, 2009, 2010 ?
<jam> I certainly wouldn't collapse 2007, 2008 => 2007-2008
<vila> Never said I will, but I've seen multi-lines copyright just after you mentioned the problem
<jam> also, should it be "2007-2010" or "2007 - 2010"
<vila> I thought range notation ought to be avoided but IANAL and I forgot why
<jam> vila: I thought so too, but poolie just submitted a patch with ranges
<jam> and I have to say, it looks a lot nicer than 2005-2010 expanded
<jam> -# Copyright (C) 2005, 2006, 2007, 2008, 2009 Canonical Ltd +# Copyright (C) 2005-2010 Canonical Ltd
<vila> and the multi-line occurrence was from a source I thought was valid and serious when I read it
<vila> yeah, not sure lawers care about nice looking :)
<jam> ok, for now I'm using >= 4 years as the collapsing point
<vila> so, afk for ~<1h starting now :)
<jam> vila: enjoy your time off :)
<jam> http://www.mateoaboy.com/f6/blog_files/e740002542ebfcf81fae2653baaf4170-12.html
<jam> "In the cases of derivative works it is recommended to indicate a range of years for a work (although this is not required by law)."
<jam> I haven't found anything about not using "-"
<quicksilver> jam: hm. Of coruse. The uncommit version leaves the uncommited revision in the repo :)
<quicksilver> jam: so my large file is still there, just in an orphaned revision.
<jam> quicksilver: yep, but fetching out of that repo won't
<quicksilver> IIRC there is no way to remove orphaned revisions.
<jam> quicksilver: well there is the "create a new repo and fetch"
<jam> but *today* we don't have a "bzr gc" command.
<jam> quicksilver: also note that after replay you'll have the same objects 2x in the repo
<jam> so you'll probably want to do it in a temp repo
<jam> and then create a pristine repo from that
<quicksilver> you mean if I were using shared repos?
<quicksilver> I'm not, at the moment, although way back at the beginning of this conversation I was trying to switch to them :)
<jam> I'm not 100% sure how replay works
<jam> I'm guessing it does leave the "from" revisions in the local repo
<jam> again, fetching out of there won't propagate them
 * quicksilver nods
<quicksilver> ok, so I have my clean repo at revision "N+1" with the altered revision not to commit that horrible file.
<quicksilver> I want to bring it up to the most recent version
<quicksilver> I bzr rebase <path/to/most/recent> ?
<jam> quicksilver: you have reached the limit of my rebase knowledge
 * quicksilver nods
<quicksilver> well I'm trying it
<jam> I think you'll have to somehow say you don't want N
<quicksilver> that's the part I don't get, yes :)
<jam> so "bzr rebase -r N+1..-1 path/to/old/brancH"
<quicksilver> I think it might be --onto
<quicksilver> bzr rebase --onto N+1 path/to/most/recent
<quicksilver> certainly bzr rebase /path/to/most/recent gives the familiar malloc error
<quicksilver> OK I'm pretty sure that was wrong, since it's given hundreds of conflicts which are wrong
<quicksilver> maybe I want to be *in* the recent branch
<quicksilver> and bzr rebase relative to the fixed branch
<quicksilver> maybe I just want to wait to jelmer to appear :)
<salgado> jam, around?  I was just wondering if there's anything else I need to do to get my fix for bug 308122 through review...
<ubottu> Launchpad bug 308122 in bzr "No reliable way to show shelved changes" [Medium,In progress] https://launchpad.net/bugs/308122
<quicksilver> possiblye https://bugs.launchpad.net/bzr-rewrite/+bug/329951 is what I need
<quicksilver> but that's an open wishlist :)
<ubottu> Launchpad bug 329951 in bzr-rewrite "support squashing commits" [Wishlist,Triaged]
<davidstrauss> I'm having trouble with bzr-svn. I need it to use a Subversion 1.5+ client, but the OS X install appears bundled to 1.4.
<davidstrauss> I have Subversion 1.6 installed to my Mac.
 * vila back from garage, talk about a time-off it's freezing outside :)
<maxb> quicksilver: I think the bzr-rewrite code for choosing merge base revisions is a bit dodgy when rebasing merge commits
<quicksilver> maxb: I have managed to get bzr replay to do something useful
<quicksilver> but only one revision at a time
<quicksilver> and it throws out of memory errors
<quicksilver> but they don't appear to *matter*
<quicksilver> it still works.
<maxb> It does not help that bzr replay is a hidden command
<quicksilver> so by sitting in the "fixed" dir which has the bad commit removed
<maxb> Why only one revision at a time, though?
<quicksilver> I can do "bzr replay -rX.Y.Z ../newest-ver"
<quicksilver> each time I do that, it brings in that actual changeset
<quicksilver> but nothing older
<quicksilver> so I need to do that for each value of X,Y,Z
<quicksilver> still if it works, I can do that mechanically
<quicksilver> I have the list of revisions.
<quicksilver> however, I have a conflict because I missed one
<quicksilver> I did that deliberately to check my understanding of what it was doing
<quicksilver> missing one really does miss out that change
<quicksilver> Yes, this actually does seem to work!
<quicksilver> well let's see what happens when we get to the first merge revision though
<quicksilver> that's what matters
<quicksilver> maxb: hmm this may actually work. bash for loop reapplying revisions one by one. I've found another 'evil' one which is using up all my python memroy though
<quicksilver> not sure why this one is evil.
<quicksilver> ack repo size up to 470M again :(
<quicksilver> clean branch just to check, maybe that's orphaned revisions.
<quicksilver> ok, clean copy is still only 80M
<quicksilver> I'll shift to useing that
<quicksilver> hmm. I seem to have got to a critical point where every single replay is upsetting it, by making it thing about the large file
<quicksilver> but it *is* working.
<vila> quicksilver: someone may have merged the poisoned revision
<quicksilver> vila: well the poisoned revision hasn't come back yet
<quicksilver> vila: (using repository size as the proof)
<vila> quicksilver: sry for the noise then, I thought you were saying it was back
<quicksilver> vila: well it's coming back as an orphaned revision.
<quicksilver> vila: something keeps bringing it back into .bzr/repository
<quicksilver> vila: but, because it's not referenced by any version in my history, if I do a clean branch or push it vanishes.
<vila> ok
<quicksilver> unfortunately it makes every replay slow
<quicksilver> because I have to replay each revision independently, and each replay is 'worrying' about that huge file in some way I don't understand
<quicksilver> or maybe not.
<quicksilver> they're going faster now.
<quicksilver> Ah, but in a critical way they're not working.
<quicksilver> they're not actually recognising merges as merges.
<quicksilver> OK, so replay isn't the right tool.
<quicksilver> so maybe rebase is
<quicksilver> but I really don't understand how
<vila> damnghosts
<Adys> is there a command for cleaning up all the .~1~ files?
<Adys> other than find and xargs rm
<maxb> clean-tree
<quicksilver> vila: I've established that "replay" neveer seems to replay merginess in the way I want, so it's presumably the wrong tool.
<quicksilver> vila: It's possible that rebase may be the right tool
<Adys> cheers
<quicksilver> but I can't work out how to use it.
<vila> quicksilver: I don't use it myself, let's try to ping jelmer
<vila> damn he's not online
<quicksilver> replay replays simple commits (no merge involved) fine
<quicksilver> preserving the author, the message, etc
<quicksilver> I wonder if it preserves the ID
<maxb> It would be erroneous to preserve the revid
<quicksilver> OK, so other merges from this branch would be broken
<ronny> quicksilver: talking about bzr-svn? full roundtrip is supported by using svn revision properties and/or storing metadata in rich-root
<quicksilver> or at least will need the same kind of fixing.
<quicksilver> but fortnuately I don't have any of those
<maxb> ronny: No, not bzr-svnhere
<quicksilver> ronny: no. Just trying to use rebase to rewrite history.
<ronny> ok
<quicksilver> vila: I will keep an eye open for jelmer.
<maxb> quicksilver: rebase won't rebase merge revisions either, at least rebase's official versions
<maxb> I have a branch pending that I need to cast a final eye over and submit to jelmer
<quicksilver> maxb: you mean it won't rebase them preserving their "merginess" ?
<quicksilver> replay will replay them as naive diffs
<quicksilver> but that doesn't solve hte problem - it means later merges will conflict all over the shop
<maxb> The trunk bzr-rewrite's rebase starts by picking out a leftmost path, and only ever rebasing revisions on that path
<maxb> I have no idea why anyone would want that
<maxb> So I rewrote it
<quicksilver> I don't actually understand the connection between what I want to do and what rebase's docs claim it is for
<quicksilver> but jam + vila suggested it.
<quicksilver> the docs for rebase look to describe something which simple re-pivots an existing history
<jam> salgado: It looks like you've covered our requests, I'll merge it
<quicksilver> which you can actually just do with back-and-forth merging
<jam> I think the delay is just that it isn't always clear when someone has done work
<quicksilver> although some might consider that inconvenient
<quicksilver> maxb: do you understand the probelm I'm trying to solve though?
<maxb> I think I do
<salgado> jam, great, I can't wait to have the feature available in a release. thanks a lot!
<maxb> What's the proper URL for the bzr pqm status page?
<Peng> maxb: http://pqm.bazaar-vcs.org/ ?
<maxb> wiki/BzrDevelopment links to the SSL version of that, which then triggers a SSL error since the certificate is for canonical.com
<maxb> Maybe I should just edit the wiki page to point to the plain-http url?
 * Peng shrugs
<Peng> I usually use the SSL version (I'm weird), but I linked to the non-SSL version because it came up first in my browser history.
<Peng> maxb: ...The HTTPS version redirects to the HTTP version...
<maxb> Peng: Not if your browser complains about the SSL certificate first.
<Peng> maxb: Well yeah. My point was, it seems HTTP is canonical.
<Peng> (No pun intended. Although it was probably a bad choice of word anyway.)
<vila> maxb: but if you accept and makes a security exception *then* it redirects
<Peng> maxb: For whatever it's worth, editing the wiki sounds good to me.
<vila> maxb: it's probably a typo in the wiki as https makes no sense here
<Peng> maxb: Also, grepping my IRC logs, everybody (including core devs) uses http.
<maxb> right. wiki amended.
<Peng> :D
<quicksilver> maxb: I think I'm going to solve it by a mixture of replay (when it's a plain revision) and careful manual merging to exact revids (when it's a merge)
<quicksilver> maxb: I only have 40-odd revisions to go through
<maxb> The only alternative I can think of would require some tweaks to the rebase sourcecode
<quicksilver> it's quite painful when I have a major conflict though
<quicksilver> (which was already resolved by the developer concerned"
<quicksilver> I wish there was a way to say "give me the working tree state of this revid, without actually 'pull' ing it.
<quicksilver> becauase I"m courrnetly not seeing a simple way to 'get' his conflict resolution.
<quicksilver> maxb, vila: any clever suggestions?
<maxb> I'd be tempted to avoid doing this manually at all costs
<maxb> Perhaps trying to write some code using bzrlib if need be
<maxb> I wonder if 'bzr rebase -r (revno after problem).. ../original-branch' would work out
<maxb> Using --include-merges, and my branch of bzr-rewrite (lp:~maxb/bzr-rewrite/rebase-merges-properly)
<quicksilver> maxb: with the working directory being the 'fixed' branch?
<maxb> Indeed.
<quicksilver> maxb: I've not used python in anger ever (I've dabbled, and I can read it, but that's not he same as being comfortable enough to knock up a quick bzrlib script ;)
<vila> quicksilver: hmm, did you look at fastimport ? I'm not sure it has been implemented but I think their was talk about that scenario (excluding a file from history)
<quicksilver> vila: I took a brief look and it seems to require writing an exporter to tweak the history.
<vila> damn
<maxb> Couldn't you just fast-export the revisions after the problem and fast-import them onto the fixed branch?
<quicksilver> maxb: well I'm on a train now so I'm not going to try downloading your launchpad now :)
<maxb> quicksilver: If you have a branch of lp:bzr-rewrite, there's only about 6 more revisions in mine
<quicksilver> maxb: I don't. I'm using the 0.53 bzr-rebase from macports
<vila> I think bzr-rewrite is python only so you should be able to install it from source in your $HOME/.bazaar/plugins
<maxb> It's 539KB to branch, if you want
<vila> maxb: ^ ?
<maxb> the size of the branch, should quicksilver choose to download it
<vila> maxb: sry, my question was: is it python-only ?
<quicksilver> oh, that is quite small, even over 3G.
<maxb> Yes, it's python-only
<maxb> quicksilver: So, it would actually be more like: in a branch of the original branch: bzr rebase --always-rebase-merges -r (first revno to rebase).. ../the-fixed-branch
<quicksilver> how will bzr cope with having two plugins with same name? will the one in ~/.bazaar/plugins take priority over the globally installed one?
<maxb> yes
<quicksilver> maxb I think I've symlinked it in; is there an easy way to confirm I have your version?
<quicksilver> ah, bzr puglins -v
<quicksilver> maxb: bzr: ERROR: no such option: --include-merges
<quicksilver> bzr oh, always-rebase-merges?
<maxb> --always-rebase-merges
<quicksilver> not what you said the first time.
<quicksilver> but now I'm confused; you say to run it in a branch of the original?
<quicksilver> I thought I was supposed to run it in the fixed one?
<quicksilver> maxb: whose numbering scheme should I use for the -r?
<maxb> You should run it in a fresh branch of the original
<quicksilver> ah. I'm getting trouble because the repo formats differ.
<quicksilver> which is a bit of a problem because I was never able to "bzr upgrade" the original
<quicksilver> that was one of the symptoms of the bug.
<quicksilver> however my new fixed one has been upgraded
<maxb> rebase is a little weird. It basically does a pull --overwrite of the "other branch" and then re-adds rebased forms of some revisions of the branch you ran it in on top of that
<quicksilver> since at one stage I thought that might fix the problems.
<quicksilver> my original branch is stuck in pack-0.92
<quicksilver> so, I need to make a pack-0.92 version of the 'fixed' one
<quicksilver> how do I ask for a specific format?
 * quicksilver rebranches from a branch in old format.
<rubbs> Got a friend here whose given me a problem I'm not sure how to best solve. He's looking to version a bunch of managerial documents, and only wants certain people to have access to it. I mentioned making them all wikis so they are versioned, but he said they need to be offline and some are spreedsheets. He was trying to tell me he wanted to use bzr, but I told him at best he'd have to separate all his managerial documents into a separate repo and
<rubbs> He keeps wanting a per-file authorization within bzr... I don't think that possible though
<rubbs> My other issue is that most of these docs will be binary... so versioning them is going to get big.
<luks> bzr doesn't handle authorization at all
<rubbs> I didn't think so... I also told him that due to the distributed nature once it was branched it's out of his control anyway
<beuno> rubbs, I think someone was working ona plugin for that
<beuno> not sure where it got
<rubbs> I tried to tell him that a CMS might be better, but he said that they didn't version attached files. (I havent vetted that claim yet)
<luks> well, he can use bzr to manage history of the documents
<luks> but then needs some layer to make them available to users
<rubbs> I'm thinking of having bzr behind a CMS,
<rubbs> so luks I think you got the best idea.
<luks> I'm sure some existing CMS can make static documents available to users with per-file access
<luks> I've never tried, but it doesn't seem as a rare problem
<rubbs> yeah... I'm thinking he wants these users to have the ability to checkout old verstions too :( This is a hard one... I'm gonna keep diggin
<luks> oh
<luks> yeah, that would be more complicated
<rubbs> yeah. I guess he's just brainstorming... so I don't know how crutial this is yet.
<quicksilver> maxb: bzr rebase -r... ../fixed-branch wants a revision number relative to the 'current' branch
<quicksilver> i.e. the original branch
<quicksilver> oh eys, that's what you said
<quicksilver> maxb: No revisions to rebase
<quicksilver> it says.
<quicksilver> OK, I have another approach.
<quicksilver> I need to be able to accept a merge but reject all its changes
<quicksilver> I'm sure I remember reading about that one day
<quicksilver> ah, bzr revert .
<quicksilver> YES. I think this works.
<quicksilver> no, it doesn't.
<quicksilver> jelmer: was looking for you earlier. Trying to find a good way to rewrite history.
<quicksilver> Ah. Pebkac.
<quicksilver> my solution does work.
<quicksilver> It's a bit painful but it works.
<quicksilver> vila, maxb, jam : I have a solution :)
<mkanat> What's the best way to sync a bzr branch back to CVS?
<mkanat> kiko: ping ^^^ (The above question is our primary hold up on actually switching now.)
<lifeless> vila: http://junit.sourceforge.net/doc/faq/faq.htm#tests_7
<vila> lifeless: been there, seen that, not an *expected* failure only an test using assertRaises
<quicksilver> ok that's odd.
<MFen> how do i fix not compatible because "different rich-root support" during a merge?
<quicksilver> why would a bzr merge explictly create 'OTHER' files?
<quicksilver> instead of a proper conflict?
<lifeless> MFen: you have to upgrade
<quicksilver> side effect is if I "bzr revert ." the file gets deleted.
<MFen> lifeless: is it definitely me that has to upgrade and not the other person? i thought i was recent, but i'm not positive
<lifeless> quicksilver: if the files are not textually mergable
<MFen> i'm at 2.0.3
<lifeless> MFen: if you are merging, and get that error, then you need to upgrade the repository that your data is stored in to a rich root capable format - e.g. 2a, the default in the 2.0 releases
<MFen> lifeless: i'm not sure whether that means the other guy's remote branch, my local branch, or even the remote trunk.  is there a way to inspect the version?
<lifeless> bzr info
<lifeless> vila: its the closest I've found so far
<quicksilver> lifeless: I mean, it actually displays +N /path/to/file.OTHER when I merge
<lifeless> quicksilver: then someone add file to the branch and you already have it in your branch
<lifeless> they haven't edited your file, they started over
<vila> lifeless: yeah, me too :-/
<MFen> lifeless: ok, bzr info -v on my local branch shows        control: Meta directory format 1
<MFen>  (and some other versions of stuff too)
<quicksilver> lifeless: ah right. another botched merge.
<lifeless> MFen: whats the top line
<quicksilver> damn I need sleep.
<quicksilver> will come back to this tomorrow.
<MFen> Standalone tree (format: unnamed)
<vila> lifeless: but from there I got the feeling that I was chasing a ghost
<lifeless> MFen: bleh :P
<lifeless> MFen: whats the Repository line then
<MFen>     repository: Packs containing knits without subtree support
<lifeless> right
<lifeless> so your format can't do rich roots
<lifeless> whomever you are merging from can.
<lifeless> this is a one-way transition
<lifeless> and it occurs by default in 2.0
<MFen> lifeless: ok. i don't know what to do. i'm at 2.0.3 so whatever was supposed to occur doesn't seem to have occurred
<lifeless> MFen: run 'bzr upgrade'
<lifeless> it will migrate your data
<MFen> lifeless: you are an enlightened gentleman. thank you.
<lifeless> MFen: np :P
<lifeless> vila: xfail - try this: change the <failure> to <xfail> but keep the exception type and everything else
<poolie> hi vila, lifeless
<lifeless> hi poolie
<poolie> lifeless: of course you're welcome to use my screenshot
<lifeless> \o/
<poolie> i hope it may do more stuff before your talk but no promises
<poolie> if not, then i have a ~24 hour flight, that always seems good for hacking
<poolie> assuming one gets a decent seat
<jam> hi lifeless and poolie
<poolie> hi jam
<jam> poolie: so... the SilentUIFactory stuff strikes again
<lifeless> hi jam
<jam> running the 'unshelve --preview' stuff passes manually
<jam> unless you redirect to a file
<jam> then 100 test fail
<poolie> jam, oh, really?
<jam> lifeless: did you see my message about testr?
<poolie> do you mean if the stdout of selftest is redirected?
<jam> poolie: yeah, because ShelfUi now calls make_output_stream
<poolie> that's quite a bug
<poolie> i was hoping to do that soon after finishing the mysql cross-format-fetch bug
<poolie> jam, it seems like a separate bug if the code under test can even ever be influenced by redirection of the test output
<jam> well, without that, we would have hooked up the diff to write to stderr I think
<jam> well, stdout
<jam> and just never generated the diff
<lifeless> jam: found it
<jam> of course, I just ran without redirect, and 14 tests fail...
<poolie> i don't really understand, but did you send mail about this already?
<jam> I'm not sure why the tests would have passed before
<jam> I sent main to the review list
<jam> that I can't land it because tests fail
<jam> but since I'm PP I figured I should try to debug it
<poolie> ok i'll look in a sec
<jam> of course, it *also* fails because of a mismatched lock count, which makes the test results pretty hard to read
<dutchie> I tried to "bzr mv chapter6.tex maintenance.tex" but it said "bzr: ERROR: Specified file "maintenance.tex" is outside the current view: chapter6/chapter6.tex". WTF is going on?
<jam> (and I can't redirect to a file :)
<jam> dutchie: you have a view specified
<jam> which limits what files will be effected by commands
<jam> so you don't commit/etc files outside of that
<dutchie> how do I un-specify it?
<jam> I don't know *why* you have a view
<jam> but check "bzr view"
<jam> bzr view --delete --all
<dutchie> ok, thanks
<jam> or just
<jam> bzr view --delete
<jam> poolie: so if I do this: http://paste.ubuntu.com/355766/
<jam> the test suite passes
<jam> basically, it is just 'delay calling make_output_stream()' until we actually try to write the diff
<jam> and since 99% of the tests don't, and the ones that do already set everything up correctly
<jam> it works
<poolie> !!
<jam> lifeless: oh, and 'testr failing' doesn't exist... :)
<spiv> Good morning.
<jam> poolie: right, the failure is that the default ui is Silent which doesn't support make_output_stream
<jam> (especially when redirected)
<jam> this avoids trying to grab an output stream at all
<jam> (which is decent if it isn't going to be used)
<jam> poolie: btw, I don't think 'make_output_stream' is particularly clear on who is supposed to close it.
<jam> maybe I'm wrong
<lifeless> jam: yeah,  I'll write that one this afternoon :P
<jam> lifeless: so having a "testr load -v" would be nice
<jam> if it could do the progress bar stuff
<lifeless> Sure
<poolie> jam, so
<poolie> which test is this?
<poolie> jam, sorry, another call now
<poolie> istm that setting that globally will just make the diffs go to selftest's stdout
<poolie> which would be weird
<jam> poolie: 'bzr selftest -s bt.test_shelf' with salgado's patch
<jam> the code as written
<jam> always calls make_output_stream in ShelfUI's constructor
<jam> even if it never generates a diff
<poolie> oh i see
<jam> if a file isn't passed in
<jam> so the tests that did care about the diff
<jam> passed a file
<poolie> and there are some tests that assume that if it isn't going to create a diff, they can use the default ui
<poolie> i see
<jam> and ones testing the behavior made sure the factory was available
<poolie> ok i see
<poolie> so istm that if the tests want to install a Silent factory, it should probably discard output?
<poolie> that would be correct for these tests at least
<jam> poolie: for code that existed before make_output_stream, I think we would have just written to stdout
<mkanat> poolie: Hey, do you know of any really good ways to mirror a bzr repo back to CVS after each commit to bzr?
<mkanat> poolie: That's the only thing we really need help with, right now, for Bugzilla.
<jam> mkanat: you could look at a "post_branch_tip_changed" hook
<mkanat> jam: Yeah, I know what hook I'd use.
<jam> mkanat: then i would just have a co-located cvs repo and bzr repo
<mkanat> jam: What I was hoping to find was some code that already does what I want.
<jam> and the post-change hook would update & commit in a loop
<mkanat> jam: That's not possible.
<jam> not possible?
<mkanat> jam: Well, yeah, that's what I was thinking of doing, sort of.
<jam> oh, there was also a plugin a while back that provided a cvs *view* of a bazaar repository
<mkanat> jam: Yeah, but that won't work, for sure. :-)
<jam> so you could "cvs co :pserver:/path/to/bzr
<jam> but you couldn't commit to it
<mkanat> jam: I know, I wish I could just use bzrcvsserve.
<jam> mkanat: trying to allow commits to cvs *and* bzr *and* have the bzr commits auto-mirrored back to cvs are going to be a real pain
<mkanat> jam: There will be no commits to CVS.
<jam> mkanat: then what is wrong with cvsserve ?
<mkanat> jam: The path to the CVS repo can't change.
<jam> mkanat: so cheat
<chx> hi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well.
<mkanat> Basically, I need to copy the bzr repo's contents into a CVS directory, do "cvs add" in a loop until there are no more ? outputs, then do "rm; cvs rm" for any files that don't exist in the bzr repo, and then properly mark and binary files, and then get the log message, and then commit to CVS.
<chx> huh
<mkanat> And I need to do it for one bzr commit at a time.
<chx> hi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well. (sorryfor repea but it seems i asked in the middle of a netsplit)
<lifeless> chx: no, there isn't.
<lifeless> chx: I believe you can make a comment though, or description.
<lifeless> or something like that
<chx> yes but that's not something i can specify to bzr unshelve
<chx> but i guess i can write two handy lil shell scripts that fix this
<lifeless> chx: you could improve unshelve so that you could say unshelve --description bug-45
<chx> lifeless: that'd require me coding python :P
<chx> lifeless: some other time :)
<lifeless> its not contagious ;)
<chx> no but i do not have the time
<chx> last i tried it was a breeze to code python
<chx> so to quote Jeff Eaton, I am Py-curious :)
<lifeless> :)
<MFen> nice
<chx> yeah, last i tried (it was the first serious try really) i whipped a two way gateway in 40 min between skype and konversation....
<chx> messages travelling on d-bus :)
#bzr 2010-01-13
<lifeless> vila: still up?
<PureRumble> greetings, newb here failing to properly setup bazaar server on localhost.
<PureRumble> This is what I do to setup bazaar server: "sudo bzr serve --directory=files/servers/bazaar/ --bzr"
<lifeless> you probably don't want the server running as root
<PureRumble> See... I'm that bad. :-)
<PureRumble> I mean bad as in notknowing.
<spiv> PureRumble: I agree with lifeless, but that command should still work
<PureRumble> Ok, so I will not run as sudo. bad idea. bad idea! :-]
<PureRumble> Ok but there are still problems. So now I no longer run server as root.
<spiv> PureRumble: what problems?  What error are you getting?
<PureRumble> But still when I do "bzr push bzr://localhost/test" I get "bzr: ERROR: Transport operation not possible: readonly transport"
<spiv> PureRumble: right
<spiv> PureRumble: you need to explicitly pass --allow-writes to bzr serve if you want to allow that
<PureRumble> see, it's that easy! :-)
<spiv> PureRumble: (in which case it's a really good idea not to run it as root!)
<spiv> PureRumble: you may want to create a user on your system just for bzr serve
<PureRumble> Ok, I have now created my first branch! But right now anyone can connect to my server from the web (if it wasn't for ufw), right?
<spiv> PureRumble: connect, and write to!
<spiv> PureRumble: Why do you want to run a server?
<PureRumble> ok, so something tells me that is not good and needs to be taken care of :)
<spiv> You don't need one to create branches.
<PureRumble> Because, I thought it would be better than storing stuff in .bzr folders, but perhaps I'm wrong?
<spiv> You don't need a bzr server for that.
<spiv> If it's just you, locally, don't bother with bzr serve.
<spiv> Just run bzr directly.
<PureRumble> But then stuff would be stored in .bzr-folders, is that a good idea? *non-rethorical question*
<spiv> e.g. instead of "bzr push bzr://localhost/test", you can do "bzr push files/servers/bazaar/test"
<spiv> I'm not sure what you mean by .bzr folders.
<rockstar> How can I find out what revision a file in my tree was last changed?
<rockstar> I thought blame would do it, but that seems to be an alias for annotate
<bob2> bzr log -l1 filename ?
<rockstar> bob2, yeah, after typing that, I had to wonder if log would take a file as an argument, so I went to look.
<rockstar> bob2, cheers though.
<bob2> ahh
<spiv> PureRumble: I think maybe you're talking about the difference between a treeless branch and branch with a colocated working tree.
<idnar> is it possible to uncommit a revision that isn't the tip?
<idnar> actually, nevermind, I don't think I want to do that
<spiv> PureRumble: bzr doesn't really care either way; the full history is still stored.  If you want to make treeless branches directly then you can use e.g. "bzr branch --no-tree" or even better make a shared repository for your branches with "bzr init-repo --no-trees"
<spiv> idnar: good, because you can't (without also uncommitting the revisions between it and tip)
<PureRumble> I'll be honest and say my revision-controlling knowledge is not the best. I thought I would setup a bazaar server on my computer so I can manage code from anywhere.
<spiv> idnar: you can reverse the changes made by a particular revision, though.
<spiv> (and commit that)
<spiv> PureRumble: you can access bzr branches via SFTP and SSH
<spiv> PureRumble: you don't need a special bzr server to do that, just allow SSH access.
<idnar> spiv: that causes problems if you want to put the changes back later
<PureRumble> Ok, so having done bzr init, add and commit for some branch, how can I modify it from another host without setting up server?
<spiv> idnar: no more than the reversing
<lifeless> PureRumble: the most secure way is via bzr+ssh
<idnar> https://bugs.edge.launchpad.net/bzr/+bug/152008
<ubottu> Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Triaged]
<spiv> idnar: I'm talking about a cherrypick merge; e.g. "bzr merge . -r 99..98 && bzr ci -m 'Undo r99'"
<lifeless> PureRumble: install opensshd
<idnar> I believe that bug covers what I'm talking about
<spiv> idnar: right, including the merge . -r <backwards-revision-range> recipe.
<PureRumble> ... Ahaaaa, so you mean I should connect through opensshd and just navigate to the same dir and continue working?
<mmj8237> Hello, I did a bzr push before to a new location and noticed that it created a working tree at the new location when I didn't expect it to - is there an option for bzr push that prevents creating a working tree in the new location?
<bob2> that's the default
<chx> what happens if someone runs a bzr up on a checkout and someone else does a bzr uncommit...? the uncommitted changes disappear on next up?
<mmj8237> The documentation may be out of date, or maybe I have read it wrong, but I thought that bzr push wasn't supposed to update/create the remote working tree
<spiv> PureRumble: you can do that, but you can also use commands like "bzr branch bzr+ssh://yourhost/path/to/your/branch"
<lifeless> mmj8237: you pushed to a file:/// url
<spiv> mmj8237: "remote" in that context just means "connected via a network URL than a local file path"
<lifeless> mmj8237: they aren't 'remote'
<mmj8237> lifeless: yes it was a file:// url, though it was a mapped network drive with a kind of low disk space quota and I didn't expect a working tree...
<spiv> mmj8237: If it's a one-off, you can just remove the branch afterwards with the "bzr remove-tree" command.  If you're going to push several of these, maybe you want a shared repository made with "bzr init-repo --no-trees"
<PureRumble> ok so I'll install openssh-server... but will I need the client too?
<spiv> PureRumble: only if you need to connect to the server ;)
<mmj8237> spiv: thanks for your help.  Yep bzr remove-tree works, just wondering if there was another command, but it seems like there isn't.  Chosen not to use a shared repo for various reasons.
<PureRumble> I'm not very good at this, no not at all :-/
<spiv> mmj8237: yeah, we should probably add --no-tree to 'bzr push', 'bzr branch' had that added relatively recently.
<mmj8237> cool
<spiv> mmj8237: I'm a bit surprised that a shared repo isn't suitable given that you're concerned about disk space, but ok.
<spiv> mmj8237: file a bug? :)
<mmj8237> spiv: I am using stacked branches rather than a shared repo, I figure that if I delete a branch off that server it allows me to recover the disk space more easily than with a shared repo.
<mmj8237> Though if you had other suggestions I'd be all ears :)
<spiv> mmj8237: ah ok, interesting.  I would expect with most workflows that a shared repo would still be smaller than a collection of stacked branches.
<lifeless> poolie: http://rproxy.samba.org/ has a stale link to http://samba.org/~mbp/superlifter/
<spiv> mmj8237: because stacked branches inherently have a little bit of duplication with the repo they are stacked on, plus merges between them will require copying revisions around rather than just having one copy.
<PureRumble> So if the branch's absolute path is /home/foo/bar, do I do "bzr diff bzr+ssh://localhost/home/foo/bar" ?
<spiv> mmj8237: but I guess it depends on how much being able to completely delete unwanted revisions can save you space.
<lifeless> PureRumble: typically no
<lifeless> PureRumble: you generally only diff locally - 'bzr diff'
<PureRumble> ok but that was just an example.
<lifeless> PureRumble: but that url is correct
<PureRumble> Ok, it actually works! But a bit annoying to print the password each time I wanna do something.... :-/
<lifeless> PureRumble: you can use an agent to remember the password or passphrase (if you use ssh keys)
<mmj8237> After a quick bug search I filed a request for --no-tree on bzr push at https://bugs.launchpad.net/bzr/+bug/506730 - hope this is ok thx
<ubottu> Launchpad bug 506730 in bzr "Add --no-tree to bzr push" [Undecided,New]
<spiv> mmj8237: thank you!
<PureRumble> Ok thanks, so now things seam to be working smoothly.
<PureRumble> But how can I restrict what users can connect to my bzr server if I want to have such a server?
<lifeless> the plain bzr:// protocol doesn't have authentication or access control
<lifeless> if you need that, use bzr+ssh or bzr+http
<PureRumble> ok, but how does say launchpad work? They restrict who connects and gets to see the code, right? And they use bazaar servers, right?
<spiv> PureRumble: in your situation I'd just provide access via SSH, and then only users that can connect are the ones I've created accounts on my system for.
<lifeless> they use bzr+ssh
<spiv> PureRumble: and if you want to limit which of those users can read/write particular things, I'd use regular filesystem permissions to control that.
<PureRumble> spiv: but that would be a problem if the files happen to be on ntfs, right?
<spiv> PureRumble: I wouldn't think so, ntfs has file permissions too.
<spiv> ACLs even! :)
<spiv> (But I don't have much experience with managing ntfs from linux)
<PureRumble> yeah i knew that, i'm not that bad :-(. Just didn't think linux can modify them.
<PureRumble> General question: what do you suggest for managing php project (with revision control) remotely?
<PureRumble> I can set up apache on my host to connect remotely and test my code... but how can I work remotely on my code with revision control?
<spiv> PureRumble: maybe the bzr-upload plugin or the bzr-push-and-update plugin would help.
<PureRumble> Ok so bzr+ssh to retrieve files and modify and the upload back... but how to do build commands, such as ant, remotely?
<PureRumble> Pardon newbie questions.
<RAOF> Well, you could do that with ssh.
<RAOF> I'd also expect it to be relatively easy to write a server-side bzr plugin that ran your buildsystem for every commit.
<lifeless> or use e.g. hudson
<PureRumble> so much knowledge outside my brain, so little inside it! googling hudson
<lifeless> hudson-ci.org
<lifeless> PureRumble: thats for doing build testing
<lifeless> PureRumble: if you want deployment tools, you probably want to ssh into the server and then do a bzr pull; ant build  (or other sequence of commands)
<PureRumble> Ok some other general questions if I may: if I have hostA and another hostB, can I somehow map /foo/magic on hostA to /bar/magic on hostB safely through ssh? That would make things easy!
<PureRumble> hostA and hostB different computers connected to web.
<jacseen> I've run into a merge issue with bzr 1.16, a new branch on launchpad is listed on lp: as format 7, but bzr lists it as unknown. How do I upgrade my old branches so that htey can be merged into a local copy of version 7? My other branches are 'pack-0.92' and lp: calles them version 6.
<PureRumble> So like if I write some file to /foo/magic, ssh makes sure it is written remotely to /bar/magic on hostB.
<RAOF> jacseen: âbzr upgradeâ your branches.  You can do this on your local branches, and also remotely (âbzr upgrade lp:my-projectâ will work, but slowly).
<RAOF> PureRumble: You can do that (at least in linux), but why do you want to?
<PureRumble> So I can easily manage stuff remotely of course :-)
<chx> RAOF: Fuse (hence sshfs) exists for BSD too :p
<PureRumble> Look, I have my computer here at home and sometimes do coding on it. But sometimes I want to continue code on the same project but on my laptop.
<RAOF> chx: And I think MacFUSE exists, too :P
<chx> RAOF: not to mention the opensolaris port.
<jacseen> RAOF, just a noob question, how does bzr know what format to upgrade my 'pack-0.92' branches too? It doesn't even recognize the format of the version 7's as reported by launchpad?
<RAOF> jacseen: Bah.  Sorry, I should have read your question more thoroghly.
<AfC> jacseen: also, if you can upgrade to bzr >= 2.0 you'll find things work faster.
<chx> and Dokan on Windows.
<PureRumble> So that's pretty much my problem. I have a php project on my main computer, but sometimes I wanna work from my laptop... all in all without duplicate code of course!
<mac9416> AfC, how does one upgrade to bzr 2.0 in, say, Ubuntu 9.10?
<RAOF> PureRumble: ssh will do that, but I'm not sure why you're hung up on the âwithout duplicate codeâ.  I'd just have a branch on the main computer, and a branch on the laptop.
<AfC> mac9416: use the bzr PPA
<lifeless> jacseen: I think you need a newer version of bzr
<AfC> deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main
<mac9416> AfC, gracias.
<AfC> that has the latest stable release.
<PureRumble> RAOF: Help a guy that has been haunted by this for a while now and wanna sleep. :-( Say I've done bzr init, add & commit on some folder on main computer. That starts the branch there, right? I've also enabled ssh on it. Good.
<jacseen> AFAIK bzr 2.0+ uses a different default branch format (no complaint), how do I ensure all the branches in one project - most likely of an older format - stay in that format as I create new branches and do merges and stuff?
<PureRumble> Now what do you propose I do on laptop to continue working?
<RAOF> PureRumble: So, the next thing I'd do is push that branch up to launchpad, so it's easily available everywhere :).  If that's not what you want to do, then you can âbzr branch sftp://the-main-computer/path/to/that/branchâ on the laptop.
<cody-somerville> jacseen, create a repository to place all your branches in
<PureRumble> but if I'm not misstaken then when you create a new branch it will go its own way... unless you merge them, right?
<RAOF> PureRumble: Right.
<jacseen> cody-somerville, I never actually created a repo for my branches, the tutes didn't explain them. Do these repos force all branches inside them to remain the same format, or just affects the format of newly created branches(the main requirement)?
<RAOF> So, once you're done working on your laptop, you can either (a) âbzr push sftp://the-same-thingâ to push your changes to the main computer or (b) Merge on the main computer from the laptop
<PureRumble> But there would still be inconvenience if I'm working with php code, right? Because webserver is on main computer. I would have to pull/push on laptop and then connect to computer through http to verify each little change I wanna see, right?
<RAOF> Unless you run a webserver on your laptop, right.
<PureRumble> Yes but then it becomes a matter of keeping webserver configuration up-to-date too :). RAOF, lifeless, spiv thx for your help. I think I have enough to walk on from here.
<jacseen> Is there anyway to 'downgrade' a branch from a newer version to like 'pack-0.92' to maintain compatibilty across a whole project? Or must a person copy over the data files between the branches?
<spiv> jacseen: you can use 'bzr upgrade' to downgrade too
<spiv> jacseen: but not all downgrades are possibly, e.g. you can't go from 2a to pack-0.92 because 2a stores some data that pack-0.92 cannot represent
<jacseen> spiv by passing the format in cmdline. OK thanks
<jacseen> spiv that's what I was trying to confirm. Makes sense.
<jacseen> what is launchpad 'branch format 7' really in bzr terms?
<spiv> jacseen: the branch format used by the "1.6" format option and newer, but branch formats aren't much of a compatibility issue.
<spiv> jacseen: it's the repository format that is usually the problem
<spiv> jacseen: it might be a bit confusing because the command-line options actually refer to combinations of working-tree/branch/repository formats, but I think Launchpad just shows the individual branch and repository formats.
<jacseen> spiv and here I thought I had it almost figured out :P
 * igc heads off for a few days of holidays
<jacseen> thank you all for the added information, eventually I'll know everything again. :p
<mac9416> jacseen, then will come another big upgrade. :-)
<mwhudson> here's a quiz
<NfNitLoop> 42
<mwhudson> what's going on here: http://pastebin.ubuntu.com/355857/
<thumper> poolie: ping
<poolie> pong
<thumper> poolie: I have a bug
<thumper> poolie: see mwhudson's paste
<thumper> poolie: I'm trying to work out a summary
<thumper> poolie: the actual branches in the pastebin have moved
<thumper> poolie: but I have kept the branch for bug triage
<thumper> poolie: it is now lp:~launchpad-pqm/bzr-hg/broken
<poolie> if in doubt, file a bug with the exception and the innermost function name
<poolie> from -Derror
<thumper> ok
<poolie> with that stuff in the subject line, i mean
<poolie> and the tracebac in the description
<thumper> poolie: https://bugs.edge.launchpad.net/bzr/+bug/506777
<ubottu> Launchpad bug 506777 in bzr "InvalidRevisionSpec: Requested revision: u'281' does not exist in branch" [Undecided,New]
<poolie> ok
<poolie> thumper: is this urgent?
<thumper> poolie: no, I've worked around by making an unstacked branch
<poolie> high?medium?
<thumper> on the whole, it seems a little broken, so high
<thumper> but I also have that feeling about committing to a stacked branch
<lifeless> what, that you can't ? :)
<poolie> thumper: just in case jelmer did something weird in the history it might be useful to check that branch before pushing
<thumper> poolie: it works for an unstacked branch
<poolie> i'll have a bit of a poke at it
<thumper> lifeless: EPARSE
<lifeless> thumper: commit to a stacked branch.
<thumper> lifeless: as far as we are aware, if you have a stacked branch, you can't commit to it (except using a heavy weight checkout)
<lifeless> thats right
<thumper> we want to commit directly to the branch
<thumper> we now have at least two different use cases in LP for this
<lifeless> cool
<lifeless> would love to see that fixed ;)
<thumper> poolie: how do I go about increasing the priority of that?
<poolie> which one? commit to a branch or log?
<spiv> commit to a stacked branch (bug 375013) is already marked High, FWIW.
<ubottu> Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013
<jacseen> what does it mean when bzr claims a branch is 'format: unnamed'?  lp:~keryx-admins/keryx/devel/
<jacseen> from 'bzr info'.
<jacseen> what format should I use for a repo/branch in order to make it the same format to ease the merges?
<spiv> jacseen: try 'bzr info -v'
<spiv> jacseen: it just means that the combination of tree/branch/repo format doesn't match one you can name via the usual options (like --pack-0.92)
<spiv> jacseen: in this case,
<spiv> jacseen: --2a (i.e. the default format that bzr 2.0 creates) is fine
<jacseen> still 'format: unnamed'
<jacseen> alright
<spiv> jacseen: oh, in fact that is regular combination, and just affected by a bug to do with 'bzr info' over the smart server protocol
<spiv> jacseen: -v shows extra lines like "repository: Remote: Repository format 2a ..." for me, but maybe that's not in 2.0 (I'm using lp:bzr)
<jacseen> Oookaaay, I won't try to understand taht one yet
<spiv> jacseen: as a workaround, you can use 'bzr info nosmart+lp:~keryx-admins/keryx/devel/' :/
<spiv> jacseen: sorry about that bug
<jacseen> Format:
<jacseen>        control: bzr remote bzrdir
<jacseen>         branch: Remote BZR Branch
<jacseen>     repository: bzr remote repository
<spiv> Yeah, the 2.1 betas do a little better there.
<jacseen> my main concern is, will my branches in 2a format cause extra headaches when merging back into the branches upstream?
<spiv> jacseen: no, 2a is exactly the right format
<spiv> jacseen: that branch is in fact in 2a format
<spiv> jacseen: there's just a bug with bzr info that stops that from being obvious :(
<SamB_XP> jacseen: upstream of what ?
<spiv> jacseen: just to be clear, "upstream" here == lp:~keryx-admins/keryx/devel/, yes?
<jacseen> is that why my bzr 1.16 complained bitterly about rich-root when I tryed merging pack-0.92 into that one?
<jacseen> spiv yes on the upstream currently
<spiv> jacseen: yes, you can upgrade (and pull, merge, etc) from pack-0.92 into 2a, but not vice versa, because of rich roots.
<jacseen> hmm interesting, I thought I was going that direction
<spiv> jacseen: 2a is a much better format than pack-0.92 (not just because of rich roots), and it's the default in 2.0, so I definitely recommend using it unless you have a good reason not to.
<jacseen> on Keryx Project, lp:keryx, we were mainly using pack-0.92, but now with the admins changing/renaming the primary branches into stable/unstable, those are no longer in pack-0.92 it seems and is cuding slight conflicts when I try to branch them to have a local copy
<jacseen> but I upgraded to bzr 2.0.3, so now my branches are all 2a, so that should help my side
<spiv> Yes, sounds like it should :)
<spiv> Things should be faster now, too :)
<jacseen> spiv: great so now I have to finish rebranching all keryx branches and translate my code changes over. No problem. Solution found
<jacseen> spiv: thanks
<spiv> jacseen: you're welcome, glad I could help.
<poolie> hi spiv, all
<vila> hi all
<spiv> Hmm, I think I'm close to having a working NEWS file merge plugin.
<bialix> heya bzr
<spiv> Woo, it works.
<spiv> So, that's a useful proof-of-concept for the per-file merge hook.
<spiv> Also shows where things are a bit more cumbersome than necessary.
 * spiv submits
<spiv> Ok, merge proposal submitted.  I'm done for the day.
<poolie> cheerio spiv
<poolie> hope we see you tomorrow :)
<poolie> hi vila
<spiv> poolie: who knows! :)
<vila> hey poolie ! Thanks for your feedbackS on conflicts, replying now
<poolie> thanks
<poolie> i hope that didn't sound too critical
<vila> nope, never :)
<vila> The problem domain is complex anyway, so it's hard to find the small steps :)
<poolie> well, goodnight
<quicksilver> vila: good morning
<vila> good morning quicksilver
<vila> I think I read you had a solution but not what that solution was :)
<quicksilver> vila: I believe I have an approach which solves my problem.
<vila> quicksilver: and the approach is ?
<quicksilver> vila: after the manually fixed poison revision, proceed up the history tree of the old (poisoned) branch
<quicksilver> vila: for each revision which is merely a plain commit, use bzr replay to replay it.
<quicksilver> for each merge do the following:
<quicksilver> 1. bzr merge -r"revid:exact-revid-of-merge-source"
<quicksilver> 2. bzr revert . # discard those changes but keep them registered
<quicksilver> 3. bzr diff -rA.B.C..D.E.F > my.diff # get a copy of the diff which this merge should result in
<quicksilver> 3. patch -p0 < my.diff # apply most of it
<quicksilver> 5. for i in `egrep '^=== added' my.diff | awk -F"'" '{print $2}'`; do bzr add $i; done; # record the added files as added
<vila> That should work except for the renames
<quicksilver> 6. manually process any binary files added or changed using bzr cat (binary files don't get included in the diff)
<vila> and the binary files, yes, 'bzr shelve' should help if called at the right time
<bialix> spiv: cool! (re per-file merge)
<quicksilver> 7. egrep '^=== renamed' to identify any renames and process them by hand
<bialix> hi spiv, vila
<vila> hi bialix
<quicksilver> vila: I thought about bzr shelve but couldn't work out how to use it for this.
<quicksilver> vila: of course br bundle format would be ideal, but there is no way to say "act on the add/rename/modify directives in this bundle whilst ignoring the revids"
<vila> the poisoned revisions appears in the history of the branches you are merging from right >
<vila> s/>/?/
<quicksilver> vila: no, they don't
<vila> I don't understand why you do 2. bzr revert then
<quicksilver> vila: because the merge causes large, complex conflicts.
<quicksilver> vila: and the original developer resolved them
<vila> ha, yes, of course
<quicksilver> and I want to use his resolution, which lies in that diff.
<quicksilver> gah. Now I have a conflict in a plain replay. This means I made a mistake, I think
<quicksilver> oh well, it's getting more and more automated. I think I'll start again it will be faster now.
<vila> quicksilver: you should mail the list or file a bug against bzr-rewrite, we definitely needs that feature
<quicksilver> vila: maxb thought it might be possible with his branch of rewrite but I couldn't make it work.
<quicksilver> vila: this could easily be my fault :)
<vila> quicksilver: *how* you end up make it work is the interesting part :)
<vila> I'm sure maxb will be interested too :)
 * bialix hates such lame posts: http://community.livejournal.com/shlomif_tech/41922.html grr
<quicksilver> vila: I will mail the list once I've got it all sorted. This is something of a crisis right now though.
<vila> quicksilver: Sure, I understand that
<asabil> quicksilver, I think bzr-rewrite doesn't support what you need yet
<asabil> I started working on a bzr filter-branch command for bzr-rewrite a while ago, it only supported rewriting the commit messages and it never got merged
<asabil> you can also use bzr fast-export/fast-import
<asabil> they have the ability to filter out files
<quicksilver> vila: hmm. No. I think my method is unsound after all.
<vila> :-/
<quicksilver> vila: when I do "bzr revert ." after the merge that reverts the added files
<quicksilver> then when I readd them manually
<quicksilver> they are flagged as coming in in *that* revision
<quicksilver> rather than coming in in the revision they came in
<quicksilver> which means they conflict on the next merge.
<quicksilver> because bzr thinks they're different files.
<quicksilver> I think really I want to only revert the conflicted files.
<quicksilver> or, just bzr cat the conflicted files from the right revision.
<vila> hmm, yes, you should preserve the file-ids
<quicksilver> is there a way to instruct a merge always to give priority to OTHER?
<vila> if you have only text conflicts then bzr cat -rnnn FILE ; bzr resolve FILE, should to it
<quicksilver> bzr cat -rnnn FILE > FILE, you mean
<quicksilver> but yes
<vila> quicksilver: There is a merge proposal about that for tree shape conflicts: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785
<vila> but that doesn't address text conflicts where more cases are needed
 * quicksilver nods
<lifeless> quicksilver: you shouldn't generally do 'revert .' - because that *keeps* the record of the merge
<quicksilver> lifeless: but that's exactly why I'm doing it
<quicksilver> lifeless: I need to keep the record of the merge
<quicksilver> but I don't want to do the hard work to resolve the conflicts again
<quicksilver> so I want ot manuallly re-apply the previous conflict resolution.
 * rml waves at quicksilver
<quicksilver> vila: for i in `bzr conflicts | egrep '^Text conflict in' | awk '{print $4}'`; do echo $i; bzr cat -r"revid:$MERGEID" $i > $i; bzr resolved $i; done;
<vila> bzr pull --overwrite -r$MERGED ; bzr uncommit ; bzr shelve --all -m $MERGED
<vila> I think you can prepare the changes with that and then apply them after bzr revert .
<vila> bzr resolve --auto should then get rid of the text conflicts
<quicksilver> vila: I have a different approach, which is maybe equivalent.
<quicksilver> vila: suppose X.Y.Z is the revision which merges $MERGEID (and possibly fixes some conflicts or adds some more code)
<quicksilver> vila: first bzr merge -R"revid:$MERGEID"
<quicksilver> vila: then resolve all conflicts in favour of $MERGEID
<quicksilver> vila: now, bzr merge -rX.Y.Z
<quicksilver> vila: and that applies the new changes but it "notices" the $MERGEID is already merged and so that's OK.
<quicksilver> vila: seemed to work just now.
<vila> cool, you'll get X.Y.Z as an additional parent though
<vila> but that may be better to show where you add to tweak your history
<quicksilver> yeah, I don't really care about the extra parent
<vila> quicksilver: on the other hand if your merged branches are not poisoned why not just merged them as a whole ?
<quicksilver> the general soundness is more important )
<quicksilver> vila: because of the conflicts?
<vila> ha, hmmm, yeah, hard to tell from here if resolving them once is enough or if each branch brings its own set, so yeah 'bzr resolve --take-theirs' ftw
<vila> this is a case where you *knwo* you want the conflicts resolved in your wt as they were resolved in the merged branch, without thinking about it
<vila> s/knwo/know/
<quicksilver> ah bother, it didn't work with file add/rename conflicts
 * quicksilver backtracks and thinks again
<vila> quicksilver: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 *implement* --take-theirs for add/rename conflicts !
<quicksilver> yes, I saw it.
<quicksilver> "bzr merge -rX.Y.Z" is a bad idea.
<quicksilver> it brings the poison back in.
<vila> ha, so the poison is in the other branches too then
<quicksilver> no, X.Y.Z isn't the "other" branch
<quicksilver> X.Y.Z was the bad branch anyway
<vila> how about 'merge -cX.Y.Z' then ?
<quicksilver> oh, I didn't know about that one
<quicksilver> what does  -c do? the help page isn't very detailed :)
<vila> I'm unsure about it in your particular case :) It's supposed to bring only the changes in the specified revision
<quicksilver> vila: bzr merge -cX.Y.Z gives bzr: ERROR: exceptions.AssertionError: Unknown kind 'relocated'
 * vila bangs head on desktop
<vila> 2.0.1 right ?
<quicksilver> 2.0.3 actually
<quicksilver> upgraded yesterday whilst tearing hair out
<vila> ha, gee, I thought I went in the twilight zone for a second, I was sure we had the reverse conversation yesterday :-D 2.0.3 ? 2.0.1 actually
<vila> I'm 60% sure some bugs has been fixed in at least bzr.dev and may be bzr-2.1betaxx
<vila> but anyway, did you try the pull/uncommit/shelve trick ?
<vila> It's supposed to record the actual changes for each revision so you'll get a poor-man replay, you can still insert some merge/revert . to set the parents
<quicksilver> vila: No. I think I'll try that next.
<vila> quicksilver: remember that shelve is tight to the wt so be ready for some pull --overwrite to set the right wt or to copy/move the .bzr/checkout/shelf directory in the right place
<quicksilver> vila: "wt" ?
<vila> working tree
 * quicksilver nods
<quicksilver> but pull --overwrite complete nukes my branch history?
<vila> nukes is a bit strong :) It makes your branch history the same as the one you're pulling from
<vila> and also updates the wt
<quicksilver> vila: but I don't want to lose the branch history, do I?
<quicksilver> or are you suggesting a use an auxiliary working tree and merge between
<vila> yup, when in doubt, always use a scratch monkey
<quicksilver> vila: in particular, a bzr pull --overwrite will pull the poison back in.
<vila> yes, but it shouldn't pollute the shelved changes
<vila> when all your changes are ready, you can then, bzr pull --overwrite -r<clean_revno> ../<dirty branch> and start from there
<vila> pull --overwrite -rrevno, gives you a branch and a  working tree exactly as they were after the commit that created revno
<quicksilver> something in the help page for shelve implies that it only applies to text changes though
<quicksilver> so it won't fix my rename / binary problems?
<vila> if you uncommit/shelve, you should get unpoisoned changes from that
<vila> file a bug about that, shelve in bzr -core was rewritten from scratch to address shel from bzrtools relying on patch
<vila> if you get the wrong impression there, the doc should be fixed
<quicksilver> Right.
<quicksilver> So, I need one shelf per merge?
<quicksilver> uncommit each merge point to a shelf
<quicksilver> then pull a clean revision
<quicksilver> and unshelve one merge at a time
<quicksilver> well, (bzr merge ...; bzr revert.) to set the parent
<quicksilver> and then unshelve the shelved version of the merge changeset on top
<vila> that's the idea
<quicksilver> do shelves show up as a single change
<quicksilver> or do they look like a merge?
<vila> think of shelves as you think about patches
<vila> you add or subtract them from a working tree, no merges or commits are involved
<quicksilver> so I still want to replay the non-contentious revisions
<quicksilver> if I want to keep as much of the history as possible
<vila> be careful to not bring back poisoned revisions though, even if the poisoned file is not in your mainline revisions setting a poisoned revision as a parent will still reference it in the repository
<vila> so while you can get back the changes from the poisoned branches, you can't get their full history
<quicksilver> yup
<quicksilver> well replay makes new revisions, it doesn't reference poisoned ones
<quicksilver> I guess replay is a bit like the uncommit/shelve/commit trick for a single revision.
<vila> yup, simpler, otherwise you have to come up with some mapping for the merged revisions
<quicksilver> vila: right. So basically your point is that shelves > diffs, because shelves can include renames and binary files etc.
<quicksilver> vila: that makes sense but I kind of coped with renames and binary files anyway although it was a little painful.
<quicksilver> vila: however it *doesn't* solve the file-id problem for added files.
<quicksilver> (bzr merge -r$MERGEID; bzr revert .) is broken because it loses the file-ids for files added in that merge.
<quicksilver> similarly, if you shelve an uncomitted merge, you lose the file-ids, surely?
<vila> no, shelve should preserve the file-ids
<quicksilver> ah, OK
<quicksilver> in that case perhaps I can see how to make this work
<quicksilver> using two branches
<quicksilver> I mean, two working trees
<quicksilver> one working tree stays clean and I replay along it for the simple revisions.
<quicksilver> when I get to a merge, I use a dirty working tree to pull to the merge, uncommit it, shelve it
<quicksilver> then pull --overwrite to get the *clean* tree in
<quicksilver> and unshelve that merge
<quicksilver> vila: is that what you suggest?
<vila> err, no, I suggest preparing all the shelves  first in wt-dirty, then move them to wt-clean and apply them there when needed
<vila> but you get the general idea yes
<vila> quicksilver: lunch time here, I'll be back in ~1 hour, anything urgent before ?
<maxb> Under what circumstances does bzr-svn need to build a fileidmap-v3.knit ?
<quicksilver> vila: no, thanks for all your help
<vila> quicksilver: youre' welcome, keep giving feedback
<quicksilver> vila: of course, each time I branch/pull a bad revision it takes ages and uses up all my machine's memory, but that's life I suppose
<quicksilver> vila: when trying to shelve a complex merge : bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-150')]
<quicksilver> vila: even if I commit and uncommit it's no better
<quicksilver> apparently some kinds of change can't be shelved...
<quicksilver> and to whoever it was who was suggesting fast-export
<quicksilver> I read that fast-export / import roundtrip discards file-ids
<quicksilver> so that's not the answer
<quicksilver> although I read some bug reports to suggest it *does* have file-ids
<quicksilver> hmm
<quicksilver> well, I'll try it.
<vila> quicksilver: you got malformed transform while shelving a wt without conflicts ?
<quicksilver> vila: yes.
<vila> quicksilver: internally shelve is supposed to serialize an intermediate representation that supports everything bzr support (bar conflicts and pending merges I think)
<quicksilver> ah well there was a pending merge.
<quicksilver> but that's the point of what I'm doing isn't it
<vila> hmm, no, you want only the changes themselves, not the parents or at least not the poisoned ones and you're supposed to fake the others anyway
<quicksilver> well, this wasn't a poisoned one.
<quicksilver> but how do I get the changes from a merge without the pending merge?
<quicksilver> you said to go to the next revision, uncommit, and shelve :)
<quicksilver> if I do that, I have a pending merge
<vila> pull --overwritw/uncommit/shelve
<quicksilver> yes, but if the thing I uncommit is a merge
<vila> oh, wait
<quicksilver> then I have a pending merge after the uncommit
<quicksilver> naturally.
<quicksilver> incidentally, bzr fast-export eventually runs out of memory and dies.
<vila> pull --overwritw/uncommit/bzr revert --forget-merges/shelve
<vila> sorry about that, silly me :-/
<quicksilver> ah
<quicksilver> I also had a problem where pull --overwrite pivoted the tree
<quicksilver> so that uncommit did the wrong thing
<quicksilver> so I had to re-merge to get the right "mainline"
<vila> pull --overwrite always does that, it really puts you into the state when the revision was committed
<quicksilver> I know
<quicksilver> I understand why, I was just remarking
<quicksilver> because the tree I'm recovering is a far-right branch
<vila> I find qlog really helpful for that
<quicksilver> occasionally I need to pivot the line
<quicksilver> but that's OK, I'm used to this.
<quicksilver> I'm still getting bzr: ERROR: Tree transform is malformed
<quicksilver> even after a --forget-merges
<vila> oh, ok, hard to visualize from here :-//
<quicksilver> so I have a bunch of uncommitted changes in my 'dirty' wt
<quicksilver> they are essentially the changes corresponding to a merge
<quicksilver> but they have forgotten about the merge
<quicksilver> because I did --forget-merges.
<quicksilver> and I still can't shelve them :(
<vila> that's weird, shelve and commit are supposed to use the same code... can you commit ?
<quicksilver> Yes, I can
<quicksilver> I tried commit/uncommit at one point
<quicksilver> just to make sure nothing odd was doing on
 * quicksilver does it again
 * vila bangs head on desktop again
<quicksilver> Yup.
<quicksilver> I can definitely commit fine.
<quicksilver> and after I comment "bzr st" says the tree is clean
<quicksilver> (that is, it says nothing)
<quicksilver> and I can uncommit again, and shelve crashes again :)
<vila> uncommit/shelve from there ?
<quicksilver> yes, I just did. It crashes.
<vila> anything suspicious in bzr st ?
<quicksilver> 10 files removed, 40 added, 1 renamed, 80 modified
<quicksilver> nothing out of the ordinary though
<quicksilver> although it certainly is a big merge
<vila> haystack...
<maxb> I think the best way to do this would be to fast-export | fast-import *JUST* the changes after the poison revision
<quicksilver> maxb: fast-export crashes on all poisoned revisions.
<quicksilver> maxb: the poison is too much for fast-export to take.
<maxb> ugh
<maxb> How many poisoned revisions are there, about?
<vila> quicksilver: you've got quite an assassin in your team...
<quicksilver> Python(43161) malloc: *** mmap(size=691982336) failed (error code=12)
<quicksilver> *** error: can't allocate region
<quicksilver> *** set a breakpoint in malloc_error_break to debug
<quicksilver> bzr: out of memory
<quicksilver> maxb: just one.
<maxb> And are there valuable changes in the same revision as the poison?
<quicksilver> yes
<maxb> :-/
<quicksilver> but I reconstructed that one revision by hand easily enough
<quicksilver> bzr uncommit; bzr rm big-file; bzr commit -m"<copy-paste-long-commit-message>"
<quicksilver> that was the easy bit.
<quicksilver> the hard bit is replaying the future.
<maxb> Right, well what I would do is to branch just before the poison. Manually reconstruct and recommit that one rev. And fast-export / fast-import the subsequent revisions
<quicksilver> you can fast-export just a revision range?
<quicksilver> I didn't know that.
<vila> argh, I thought that was the failing run !
<maxb> In order to make fast-import append to an existing history, it's likely going to be necessary to use --export-marks and --import-marks with manual editing of the revid in the marks file
<maxb> Also you're likely going to have to fix up the marks file because of a bzr-fastimport bug, where fast-import and fast-export use slightly different syntax in their marks!
<quicksilver> vila: ?
<vila> I thought you tried fast-export with a range and it crashed, it's worth a try I think (but no first hand experience with it here)
<quicksilver> maxb: well, fast-export with a range is certainly very fast.
<vila> maxb: the file-ids will be preserved right ?
<maxb> I'm hoping they will for existing files
<maxb> Which should be good enough
<maxb> I admit to not really being sure
<quicksilver> I don't see any file-ids in the .fi file
<maxb> Correct
<quicksilver> maybe I'm looking in the wrong bit
<maxb> I'm hoping that it will necessarily have to match onto the existing files by path
<quicksilver> well some of the conflict resolution at merges is where files collide
<quicksilver> so the resolution to the conflict is to rename one
<quicksilver> so it's pretty import to preserve that part of conflict resolution.
<maxb> Ah. I have no idea how well that will work, then
<maxb> I don't know enough about the guts of fastimport to understand what it will do here
<quicksilver> well no harm trying it
<vila> quicksilver: everybody involved in on OSX ? (Trying to rule out some path encoding problems)
<quicksilver> I have the fast export file.
<quicksilver> vila: no, mixture of OSX/linux
<quicksilver> vila: although the author of the problem branch is on OSX and so am I
<maxb> quicksilver: Did you --export-marks=somefilename?
<quicksilver> maxb: yes.
<quicksilver> maxb: just making a branch of the "manually fixed-up" revision to try to import into.
<maxb> quicksilver: I think that two manual edits to the marks file will be needed
<maxb> First, check whether all the data lines (line 3 and onwards I think) start with a colon. If they don't, it's a bug, and you'll need to edit to fix that
<quicksilver> no, they all start just with a number
<quicksilver> add colons to all?
<maxb> Yes
<quicksilver> done
<maxb> Second, if you look at the first commit in the .fi file, and see what its "from :XXX" line says - and then change the corresponding mark's revid to be the revid of your un-poisoned revision that you want to play history on top of
<quicksilver> (hurrah for C-x r t)
<vila> quicksilver: hehe
<maxb> (also hurrah for vim visual block mode :-) )
<quicksilver> there isn't a from
<vila> C-x r : useless until you need it and soooo nice then
<quicksilver> the second commit is "mark :2" and "from :1" but the first commit has no from line.
<maxb> quicksilver: umm?! No from, no merge :XXX either?
<quicksilver> nope
<quicksilver> commit, mark, committer, data, (the commit message) and then the actual changes start
<maxb> Oh, on an unrelated note, you probably want to export with --no-plain
<maxb> OK, change of idea re the marks
<maxb> *Add* a line reading "from :1000000" to the initial revision
<maxb> *Delete* all the data lines from the marks file, and replace them with one saying :1000000 revid-of-revision-that-should-be-new-parent
<quicksilver> hmm ok
<quicksilver> 13:40:25 Starting import of 50 commits ...
<quicksilver> ABORT: exception occurred processing commit :1
<quicksilver> bzr: ERROR: exceptions.KeyError: ':1'
 * rubbs is confused... is repository surgery being performed?
<quicksilver> rubbs: sadly not.
<quicksilver> rubbs: would like to, though.
<vila> rubbs: kind of, lossy rebuild instead
<quicksilver> vila: the reason I did a full fast-export the first time around, by the way, is that I read this is actually a documented purpose of fast-export ;) -x to exclude a CD image added in error.
<quicksilver> vila: not much use if it gives out of memory when processing the file though.
<quicksilver> and I have a suspicion it will kill all the file-ids making it unmergeable.
<vila> bug filing time again :-/
 * quicksilver doesn't even know which parts of what's going on are bugs.
<quicksilver> presumably the uncommit which I can't shelve is a bug.
<quicksilver> I think I'm going to have to revert to slow replay approach.
<rubbs> ah... gotcha... I'll just sit back and watch. This is fasinating(sp?)
<vila> that's one yes, abentley may have an explanation about what kind of change can be committed but not shelved
<vila> fast-export blowing out memory may be one too (but it may be a dupe of the one you get with bzr itself)
<quicksilver> yes
<maxb> quicksilver: What's the first occurrence of :1 in your fi file?
<quicksilver> and some operations don't crash
<quicksilver> (which is just as well, because otherwise this branch would be totaly useless)
<quicksilver> some operations give the memory error but still succeed
<quicksilver> which I find fairly mysterious.
<quicksilver> maxb: mark :1 near the top
<maxb> huh
<quicksilver> maxb: line 5, after 3 "feature" lines, and one "commit" line
<vila> quicksilver: As said yesterday, 2.1 fixed several memory issues, that could help
<maxb> quicksilver: pastebin the stacktrace?
<vila> quicksilver: quick check, you still use *only* 0.92 branches right ?
<quicksilver> maxb: http://pastebin.com/d6f95e4cf
<quicksilver> vila: these fastimport tests are in a 2a branch
<quicksilver> vila: in fact, probably all the fixup work has been in a 2a branch
<quicksilver> one of the first things I did was upgrade the branch
<quicksilver> because, initially, I thought that might solve the problem.
<vila> ok
 * vila strike yet another cause
 * maxb confused, sorry
<maxb> afk for a bit
<quicksilver> if 2.1 fixes bzr-fastexport so that it works even on the huge file, then one solution would be to bzr-fastexport *all* my branches, including the non-poisoned one
<quicksilver> and then reimport them all, thus retaining their relationships
<quicksilver> (using -x to remove the bad file at export time)
<quicksilver> but that's a big if.
<vila> yeah :-/
<quicksilver> vila: OK, in the absence of other smart ideas, I'm going to return to "replay, remerge, and carefully re-resolve conflicts"
<quicksilver> I may even use rsync.
<vila> without looking at your data, it's hard to understand what makes shelve crash :-/ rsync/bzr st/bzr diff should help you validate your changes...
<quicksilver> vila: I'm inclined to guess that fixing shelve is not the shortest path to my solution ;)
<vila> fixing it now, working around the problem, may be...
<vila> s/now/no/
<vila> or... bzr pull -overwrite -r<some revno> in wt-dirty ; cd wt-clean; bzr merge ../wt-dirty ; bzr revert --forget-merges ?
<vila> hmm, will not allow you to set the parents...
<quicksilver> that is essentially what I've been doing, yes.
<quicksilver> except I didn't bother to pull --overwrite wt-dirty
<quicksilver> I just specified the -r in the bzr merge
<quicksilver> since it's sufficine for <revno> to excist somewhere in wt-dirty's history to be able to merge it.
<vila> yeah, sorry looping :)
<quicksilver> I'm running bzr reconcile in both working trees on a hunch
<quicksilver> although I'm pretty sure I did that yesterday
 * vila discovers hunch meaning in that context...
<maxb> Personally I think the best way to resolve this would involve hacking on bzr-rewrite until replay could actually follow a branched history
<vila> maxb: sure
<vila> bzr-rewrite or fastexport, but we definitely needs a nuke-that-file-yes-I-know-my-history-will-change command
<doctormo> if remote_branch.bzrdir.spout is used for doing a typical `bzr branch` to get code for modification, what's the equiv code for `bzr checkout` with the lightweight option?
<Kinnison> remote_branch.create_checkout(targetlocation, revid, lightweight, acc_tree, hardlink)
<Kinnison> appears to be the critical bit of bzrlib/builtins.py:cmd_checkout():run()
<quicksilver> vila: OK, I was wrong about one thing. My dirty-wt was in knit format.
<quicksilver> vila: whilst my clean wt was in CHKCHK format
<quicksilver> vila: do you think that might have been relevant to anything?
<vila> quicksilver: well, numerous differences between 0.92 and 2a, so worth retrying the shelve with 2a
 * quicksilver nods
 * vila crosses fingers
<quicksilver> I note that reconcile is pretty fast with knit and dog-slow with chkchk
<quicksilver> the two chkchk reconciles I started are still running.
<vila> the later is doing far more checks
<quicksilver> and they've both hit the out-of-memory error
<quicksilver> even the so-called clean one
<quicksilver> but even that clean branch has poison in its *repository*
<quicksilver> just not in a reference revision.
<quicksilver> so if reconcile touches the non-referenced revisions, that's not surprising.
<vila> it is
 * quicksilver wonders how long bzr upgrade will take in the poisoned repo.
<doctormo> thanks Kinnison
<vila> quicksilver: you can try to branch in repo that already contains the poisoned revision...
<quicksilver> vila: do you think it matters if it's an 'unnamed' combination as long as the repo format is rich root/group cmp/chk inventories?
<quicksilver> oh, it's done anyway.
<quicksilver> good
<vila> hmm, I don't think so
<quicksilver> vila: bzr: ERROR: Tree transform is malformed
<quicksilver> so even in 2a, this merge is unshelvable
<vila> damn
<quicksilver> so, back to plan D. Merge carefully, resolve conflicts carefully. *sigh*
<vila> quicksilver: can you keep that unshelvable tree somewhere ?
<quicksilver> vila: I have around 50 copies of it so far :)
<quicksilver> vila: it seems unlikely I'll lose them all.
<vila> :-) :-/
<teknico> hi esteemed colleagues, everyone :-) got a problem with bazaar, not sure what's going on, any ideas? https://bugs.launchpad.net/ubuntuone-storage-protocol/+bug/506974
<ubottu> Launchpad bug 506974 in ubuntuone-storage-protocol "Bazaar traceback when running "make link-sourcedeps"" [High,Confirmed]
<vila> teknico: did you run 'bzr check' ?
<teknico> vila, no, I'll do it now in a number of places :-)
<vila> teknico: also the 'No handlers could be found for logger "bzr"' is... unexpected and may indicate that you can't write to $HOME/,bzr.log which in turn may contain relevant information about the problem
<teknico> vila, .bzr.log is regularly written to, I looked at it, it doesn't record anything when there's one of those crashes
<vila> anything relevant or anything at all ? You should at least find your commands there
<teknico> vila, yes, I meant in that specific cases, it records output for all other commands
<teknico> in *those specific cases
<vila> sorry, I should be dumb, you mean it doesn't record that command (but it records all the other ones ?)
<vila> teknico: ^
<teknico> vila, yes, that's what I was trying to say, sorry :-)
<vila> that means bzr is running under a different uid ? SO maybe it *can't* write to the repo leading to the error
<teknico> vila, different uid? no, why do you say so?
<vila> teknico: if it can't write to .bzr.log, something weird is going on like running under a different uid, but there may be other causes
<teknico> vila, bzr does write to .bzr.log, except when it crashes, it doesn't, but it seems only natural :-)
<vila> teknico: not at all natural, every command is logged far before a crash can occur
<teknico> mmm
<vila> teknico: what is utilities/link-external-sourcecode ? (first line in the traceback)
<vila> oh wait, you're using bzrlib directly ?
<vila> teknico: does your script calls bzrlib.trace.enable_default_logging() ?
<teknico> let me check that script
<vila> morning jam ;D
<jam> morning vila
<teknico> vila, no, it doesn't
<jam> teknico: then it won't write to ~/.bzr.log :)
<jam> good catch, vila
<vila> jam: do you have any idea why a 'bzr uncommit' followed by 'bzr shelve' may crash with bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-150')] ?
<jam> vila: well, shelve doesn't handle stuff like changing the tree root id
<jam> I don't know of other specific reasons
<jam> the error above looks like it is trying to remove an empty file?
<vila> something related yes, quicksilver does that rings a bell ?
<quicksilver> I think there might have been an empty directory
<quicksilver> I don't think there were any empty files.
<quicksilver> what is the best way to get the file-id of a file?
<vila> yeah, better, an empty file *can* be versioned right ?
<quicksilver> (am now trying to follow through my conflicts)
<vila> quicksilver: ready to dive into pdb ?
<vila> oh, for conflicts that's different
<vila> bzr st --show-ids ?
<quicksilver> bzr st doesn't seem to say anything about untouched files
<quicksilver> which is annoying
<quicksilver> it will tell me the ids of modified or renamed files, yes
<vila> why would you want to know the file-id otherwise ?
<quicksilver> so I can work out how a conflict was resolved
<vila> bzr st -r<right parent>..<trunk> --show-ids
<quicksilver> it's just one particular files I want the id of
<quicksilver> (well, two)
<quicksilver> so I can see which copies got kept and which got renamed.
<quicksilver> I'll just md5sum them :P
<vila> going tricky are you ? bzr st -r<right parent>..<trunk> --show-ids FILE
<jam> quicksilver: bzr inventory file --show-ids I believe
<jam> or "bzr ls --show-ids" if you can use that
<quicksilver> bzr ls only works on directories apparently
<jam> I think it is supposed to work on more, but is broken for files on Windows at least
<vila> quicksilver is on OSX
<quicksilver> bzr inventory works :)
<quicksilver> thanks jam.
<vila> jam: can your fix for #494269 be relevant for a case where shelve crashes while commit works ?
<jam> bug #494269
<ubottu> Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269
<jam> vila: its a possibility
<jam> commit can handle root-id changes
<jam> however, revert pull and update *didn't* either
<quicksilver> jam: what's a root-id change?
<quicksilver> how can I deduce whether it applies to my case?
<jam> quicksilver: it is when the file id assigned to "" changes (the root of your tree)
<jam> it is unlikely to be the case
<jam> but if you did "bzr init" 2 times in different directories, and then tried to merge those branches
<quicksilver> ah, I don't think so, no.
<jam> it could
<quicksilver> nope, never did that.
<quicksilver> this was just a commit which was a big merge
<quicksilver> (including additions, deletions, renamings and modifications)
<jam> quicksilver: you're the one hitting "versioning no contents" ?
<quicksilver> yes
<quicksilver> I can commit/uncommit it merrily as many times as I want
<quicksilver> but I can't shelve it
<quicksilver> which is a shame, because vila's evil hack for replaying merges on an alternate history depends on copying shelves around.
<jam> I just suspect a bug in the shelve code, not passing something along to the transform
<jam> specifically, that happens
<jam> if we call "create_path()" but no "create_contents()"
<jam> (or create_directory, etc)
<jam> I don't know exactly how to reproduce, but I'll poke around a bit
<jam> in the meantime, sounds like a bug :)
<quicksilver> unfortunately I don't know exactly how to reproduce without giving the repo which I'm not at liberty to do :(
<jam> quicksilver:  it also sounds a little bit like it would involve a file or directory which is deleted in the tree
<jam> quicksilver: you could at least give the output of "bzr status -r -2..-1" after the commit
<jam> so we get an idea of what delta the shelver is trying to undo
<jam> poking around the transform code, the number of places where it would look up the data is pretty convoluted
<jam> so having a reproducible test case would help tracking down where the bug is
<vila> jam: it's an uncommit after a merge, 'bzr st' alone should be emough no ?
<vila> yeah emough :)
<jam> vila: uncommit + status should be equivalent to commit + status -r -2..-1
<jam> Except I don't think the latter mentions pending merges...
<vila> oh yes, missed the context
<jam> and adding a pending merge could certainly complicate things
<vila> jam: quick silver is trying to shelve the changes that represent the merge + the conflicts resolution though which complicate things
<jam> vila: certainly. I'm pretty sure it is just an edge case that we aren't handling correctly.
<jam> I'm guessing it is a bug in shelver
<jam> though, tbh, uncommit/commit don't invoke TreeTransform either
<jam> a better test is
<jam> bzr commit
<jam> bzr branch -r -2 ../other
<jam> cd ../other
<jam> bzr pull ../orig
<jam> since that requires applying the transform to the working tree
<jam> though I would be pretty surprised if that failed
<jam> then
<jam> bzr pull ../orig -r -2
<jam> which backs out that change
<jam> oh
<jam> you need
<jam> bzr pull ../orig -r -2 --overwrite
<jam> (so that it actually steps backwards)
<vila> yeah, sounds like what quicksilver is doing, then, bzr uncomit and from there commit works shelve crashes
<teknico_> vila, "bzr check" pointed out another problem, not sure it's related though: https://bugs.launchpad.net/bzr/+bug/507040
<ubottu> Launchpad bug 507040 in bzr "Crash during "bzr check"" [Undecided,New]
<vila> teknico_: the missing antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz is from 2009/04/20, any conversion since then ? Any stacked branch involved ?
<teknico_> vila, yes, we converted the repo to 2a format a few months ago, and yes, that repo is a top stacked one
<vila> teknico_: can you attach the relevant .bzr.log part to the bug ?
<teknico_> vila, there's only the same traceback that's already in the crash log
<vila> teknico_: is it the same repo than bug #506974 ? Oh damn, I thought check outputs more details in .bzr.log
<ubottu> Launchpad bug 506974 in ubuntuone-storage-protocol "Bazaar traceback when running "make link-sourcedeps"" [High,Confirmed] https://launchpad.net/bugs/506974
<vila> teknico_: and is it the only repo failing the check ?
<teknico_> vila, no, it's not the same repo, and the check stops at that error, no other errors previously
<vila> teknico_: can you do 'bzr st -c revid:antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz' ?
<teknico_> vila, output: bzr: ERROR: No WorkingTree exists for "file:///home/nl/canonical/ubuntuone/.bzr/checkout/".
<vila> meh, can you do it from a working tree ? Or do 'bzr diff -c revid:antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz' instead ?
<vila> I'm just trying to verify if we can access that revision one way or another
<vila> s/verify if/verify that/
<teknico_> now it's: bzr: ERROR: Not a branch: "/home/nl/canonical/ubuntuone/.bzr/branch/".
<teknico_> it's the top of a stacked repo, there's no working tree of it
<NfNitLoop> Hrmm, is Hrmm, is 'bzr svn-push' now just 'bzr push <svnURL>'?
<vila> teknico_: there should be some branches below, go in any of them, I can't see which one is involved (that may be in .bzr.log though)
<teknico_> vila, the error in #507040 is in the top repo
<teknico_> however, I'm more interested in the error in #506974
<vila> teknico_: can you explain your layout a bit ? Are all your branches sharing the same repo with branches stacked on different branches ?
<NfNitLoop> Hrmm, is there a way to see a log of the pending merges?
<vila> teknico_: did you had the bzrlib.trace.enable_default_logging() call to your script ? Did that outputs something in .bzr.log ?
<teknico_> vila, no, the script does not call that
<vila> NfNitLoop: 'bzr st -v ' ?
<vila> teknico_: can you add it then so we know what it is trying to say when the 'no loggers found' message is emitted ?
<teknico_> vila, I have a top ubuntuone stacked repo, and below it there's trunk, and other branches branched from trunk
<teknico_> the error in #506974 is in a completely different repo
<NfNitLoop> vila: that shows me a one-line summary of the commit messages...
<NfNitLoop> not the full commit.  Nor the files changed in that commit.
<NfNitLoop> I sortof want 'bzr log -v' behavior, but on the commits I merged in.
<NfNitLoop> but they hvaen't been committed locally yet, so they don't seem to show up in bzr log.
<vila> NfNitLoop: is 'bzr qlog' an option ?
<NfNitLoop> Oh well.   I know where they occurred in the source branch so I just did bzr log on that.  But if history had been odd, that would've been a pain. :p
<teknico_> vila, thanks for the help, I have to go now
<vila> teknico_: update the bugs if you collect more info
<teknico_> vila, I will
<NfNitLoop> qlog is nice.  Though, will it show pending merges?   *Shrug*  too late, already committed. :p
<NfNitLoop> Sooo glad I got bzr-svn working with our repo. :p
<jam> vila: what is the status of https://code.edge.launchpad.net/~kamil-szot/bzr/non-ascii-chars-in-ftp-filenames/+merge/17012
<jam> I'd like to knock it out of the review queue, but are we waiting for feedback from kamil?
<jam> vila: also, can you give a second review on https://code.edge.launchpad.net/~nmb/bzr/script-test-mv/+merge/17269 ?
<vila> jam: I think it's fine putting kamil's mp to wip while waiting for feedback
<jam> well, I'm thinking it really needs "Rejected" since we fixed it a different way
<jam> (that way WIP doesn't get full)
<jam> I hesitate to wield the big hammer, though
<rubbs> NfNitLoop: if you do a qcommit rather than commit it will show pending merges.
<vila> yeah, then a comment explaining that it's rejected because the tried approach is not appropriate then to make the hammer softer :D
<vila> NfNitLoop: yes it shows pending merges, I use it a lot when merging up to copy/paste part of the commit messages
<jam> vila: well, I'd like confirmation that upload + ftp is actually fixed
<vila> jam: the test I *added* to bzr-upload should cover that for bzr-core, all the transport methods used there are now covered
<vila> jam: I (wrongly) relied on bzr test suite for the first patch
<jam> vila: what is the missing bzrlib test ?
<jam> It sounds more like bzr-upload was supplying an invalid path
<vila> it was suppyling unicode paths instead of urlutils.escape()'d paths
<jam> which, tbh, was probably part of the original design (4?) years ago
<jam> I spent a lot of time making Transport work with non-ascii
<jam> only to end up with us never using it in bzrlib ...
<vila> so there are no missing tests in bzr since we use ascii paths... wait... we *may* add more tests that we support unicode paths for the directories containing the branches...
<vila> jam: I think some users may use it for their path to .bzr
<jam> vila: the root path should be a URL
<jam> and we ~ don't care
<jam> it should work
<jam> but Transport shouldn't directly be munging that part of the URL
<jam> (I think...)
<jam> anyway, for HTTP transports we wanted to make sure not to touch anything but the part we control
<vila> it doesn't but it should receive url encoded paths, bzr-upload was violating that assumption
<vila> oh no, where is my day gone !!!
<vila> jam: reviewed and pqm'ed
<fullermd> I ate it.  I'm sorry.
<quicksilver> vila: I ate it with my demon repo, sorry.
<vila> quicksilver: how is it going ?
<quicksilver> vila: I've had other things to do in the mean time, but a hybrid replay/merge/rsync approach looks like it will work.
<vila> shame we can't do better :-/
<quicksilver> seems like "repacking texts" results in the occasional very slow commit.
<vila> quicksilver: that's expected, should occur every 10, 100, 1000 commits, look at .bzr/repository/packs sorted by size and you should get the idea
 * quicksilver nods
<quicksilver> fine, just checking
<quicksilver> well remarking rather than checking
<quicksilver> vila: initially disconcerting because I worried that it indicated I had actually merged the poison in since it was so slow
 * vila nods :D
<quicksilver> vila: always takes me longer than I'd like to discover the correct selection of rsync options, too. For some reason I'm unable to remember rsnc commandline syntax
<vila> quicksilver: me neither, that's why I put them in scripts and under version control
<vila> but I'd bet you want to start with '-av --delete' here and then carefully read the help about what -a is aliased to :)
<quicksilver> I didn't want a, in fact.
<quicksilver> -i --checksum --delete
<quicksilver> --dry-run, of course
<quicksilver> -r
<quicksilver> oops. the bad file is in the repo, this repacking is throwing memory errors
<quicksilver> hopefully it's just garbage
 * quicksilver branches to test
<vila> jam: can any of your memory fixes be relevant here ? A repack, even with a 600M object shouldn't reach the 2GB peak no ?
<quicksilver> curiously the repack does succeed even with the error
<vila> quicksilver: the poison is a *text* file right ? And the size is ?
<quicksilver> well it claims to succeed
<quicksilver> vila: yes, 600M text.
<quicksilver> vila: phew. branching it has sane size. the posion is not in a reference revision ;)
<vila> \o/
<rubbs> well done
 * rubbs applauds.
<vila> quicksilver: was it the final reconstructed branch or just an intermediate one ?
<cody-somerville> everytime I commit a change, I get an error about inconsistent details in skipped record.
<cody-somerville> http://pastebin.ubuntu.com/356189/
<NfNitLoop> Are there any major differences between 'bzr checkout' and 'bzr checkout --lightweight' if you're checking out from and into the same shared repository?
<NfNitLoop> My assumption is... no. :p
<quicksilver> vila: almost final.
<quicksilver> vila: no merges left so remaining replays should be trivial. I just got busy.
<doctormo> How would I get the parent_location or transport from a branch?
<NfNitLoop> Yay, think I got another coworker interested in using bzr(-svn) here. :)
 * NfNitLoop just wrote a wiki page with recommended workflow for working w/ our repo. 
<NfNitLoop> I had to make some tiny changes to allow working with our SVN repo.
<NfNitLoop> I Just stripped the places that check for backslashes in file names.
<NfNitLoop> since at one point in history we had a file in the repo with backslashes in its name.
<NfNitLoop> https://code.launchpad.net/~cody-casterline
<NfNitLoop> are my changes.
<NfNitLoop> Someone said they might break other things, but I haven't had a chance to look into that very deeply.
<NfNitLoop> the test suite didn't seem to find any errors with it.   (There were some test failures, but for seemingly unrelated things that I think we're failing in the upstream branch too.)
<jfroy|work> jelmer: greetings, any words on https://bugs.launchpad.net/bzr-svn/+bug/505049?
<ubottu> Launchpad bug 505049 in bzr-svn "VersionedFileInvalidChecksum exception while branching remove svn branch" [Undecided,New]
<jfroy|work> I actually did a bit of experimentation by hacking bzr-svn to use a different prop prefix, and that didn't solve the issue, so it's probably not a bad revprop issue
<jelmer> jfroy|work, I'll have a look when I have a spare moment
<jfroy|work> jelmer: thanks, let me know if you need more data, and sorry to be annoying about it
<jam> vila: late answer, but I didn't fix the peak memory issues for "pack"
<jam> the pack code creates an index which can take a significant amount of mem
<jam> it is on my TODO, but is unfortunately pretty low
<maxb> What are the circumstances in which bzr-svn needs to build a fileidmap knit?
<maxb> For some of my repositories it has done so, for others not.
<maxb> I'd like to know how to provoke it, so I can let it run overnight on a huge repository
<NfNitLoop> Hrmm, maybe it only happens on repos that directly interact with svn?
<jml> can bzr be tricked into preserving timestamps
<doctormo> I would like to detect if changes have been made to a working branch, a cheap boolean would be most effective.
<doctormo> But I can't figure anything out other than making an entire change tree.
<rubbs> doctormo: would bzr status work? or am I missunderstanding your question?
<doctormo> rubbs: sorry I should have specified, using bzrlib
<rubbs> ah, then I will be no help
<beuno> doctormo,
<beuno> something like
<beuno> changes = wt.changes_from(wt.basis_tree())
<beuno> if revision is None and changes.has_changed():
<beuno>     return True
<beuno> or something
<beuno> wt being the working tree
<doctormo> wt is the working tree I guess and revision is the branch.last_revision()
<beuno> right
<beuno> should be more robust if you check for at least one commit
<doctormo> I'm wondering if the best way to get than is branch.basis_tree()
<doctormo> apparently wt.changes_from(wt) is unimpressive, so I guess there is a way to get a wt of what exists.
<doctormo> (wt, wt_path) = workingtree.WorkingTree.open_containing(path)
<doctormo> Hmm I can see removals, additions and changes... but not unversioned files
<doctormo> Ah I guess you get those from wt.unknowns()
<beuno> doctormo, correct
<poolie> good morning!
<jelmer> poolie: Hello!
<poolie> hi
<poolie> are you in nz? how's it going?
<mwhudson> poolie: jelmer is navigating the bowels of the soyuz data model
<mwhudson> he might be back soon
<jelmer> poolie: Yep, hacking on building from branches :-)
<poolie> heh, with an endoscope?
<mkanat> What's the proper way to get the on-disk path of a bzr branch, given a Branch object?
<mkanat> Or, barring that, is there any string that I could get out of a branch object to uniquely identify it (even if it gets updated)?
<poolie> branch.transport.base
<mkanat> poolie: Awesome, thank you.
<poolie> nb there is also .has_same_location()
<poolie> um
<poolie> add extra underscores as needed
<poolie> this should be made a bit simpler and more consistent
<jml> bzr: ERROR: unknown command "cp"
<jml> fail
<mkanat> poolie: Is there a more correct way to get branch._transport from an external program than to just access it directly?
<poolie> jml, that's our most affecting bug
<jml> heh heh
<poolie> mkanat: no; we should rename it to be pubilc
<mkanat> poolie: Okay. Is it safe to have loggerhead depend on its current private name, though?
<poolie> yes
<mkanat> poolie: Okay, thanks. :-)
<spiv> Good morning.
<maxb> Why does locations.conf override direct config in a branch's branch.conf? This seems a bit odd
<maxb> Mainly because it then becomes impossible to have special cases within an appendpath tree
<Peng> maxb: Try puttig the branch's config in locations.conf too?
<mkanat> mwhudson: Okay, I submitted a merge proposal for a possible fix for the codebrowse hangs.
<mwhudson> mkanat: woo
<mkanat> maxb: I think it makes sense to have locations.conf override the branch configuration, because locations.conf is per-user, no?
<Peng> mkanat: Ooooh, neat.
<maxb> hmm... I guess... I don't have any multiuser branches that have any branch.conf setttings
<Peng> mkanat: Why does line 21 of LP's diff end with a ";"? :D
<mkanat> Peng: Ahh, silly habits. :-)
<mkanat> Peng: Probably just did that totally unconsciously.
<poolie> hello spiv
<Peng> Would using cache_key in revision_graph_locks work?
<mkanat> Peng: Oh, instead of using the branch thing? Yeah, that would probably make more sense.
<Peng> mkanat: This doesn't matter, but you don't need to declare revision_graph_locks global.
<mkanat> Peng: Oh, right, because I'm not instantiating it?
<mkanat> Peng: This honestly is the first time I've had to explicitly use thread locking, and I almost never use global data structures for any reason, so.... :-)
<Peng> mkanat: You only have to declare a variable as global if you rebind it (foo = bar).
<mkanat> Peng: Right.
<Peng> Writing to a dict is just accessing foo.__setitem__.
<mkanat> Peng: For these sorts of review fixes, is it more traditional to uncommit and re-push, or to simply do another commit to address the review issues and then push? (This is my first merge proposal in any Canonical process.)
<mkanat> Peng: Yeah, that I know.
<Peng> mkanat: I'd do a second commit.
<mkanat> Peng: Okay.
<Peng> That seems to be standard practice here.
<Peng> "bzr log lp:bzr | grep -i review" :P
<mkanat> Peng: Any other comments?
<mwhudson> mkanat: don't uncommit unless you really have to
<mkanat> mwhudson: Okay.
<mwhudson> mkanat: +"""Used to store locks that prevent mulitple threads from building a
<mwhudson> 17	+revision graph for the same branch at the same time, because that can
<mwhudson> ...
<mwhudson> mkanat: should be a comment, not a string?
<mkanat> mwhudson: I was thinking so probably, too.
<Peng> It looks like this adds a second call to update_missed_caches()? Was that intentional?
<mwhudson> mkanat: did you consider pushing the locking into compute_whole_history_data ?
<Peng> I don't really know this code, so I can't say anything for sure...
<mwhudson> Peng: i think that's just the diff being a bit odd
<mkanat> mwhudson: I did...there was some reason I didn't...oh yes, because we don't have the cache within that method.
<mwhudson> mkanat: ok
<Peng> mwhudson: It's not.
<mwhudson> Peng: there are two calls before and two calls after, i think?
<Peng> Err, wait.
<Peng> Wait, I, uh. Yeah, you're right.
<Peng> This locks even if it doesn't end up calling compute_whole_history_data(), doesn't it? Is that a problem?
<mkanat> Peng: It does. It wasn't a problem in my testing.
<mkanat> Peng: The logical problem is that we must lock before checking if there's a cached revision graph.
<mkanat> Peng: I mean, we don't *have* to--I could refactor things to avoid it.
<Peng> It'd be more complicated to do it that way, and not really worth it, right?
<mkanat> Peng: Yeah, I think so.
<mkanat> It'd be one of those check, lock, check, run things.
<Peng> Fun.
<mkanat> Loggerhead is still considerably slower under massive simultaneous load than it is under a light load, but I couldn't get it to demonstrate the hanging level of slowness that I was seeing before.
<Peng> Is there a race condition when creating the lock? Is it possible that another thread could create a lock between "if ... in ..." and "... = Lock()"?
<mkanat> Peng: I thought about that. Logically, yes. Practically, because of the GIL, no.
<mwhudson> still
<mwhudson> using defaultdict would be better here no?
<mkanat> At least, practically, it's unlikely. I could avoid it with another lock though.
<mwhudson> mind you, 2.5 only
<Peng> Ick.
<mwhudson> or setdefault, but then you'll end up creating a lock for every request
<mkanat> mwhudson: What version do we require now?
<mwhudson> mkanat: 2.4
<Peng> mkanat: 2.4
<Peng> Oops.
<mwhudson> but launchpad is on 2.5 so i care a lot less now :)
<mkanat> Yeah, but RHEL 5 is 2.4....
<mkanat> That's sort of what I generally use as a limiter for stuff that's really hard to reinstall at a base OS level.
<Peng> bzr still supports 2.4, but that doesn't really stop Loggerhead from dropping it.
<mkanat> mwhudson: A simpler solution is to put another lock around the check.
<Peng> If we wanted to, anyway. Loggerhead obviously has fewer users than bzr, but more of its users will be on old server installs... Meh.
<mkanat> mwhudson: The only problem is that that lock totally synchronizes loggerhead, because it would be one global lock. It's pretty short, though.
<mwhudson> mkanat: simpler, but more expensive i guess
<mkanat> mwhudson: Yeah.
<Peng> _I_ don't run 2.4, so I don't care much, but...
<Peng> mwhudson: Launchpad is on 2.5?
 * mkanat runs 2.4 on all his servers.
<mwhudson> if we hit this race, i guess it's possible to end up in the bad old situation of building multiple caches
<mwhudson> Peng: yes! finally
#bzr 2010-01-14
<mwhudson> but it's actively bad, just poorly performant
<mkanat> mwhudson: Yeah.
<mwhudson> mkanat: i guess i'd say it's ok as it is
<Peng> Race conditions and bug fixes that don't always work make me feel icky.
<Peng> Objectively, it's an improvement over hte current situation, but..
<mwhudson> mkanat: maybe put a comment in?
<mkanat> mwhudson: That seems reasonable.
<mwhudson> or maybe try the extra lock and see how performance goes?
<mkanat> mwhudson: Sure, I'll try the second lock.
<mkanat> mwhudson: It has no noticeable effect on performance (within the margin of error of my tests).
<Peng> Could Loggerhead still get killed by a bunch of different caches being built at once?
<mkanat> Peng: That's what we're going to see.
<mkanat> Peng: That problem didn't actually happen in the hang logs--it was always the building of a graph for the same project over and over.
<Peng> Huh.
<Peng> mkanat: Ah, I see what you wrote on the bug.
<Peng> OK.
<mkanat> Okay, pushed a new version.
<mkanat> Hmm, the preview diff doesn't include my newly-pushed commit?
<poolie> it takes a minute
<poolie> to update
<mkanat> Ah, okay.
<poolie> minute==little while, not precisely a minute
<mwhudson> the cronjob runs every minute now actually
<Peng> This is getting excessively pedantic, but should the new lock use a try...finally too? :D
<Peng> (The answer is probably no!)
<mwhudson> i reviewed the branch
<mkanat> Peng: Yeah, no. :-)
<mwhudson> it's lunchtime though
<mkanat> Peng: I don't think anything in there can throw an exception.
<mwhudson> Peng: want to land if if you're happy with it?
<mwhudson> mkanat: well anything _can_ fail (consider memoryerror)
<mwhudson> but....
<mwhudson> oh no
<Peng> Yeah.
<Peng> Oh no?
<mwhudson> hm
<mwhudson> we have this thread killer in launchpad
<mwhudson> so we should be really paranoid i think
<Peng> Given the consequences (LH would basically die), paranoid sounds good to me.
<mwhudson> i can't see why a thread would have only got this far in 300 seconds or whatever
<mwhudson> but what Peng says
<poolie> jam, does https://bugs.edge.launchpad.net/bzr/+bug/507040 suggest anything to you?
<mkanat> mwhudson: Okay.
<ubottu> Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed]
<Peng> With that change, I'd be happy to land it.
 * mwhudson vanishes for a bit
<mwhudson> Peng: thanks
<mkanat> Okay, pushed.
<mkanat> AnnotateUI is still really slow.
<mkanat> But everything else is fast.
<mkanat> And "really slow" now is 11 seconds, not 120.
<Peng> mkanat: Awesomesocks, thanks.
<mkanat> 2x users = 5x time.
<Peng> Pushing now.
<mkanat> Peng: Once it's live, an easy way to test would be to open several tabs that would all build a revision graph cache at once, for one branch.
<mkanat> Peng: That seems to be what people were doing that caused the hangs.
<mkanat> Peng: It has to be on a huge branch though, like launchpad or bzr itself or mysql.
<Peng> Mm.
<Peng> It's totally _possible_ for someone to do the same thing to several different branches of LP or MySQL, just even less likely./
<mkanat> Peng: Yeah. And also, that's a level of concurrency that loggerhead should validly handle.
<mkanat> Peng: Whereas buliding multiple revision graph caches for the same branch is something that's never necessary.
<mkanat> Peng: If we see problems across multiple projects, then we can switch to a global semaphore around the per-branch lock.
<mkanat> Peng: The problem then is that we have to make some judgement about how many caches it's OK to build simultaneously, which we can't really know, and that gets into needless configuration by the admin, and so on.
<Peng> Plus, it would be a shame to block everyone building a little cache as well.
<Peng> BBIAB -- Hopefully we didn't just blow anything up.
<Peng> Yay, nothing exploded.
<mkanat> Yay. :-)
<mkanat> Now we see if the hangs keep happening.
<jam> poolie: bug #507040 looks to me like a missing inventory that is expected to be there
<ubottu> Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed] https://launchpad.net/bugs/507040
<jam> which hints at a stacking issue
<jam> but it isn't something I've specifically seen
<magcius> Is there documentation about how bzr works internally? The object format... are full files stored or just deltas.
<Peng> Both.
<magcius> Peng, where?
<Peng> Err, i was answering the second question. :P
<Peng> It mainly uses deltas, but occasionally throws in a fulltext to keep performance up.
<magcius> Oh.
<spiv> magcius: there's some docs in the doc/developers directory
<spiv> (or http://doc.bazaar.canonical.com/bzr.dev/developers/)
<spiv> magcius: but they are far from complete on this sort of topic :/
<bvk> hi, how do i get combined diff (without using revision numbers) after some "local commits" in a "bzr checkout" directory?
<spiv> Hmm, possibly "bzr diff :bound" ?
<bvk> spiv: no, it didn't work :(
<fullermd> You'd probably need something more like 'bzr diff -rancestor::bound..' I'd guess.
<StevenK> spiv: Did you get the e-mail that contained my bzr logs? It was sent a while ago.
<spiv> StevenK: hmm, I think so yes
<scorp007> when I make a merge directive, will it contain my log messages that I committed locally with?
<scorp007> or does the patch simply forget them and treat em all as one change?
<bob2> yes, no
<scorp007> oh, so from the merge directive, how can I see/extract the log messages?
<scorp007> will it automatically happen when I merge?
<bob2> yes
<scorp007> ah, great. Out of curiosity, is it possible to view them prior to that?
<bob2> don't know, sorry
<scorp007> ok, that's fine. Thanks
<scorp007> how can I temporarily set my HEAD to an older revision. (not revert, I don't want uncommitted changes)
<scorp007> sort of like a svn update -r<old revision>
<RAOF> bzr branch -r<old revision> old-thing
<RAOF> Sorry, âbzr branch -r<old revision> current-branch old-revisionâ.
<scorp007> won't that make a new branch?
<poolie> scorp007: if you have a recent bzr 2.1, you can use update -r
<scorp007> otherwise I must make a new branch each time?
<RAOF> poolie: Interesting.  How does that handle allowing you to get back to your old branch?
<poolie> raof, it only sets the working tree back to an old revision, it doesn't change the branch
<poolie> so plain update will take you back to the tip
<RAOF> Hm.  That could be useful, yah.
<poolie> so scorp's question is a bit contradictory: it fulfils the aspect of being like svn update
<lifeless> poolie: the exit button in tribunal-view-subunit is greyed out for me.
<poolie> yes :)
<poolie> it is a placeholder for useful tb buttons
<poolie> i saw your mail
<lifeless> ok
<lifeless> I wasn't sure if it was just me :(
<lifeless> s/(/)
<poolie> i don't think it's good for gui programs to default to reading stdin
<poolie> cos it tends to make them just sit there waiting for stuff
<scorp007> poolie, I'm not sure I understand.
<mneptok> lifeless: you should use that as the title for your memoirs.
<poolie> i'd be happy to have it understand '-' as an argument though
<lifeless> poolie: oh, ok. I did that because of the module docstring.
<scorp007> I made a new branch as a copy from my main one -- I want to simulate a merge using a merge directive
<mneptok> s/(/)
<scorp007> but my copy is alreadt at the latest verison
<lifeless> poolie: 'Reads a subunit stream from stdin  ...' - I figured it was a bug I was fixing for you :)
<poolie> heh
<poolie> anyhow i'll look at merging it
<lifeless> poolie: yeah, - would be better.
<poolie> i'd like to eventually give it commands to open files and to run subprocesses
<lifeless> poolie: what I /wanted/ was for no-args to not crash with an IndexError, and to put in the testrepository support
<poolie> :-)
<poolie> as another comment notes, reading from a pipe will suck a bit until it's done asynchronously
<lifeless> I'm going to have dinner with scott, see you tomorrow
<lifeless> poolie: if you want code to read from a pipe asynchronously in gtk
<poolie> oh ok
<poolie> say hi for me please
<lifeless> poolie: see subunit2gtk - it has code to do that.
<poolie> ok
<lifeless> feel free to liberate and repurpose to your hearts desie
<lifeless> s/ie/ire/
<lifeless> mneptok: econtext
<poolie> k
 * lifeless is gone
<poolie> thanks for the imports spiv
<vila> hi all !
<poolie> hi vila
<vila> hey poolie !
<_Andrew> Is there something like svn's propset in bzr? I want to insert the revision number into a file
<poolie> _Andrew: http://wiki.bazaar.canonical.com/KeywordExpansion
<poolie> vila, circular imports are hurting me :/
<vila> where ?
<poolie> i want to set ui.ui_factory to be an instance of the TextUIFactory
<poolie> but that's declared in a submodule of ui of course
<vila> hmm, setting a global instance is always tricky, generally you need to involve a call somewhere to add some lazyness in the loop
<vila> If you can't.... you need to rethink your design :D
<poolie> mm
<poolie> good night
<bialix> heya bzr
<vila> hi bialix
<bialix> hi vila
<quicksilver> vila: I'm fairly sure my solution worked. I have pushed the clean branch to our repository.
<quicksilver> vila: it seems to merge cleanly with other related branches, which is the main test.
<quicksilver> (if I'd done it wrong, merges would be expected to cause conflicts)
<vila> http://instantrimshot.com/
<quicksilver> vila: I'm just writing up a report for the mailing list, although I have plenty of work to do so I might not email it for a day or two.
<vila> quicksilver: great ! as long it comes in, I'm happy
<bob2> f/win29
<bob2> bah
<jkprg_> hi! I want to implement central shared repository. How could I prevent someone will delete the repository? Thx
<davertron> hi guys, if i have a branch with a working tree, and i want to create a "central" branch with no working tree from that branch, how do i do that?
<jam> davertron: 'bzr push' or 'bzr branch --no-tree"
<davertron> bzr: ERROR: no such option: --no-tree
<Toksyuryel> What version of bzr are you using?
<davertron> i'm using 1.12
<davertron> maybe too old?
<Toksyuryel> Ancient
<davertron> figures
<wundo> Hi, right now I have an SVN repository with tons of data (and over 5k revisions), I'm willing to change to BZR, but I'm not sure how to deal with access control. Could someone give me some guidance please?
<rubbs> wundo: really the only way to deal with access control is to do it at the system level.
<rubbs> wundo: due to the distributed nature of DVCS, commit-access isn't as much of an issue at the repo level (since everyone gets their own repo).
<rubbs> so the only way to really stop write access is to do so at the system level.
<wundo> I'm willing to use bzr with a centralized workflow... And I'm willing to prevent people from reading certain directories too, not only writing.
<quicksilver> I don't think bzr works well with people only having access to certain directories?
<quicksilver> in my experience you always get a whole branch.
<rubbs> exactly
<rubbs> if you're looking for per-directory/per-file permissions, you'd have to split up the repo
<rubbs> bzr doesn't allow for partial checkouts
<wundo> hmm...
<MvG> Hi! Do I see this correctly that there is no "commit --amend" for bzr, as there is for git, and that I'd have to uncommit and commit manually to get a similar effect?
<MvG> If so, would you agree that this would be a nice feature to have, should be feasible, and would warrant a request for enhancement in lp?
<rubbs> MvG: you are correct there is no commit --amend
<rubbs> there has been debate IIRC about that feature.
<wundo> another question,  most of the people work from our office, is possible to have an local mirror from the central repository where the people can commit/checkout their code without using our internet connection?
<rubbs> yes
<rubbs> this is how bzr was designed
<rubbs> they each can have their own repo as a copy of the "central" branch
<MvG> rubbs: There was some discussion back in 2007 for editing the comment: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/21558
<wundo> I mean, there are 5 people in our LAN, but our internet connection is off...  assuming user A has new changes he wants to share it to user B. Could he commit to a local server from which user B can checkout and when the internet is back on the local server seamless synchronizes with the external server?
<rubbs> MvG: I am not a dev... but as I recall the biggest problem with doing an amend is that changing history at all can screw up with some other people's things.
<rubbs> wundo: yes
<rubbs> wundo: you can push and pull to different locations
<MvG> rubbs: As can uncommit, and it's still there, and I'm glad it is. Rule is, once you pushed something, then changing it can cause divergence. Nothing new there.
<wundo> rubbs: any how to setup it available?
<rubbs> wundo: when you branch from the central repo,bzr would remember that repo, but you could tell it to pull, push , or merge from another one quite easily.
<rubbs> wundo: http://doc.bazaar.canonical.com/bzr.2.0/en/
<rubbs> check them out that might help
<rubbs> MvG: good point
<rubbs> MvG: you could try requesting it again.
<MvG> Will do so.
<rubbs> wundo: if you are looking for a pseudo-centralized workflow check out this: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/centralized_workflow.html
<quicksilver> uncommit loses the commit message though I think?
<quicksilver> minor disadvantage of it.
<rubbs> quicksilver: yes, it does... that's why he want's an ammend.
<rubbs> amend*
 * quicksilver nods
<jam> morning vila, rubbs and quicksilver
<quicksilver> morning jam.
<jam> quicksilver: I thought there was a hook that preserved uncommit
<jam> check with vila / qbzr
<vila> mornign jam
<quicksilver> you're more likely to be right than me jam ;)
<quicksilver> the very very long message I'm writing to the bzr mailing list does mention this point as an aside.
<jam> I don't think 'bzr commit' defaults to reusing it, but certainly "bzr qcommit" can remember something
<vila> AFAIK both bzr-gtk and qbzr saves commit/uncommit messages in branch.conf
<rubbs> Morning
<rubbs> MvG: wundo: I have to go to a meeting, but others here can help if you have any other questions.
<vila> another trick is to have a qlog running around and copy/paste from there
<wundo> thanks rubbs
<wundo> still is not an one hour decision to change a whole company VCS :P
<wundo> I will probably be here when you come back...
<MvG> I'm also copy and pasting from console output, but that's not nice. Writing a lp whishlist item for commit --amend just now.
<vila> MvG: search for duplicates instead and click the affects me too button instead
<vila> MvG: I'm 80% sure this has been reported
<MvG> vila: I did search, and found nothing.
<vila> ok, thks for trying :D
<MvG> Problem is, it's kind of difficult to find suitable terms for it.
<MvG> Does lp do a full text search?
<vila> when you file a bug, lp does a pretty good search, details available at #laundpad-dev :)
<phinze_> hey folks, does anybody have a second to look at this 8 lines of error and tell me if this might be a fluke... http://gist.github.com/277228
<doctormo> Using bzrlib, What's the best way to check if a local working tree has commits which are not pushed (assuming push_location is set)
<jam> anyone know if John Whitley hangs out on IRC?
<jam> phinze: that looks like a really low-level failure
<jam> as it means "import os" is failing
<jam> do you have a "posix.py" file somewhere in your path?
<phinze> that's what i figured -- we run bzr every minute in a cron job and that came up once last night -- so there is much room for flukes
<jam> (some platforms accidentally set things up to include the current working dir in the python search path.)
<jam> phinze: could the system have been updating itself?
<phinze> python -> 'import posix' works fine
<phinze> jam: mmm good thought
<vila> it doesn't help that '' in PYTHON_PATH also means add current directory
<phinze> might want to see what other cron jobs run on our build server and pause all the bzr activity for that time
<jam> doctormo: last_local_rev = wt.branch.last_revision(); push_url = wt.branch.get_push_location(); push_branch = bzrlib.branch.Branch.open(push_url); push_last_rev = push_branch.last_revision()
<phinze> so, tentative conclusion is -- not really bzr's job to handle that sort of error?
<jam> if last_local_rev == push_last_rev: then you know there is nothing to do
<jam> otherwise you may have local changes, or remote may have changes
<jam> you can use  graph = wt.branch.repository.get_graph(push_branch.repository)
<doctormo> jam: I see, what if we assume that remote doesn't have changes.
<vila> phinze:  so far, the occurrences have been rare enough that the bug hasn't been fixed (there is one I can't remember the # just now )
<jam> graph.find_difference() if you care about both sides
<jam> or
<doctormo> jam: See what would be good is to be able to say "Have there been any commits after the last push command"
<jam> graph.find_unique_ancestors(local_rev, [push_rev])
<jam> doctormo: well, if the local revision is different than remote
<jam> and nobody else updates remote
<jam> then yes
<jam> there must be something to push
<phinze> vila: sounds good -- initial bug searches for the text of my error weren't yielding much
<phinze> at the end of the day i'm not too worried either
<doctormo> jam: OK, if that's the only way, I just want to avoid remote requests if I can.
<jam> doctormo: if you are writing your own stuf
<jam> you can save the revision at push time
<jam> using something like a "post_branch_tip_changed" hook
<jam> however, *bzr* does not track that
<jam> it doesn't save a 'this branch was pushed at this revision' anywhere
<jam> I think there is also a post_push hook, if you just wanted to trap that
<doctormo> I see, then perhaps I should do a bit of code to track and then fall back on discrepency
<MvG> vila: https://bugs.launchpad.net/bzr/+bug/507529
<quicksilver> Is there a command-line way to get the nearest common ancestor of two branches?
<vila> quicksilver: 'bzr merge --preview --show-base' may not be the pretiest, but from command-line... it's the only way I can think of
<vila> there was an approximate command in bzrtools at one point but I'm pretty sure it's not up to date
<DaffyDuck_`> I want to set up a few potential complicated ignore-rules. Anyone here proficient in ignores with regular expressions?
<quicksilver> vila: Hmm. Bzr is very clever but it's a bit hard to get the information out of it sometimes. I suppose you're expected to use bzrlib.
<quicksilver> vila: do any of the visualisation tools help you visualise the relationship between a bunch of branches?
<vila> quicksilver: bug filing time ! :D
<DaffyDuck_`> I have an /src directory in a project which contains lots of files and directories. I want to ignore everything in there, with a few (something like 10) exceptions, which I want to track.
<vila> qlog accepts seveal branches as input like : bzr qlog b1 b2 b3
<vila> quicksilver: it then display special tags for the tips and doing a very good job at displaying the multiple heads
<quicksilver> vila: but still shows you all the revisions doesn't it?
<vila> quicksilver: if the branches diverge a lot it becomes harder to track though
<MvG> What are ghosts?
<MvG> Is there some kind of document (wiki page, source file, mailing thread) that I could read to get an idea about what ghosts are and how different parts of bzrlib deal with them, i.e. which parts take care of them themselves and which expect the caller to deal with them? Or could you tell me in a few lines here?
<MvG> Might be important to get support for them into trac-bzr one day, I'm not sure.
<vila> quicksilver: qlog default to masking most of the merged revisions but you can then open the ones marked with a '+'
<vila> an close the ones marked with a '-', obvious when you use, akward to describe :)
<quicksilver> vila: sure. The thing is all I want is an overview which shows branches and all of their nearest common ancestors.
<quicksilver> vila: so I can see what branched from where, when.
<quicksilver> I don't want ot see individual revs at all
<vila> then definitely give a try to bzr qlog **/* or whatever
<vila> that's the closest I can think of
<vila> you will see the revs but one line for each but that's the best we have to present a *graph* with multiple heads so far
<quicksilver> vila: *nod*
<MvG> DaffyDuck_`: Simply ignore the whole dir and add the files you want to track. Ignore only affects untracked files; once you told bzr about the ones you are interested in, it will track them.
<quicksilver> vila: I don't really like GUI toolkits.
<quicksilver> vila: I was thinking of something a bit more elegant like a .dot file or a PDF file or something :)
<vila> quicksilver: I use almost no GUI myself *except* qlog
<MvG> quicksilver: You want to write a bzr plugin generating dot output?
<jam> vila: giving qlog a repo will do everything underneath, I don't know about a plain dir
<quicksilver> MvG: no, I want someone else to :P
<jam> quicksilver: there is also "graph-ancestry" from bzrtools
<vila> quicksilver: I've played with .dot files and intend to replay with one day.... when time permits
<MvG> quicksilver: You want to pay someone else to... doesn't matter, still no time...
<jam> which does generate DOT output
<jam> or PNG (generated from DOT), etc
<quicksilver> jam: that looks promising :)
<vila> quicksilver: how many revisions in your repo ? (all revisions not only the mainline ones)
<jam> I think it can also take a revision range
<quicksilver> vila: 2000 or so? I'm not sure
<jam> You may have to tweak it if you want specific information
<vila> last time I played I started with graph-ancestry but my graph was too big but it was a decent starting point
<jam> I think it handles 2 branches, but not more than that
<jam> vila: I think it now supports giving a range of revisions so you don't have to graph the whole thing
<quicksilver> ah, right. So not quite what I'm after but definitely thinking in the right direction.
<jam> quicksilver: IME dot doesn't like graphs with more than ~100 revs
<jam> 100 nodes
<quicksilver> jam: I only want a node per 'most-recent-ancestor' really
<vila> from memory I'd say 2000 will blow away graph-ancestry (or give you a result you can't really use)
<vila> jam: qlog  or graph-ancestry ?
<quicksilver> so I'm talking 20 branches and 20 MRAs at most, I think.
<jam> I tried using it with a 100k object graph... and after 8 hours an 2GB of memory... it still hadn't finished formatting to -Tplain
<jam> vila: graph-ancestry
<jam> dot itself doesn't handle lots of nodes very well
<jam> it would probably be better with revision graphs, since there is less cross-linking and no cycles
<jam> unlike object reference graphs
<quicksilver> well something else to think about next time I have free time...
<quicksilver> not immediately clear how you find the right set of MRAs either
<quicksilver> although I'm sure it should be clear.
<quicksilver> can loggerhead cope with multiple bzr branches or is that a launchpad feature?
<quicksilver> when I say 'cope with' I mean have some idea of the relationship between, I suppose.
<beuno> quicksilver, what do you mean by a relationship?
<quicksilver> well the fact that one branch is a branch of the other
<quicksilver> they're not just two unrelated lumps of code.
<beuno> so, the loggerhead instance running on Launchpad is the same one as trunk (minus some glue)
<quicksilver> beuno: I'm not quite clear how much of what I look at is generated by launchpad and how much by loggerhead
<quicksilver> beuno: for example : https://code.launchpad.net/loggerhead
<quicksilver> beuno: is that page launchpad or loggerhead?
<beuno> quicksilver, launchpad
 * quicksilver nods
<quicksilver> beuno: but this one is loggerhead: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/files I presume?
<beuno> quicksilver, correct
<beuno> anything UI under  http://bazaar.launchpad.net is loggerhead
<beuno> I suspect that what you want isn't part of loggerhead, but it may not be too hard to do
 * quicksilver nods
<quicksilver> loggerhead looks like a 'branch inspector' so it inspects one branch at a time.
<beuno> yes it does
<beuno> within a directory
<beuno> but you can infer some relationship with commid revids and parent URLs
<beuno> launchpad is different, because it stuffs everything into a DB  :)
 * quicksilver nods
<jkprg> hi. how to protect shared (centralized) repository against deleting or corrupting?
<Peng> Don't give people write access to it.
<Peng> Seriously, though. If you use stacked branches, that's a viable solution.
<jkprg> Peng: Stacked branches? I have to read about it
<Peng> That's what Launchpad does, FYI.
<Peng> Stacking policy, too.
<jkprg> Peng: Is there no need to have write access to whole shared repository to push changes?
<Peng> jkprg: If you use stacked branches, it's not necessary.
<jam> jkprg: one option is that you also only need read access to existing objects
<jam> so once a transfer finishes, you could mark all files in .bzr/repository/packs and indices as readonly
<jam> (note that new ones will get created, old ones get moved to obsolete_packs and eventually deleted...)
<guilhembi> jam: hello! thanks for the explanation about "bzr log" order constraints; I understand (1), but not (2):
<guilhembi> "2) We also output a revision after the last revision which did not have it in
<guilhembi> the ancestry.
<guilhembi> what is "it"?
<jam> guilhembi: hi
<jam> so if you have revs A B C.
<jam> If B is in the ancestry of C, but not in the ancestry of A
<jam> then B will appear in the log output between A & C
<jam> if you go back to the graph I put up on the bug
<jam> I detailed the difference between that an just 'topological'
<guilhembi> jam: I promised I read it, I saw "(2) says that C E G"
<guilhembi> but I cannot parse (2)
<guilhembi> could (2) mean: a revision is always after the last revision which didn't have it in its ancestry...
<guilhembi> could (2) mean: a revision is always after the last revision which isn't a child of it?
<guilhembi> No, that wouldn't imply that "that C E G has to come after F ".
<jam> C has to come after F because F does not have C in the ancestry
<jam> is that an easier way to see it?
<jam> A revision X will appear in the log after all revisions which do not contain X in their ancestry
<guilhembi> jam: but I could also say "F has to come after C because C does not have F in its ancestry"...?
<jam> guilhembi: left ancestry first :)
<jam> something has to come first
<jam> let me think of a way to word it
<guilhembi> jam: I'm grateful for the current effort to phrase that!
<jam> back in a sec
<jam> a revision X will appear before any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Z and Y in the output
<jam> guilhembi: how's that?
 * guilhembi reads and reads again
<guilhembi> jam: "a revision X will appear before any child revision Y"
<guilhembi> no, children appear first (newest revision on top)
<jam> guilhembi: I always draw time downwards (--forward)
<jam> you can reverse the statement
<jam> a revision X will appear after any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Y and Z in the output
<jam> Note that the graphs in the bug report are also directed that way, in case you had some confusion there as well
<jam> A is the *first* commit
<guilhembi> yes, I had understood graphs in the proper way. Re-reading the new sentence now...
<guilhembi> Testing that sentence on various examples posted in the bug report...
<guilhembi> matches your A B D F C E G H example...
<lifeless> moin
<guilhembi> matches the example for which I had posted a postscript file...
<guilhembi> jam: your explanation looks quite good. However I'm not sure it adresses defining the initial set of nodes on which the rules apply (from the bug report):
<guilhembi> <quote>
<guilhembi> if you have this graph:
<guilhembi> A
<guilhembi> | \
<guilhembi> B C
<guilhembi> | /
<guilhembi> D
<guilhembi> then "bzr log -rB..D -n0" shows
<guilhembi> D
<guilhembi>   C
<guilhembi> B
<guilhembi> but "bzr log -rC..D -n0" shows
<guilhembi> D
<guilhembi>   C
<guilhembi> See, it's assymetric: the "mainline" property of the starting point of the -r range, influences how many revisions you see (3 versus 2).
<guilhembi> </quote>
<guilhembi> (A is the first revision).
<guilhembi> ?
<guilhembi> I'm not sure this is covered by the "left-hand" piece of your explanation.
<guilhembi> Depends on what graph subset this piece applies.
<guilhembi> Apparently it's not "all nodes on all paths from X to Y" (for -rX..Y), as for -rB..D it would mean B,D (only those two nodes are on the paths),
<guilhembi> and "bzr log -n0 -rB..D" also shows C.
<guilhembi> guilhembi: I'm off to bed and that will log me out. If you like, you can reply in the bug report or to my mail. Thanks for the help and patience!
<guilhembi> jam: I'm off to bed and that will log me out. If you like, you can reply in the bug report or to my mail. Thanks for the help and patience!
 * guilhembi talks to himself, thus is tired
<guilhembi> jam: In other words: the bug report is maybe more about "what set of nodes do I see and how does -n0 influence that?", rather than "in what order do I see those nodes?". I understand that the order has to be non-trivial for humans, because it's a serialized graph; but the set could be interest for humans.
<guilhembi> good night
<jam> guilhembi: night. if you take the serialized order and then just start and stop, then I think it works out
<jam> your graph orders to "A B C D" given my rules
<jam> (or D C B A)
<guilhembi> jam: ah, ok, looks good then.
<guilhembi> jam: I'll think more about it. Bye and thanks again.
<guilhembi> jam: ah, and also, the influence of -n0...
<guilhembi> see you later.
<jam> morning lifeless
<jam> lifeless, do you know if spiv is officially on parent leave now?
<jam> he mentioned he was "likely going" this week
<jam> but I didn't get a "I have a new baby" email.
<lifeless> jam: they are overdue I think
<lifeless> jam: I haven't heard a pop,squall yet.
<thumper> lifeless: hey
<thumper> lifeless: when are you arriving in wellington?
<lifeless> tomorrow 2pm
<lifeless> jml: btw 'testr failing' works now.
<thumper> lifeless: bumped into pia this morning and she was asking if you were here yet
<lifeless> heh
<lifeless> I'm fairly sure she can see on tripit.
<lifeless> all this web2 stuff ...
<thumper> i have some kudos to hand out to all you guys
<lifeless> nice! what flavour?
<thumper> I was going to wait for poolie to give the report though
<thumper> that way, I won't have to repeat myself again
 * lifeless summons poolie
<thumper> lifeless: nice kudos
<lifeless> ...
<lifeless> nope didn't work
 * mneptok pulls on his full-head latex Martin Pool mask
<lifeless> mneptok: 'ew'
<mneptok> one moment. can't find my panty hose and nipple-clamps.
<mneptok> attention everyone! we are rechristening the project "Bizarre Revision Control"
<lifeless> mneptok: you are aware that we have minors in this channel ? :)
<lifeless> And I don't mean the birds.
<Peng> Right. You better wear pasties under those nipple clamps.
<mneptok> "Even the ravens are calling my name," thought Caw.
<mwhudson> mneptok: btw
<mwhudson> mneptok: have you seen http://uncyclopedia.wikia.com/wiki/Ubuntu recenty?
<mneptok> mwhudson: ?
<mneptok> mwhudson: is my picture removed?
<mwhudson> mneptok: no
<mneptok> oh good.
<mneptok> that's been there for *ages*
<mwhudson> mneptok: did you add it, by any chance?
<mneptok> no.
<lifeless> mwhudson: lol
<mwhudson> i edited the caption
<mneptok> the actual caption is "My hair is luxurious. Touch it."
<mwhudson> mneptok: it's a wiki!
<lifeless> thumper: go here: https://code.edge.launchpad.net/~subunit/subunit/trunk . click on '1 branch proposed for merging'.
<lifeless> thumper: I think this is my #1 code complaint at the moment.
<jam> lifeless: ouch
<thumper> lifeless: but if I fix that, you'll just get another #1 code complaint
<jam> you can select "needs review" on that page, though
<thumper> lifeless: is there a bug for that?
<thumper> it is trivial
<mneptok> mwhudson: OK, OK. i done it.
<jam> of course: https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges has 320 results on it
<lifeless> thumper: there is a bug for it
<lifeless> thumper: and you even commented on it :)
<thumper> lifeless: I was hoping you'd give me a number
<mwhudson> mneptok: :-)
<mwhudson> thanks
 * bigjools waves at mneptok
<mneptok> bigjools: ahoyhoy
 * mneptok tootles off to run some errands
<thumper> lifeless: when does poolie normally turn up?
<lifeless> before now
<lifeless> why don't you put your news in a bufer
<lifeless> and paste it ;)
<lifeless> thumper: bug 490139
<ubottu> Launchpad bug 490139 in launchpad-code "'X branches proposed for merging' goes +merges not +activereviews on branch page" [Undecided,New] https://launchpad.net/bugs/490139
<lifeless> thumper: I was wrong, Aaron has commented on it, not you.
* poolie changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.1.0b4 and 2.0.3 released
<poolie> hi all
<thumper> Firstly a big kudos to all bzr devs, with extra to jelmer
<thumper> last night we were at a local pug meeting where most non-lp devs used git
<thumper> we gave an on the fly demo of bzr (pushing to lp and code reviews)
<thumper> the question was asked about a nice gui
<thumper> we said "bzr explorer is awesome"
<thumper> the question came - "does it have a pluggable back end?"
<thumper> we said "bzr is a pluggable back end"
<thumper> we decided that with bzr-git installed, bzr explorer should work on a git repo
<thumper> so I did a git clone of one of their local works
<thumper> installed bzr-git from the repos and (bzr explorer)
<thumper> died due to me using bzr-nightly ppa
<thumper> jelmer got the latest and greatest dulwich and bzr-git on my laptop
<thumper> went into the git repo and did "bzr explorer"
<thumper> it worked!!!
<thumper> it was a great smug moment
 * thumper hands out kudos to bzr devs
<mwhudson> it was also a 300 meg git repo with 15000 revisions
<mwhudson> and it was pretty fast
<bigjools> I was very surprised at how fast it was
<lifeless> thumper: yeah that kind of thing is real nice
<lifeless> thumper: I remember doing a lightning talk @ europython, showing bzr-hg (written that afternoon) doing bzr-viz
<lifeless> thumper: is there a secondly?
<thumper> no
<thumper> it was just the start of the message
<thumper> there was another thing
<thumper> but it was more LP related
<thumper> I think our bzr demo helped though
<thumper> this was at catalyst
<AfC> I've been using bzr-git to track GTK and GLib. Updating (pulling) is not what I'd call fast, and it seems to be really CPU intensive. But it does work (given that I can use git+ssh://, since git:// doesn't) which is really nice.
<mwhudson> what we did in explorer only really tested the revision graph stuff
<jelmer> AfC, what about git:// doesn't work?
<AfC> jelmer: it crashed, if I remember correctly.
<lifeless> mwhudson: same as viz :P
<mwhudson> right
<lifeless> mwhudson: but ssh, don't tell em
<mwhudson> we didn't :-)
<jelmer> AfC: If you can still reproduce, please file a bug. I'm pretty sure most of the crash bugs are gone now
<AfC> jelmer: [your VCS tools use the same ID-for-foreign-revision mapping mechanism regardless of protocol, right? So given I have a more or less up to date git+ssh:// checkout, I can bzr pull git:// without causing cats and dogs to sleep together. right?]
<AfC> jelmer: I was using whatever is in the bzr PPA as of, oh, 2 weeks ago?
<jelmer> AfC: Yes
<jelmer> AfC: Ah, I think we haven't updated that in a while
<AfC> jelmer: do you want me to try and reproduce, or do you want me to wait for you to publish a new package?
<AfC> jelmer: [ready to try right now with $whatever is installed if you want
<AfC> haha
<AfC> bzr: ERROR: This operation is not supported by the Git smart server protocol.
<AfC> that should be
<AfC> bzr: ERROR: This operation is not supported by the Git not-so-smart server protocol.
<AfC> (`bzr missing`)
<jelmer> AfC: I don't think there is anybody updating the bzr-git ppa packages
<AfC> jelmer: uh, I'm talking about "deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main", which I thought was the one we all agreed [after months of email debate] would be the best place to get releases of the current Bazaar ecosystem
<jam> AfC: according to jelmer, you can only fetch over the git protocol
<AfC> is that not [no longer, not again] correct?
<jam> you can't do stuff like log/ compare etc
<AfC> jam: sure; not critiquing anyone for that (well, other than Git)
<spiv> jam: still no baby :)
<jelmer> AfC: I'm not involved in the PPA packaging, but I think only the core set of plugins is packaged there
<jam> spiv: well probably your wife is :(
<jam> spiv: anyway, mostly I wanted to check if we should be landing your patches
<jam> you have 2 mostly-approved ones right now
<spiv> jam: not yet :)
<spiv> Yeah, I'll do those now.
<AfC> jelmer: uh, oh. I thought we had agreed that bzr-$VCS was in that category.
<AfC> ie the ENDLESS debacles with bzr-svn not working with bzr releases.
<jam> AfC: atm only bzr-svn is
<maxb> Has anyone ever set up some system to automatically back up bzr branches when changes are pushed?
<lifeless> maxb: the autopush plugin?
<maxb> Will that only catch tip changes? In a perfect world I'd want to catch things like tag changes without a tip change
<maxb> Though I imagine it might need something like launchpad's custom sftp/ssh server for that
<spiv> maxb: hmm, probably.  I'm not sure if we have a hook point for tag changes, but if not we should fix that.
<spiv> maxb: FWIW, http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html suggests the automirror plugin
<AfC> jam: perhaps someone in the Bazaar team might consider adding bzr-git to that PPA, then.
<maxb> right... hmm, I'd want it asynchronous from user's pushes
<jam> AfC: well, until recently bzr-git was quite alpha state, if Jelmer feels it is ready to be in 'production' then we can consider it
<jam> of course, we'd need someone willing to actually do the packaging
<maxb> Also I need to come up with some way to make it work for new branches, without manual configuration for each branch
<AfC> jam: sure.
<AfC> jam: (but consider people are *using* it out of Karmic, so maybe we can just take "in production" as read)
<spiv> maxb: hmm, it *might* try to use locations.conf too
<spiv> maxb: if not that's probably fairly easy to fix.
<poolie> jam, hi
<poolie> about https://code.launchpad.net/~mbp/bzr/499637-default-uifactory/+merge/17358
<poolie> there are two stages
<poolie> the first is making SilentUIFactory still be silent and not error if you try to make_output_stream
<poolie> the second is defaulting to text output if you do no special initialization
<poolie> which i think would be reasonable
<poolie> but is a bit blocked by the circular import problem
<jam> poolie: I think no progress bars, etc is reasonable without configuration
<jam> for interactive mode, etc.
<jam> I don't know, I feel like we have a bit of a "bzrlib.actually_make_things_work()" issue
<jam> load_plugins, trace.enable_default_logging, install_bzr_command_hooks,...
<jam> make_ui_factory()
<jam> If we had a standard function for plugins to call to set up bzrlib as though it was a command-line client
<jam> that might be the best thing
<jam> and then put whatever we need to in there
<jam> instead of telling people ad-hoc that "In 2.1 you need to call these functions to get set up."
<mwhudson> jam: load_plugins()!
<poolie> that would avoid the problems of doing it at import time
<jam> poolie: right, and unless we are going to do the rest of them at "import" time, then I think it makes sense to have a helper function
<poolie> i wonder if one size fits all?
<jam> poolie: pass it flags
<jam> with **kwargs so it is forward & backward compatible
<jam> when I debug in interactive mode, I generally copy & paste "from bzrlib import branch, trace, ui; trace.enable_default_logging(), ui.ui_factory = ui.make_ui_factory..."
<jam> as the first line
<jam> I do wish it was a bit easier
<poolie> then they could say plugins=False
<poolie> for examlpe
<jam> poolie: right
<poolie> wfm
<poolie> kwargs, or maybe a dict of options?
<jam> poolie: kwargs is easier to type
<jam> but either is ok
<poolie> but it's a kind of one-shot thing
<jam> I can always do "foo(dict(a=1,b=2))" :)
<poolie> i kind of like to keep it as an escape valve
<poolie> right
<jam> anyway, time for me to go
<poolie> k
<jam> maybe I'll see you later
<poolie> please send a patch pilot wrapup around the end of your week?
<jelmer> spiv: awesome to finally see the per-file-merge happening
<spiv> jelmer: :)
<poolie> hi spiv, jelmer
<jelmer> hi poolie
<poolie> lifeless, jml, what's the best place to talk about tribunal-subunit? istm maybe on the overall testtools-dev list?
<spiv> poolie: or possibly testing-in-python?
<poolie> mm
<poolie> i wonder if detailed conversation there would be too intrusive though
<spiv> poolie: well, so long as you make some noise about tribunal-subunit on t-i-p at some point, I think it'll be worth advertising :)
<lifeless> poolie: subunit dev has all the relevant people I thik
<lifeless> poolie: testing-in-python would be good from the wider-audience perspective
<lifeless> poolie: I don't think there is a testtools-dev specific list, last I saw the list for testtools is testing-in-python
#bzr 2010-01-15
<poolie> spiv, igc, lifeless, do you think https://code.edge.launchpad.net/~mbp/bzr/456077-cross-format-fetch/+merge/17354 is worth merging to 2.0?
<poolie> it is a bug, and a mysql bug, but
<poolie> there's some risk of regressions
<poolie> and i think not a high-impact bug
<poolie> so i have doubts
<lifeless> poolie: no strong opinion
<thumper> lifeless: a fix for your most annoying code bug is playing in ec2
<lifeless> thumper: \o/
<lifeless> thank you
<jkprg> hi. how could I list all branches of centralized repository?
<CardinalFang> jkakar, there's a plugin that will download all tips.
<jkakar> CardinalFang: Tips for what? :)
<poolie> jkprg: 'bzr branches' (may be in bzrtools)
<jkprg> poolie: thx. I have some problem with this command. it generates error of pycrypto (http://nopaste.info/b5e646b452.html)
<poolie> it's not an error, it's a bug in another python library
<poolie> i think recent bzrs suppress it?
<jkprg> poolie: may be i'm too fresh. i have bzr 2.1.0b4
<poolie> can you file a bug please?
<poolie> https://bugs.edge.launchpad.net/bzr/+bugs
<poolie> i thought there was one but this may be a different issue
<jkprg> poolie: sure
<jml> poolie, sorry, you asked earlier about where to talk about testtools.
<jml> poolie, I'm sorry but I don't have a clear answer -- hip-deep in sprint, and not satisfied by the current channels for communication.
<poolie> np, not at all urgent
<poolie> i shall blather on subunit-dev i think
<poolie> hi spiv, still around?
<spiv> poolie: yeah
<DaffyDuck_`> Let's say I want to ignore everything under src/, except src/sys/dev/cgd.c and src/sys/kern/kern_main.c. Is there a way to accomplish this using .bzrignore?
<lifeless> bzr ignore ./src
<lifeless> bzr add src/sys/dev/cgd.c src/sys/kern/kern_main.c
<lifeless> (adds take precedence over ignores)
<DaffyDuck_`> Oh, I thought "ignore"
<DaffyDuck_`> ... ah. :)
<DaffyDuck_`> Many thanks.
<DaffyDuck_`> Makes sense, now that I think about it.
<lifeless> np
<vila> hi all
 * fullermd waves at vila.
<lifeless> hi vila
 * vila feels welcome :)
<DaffyDuck_`> lifeless: There's an interesting side effect when adding ./src to .bzrignore, and adding explicit files. Once I added the explicit files, it adds the paths up until the files, which means it finds lots of "unknowns". I guess I could set an explicit "ignore everything under ./src" rule? But how?
<lifeless> DaffyDuck_`: hmm, let me check
<DaffyDuck_`> I tried something like RE:./src/.*
<DaffyDuck_`> Aha. "RE:src/.*" seems to have done it.
<lifeless> bzr ignore './src/**/*'
<lifeless> if you want to use an re thats fine - but be sure to anchor it to root
<DaffyDuck_`> Even better. Thanks again.
<lifeless> as you don't want to ignore *any* dir called src, only ones at the top.
<DaffyDuck_`> Yeah, that's what I was worried about.
<lifeless> contrast with (for instance) 'bzr ignore Makefile.in' where any Makefile.in should be ignored.
<lifeless> poolie: ping
<poolie> hi
<lifeless> something is calling stopTest without calling any outcome, for a number of tests
<poolie> ... to cause that behaviour i complained about?
<lifeless> to cause the stderr output
<lifeless> its because the test before the first one shown hasn't 'finished' in the stream.
<poolie> something in bzr?
<lifeless> yeah - bzr/testtools
<lifeless> if you run subunit-stats < subunit.out | head
<poolie> :{
<lifeless> you'll see the start of a subunit stream
<lifeless> look in subunit.out with vim, find the test: line that was at the top of head
<lifeless> and look up
<poolie> mm
<lifeless> you'll see a test that is misbehaving
<lifeless> its probably my fault :)
<poolie> mm
<poolie> test_info_locking
<poolie> there is a test line but no other mention of it
<lifeless> right
<poolie> are you allowed to have multiple tests in flight at once?
<lifeless> that means that startTest was called, but not addSuccess/addSkip/addExpectedFailure/addError/addFailure/addUnexpectedSuccess
<lifeless> poolie: in a single stream, no. the parser will emit an error for that test after the stream ends at the moment.
<poolie> i kind of want a --strict that will flag these
<poolie> or a subunit-lint
<lifeless> poolie: It may be a good idea to warn on any token seen out of state; I don't at the moment to be as transparent as possible.
<lifeless> if you do subunit2pyunit < subunit.out
<lifeless> you get
<lifeless> ERROR: bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_not_versioned(PreviewTree)
<lifeless> ----------------------------------------------------------------------
<lifeless> _StringException: lost connection during test 'bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_not_versioned(PreviewTree)'
<poolie> mm
<poolie> it may be better but it's not exactly clear
<lifeless> I agree.
<poolie> sorry if that sounds grumpy
<lifeless> We can definitely have a specific linter
<lifeless> I'm hesitant to make the main parser more aggressive though.
<poolie> yes that makes sense not to
<lifeless> you don't sound grumpy
<lifeless> this is with bzr.dev yes?
<poolie> i think i'd like it to try to catch up and keep going
<poolie> approximately
<poolie> so
<poolie> i'm going to stop for today
<lifeless> what combination of bzr branch + testtools version did you use to generate the subunit.out ?
<lifeless> poolie: ^
<lifeless> vila: ping
<vila> lifeless: pong
<lifeless> bug 507804 - is it possible that you have the same sort of damage to the subunit stream you're testing subunit2gtk with ?
<ubottu> Launchpad bug 507804 in subunit "subunit-filter doesn't seem to actually filter" [Undecided,New] https://launchpad.net/bugs/507804
<poolie> lifeless: it's within a few revs of bzr head
<poolie> well, ~mbp/bzr/progress if you want to be specific
<poolie> and
<poolie> >>> testtools.__version__
<poolie> (0, 9, 2, 'final', 0)
<lifeless> poolie: could you try running just ./bzr selftest --subunit bzrlib.tests.blackbox.test_info.TestInfo.test_info_locking | subunit-stats before you sign off
<vila> lifeless: I don't think so but I notice that:
<poolie> Total tests:       2
<poolie> Passed tests:      2
<poolie> Failed tests:      0
<poolie> Skipped tests:     0
<vila> ./bzr selftest -s bt.test_log --subunit | ~/src/subunit/trunk/filters/subunit2gtk is broken
<lifeless> poolie: ok, so whatever damaged the stream either needs a full test run, or was post-output from bzr
<vila> while redirect the output and then using the file works (selftest > file ; filter < file)
<poolie> the whole module works
<lifeless> vila: just tried it - it worked for me
<vila> lifeless: so not bug #507804, but something specific to subunit2gtk
<ubottu> Launchpad bug 507804 in subunit "subunit-filter doesn't seem to actually filter" [Undecided,New] https://launchpad.net/bugs/507804
<lifeless> vila: thanks
<poolie> but now i have to go
<lifeless> poolie: thanks
<poolie> dinner and extremely strange movies at the Chauvel
<lifeless> enjoy!
<lifeless> Did you do any post processing of the stream?
<vila> lifeless: what worked ? selftest | filter ?
<lifeless> vila: ./bzr selftest -s bt.test_log --subunit | ~/source/unittest/subunit/working/filters/subunit2gtk
<lifeless> 67 ok, 0 not ok.
<vila> lifeless: try subunit-stats as the filter
<vila> oh damn, my version says 67 ok when stats says 70, whereas trunk says 67 ok 1 nok when stats says 70 >-/
<vila> lifeless: right, got that fixed too, hup is trigger-happy so we should process all pending reads first
<lifeless> visik7: welcome back
<vila> lifeless: right, got that fixed too, hup is trigger-happy so we should process all pending reads first
<lifeless> vila: I don't like the approach
<vila> lifeless: pushed to lp~vila/subunit/gtk-filter-fixes
<vila> lifeless: fine with me, as long as you fix the bugs :)
<lifeless> vila: busy reading in 'idle' is not nice
<lifeless> vila: in particular, running two or three of these in the same process is going to end badly  (think multiple ec2 machines)
<vila> installing/uninstalling io watch have race conditions, you can miss events
<lifeless> vila: ! its not level triggered ?
<vila> I didn't change *when* we read, you said the UI is starving, fine, let's process the events
<vila> level triggered means ?
<lifeless> edge vs level
<vila> ECANTPARSE
<lifeless> http://en.wikipedia.org/wiki/Interrupt#Level-triggered
<lifeless> If there is data to read, adding a watch should trigger a read
<lifeless> otherwisee a trivial 'cat foo' program that supplies 'test: foo\nsuccessful: foo\n' would not cause anything to be seen
<mneptok> mmmmm .... cat food.
<vila> right, but how is that relevant to the fact that the hup signal is handled while in signals are pending ?
<lifeless> vila: your branch has conflicts btw
<lifeless> currently the merge is nonsensical
<vila> lifeless: weird
<vila> Oh, right, got it, the conflict is genuine, I deleted the lostConnection call
<lifeless> vila: I've done something similar
<lifeless> see if that fixes it for you
<vila> lifeless: yup, fixed
<lifeless> thank you for catching this issue
<vila> lifeless: hmm, but now the UI is starving again when fed with a bug file...
<vila> s/bug/big/
<lifeless> vila: via cat ?
<vila> lifeless: filter <big_file
<lifeless> bah
<lifeless> I meant to write all=False
<fullermd> all=False == none=True?
<lifeless> idnar: pshed
<lifeless> bah
<lifeless> idnar: sorry
<lifeless> vila: PSHed
<vila> which is expected since all defaults to True
<vila> perhaps you meant it to default to False instead
<vila> yup seems to do the trick
<vila> Now you can compare both versions and see decide which behaviour you prefer
<lifeless> Scheduling a read later is better for now IMO
<lifeless> reentering into the event loop is nasty
<lifeless> imagine you had three streams
<vila> io_watch events are not the same as othe events (IIRC) I did it that way in a gtk app with admiteddly a single data source, but never encounter problems in years
<vila> lifeless: in fact, since the  loop is while event: process_event and the script can exit this loop *while there are still pending reads* I'm pretty sure it's safe :0D
<lifeless> vila: if you're playing with subunit
<lifeless> be sure to checkout testrepository
<vila> lifeless: sure, I came to subunit filters when toying with testrepository as you pinged me about it yesterday or the day before :)
<grettke> Hi. I had done a bzr unbind to work disconnected, and bound back to the remote branch. I want to blow away those changes now. Would you say, unbind and revert them, or, is there a simpler way?
<LeoNerd> pull --overwrite  ?
<grettke> I'll try it... just realizing that I ought to study up a bit more on the nature of doing the SVN model with BZR ;).
<lifeless> grettke: if you want to blow them away
<lifeless> grettke: then do 'bzr update; bzr revert'
<lifeless> grettke: when you're using a checkout, it works like a checkout :)
<grettke> lifeless: doh! :), pull in the changes and then blow them away, I see
<lifeless> grettke: updating makes your local offline work into a pending merge and sets the master as your tip
<lifeless> grettke: then revert discards the pending merge
<grettke> lifeless: thank you
<vila> lifeless: how do I get a subunit stream *out* of testr ?
<bialix> heya bzr
<vila> hi bialix
<bialix> hi vila!
<ruk> i am geting this error: http://pastebin.com/m4b2e273
<vila> ruk: what is en_IN ?
<vila> ruk: python doesn't know about it, that's the problem, try en_US.UTF-8 instead
<ruk> vila: how can i change it?
<vila> as in export LANG=en_US.UTF-8
<vila> ruk:  but it's strange you ended up with such a $LANG, any idea how you ended with that ?
<ruk> vila: no. i am using ssh login for first time and then i did $bzr
<vila> ok, so ask the remote admin about it
<ruk> btw i m stiil getting same error: http://pastebin.com/m790fa6e5
<ruk> vila: ok
<vila> ruk: oooh, that's english(India) does that ring a bell ?
<ruk> vila: yeah
<vila> ruk:  so you may try en_IN.UTF-8 instead, no need to force US on India :)
<ruk> vila: same error only lang is changin!
<vila> does it work with en_US.UTF-8 ?
<ruk> vila: i think i can ignore it!
<ruk> vila: but while trying to get branch i get "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. "
<vila> ruk: it's hard to tell if you don't tell me what works and what doesn't work
<vila> the later error is probably because you didn't 1) log to launchpad 2) didn't install your private ssh key on the host you're running bzr from
<ruk> ok
<ruk> vila: so i have to login separtely for launchpad from ssh also ?
<vila> ruk: that's the way ssh works, each host is seen as different unless you share keys, launchpad allows you to register which keys you will use, ssh allows you to specify which key you use when connecting to a given host
<vila> finally launchpad *requires*  ssh keys
<vila> so if you don't have keys you can't connect to launchpad
<ruk> vila: do i have to save on remote machin (ssh) the ssh key file?
<vila> ruk: that or create a new key pair and upload the public one on lp
<ruk> vila: i did ssh-keygen on ssh but i think it generated a new rsa key and overwrote on my preevious key.
<vila> what do you call shh ? The remote host ?
<ruk> vila: :)
<ruk> vila: ssh for connecting tto remote host.
<ruk> securely
<vila> ruk: I can't parse "i did ssh-keygen on ssh" where did you run that ?
<ruk> vila: i logged in using sssh . after loggin i did ssh-keygen
<vila> so you ran it on the remote host, then you didn't overwrote your local key, have a look into $HOME/.ssh on both your local and remote host to check
<ruk> vila: i see only three file. rsa, rsa_pub and known hosts
<vila> locally and remotely ? Same sizes ? Same dates ? Same content ?
<ruk> vila: how do i check remotley?
<vila> ruk: you know how to use ssh right ?
<ruk> vila: i m a total n00b with both ssh and bzr! :(
<vila> ruk: What are you trying to do exactly ?
<ruk> somehow i managed to keep my branch updated! ;)
<ruk> vila: i have been assigned a web adres for uploading my app. i was given an ssh acess too! i have my branch on Launchpad which i would like to push on the web adress assigned.
<vila> so assuming that web address is an url starting with either sftp: or bzr+ssh: and that your rsa_pub is part of their authorized_keys then just do bzr push URL
<vila> if that's not the case, you need to contact the admin for that URL and set things up with him
<ruk> ok
<ruk> is thr a GUI way of uploading branch on launchpad?
<ruk> :)
<beuno> ruk, maybe using bzr-gtk?
<bialix> ruk: bzr-explorer
<davidstrauss> Is it possible to "revert" the contents of the working tree to the tree contents of a revision on a remote branch?
<bialix> revert -r xxx ?
<jam> davidstrauss: bzr revert -r -1:$REMOTE_BRANCH
<davidstrauss> ah
<jam> or bzr revert -r branch:$REMOTE_BRANCH
<davidstrauss> jam: thanks
<davidstrauss> jam: I kept trying -r revno:-1@$REMOTE_BRANCH
<jam> @ => : would have worked
<bialix> nice
<bialix> never know it's possible
<bialix> hello jam
<jam> hi bialix
<bialix> does it works only for revno?
<maxb> Whether a revision specifier accepts a branch parameter is part of the revision specifier
<ruk> i am getting internal server error when i open some folder in my branch .however i can open files!
<Peng> ruk: Go on. Is this using Loggerhead or something? What does the server's error log say? Use index files or something?
<ruk> Peng: i am checking it through my web browser on launchpad
<lifeless> vila: testr failing --subunit
<vila> lifeless: hmm, testr help failing looks promising :-) What I had in mind I asked was the ability get a stream for any run though, which I since realized is just there in the .tesr dir
<vila> s.mind.mind when/
<lifeless> vila: Feel free to add a command to show an arbitrary run, with a --subunit option to it ;)
<lifeless> vila: I'd like access to the files in .testrepository to be arbitrated
<Peng> Great, ruk's gone... :|
<Peng> Well, if it comes to it, someone could check LP's logs./
<lifeless> 'codebounce down'. ;P
<lifeless> -> plan
<lifeless> -> plane
 * vila nods @ lifeless (about arbitrated access)
<beuno> oooh...  and that's with the new patch I think
<beuno> lifeless, you've been a lot on planes lately
<vila> wow, now that's a nasty trap: read a test, think , right, so that's how we implement it.... hours pass.... realize that the test is against a deprecated function :-( Worse, the deprecation is only a comment in the function >-(
 * vila search for a chicken to eviscerate just because
<Flare183> When I use bzr register-branch it gives me this error: bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 401 Unauthorized
<Flare183> How can I fix it?
<Flare183> Or what should I do?
<znik> when i do bzr merge lp:/... Is the online branch merged or the local one?
<maxb> lp: is an alias for bzr+ssh://bazaar.launchpad.net/ or http://bazaar.launchpad.net depending on whether you've registered your launchpad login - either way, it's remote
<Flare183> ok
<lifeless> beuno: not really
<lifeless> vila: what code?
<lifeless> maxb: flare probably needed to log in
<vila> lifeless: log.calculate_view_revisions
<Adys> is there a way to completely delete files from a repo? I got like 50mb of static content I branched off that's being downloaded every time I branch my website repo
<maxb> Adys: Unfortunately no, or at least, not without rebuilding a new branch which bzr will not consider to be related to the old one (so no merging between them)
<maxb> If this is potentially acceptable to you, install bzr-fastimport and read bzr help fast-import-filter
<Adys> mmh ill stay lazy
<Peng> Adys: Yes, but not easily.
<Peng> Adys: Um, mostly people use bzr-fastimport for it.
<Peng> Eeek.
<Peng> What was that?
<mneptok> Peng: netsplit
<quotemstr> Clearly, the network should go on one humongous server.
<Peng> mneptok: Well yes, but this one was combined with some nice lag. That's unusual.
<Peng> "[Lag: 14.13]" :D
<Peng> "[Lag: 70.63]" -- even better! (Sorry, I'll stop now.)
<Peng> Aww, 5.06 now. *Now* I'll stop. :P
<Peng> What about a mainframe? :D
<mneptok> a netbook with multiple OC-192s is better for IRC than a mainframe with a single 300kbps modem :)
<Peng> mneptok: You just have to get a bunch of keyboards and monitors and make the users sit right there.
#bzr 2010-01-16
<jam> lifeless: if you get a chance, I have an analysis of bug #507566 that could use another person with fairly intimate knowledge of the pack internals. I'm technically on a 3-day weekend
<ubottu> Launchpad bug 507566 in bzr "Overlapping autopacks can lead to unreachable revisions causing NoSuchRevision" [Critical,Confirmed] https://launchpad.net/bugs/507566
<lifeless> jam: I'm on 3 1/2 days leave + 4 days conf leave :). I'll have a look though.
<jam> lifeless: certainly, don't spend a huge time on it
<jam> you're just the best for the job :)
<fullermd> jam: Hey, I had an offhand question for you...
<fullermd> jam: I recall some months back there was a discussion about pyrex versions and some advantage or other that could be had in the Cish code if it could be written ignoring pyrex and using cython.
<jam> fullermd: 'cdef list foo'
<jam> will auto-use stuff like PyList_Append()
<lifeless> jam: sounds plausible to me
<jam> also, if you have a Cython class that has to 'object' members, it doesn't get a GC header
<fullermd> Are you aware of any advantage that using cython instead of pyrex would convey with the current code?
<jam> 'has to' => 'has no'
<lifeless> jam: I'd need to drop into a debugger to be more confident than that
<jam> lifeless: that's where I got the idea (in debugger)
<jam> fullermd: cython generates slightly faster code.
<jam> it uses stuff like "likely()" macros, etc
<jam> it isn't a huge diff
<jam> but it is there
<fullermd> Are release tarballs built with cython?
<fullermd> (and/or should they be?)
<fullermd> Sorry, I'm wandering way past my offhand question...  don't wanna bother you this late.
<Peng> There are also some hacks in the code for Pyrex compatibility.
<freelanc> i am getting this error while trying to resolve diverged branches http://pastebin.com/m59e08642
<bialix> hi
 * bialix looking for nmb
 * bialix sighs
<bsdemon> Hi, can I get content of versioned file without working tree, using only bzrlib.branch.Branch? Or I need to do a checkout
<chx> hi. two plugins questions. i branched something , the bzr dir was 66m , ran bzr index and now it's 97m is it normal that the index of 10mb worth of files is 31m? another thing, i checked out bisect, ran the python setup.py build_ext -i command and bzr selftest bisect and it was OK (37 tests) but it can't find the command bisect and bzr plugins does not list it.
<Peng> D'oh, chx left. Those 37 tests aren't related to the bisect plugin...
<tumbleweed> quick Q: doing a big file re-organisation in a bzr-managed project
<tumbleweed> is there way to carry history accross when merging multiple files
<tumbleweed> bzr mv-style
<thumper> abentley: ping
<abentley> thumper: pong
<lifeless> its too early for that sort of thing
<abentley> lifeless: look who's talking.
<lifeless> abentley: :)
<lifeless> abentley: around? got a small feature request for lp code notification emails
<abentley> lifeless: Just leaving.
<meoblast001> what's the name of the bazaar config file?
<lifeless> abentley: ah, kk. Just kirkland wondering if he can get a link to loggerheads commit view in the notification
<Peng> meoblast001: Which one?
<meoblast001> the one that lets me set my email
<Peng> meoblast001: You can do that with "bzr whoami".
<meoblast001> ah, ok
<Peng> meoblast001: But, FYI, depending on the platform, it's probably ~/.bazaar/bazaar.conf. "bzr version" will show you the location.
<Peng> s/location/directory.
<meoblast001> Peng: i usually use my Ubuntu system at home but i'm using my Fedora laptop
<meoblast001> i like consistant names in my email
#bzr 2010-01-17
<abentley> lifeless: That is bug #158163
<ubottu> Launchpad bug 158163 in launchpad-code "email notifications could have the revision url" [Low,Triaged] https://launchpad.net/bugs/158163
<lifeless> kirkland: ^
<kirkland> lifeless: cheers mate
<lifeless> anytime ;)
<lifeless> abentley: thanks for digging that up
<doctormo> I'm trying to discover how bzr does it's `bzr add` filtering, where it ignores certain files. What's the best way of filtering out these files?
<spiv> doctormo: 'bzr ignore'
<doctormo> spiv: Using bzrlib methods
<spiv> doctormo: hmm, not quite sure what you're asking, exactly.
<spiv> Are you writing a plugin that wants to extend the default ignore patterns list?
<doctormo> spiv: Sorry, bit vague, no, not aplugin
<doctormo> spiv: I've got a gui that shows the user what files to add, I'd like not to show ignored files.
<doctormo> Since their not added anyway
<spiv> Hmm, I'd probably look at what cmd_ls or cmd_ignored do.
<spiv> (in bzrlib/builtins.py)
<spiv> Yeah, cmd_ignored looks like a good example of this.
<doctormo> spiv: Looks like workingtree.is_ignored(path)
<doctormo> Mwhahaha! it works.
<doctormo> More simple that I feared too.
<spiv> doctormo: asking one-by-one might not be very efficient.  If you can, I'd probably try to use the list_files method of workingtree to look at a whole directory (or tree) at once.
<doctormo> spiv: This isn't that bad, it's already using only unversioned files, but the code I have is easier to write with a call to is_ignored since I'm already looping to add items to a tree view.
<edakiri> Is there some document which indexes cherry picking support related user documents for bazaar? I wish to discover whether support for it has extended since I was last up-to-date on bazaar use.  Are there extensions which extend support for cherry picking?  Is there a term for 'uncherry picking'?  I mean picking of what not to merge rather than what to merge.
<edakiri> As a status indicator, I found this, which seems to indicate that cherry support is not extensive; although it leaves my picture of support still vague.  https://blueprints.launchpad.net/bzr/+spec/bzr-cpick-data
<spiv> lifeless: you might get a chuckle out of this
<spiv> lifeless: try 'trial bzrlib/tests/test_selftest.py'
<spiv> lifeless: and guess what causes the 1 failure :)
<ElMonkey> hiya, i am trying to set up a loggerhead server via apache on debian/squeeze
<ElMonkey> but apparently, the init.d script is borked, does anyone have a sample i could look at?
<RenatoSilva> qbzr needs to make links between ()
<RenatoSilva> commit with a link: http://this-becomes-a-link.com
<RenatoSilva> other commit (http://this-does-not-become-a-link)
<lifeless> spiv: looks like some sort of test isolation interaction
<ruk> how can i copy LaunchPad RSA key to my shell?
<Peng> ruk: What do yo umean?
<Peng> you mean*, bah
<j1mc> hi all - i have a quick question.  i merged in a branch, the resulting merge conflicing .po translation files that I do not need.
<j1mc> what is the best way to remove them from the directory, and to resolve the conflict?
<j1mc> there are lots and lots of po files...
<j1mc> as a note, the *.po files are just translation files that will be updated when the doc content gets changed.
<RumblePure> How can I print the commit message of a previous revision?
<RumblePure> Like bzr info -r X for X's commit message?
<meoblast001> hi
<meoblast001> i'm looking for a BZR cia for servers
<meoblast001> so that when code is pushed to the server, it posts to CIA
<meoblast001> anyone know of any?
<tumbleweed> meoblast001: you can accomplish that with a commit hook: http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/hooks.html
<tumbleweed> here's an exmaple that prods a bot http://bazaar.launchpad.net/~ibid-core/ibid/trunk/annotate/head:/contrib/bzr-hook.py
<meoblast001> ok, well i'm thinking about hacking up a plugin to my bot that will sync up with BZR to do what CIA usually would
<tumbleweed> meoblast001: that's excatly what that example is
<meoblast001> ah, ok :)
<meoblast001> it's a plugin for my bot? (j/k) :P
<tumbleweed> (or you can poll the bzr branch)
<meoblast001> which one is more efficient?
<tumbleweed> meoblast001: no, for my bot :)
<tumbleweed> well, obviously notification has lower latency and bandwidth usage
<meoblast001> i could probably have my bot listen on port x
<meoblast001> then have BZR send it stuff over said port
<tumbleweed> that example notifies by HTTP
<tumbleweed> but it could be anything
<meoblast001> ah, ok
<meoblast001> time to learn Python :D
 * mzz tries to remember how he did that before
<RumblePure> how can I write a new log-format?
<RumblePure> I wanna create a log-format that only prints commit message
<spiv> Good morning.
<spiv> lifeless: at first glance I thought that failure was because bzrlib.builtins wasn't imported, then I saw that the bzrtools plugin was somehow loaded so now I'm less sure.
<Noldorin> hello.
<Noldorin> i'm having an issue trying to push to an svn repo using bzr-svn:
<Noldorin> bzr: ERROR: exceptions.KeyError: u'None'
<Noldorin> Traceback (most recent call last):
<Noldorin>   File "bzrlib\commands.pyo", line 842, in exception_to_return_code
<Noldorin> it's been working until recently. any ideas what could be going wrong?
<Noldorin> no problem pushing to a remote bzr repo btw...
<spiv> Noldorin: hmm
<spiv> Noldorin: pastebin the full traceback?
<Noldorin> spiv, sure - http://pastebin.com/m122b7c64
<spiv> Noldorin: it's failing on something to do with the repository layout
<Noldorin> spiv, oh...such as?
<spiv> Noldorin: have you set any config in ~/.bazaar/subversion (or whereever it is on your platform)
<Noldorin> erm
<Noldorin> don't believe so
<Noldorin> it just worked until now :)
<spiv> *nod*
<spiv> Well, I'm not sure why it's broken.  If jelmer is around he'll probably know.
<spiv> In the meantime file a bug on bzr-svn.
<Noldorin> yeah, hopefully...
<Noldorin> thanks anyway.
<spiv> You *might* be able to workaround it by manually setting the layout.
<spiv> But I don't even know what "it" is, so that's just a guess :)
<Noldorin> heh, would be kidn of lost there :P
<Noldorin> yeah, fair enough
#bzr 2011-01-10
<sobersabre> hi.
<sobersabre> I am trying to resolve conflict
<sobersabre> (I mean in bzr)
<sobersabre> and I think if I need to "take this", I should run:
<sobersabre> bzr resolve --take-this filename.txt
<sobersabre> but this DOESNOT resolve.
<sobersabre> what is the syntax for actions ?
<sobersabre> anyone alive ?
<LeoNerd> Hrmm... Any bzr command in one workdir here is just giving me:  bzr: ERROR: pack-names is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<LeoNerd> For reference, my .bzr/repository/pack-names file - http://paste.leonerd.org.uk/?show=1232
<maxb> LeoNerd: interesting... I've only seen pack-names that are "B+Tree Graph Index 2" format
<LeoNerd> I had some other workdirs that looked very similar, those worked
<LeoNerd> I've managed to work by just checking out again, seems happy
<AfC> sobersabre: just do
<AfC> $ mv file.txt.THIS file.txt
<AfC> $ bzr resolve file.txt
<sobersabre> hi.
<sobersabre> I have a bzr branch, and I want to push changes to it (remotely).
<sobersabre> I want to override any file that is not like the pushed ones.
<sobersabre> I currently run a merge. I think this is not correctly the thing I want.
<sobersabre> I want to simply put the changes and commit'em.
<sobersabre> And if athe target branch has uncommitted changes, I want to quit the operation.
<sobersabre> which bzr command best fits my description ?
<sobersabre> I am now reading the fine manual of push: bzr --strict --overwrite push /branch/name I think is what I want.
<pluma> I'm used to creating a bare git repository on my virtual linux testing server, cloning it on my windows desktop via SSH and pushing back from the shell. How can I recreate this workflow with bazaar?
<pluma> Note: my virtual linux server may or may not be online, so it is important that the push is triggered manually.
<maxb> pluma: 'bzr init-repo --no-trees path/to/repo' on the server
<pluma> maxb: Can I make bzr use defaults so I don't have to type out the full repository path everytime I type "bzr push", too?
<maxb> bzr will remember the first-used push and pull locations automatically, and use them if no location is specified
<pluma> Ah, good.
<maxb> afterwards, you can use push/pull --remember to reset the remembered location
<pluma> Ah.
<pluma> Should I have one repository shared among all projects or one repository per project? The docs confused me a bit about that.
<maxb> For most purposes it does not really matter. In Bazaar, a repository is just a disk-space and time optimization
<maxb> So, it's important that branches of a project reside in one repository, to get those advantages of not needing to store revisions twice
<maxb> Personally I prefer to go one repository per project, but there's no harm to multiple projects residing in a single repository
<maxb> Except that if you ever did need to separate them, you'd have to branch each branch into a new shared repository of smaller scope, rather than just being able to move directories around on disk
<pluma> maxb: Okay, I did init-repos and init on the server, checked out locally, shut down the server and committed. The commit failed because the server can't be reached. Is there a way to make it _not_ auto-push?
<maxb> Ah, it's only trying to do that because you used 'bzr checkout' rather than 'bzr branch'. To change the behaviour of an existing checkout, use 'bzr unbind'
<pluma> Okay. I unbinded, committed successfully, restarted the server, pushed successfully and am a happy bunny. You're saying I won't need to specify the target when pushing again?
<pluma> maxb: Thanks for the help so far. I'm a bit surprised that I found the initial hurdles of bzr bigger than those of git (probably because of the shared repos), but I'm excited to see how this will turn out in the long run.
<pluma> Any thoughts on fossil?
<jam> lifeless: https://code.launchpad.net/~jameinel/lp-production-configs/lp_service_qa_staging/+merge/43921
<knighthawk> I've set up a central repo. But when members of my team check out they are getting different revisions. Like the latest is rev 11 one team member is able to get that one but another is only able to get up to 9 and another can only get rev 7
<knighthawk> I haven't had them ask for rev 11 yet. Wondering what I did wrong in setting up the central repos that they are seeing this.
<jelmer> knighthawk: how are they creating their clone and how are they pullin gin new revisions?
<knighthawk> bzr checkout to get their branch (though the eclipse plugin) and I think they are using bzr up to get new revisions.
<maxb> Have you checked the exact URLs various people are using, by making them show you their 'bzr info' output?
<jelmer> knighthawk: does the eclipde plugin use checkout, not "bzr branch"?
<knighthawk> checking
<knighthawk> okay no it *does* do a branch. Any reason that wouldn't allow them to access the Head?
<knighthawk> rev 11 should be head at this point.
<knighthawk> but when they branch they get rev 7
<jelmer> knighthawk: if the branch is not bound they should use "bzr pull" rather than "bzr up"
<knighthawk> okay I don't know too much about bounding except I did have to do that for myself. is it likely that they can set up bounding from a gui?
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | | 2.3b4 is officially out ! (rm vila)
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila  | 2.3b4 is officially out ! (rm vila)
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila)
<knighthawk> its still says "Tree is up to date at rev 7"
<knighthawk> tried bzr bind
<knighthawk> just forced a checkout.
<knighthawk> I'm noticing that when I run bzr info I'm getting submit branch and when they do they do not.
<jam> spiv: https://code.launchpad.net/~jameinel/bzr/2.3-update-from-readonly-701212/+merge/45760
<poolie> looks good to me
<lifeless> jam: btw - https://lp-oops.canonical.com/oops.py/?oopsid=1834CBB6546
<lifeless> jam: we're not showing codebrowse oops properly
<lifeless> jam: if poolie is there, can you poke him onto irc
<jam> lifeless: he is here, I'll poke him, but when I go to that page, I get nothing
<jam> just a search box
<lifeless> jam: thats the openid login brokeness - see the url you ended up on :P
<jam> lifeless: hmm,, re opening that page, I get something
<lifeless> hi poolie
<poolie> hi
<lifeless> poolie: I've filed a couple of shallow loggerhead bugs that we're capturing now we get loggerhead bugs
<poolie> ?
<lifeless> s/bugs/oopses/
<poolie> ok
<lifeless> we're getting 16000 oopses a day
<poolie> hooray
<lifeless> https://bugs.launchpad.net/loggerhead/+bugs?field.tag=oops
<lifeless> in launchpad we treat oops as higher-than-high bugs today
<lifeless> in the new triage process we'll treat them as critical
<poolie> bug 700,000 hey?
<ubot5> Launchpad bug 700 in boa-constructor (Ubuntu) "After installing Boa Constructor, no menu items in Gnome" [Medium,Fix released] https://launchpad.net/bugs/700
<ubot5> Error: Could not parse data returned by Launchpad: 0 (https://launchpad.net/bugs/0)
<lifeless> I'm wondering if you can ok mkanat to look at these?
<poolie> if he has time i'm very happy for him to
<lifeless> he said to talk to you :)
<poolie> ok, loop closed then
<mkanat> poolie: You mean if I have time after the things we've already discussed?
<lifeless> later today I should get the first frequency analysis of these oopses
<poolie> what's in your queue now?
<poolie> mkanat, ^
<mkanat> poolie: Etags and then performance of single requests.
<poolie> i think it's fair to treat these ahead of them
<poolie> because they're actually failures
<mkanat> poolie: Okay. Even if it means not getting to those?
<poolie> yes
<mkanat> poolie: Okay.
<poolie> https://bugs.launchpad.net/loggerhead/+bug/701256 is kind of interesting
<poolie> in a way, it is valid for it to be a bug
<poolie> i mean an oops
<poolie> it's an error meaning we can't show the branch to the user
<mkanat> Yeah, I mean, I'm not sure that I want to mask every single possible bzr error from the user.
<catphish> what network protocols does bzr support for cloning / publishing?
<poolie> ftp, sftp, ssh, http
<poolie> you can add others
<catphish> great :)
<poolie> mkanat, so i'd probably do the other two first
<mkanat> lifeless: Are the ones you're reporting ones that you know to be frequent, or do you not have any frequency analysis at all yet?
<mgz> <lifeless> later today I should get the first frequency analysis of these oopses
<mkanat> lifeless: Okay. Once you have that, let me know and I will fix the most frequent ones first.
<lifeless> james_w: ping
<james_w> hi lifeless
<lifeless> mkanat: I would start with any
<mkanat> lifeless: I only have a limited amount of time available.
<lifeless> james_w: could you spare a few minutes to look at a bzr-builddeb pristine-tar-using-failure with me and ncommander in presidente on 3?
<mkanat> lifeless: It's not a scheduling matter; it's a contract thing.
<james_w> lifeless, sure, 2 minutes and I'll be there
<lifeless> mkanat: sure, uhm the KeyError one worries me most in terms of correctness
<lifeless> mkanat: the other two worry me in potential volume
<mkanat> lifeless: Okay. Well, you'll have the analysis later today, right?
<mkanat> lifeless: So then we won't have to worry too much about potential volume, we can just know for sure what's got the highest volume.
<jam> vila
<jam> vila
<jam> vila
<james_w> lifeless, http://paste.ubuntu.com/552623/
<jam> I was trying to figure out what timer was going off
<james_w> lifeless, something to do with export + .bzrignore?
<mkanat> lifeless: The KeyError one does sound like something that shouldn't ever be happening, though.
<mkanat> And that I did fix.
<lifeless> james_w: is bzr-builder integrated with pristine-tar yet ?
<james_w> lifeless, no
<james_w> lifeless, so, pristine-tar gets unhappy if you don't give it all the files, and we provide those files by exporting the tree, so .bzr* will be missing. My hunch is that we can get away with providing /more/ files that pristine-tar needs, so we could use sprout rather than export, or add a hack and manually export any .bzr* files in the tree
<lifeless> argh!
<jam> vila
<mkanat> lifeless: Oh, somehow sourcedeps never got updated to pull in the loggerhead that had the fix for that KeyError.
<mwhudson> mkanat: ! :(
<mkanat> mwhudson: I know.
<mkanat> mwhudson: I'm proposing a merge for that now.
<mkanat> https://code.launchpad.net/~mkanat/launchpad/lp-loggerhead-update/+merge/45787
<lifeless> james_w: what does builder do for v3?
<james_w> lifeless, falls over
<lifeless> ok
#bzr 2011-01-11
<mkanat> lifeless: Merging that sourcedeps.conf update that I just proposed should fix the KeyError.
<lifeless> thank you
<maxb> Hrm... help?  I'm hacking on bzr-svn, and I'm getting exceptions a lot.... and every time, bzr fires up apport needlessly
<maxb> How do I stop it?!
<poolie> hi maxb
<poolie> ah
<poolie> turn on the no_apport debug flag
<mkanat> lifeless: I'll fix that revision number one, too.
<poolie> if you check the "don't show this again" that ought to work
<poolie> for the particular bzr script in question
<maxb> poolie: seems to work on the command line, but not in bazaar.conf
<maxb> and I don't have any 'don't show this again'
<poolie> really not in bazaar.conf?
<poolie> debug_flags = no_apport
<poolie> i think i've used that myself so i'm surprised if it's failing
<maxb> hmm. I think I may have assumed debug_flags was a space-separated list erroneously...
<maxb> :-)
<poolie> commas
<poolie> or ', '
<maxb> Still, it does seem a bit quirky that bzr does not honour the systemwide apport enabled status
<poolie> mm
<poolie> maybe
<poolie> that one flips as ubuntu goes into release mode, meaning "ubuntu no longer wants so many crash reports"
<poolie> i see that as a bit orthogonal to whether we want them in bzr
<maxb> I suppose.
<maxb> ugh, this is mad. bzr-svn is calling svn's get_dir on various things, some of which are files, and only some of the files trigger a SubversionException: ("Can't get entries of non-directory", 160016)
<jml> poolie: you still in #516?
<poolie> yes
 * jml goes to rock a small part of the world.
<mkanat> lifeless, poolie: Okay, proposed a merge for the "no such revision" oops.
<poolie> nice
<mkanat> It actually was good to fix, because it fixes it for every page, since the code is centralized for reading the revno from the URL.
<maxb> huh, novel. bzr-svn just managed to eat 4GB of RAM and drive my machine so much into swap death that I had to kill it from a text console :-/
<jelmer> maxb: what were you trying to do with it?
<AfC> Hi
<gthorslund> morning #drizzle! happy bugs week!
<gthorslund> hehe... morning #bzr
 * gthorslund little buggy today :D
<maxb> jelmer: Run a svn-import with a custom layout class which involved importing a repository with unusually many branches
<neaj> 'lo all -- I have a bunch of config files in .../configs , now i want to 'bzr merge configs/a configs/b'. bzr tells me "Nothing to do", but that's not true. What am I missing?
<sobersabre> hi.
<sobersabre> is it possible to see when the last operation of format conversion of a repository has happened ? (local bzr upgrade call)
<neaj> also, i want to 'bzr get configs/b', but bzr tells me: "bzr: ERROR: Not a branch:"
<neaj> 'bzr get configs' works, but i don't want all the configs here.
<kgoetz> sobersabre: ~/.bzr.log might carry it
<bob2> neaj: bzr doesn't currently support checking out part of branches, afaik
<bob2> I don't think any modern vcs does
<neaj> i believe with svn you can checkout any dir in the repo ..
<bob2> right
<bob2> 'modern' :-)
<neaj> heh OK
<bob2> bzr split is a thing, but I don't know how well it works nowadaus
<neaj> OK so how to merge configs/a configs/b ?
<neaj> i can do diff and patch, but that's hardly modern ;-)
<neaj> bzr has no support for merging within a branch?
<neaj> making config/a a branch of config/b just to enable merging wouldn't make sense. they're just configs that happen to be mostly similar.
<catphish_> is is possible to specify the local path to a branch in bzr commands?
<catphish_> ie a path to cwd to before executing the command
<bob2> pretty sure you can just use a normal path and it'll find the bzr repo above that
<catphish_> how do you specify that path?
<bob2> bzr add /who/cares/long/path
<catphish_> that's useful for add
<catphish_> but for example 'cat'
<bob2> it's also useful for cat
<catphish_> i'll try it
<bob2> less useful for ci
<catphish_> so there's no global cwd option?
<bob2> dunno
<catphish_> but you can specify it on individual commands as part of the filename
<catphish_> ok
<catphish_> it works for cat :)
<maxb> There is no global option, which is quite annoying sometimes. Many commands support -d / --directory, but not all
<catphish_> ok
<catphish_> it's useful that you can specify it as part of a filename
<catphish_> but i might just cd to the path before each command
<quicksilver> anyone understand bzr merge internals well enough to tell me what it does in this case here? : http://web.archive.org/web/20070603113858/zooko.com/badmerge/simple.html
<quicksilver> bzr also gets it "wrong".
<quicksilver> FWIW.
<Odd_Bloke> quicksilver: bzr has several merge algorithms, tried them all?
<quicksilver> Odd_Bloke: I tried default and weave
<jelmer> maxb: find_branches() in svn-import has known memory usage issues
<maxb> I think those are what I saw
<maxb> jelmer: oh, there was something else I was struggling with, that confused me intensely. The repository I was working with had some doc files at the hierarchy level where branches were.
<maxb> bzr-svn seemed to be attempting to interpret the paths as branches, and was calling conn.get_dir(...) on them
<maxb> Much to my complete confusion, for *some of them only*, this would cause libsvn to error "Can't get directory entries for a non-directory"
<maxb> Does anything like that sound at all familiar to you?
<jelmer> vaguely, yeah. IIRC this was a svn server bug
<maxb> Does bzr-svn mostly rely on people not having files at places in the hierarchy where it's looking for branches, or did I miss some detail when I went to implement the custom layout class?
<maxb> The layout call that seemed to be involved doesn't get passed a revno, so checking in the repo is not feasible
<maxb> Oh, actually, it looked more like finding *tags* was what killed it for me
<catphish_> what would be the most lightweight way to detect if a repo is empty, and how many commits exist in it?
<catphish_> *branch
<maxb> cat .bzr/branch/last-revision     ? :-)
<catphish_> does last-revision always == number of revisions?
<catphish_> i assume it does
<maxb> the number in there is the number of *mainline* revisions
<catphish_> mainline? (excuse my ignorance)
<maxb> i.e. bzr merge bighugebranch; bzr commit will cause it to go up by 1
<catphish_> that's merging from a totally separate branch right?
<maxb> depends what you mean by "totally separate", but probably yes
<catphish_> i'm easily confused because i come from a number of SCMs where one repository has multiple branches
<catphish_> and while that is true in bzr, the branches are almost entirely separated
<catphish_> i'm trying to git bzr into an environment where one repository has multiple branches
<catphish_> which is true of bzr :)
<catphish_> but in a way i'm not used to
<catphish_> for example to switch branches, one has to switch to a different location on the filesystem
<jml> do you guys know about this warning in natty?
<jml> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
<jml> /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
<jml>   RandomPool_DeprecationWarning)
<maxb> jml: It's been around for aaaages, but you don't see it normally because warnings are suppressed in bzr final releases. But natty currently has a beta.
<jml> maxb: ahh, I see.
<maxb> IIRC it's waiting for the paramiko team to merge the fix
<jml> maxb: Isn't the paramiko team just Robey?
<maxb> could be, I don't know
<jml> :)
<jml> maxb: I guess it's safe for me to ignore the warning for now.
<spiv> jml: yeah, it's safe
<poolie> maxb, around?
<maxb> hi
<poolie> maxb i think our 2.2.2 SRU should now be unblocked
<poolie> per https://lists.ubuntu.com/archives/technical-board/2010-December/000632.html
<poolie> what do you think?
<maxb> I think *technically* we were also waiting for 2.3b4/5 in natty
<maxb> (Because fixes are supposed to enter natty first)
<poolie> hm, really?
<poolie> even with a MRE?
<poolie> if we were backporting particular patches that would make sense,
<poolie> but if we've generally said "2.2.x is acceptable"
<maxb> yeah, but we're being quite odd by shipping a beta in natty currently
<maxb> most packages wouldn't do that
<poolie> why?
<poolie> i mean why odd?
<poolie> because they're kinda counting on it becoming stable before release?
<maxb> Well, it's relatively rare for packages to have beta versions in the archive, that's all
<poolie> right, though not unprecedented
<poolie> is this a concern to asking for an sru?
<poolie> i'd just like to get them actually out, now we've done the releases
<maxb> poolie: Understood, I just don't much feel like requesting a SRU whilst we're violating point 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<poolie> i see what you mean
<poolie> i think that procedure doesn't really allow for the existence of MREs though
<poolie> in fact it pretty much contradicts it
<poolie> so, i'd like to persuade you to request one and have the conversation with them
<quicksilver> is there a way to "resurrect" a deleted file in a way that bzr will actually see as an undeleted?
<quicksilver> of course I can just extract it from an old revision and re-add it, but I'm curious
<fullermd> revert it to a rev it was in.
<quicksilver> ah
<quicksilver> I always forget you can revert single files
<quicksilver> I always think of doing bzr operations on whole trees
<quicksilver> thanks
<poolie> quicksilver, i think there's actually a plugin that adds a 'resurrect' command
<quicksilver> bzr can't track the case where a file 'becomes two files', can it?
<maxb> no
<maxb> Hence wailing and gnashing of teeth in the bugtracker concerning 'bzr cp' :-)
<poolie> so, maxb, about the sru?
<poolie> do you have reservations yourself about proceeding with it, or do you just think it will be rejected, or ..?
<maxb> poolie: two things: I'm not happy to push this ahead myself without an explicit waiver on point 1 from ubuntu-sru (because my enthusiasm for this SRU is low and I don't see worth in pushing the borders of policy), and additionally, it's not ubuntu-sru's job to upload packages, so you need to speak to ubuntu-sponsors first, I think
<poolie> ok
<poolie> your enthusiasm for this SRU is low because...
<poolie> the bug fixes in it aren't exciting enough?
<maxb> I feel it's taken so long, that most people who care are probably on ~bzr/ppa already
<poolie> hm
<poolie> well, in general i do want to get updates out
<poolie> i want to fix up the sru process so that it there aren't such long delays in future
<maxb> hmm, actually I'd forgotten the dput hang is in there
<poolie> i wonder if everybody affected by these things has really upgraded to the ppa
<poolie> i know, fixed by you even
<poolie> it's actually the lead bug for the request
<maxb> See, my mind is on 2.3 these days, 2.2 seems so old :-)
<poolie> :)
<poolie> we were just saying this morning that if we're not going to push them all the way through the process, we almost might as well not do bugfix releases
<poolie> i can ask -sponsors to upload it to -proposed
<poolie> that might be good practice for me
<poolie> i just wanted to understand how you thought about it
<maxb> Alright, so I take back my concerns about it not being SRU-worthy, but I'm still reluctant to press the SRU without conforming to the process w.r.t. fixing in natty first
<lifeless> james_w: so _export_iter_entries does not permit including . bzrignore
<lifeless> james_w: one way to fix things would be to provide a flag to control that
<nekohayo> hey there, I did      echo "the revision ID I got from bzr viz" > .bzr-upload.revid        on my remote host because the files are already there and I don't want to reupload them again
<nekohayo> but when I try to bzr upload, it says that my local repository has no such revision
<beuno> nekohayo, and you're sure you didn't put in the revno, but the actual revid?
<nekohayo> yeah, it's foo@bar.com-20110111174334-cg5oj39oq3piua8c
<poolie> i wonder if it's unhappy about whitespace or something?
<nekohayo> hm, what whitespace?
<nekohayo> oh
<nekohayo> maybe there's a \n at the end of the file and it doesn't like that
<nekohayo> poolie, do you have a trick to remove the trailing \n  ?
<poolie> yes
<poolie> echo -n FOO > file
<nekohayo> that worked
<nekohayo> wondering if I should file a bug though
<james_w> lifeless, that would work
<poolie> nekohayo, hm, generally speaking hacking internal files isn't documented
<poolie> s//isn't a bug
<poolie> but you could put up a merge proposal that adds it to the documentatino
<nekohayo> but for some use cases like this, I presume it can't hurt to strip out the trailing \n ?
<nekohayo> oh well
<nmendes> hi, can anyone help me? I'm having this problem:
<nmendes> bzr branch "svn://localhost/[delphi] dws gestor de licenÃ§as/trunk" C:\[dataworks]\RepositÃ³rios\test
<nmendes> ERROR: Unsupported protocol for url "svn://localhost/[delphi] dws gestor de licenÃÂ§as/trunk"
<maxb> vila: Really, Won't Fix, on bug 701581? I'd say Importance Wishlist, give us a branch if you care
<ubot5> Launchpad bug 701581 in bzr Upload plugin "Escape \n line returns in .bzr-upload.revid" [Undecided,Won't fix] https://launchpad.net/bugs/701581
<maxb> nmendes: Do you have bzr-svn installed? Run 'bzr plugins' and see
<nmendes> k, gonna try, tx
<vila> maxb: well.... what will be the point of making the plugin *less* robust ?
<maxb> vila: Lots of bzr internal files are line based. I wouldn't begrudge a .strip() call in there
<vila> maxb: but this can only happen if the file has been... tampered ?
<maxb> true, but people are encouraged to tamper with ~/.bazaar/*, .bzr/branch/branch.conf, so it's not that great a leap for people to try this
<vila> maxb: bzr-upload runs on a rather thin ice relying on this file to make sure it was the one doing the upload, editing this file will never be recommended so I don't want to encourage it either
<maxb> Basically I agree it's not worthy of yours or my time to make bzr-upload more tolerant here, but I was surprised at the implication we'd refuse a branch even if offered
<vila> maxb: well, I'm not ready to accept such a branch so instead of saying no if one is proposed, I thought it was more honest to say upfront: "no, this is not a desired feature"
<maxb> fair enough. I'd have suggested it was an acceptable change, but I doubt I'll ever use the plugin, so I don't have strong feelings on it
<vila> maxb: and it's probably the first time I used WontFix
<vila> maxb: not mentioning that rsync will probably does a better job reagrding bandwith than the plugin, so...
<maxb> ok :-)
<nmendes> I have the bzr-svn plug in installed, the problem is the special char "Ã§" on the svn path, looks like it is tanslated  to "ÃÂ§" and so the command fails
<nmendes> same command with svn paths without those king of chars work as expeted
<maxb> That is odd. I would not have expected " Unsupported protocol for url " even if there was a charset bug of that sort
<nmendes> just did it:
<nmendes> C:\Users\Nuno Mendes>bzr branch "svn://localhost/[delphi] dws meteo/trunk" "C:\U sers\Nuno Mendes\Desktop\[delphi] dws meteo" Branched 13 revision(s).
<nmendes> C:\Users\Nuno Mendes>bzr branch "svn://localhost/[delphi] dws gestor de licenÃ§as /trunk" "C:\Users\Nuno Mendes\Desktop\[delphi] dws gestor de licenÃ§as" bzr: ERROR: Unsupported protocol for url "svn://localhost/[delphi] dws gestor de  licenâÂºas/trunk"
<nmendes> looks like a bug, right?
<maxb> Indeed, that looks like a bug
<maxb> Could you try creating a bzr branch with an accented character in its name, to discover whether it is a bzr or bzr-svn bug?
<nmendes> k
<jelmer> nmendes: what version of bzr-svn?
<nmendes> C:\Users\Nuno Mendes>bzr init-repo --format=default "C:\Users\Nuno Mendes\Deskto p\a name with a Ã§ just to test" Shared repository with trees (format: 2a) Location:   shared repository: Desktop/a name with a Ã§ just to test
<nmendes> init -repo works ok
<nmendes> Tortoise Bazaar 0.5.8
<nmendes> bzr-svn 1.0.4
<nmendes> bzr branch "svn://localhost/[delphi] dws meteo/trunk" "C:\Users\Nuno Mendes\Desktop\brance_with_a_Ã§_to_test" Branched 13 revision(s).
<nmendes> looks like it's on bzr-svn
<poolie> hi vila, all
<poolie> i'm still upstairs
<jam> poolie: be that way, then
<jam> :)
<lifeless> its all me :P
<lifeless> jelmer: ncommander in the arm room would benefit from some 1:1 on bzr-builddeb - how to get it going on existing source+packaging branches that don't have import revisions etc
<jelmer> lifeless: hey
<poolie> i'm going to see about getting lifeless some help for his stiff neck^Wback
 * jelmer goes by the arm room
<vila> poolie: don't worry we're waiting for you to open the door
<poolie> ?
<poolie> seriously? didn't i give you the card?
<vila> :)
<vila> sorry
<poolie> :)
<vila> of course you did, we're in, just teasing you for making my laptop ring :)
<TheTinyToon> Hi Everyone - a collegue and me are testing Bazaar in a partner workflow and have a question regarding the steps to get started
<TheTinyToon> From what I get, I first initialize a local repo, make some changes and commits and send a tarball over to my collegue
<TheTinyToon> he then branches from my tarball, makes some changes himself while I work on my local branch
<TheTinyToon> our changes are then send by mail via bzr send and merged in our local branches
<TheTinyToon> however, every time I try to send a mail after making some changes, I always the the warning "Bundling 0 revision(s)"
<TheTinyToon> Any hints?
<lifeless> you probably are not holding a mirror of your partner's branch
<lifeless> bzr send wants to compare two branches to see what needs to be sent
<TheTinyToon> lifeless: I tried it locally by branching my repo into another directory, made some changes in the new branch and tried to send those back to myself - same error.
<TheTinyToon> "bzr status" shows me the correct parent branch path
<lifeless> you may need to show a pastebin of your commands or something
<TheTinyToon> k, one sec
<TheTinyToon> http://pastebin.com/Z4QLz77s
<lifeless> jam: might be interesting to run http://draketo.de/proj/hg-vs-git-server/test-results.html agains bzr
<TheTinyToon> we are currently evaluating Bazaar as a method for our students to get them used to effectively work in teams
<maxb> TheTinyToon: It's often more convenient to use some shared server than email to pass around changes. Is there a particular reason you are focussing on 'bzr send' ?
<TheTinyToon> maxb: no particular reason - we just want to start without a central server
<TheTinyToon> ... or public repos at all
<spiv> jam: http://paste.ubuntu.com/552997/
<maxb> OK, well the two arguments to bzr send are the submit branch and the public branch
<maxb> The submit branch is the branch you are submitting the changes to - or a mirror thereof
<TheTinyToon> aah, switched the arguments
<maxb> The public branch is a public location holding a copy of the branch you are currently in - it's optional unless --no-bundle is in use
<maxb> The problem with having no central server is that it is hard for a group to have a good collective idea of what the latest master version is. Use of sent bundles generally works best when there's a clear hierarchy of how changes flow from person to person, which there generally isn't in a student project
<maxb> Unless the project has deliberately been structured to exemplify this workflow
<TheTinyToon> maxb: yes, we are thinking about showing several workflows, one of which should be the "manual one"
<maxb> NB that even when using 'bzr send' to send changes *up*stream, there's usually a read-only public location from which people can fetch changes downstream
<maxb> i.e. developer A sends in a merge request to the project leader, developer B later pulls/merges from the project leader's public branch
<TheTinyToon> yeah, classic human gatekeeper workflow - will definetly be shown.
<maxb> In which case it's pretty much "cd mybranch && bzr send ../gatekeeper-mirror"
<TheTinyToon> jup - thanks for the help. We're testing it now...
<vila> maxb: just thought I'd mention your fix for the ssh leak associated with socketpair is about to land and the next submission in the queue should address the last failure with py27 on natty
<maxb> aha
<vila> :)
<jml> btw
<jml> really like seeing shelf status from 'bzr st'
<jml> thanks.
<jelmer> jml: Blame Parth :-)
<jml> jelmer: ok
<jml> hmm
<jml> how do I see the diff for a shelved item?
<mwhudson> bzr unshelve --preview
<spiv> wot 'e said.
<jml> ahh yes
<jml> I don't know how I missed thta
<jml> mwhudson, spiv: thanks.
<lifeless> I missed it the other day
<spiv> Perhaps because you didn't look at unshelve because you specifically didn't want to unshelve yet :)
#bzr 2011-01-12
<vila> full test suite passing on natty with python2.7 \o/
<fullermd> Must be time for py2.8 to come out.
<vila> fullermd: nah, switching to py3.x would be far much fun :)
<vila> fullermd: by the way, if you're near Dallas in the coming 10 days, come have a beer ;)
<fullermd> If I could get that far away from this project, I'd keep running and never come back   :|
<vila> . o O (Oh... one of *those* days :-/)
<fullermd> Days?  Ho ho ho.  I stopped counting it in _days_ last summer.
<AfC> Any idea what the state of the "transparent http pass through to bzr server" mechanism is? I last looked for it a couple years ago, and could make it fly, but is it still around?
<lifeless> I'm not aware of it plans or actions to remove it.
<maxb> "transparent http pass through to bzr server"?  bzr+http:// ?
<lifeless> maxb: http://
<lifeless> maxb: which probes for a bzr server
<maxb> Ah, http://, which decides to be bzr+http:// if possible
<lifeless> yes
<AfC> yeah, that
<AfC> is it in active use anywhere?
<AfC> (ie, are you guys using it on, say, Launchpad)
<AfC> I am often is given to feel that he's the only one using bzr:// :(
<AfC> I'd hate to go down another path which isn't really what the developers want me doing.
<poolie> "he" meaning AfC?
<AfC> poolie: yeah :) changed from /me to I :)
<AfC> IRC needs history editing!
<poolie> we are not using it externally on lp
<poolie> we could deploy it publicly
<poolie> probably we would only do that if we could get clients switching to it automatically when they are accessing a public readonly branch
<fullermd> I gave passing thought to setting up bzr+http once, but the inflexibility of paths made me give up before really trying.
<poolie> i don't think the efficiency win of avoiding ssh would be worth making users manually type different urls
<fullermd> Every once in a while you hear somebody here running it I think...
<poolie> some people might find it worthwhile, but probably not enough to get to the top of the list
<AfC> I've actually got it rigged up so that bzr://path/to are our public URLs and bzr+ssh://path/to are what developers push to. Symmetrical, at least
<AfC> but I was exploring whether or not [instead] I could host out of eg ~/public_html via Apache mod_userdirs and then realized I'd have to have people use http:// URLs there.
<fullermd> Is where I gave up.
<fullermd> (actually, with ~/public_bzr, but...)
<AfC> heh, nice
<AfC> yeah, obviously you wouldn't want n instances of python bzr serve running
<fullermd> (separate vhost, with UserDir so set, so it all Just Works...  except dumbly)
<AfC> and in any case, there's the port issue
<misterbiscuit> having trouble with bzr fast-export-from-svn
<misterbiscuit> probably my own fault
<maxb> define trouble
<misterbiscuit> keep ending up with svn.core.SubversionException: ("Can't open file '.../format':No such file or directory"
<maxb> hmm... without obfuscation, please?
<misterbiscuit> '...' isn't literally printed
<misterbiscuit> OK
<misterbiscuit> background: in the root of my svn repo, there are several directories, one for each project
<misterbiscuit> inside each project directory, there is the usual trunk, branches, tags
<misterbiscuit> the repo is accessed via HTTPS
<misterbiscuit> so I tried: bzr fast-export-from-svn https://svn.example.com/svn/myrepo/myproject
<misterbiscuit> and ended up with a traceback whose last line is
<misterbiscuit> svn.core.SubversionException: ("Can't open file 'https:/svn.example.com/svn/myrepo/myproject/format': No such file or directory", 2)
<misterbiscuit> correction, I tried: bzr fast-export-from-svn https://svn.example.com/svn/myrepo/myproject myproject.fi
<misterbiscuit> sorry, left off the last parameter there
<fullermd> I'd guess offhand that fast-export-from-svn expects to be pointed at the _repo_, not something inside it.
<maxb> fast-export-from-svn expects to operate on a repository locally on disk, not an URL
<maxb> it also assumes a /trunk directly in the root of the repository
<maxb> You may be better off using bzr-svn
<maxb> Instead of bzr-fastimport
<maxb> bzr svn-import https://svn.example.com/svn/myrepo/myproject myproject.bzr
<misterbiscuit> so: I scp'ed the entire repo down (myrepo) to my local disk, and tried: bzr svn-import /path/to/myrepo myrepo.fi
<misterbiscuit> and I ended up with a message like, "Exporting revision 191... skipping." for every revision
<misterbiscuit> after it finished, myrepo.fi was just an empty file
<maxb> uh, I think you mean you ran 'bzr fast-export-from-svn /path/to/myrepo myrepo.fi'
<misterbiscuit> I'm sorry, you're correct
<maxb> see what I said above about using using bzr-svn instead of bzr-fastimport
<misterbiscuit> I will try it.  I started with fast-export-from-svn because that's the approach strongly recommended by the Bazaar Data Migration Guide
<misterbiscuit> In fact, the page I'm looking at doesn't even mention svn-import
<misterbiscuit> is it deprecated or soon-to-be-deprecated?
<misterbiscuit> ahh, it is mentioned as an alternative tool on the subversion-specific page in the migration guide
<misterbiscuit> so I click the bzr-svn link and I'm taken to ... the project page?  Where's the documentation?
<misterbiscuit> this new user experience needs improvement
<misterbiscuit> and there's a third tool apparently: svn2bzr
<fullermd> That I'm pretty sure IS quite long deprecated.
<misterbiscuit> bzr svn-import https://svn.example.com/svn/myrepo results in:
<misterbiscuit> bzr: ERROR: Invalid http response for https://svn.example.com/svn/myrepo/.bzr/branch-format: Unable to handle http code 401: expected 200 or 404 for full response.
<misterbiscuit> our svn server does require authentication
<misterbiscuit> bzr help svn-import doesn't mention any way for me to provide my credentials, however
<misterbiscuit> I assume there is none
<fullermd> I believe it reads svn's stored credentials.
<misterbiscuit> Hmm, that would make sense, but then I'd argue it isn't working
<misterbiscuit> I'm running bzr svn-import /media/maxtor/svn/myrepo now
<misterbiscuit> and its cranking away
<misterbiscuit> (that's my local copy that I scp'ed down from the svn server)
<fullermd> Note that it's probing for a bzr branch there, not svn.  So maybe bzr-svn isn't engaged yet at that point.
<misterbiscuit> Yeah, that '.bzr/branch-format' looked strange to me
<misterbiscuit> Any idea why its doing that?  Did I run the command incorrectly?
<fullermd> You may be able to force it using svn+https://.
<fullermd> Well, when you get a URL, who knows what it is?  It could be svn, it could be bzr smart, it could be bzr dumb, maybe it could (if you have the plugin) be hg or git or SCCS...   so, in some order, it checks until it finds a match.
<misterbiscuit> Shouldn't "svn-import" assume its an svn repo?
<fullermd> All else being equal, probably.  But the layer connecting to the URL may have no idea what command was being run.
<misterbiscuit> I see
<fullermd> (just a guess of course)
<misterbiscuit> Yeah, fair enough
<misterbiscuit> bzr svn-import svn+https://svn.example.com/svn/myrepo looks to be working
<misterbiscuit> Did appear to be working
<maxb> You really probably wanted to be running svn-import svn+https://svn.example.com/svn/myrepo/myproject
<misterbiscuit> I'll try that now
<misterbiscuit> It did some work, but then bombed
<misterbiscuit> 'KeyError: 'No such TDB entry'
<misterbiscuit> Note that the bzr svn-import I kicked off against the repo on my local filesystem is still running
<misterbiscuit> So assuming it finishes, I guess that's the way I'll have to go
<aroman> hey all, sorry to bother you guys with such a n00b question, but I somehow set bzr to push to the wrong launchpad branch. However, when I push to the right one (manually specifying the branch), running "bzr pull" uses the _old_ branch,  not the new one. Is there any way to force bzr to push to a specific lp branch? Thanks!
<poolie> aroman, use 'push/pull --remember'
<poolie> or vi .bzr/branch/branch.conf
<aroman> poolie: brilliant -- I was just digging around in .bzr now. thanks a ton!
<lifeless> spiv: btw, you were assigned to the bug's LP bugtask... you might want to search for bugs to which you are assigned in *any* project that you're not actually intending to be assigned to.
<misterbiscuit> maxb and fullermd, thanks for your help; I have to go but it looks like running bzr svn-import on a local copy of my svn repo might work out
<catphish> is there any provision in the network protocols to allow a user to create remote branches?
<catphish> or does the server admin need to create each branch?
<maxb> bzr push url works just fine
<maxb> where url doesn't exist before
<catphish> so the server is expected to create a branch where one doesn't exist?
<AfC> yes
<neaj> i want to 'bzr branch http://svn.../somemassiverepo/sometinymodule' .. now it's downloading 10s of MB of metadata .. is this the right way?
<neaj> will that fat metadata cache be reused if i like 'bzr branch  http://svn.../somemassiverepo/sometinymodule
<neaj> sorry
<neaj> will that fat metadata cache be reused if i later 'bzr branch http://svn.../somemassiverepo/someothermodule' ?
<neaj> hmm, 'bzr branch http://svn.plone.org/svn/collective/dotipython dotipython' worked, but now 'bzr branch http://svn.plone.org/svn/collective/PDBDebugMode PDBDebugMode' fails: bzr: ERROR: Not a branch: "http://svn.plone.org/svn/collective/PDBDebugMode".
<neaj> maxb: thanks, yes, i see it isn't re-downloading the metadata
<maxb> bzr-svn has a concept of repository layouts, by which it defines what paths in svn are considered branches
<maxb> have a look in your ~/.bazaar/subversion.conf for what it has guessed as the layout for this repository
<maxb> catphish: Yes, does it not?
<catphish> it doesn't exist yet
<catphish> i'm creating a server to host bzr branches
<catphish> not sure what protocol it will use yet
<catphish> hopefully smart over http
<fabio_kreusch> Hi there, I have a repository which is a mix of a bzr repository and a subversion repository. I have this because the project was started on a Bzr server and then the client requested for us to upload it to a subversion server. So what I did was to ignore on .bzrignore the .svn folders, and on Subversion I ignored the .bzr folder
<catphish> hopefully the backend will automatically create the branches as required
<catphish> i will just not validate the last part of the url
<fabio_kreusch> But now, when I try to commit on bzr to bzr+http://mybzrserver, I receive this msg:  'A subversion remote access command failed: could not resolve hostname thehostname'
<fabio_kreusch> I think bzr is trying to commit to subversion too
<fabio_kreusch> is there any way to make bzr totally ignore svn?
<maxb> fabio_kreusch: It sounds like you have the bzr-svn plugin installed, and bzr is unsure whether it should be operating on the .bzr or .svn part of the working copy
<maxb> Try bzr --no-plugins commit
<fabio_kreusch> ok, that did it, but my co-workers use tortoise-bzr, and it doesn't seem to support --no-plugins
<fabio_kreusch> do you know if there is another way to disable it?
<fabio_kreusch> maxb: ?
<quicksilver> tell them GUIs are for the weak, and if they don't learn the CLI they will be fed to the lions?
<fabio_kreusch> haha
<quicksilver> alternatively, remove the svn plugin from their machines (if they don't need it for some other reason)
<fabio_kreusch> i whish i could do that =P
<maxb> I suggest not working in a hybrid working copy with both .bzr and .svn
<maxb> Or, you could uninstall bzr-svn if you never use
<maxb> it
<Tak> being fed to lions is preferable to using the windows cli
<fabio_kreusch> maxb: i did it that way because bzr-svn was acting weird for me
<maxb> Are you aware of how bzr-svn works? Using it properly would seem to be a far better way of managing this than separately committing to two different vcses
<maxb> You could just push the bzr branch straight into svn
<fabio_kreusch> my problem was that every time I pushed the bzr branch to svn with bzr-svn, it was recreating old branches which were already merged into trunk on the svn repository
<soren> Ok, so I've just branched lp:bzr. If I run "./bzr selftest something
<soren> "
<soren> ... I get some warnings about plugins it can't load. This is probably fine, but I also get this:
<soren> bzr: ERROR: The API for "<module 'bzrlib' from '/home/soren/src/bzr/bzr/bzrlib/__init__.pyc'>" is not compatible with "(2, 2, 0)". It supports versions "(2, 3, 0)" to "(2, 3, 0)".
<soren> Am I doing something wrong?
<maxb> Perhaps ~/.bzr.log will provide a traceback which illuminates what is complaining
<catphish> what does "bzr branches" do?
<catphish> it seems to take almost a second to run
<catphish> and produces the same output as 'ls' - is there any advantage to using it over ls?
<Tak> `bzr help commands/branches` will tell you ;-)
<soren> maxb: There's no such thing.
<soren> maxb: Oh, in ~?
<catphish> Tak: the help doesn't tell me
<catphish> i tried that first
<Tak> "Purpose: Scan a location for branches"
<catphish> yes, but my question stands, what is the advantage over 'ls'
<maxb> catphish: The problem with "bzr branches", is that it recurses over the entire tree, and if you have bzr-{svn,hg,git} installed, it spends ages probing for those kinds of branches too
<Tak> ... ls doesn't know about branches?
<maxb> that's why it's unusably slow
<soren> maxb: Oh, it's due to a plugin in ~/.bazaar/plugins
<soren> maxb: Thanks!
<catphish> maxb: thanks, i think i will just use ls then, i don't need recursion or foreign repos
<etenil> Hi there
<etenil> I'm working on a project on a linux and a windows box, and the windows box is always changing the files mode so that bazaar lists these as changes (which they aren't). How can I make bazaar ignore this?
<LeoNerd> Shared filesystem?
<awilkins> Tak, On the matter of Windows CLI, Powershell makes it almost bearable.
<awilkins> The terminal is still bobbins, but the shell has some features I wish the *nix shells had.
<etenil> LeoNerd: No, it's not shared, I just transported the files with me on a memory stick
<awilkins> etenil, There's a bug for that
<etenil> ah ok
<LeoNerd> etenil: Ah.. Try mounting noexec ?
<etenil> well then...
<awilkins> The problem is that your thumbstick is FAT32
<LeoNerd> Or at least, with a sensible mode so it doesn't go shoving +x everywhere
<awilkins> ^^ mount noexec
<etenil> yes, it is fat32
<awilkins> OR do what I used to do and keep the repo on the stick, and take a lightweight checkout from it to the local filesystem
<etenil> well the problem isn't with the linux box but with the windows box
<awilkins> Problem is that FAT32 has no exec bit - so by default Linux assumes that it's ON for every file, unless you mount noexec
<catphish> if its fat32 the problem may actually be with linux
<catphish> as far as i know fat32 has no modes
<awilkins> Windows has no concept of exec bit, so it assumes it's OFF
<catphish> so the linux kernel will make them up
<awilkins> Actually, it just leaves existing ones along
<etenil> and there's no rule I could put in .bzrignore to solve this I suppose?
<LeoNerd> noexec would break e.g. shell/perl/ypthon
<catphish> couldn't you just commit them with the the exec bits set
<LeoNerd> *gah enter key*  ... scripts that might happen to be on the filesystem, whereas exec generally doesn't break anything.  So exec  is usually the default sa it breaks less
<awilkins> Bug is : https://bugs.launchpad.net/bzr/+bug/248333
<exarkun> bzr: ERROR: No such file: u'/var/lib/buildbot/twisted/.bzr/repository/indices/49ef04533e5410f03a9e1f78b25083b0.rix': [Errno 2] No such file or directory: u'/var/lib/buildbot/twisted/.bzr/repository/indices/49ef04533e5410f03a9e1f78b25083b0.rix'
<etenil> ah
<etenil> a bzr revert did it
<exarkun> 'bzr update' started failing with this error
<etenil> \o/
<maxb> exarkun: The implication being that an internal file has mysteriously vanished from the bzr repository
<ChrisWoollard> I have a branch on my computer. I have deleted a file from it. How can I pull the latest version from lp?
<ChrisWoollard> of that file.
<awilkins> ChrisWoollard, You can either bzr revert that file (if you've not comitted it's deletion) or you can bzr cat it it from a branch that has it (if you've not committed it's deletion)
<maxb> ChrisWoollard: Deleted... and then committed the deletion? And now you want to undo the deletion and track updates from the parent branch again?
<ChrisWoollard> it is not commited
<awilkins> ChrisWoollard, Just revert it's path
<awilkins> Or use qrevert to find it
<exarkun> maxb: Hrm :/
 * awilkins is assuming you have qbzr installed or are on the default Windows distro
<ChrisWoollard> Lovely. Thanks.
<maxb> exarkun: NFS? ext4? Recent system crashes?
<exarkun> ext3, no recent crashes
<maxb> exarkun: Does the .pack file with the same hex-id exist? Do the other indices?  (.rix .iix .tix .six .cix)
<maxb> Format of this repository?
<exarkun> There's an obsolete pack with that hex
<maxb> !
<exarkun> Shared repository (format: 2a)
<maxb> are the five indices for that hex also present in the obsolete_packs dir?
<exarkun> oh.  yes.
<maxb> In that case, mv the pack into packs/ and the indices into indices/
<maxb> The implication being that something has violated the supposed inviolate ordering of moving packs vs. updating pack-names
<exarkun> okay, after that the update succeeded
<exarkun> I doubt I can provide instructions for reproducing the problem.  Is a bug report saying "something can violate the supposed inviolate ordering of moving packs vs. updating pack-names" useful?
<maxb> What is the bzr version?
<exarkun> 2.2.2
<maxb> hmm. I'm not guaranteeing anyone will do anything useful with the bug report, but it might be worth filing it anyway, to register on the developers collective conciousness that this issue occurs
<maxb> If you do, be sure to mention ext3, because a lot of this class of issue is easily blamed on ext4
<exarkun> okay, thanks
 * exarkun notices something else
<exarkun> here's the first time the error became apparent, http://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/307/steps/bzr/logs/stdio
<maxb> hrm. I wonder what the other process holding the lock was
<exarkun> yea, that'd be useful.  but I guess that information is unavailable.
<spiv> exarkun: good morning
<spiv> exarkun: I assume you're using bzr 2.1.0 or newer?
<exarkun> spiv: yes, 2.2.2
<spiv> Ok, no known bugs in this stuff since 2.1.0 I think.
<exarkun> Hm
<exarkun> I guess there is concurrent access to the shared repository in this scenario.
<exarkun> I forget, does that actually work yet?
<maxb> yes
<exarkun> okay.  At least that perhaps explains why something was locked.
<exarkun> https://bugs.launchpad.net/bzr/+bug/701940
<maxb> The real question is how the lock managed to go away without the new pack-names being written
<spiv> exarkun: thanks, that bug report looks good (as much it can be with the available info, at least...)
<ovnicraft> hello guys, i am new in bzr i have a problem i bzr merge and i dont apply the changes for specific file , how i can do it?
<ovnicraft> i found bzr revert --forget-merges but can i aplly just for a file?
<ovnicraft> i run it with my file as arg but i still see the changes in the diff my question is, when i commit the changes will applied?
<ovnicraft> any feedback here?
<fullermd> --forget-merges isn't what you want.  That makes it lose the merge metadata.
<fullermd> You'd just want to revert the file.
<spiv> ovnicraft: as fullermd says, just "bzr revert FILE"
<ovnicraft> spiv, thanks and when i push in parent repository what happen? my changes in file will applied?
<ovnicraft> or give conflicts?
<ovnicraft> spiv,
<ovnicraft> so i am trying to push and tell what the branches diverges
<spiv> It's just a regular commit, there's nothing special about reverting or not that file.
<spiv> ovnicraft: use 'bzr missing' or a graphical tool like 'bzr qlog BRANCH1 BRANCH2' to see how their revision history diverges.
<ovnicraft> spiv, the diverge is in the file what i revert
<spiv> No, divergence is a property of branches, not files.
<ovnicraft> but bzr dont letme push
<ovnicraft> isee in documentacion push args --overwrite
<spiv> Yes, because the branches have diverged.
<spiv> Yes, overwrite will let you push - but it will overwrite some changes.
<spiv> You should look at 'bzr missing' or similar first to see what's going on.
<ovnicraft> bzr missing show me the diverges ?
<spiv> It can tell you which revisions are in branch A but not in B, and vice versa.
<spiv> See 'bzr missing --help' for details.
<spiv> Or just try it :)
<ovnicraft> spiv yes i see 10 missing revisions now
<ovnicraft> so i understand with overwrite my revision will overwrite and forget the missing revision , i am ok?
<spiv> Yes, that's what overwrite will do.
<spiv> Typically you'd use 'bzr merge' to combine the divergent changes from both branches into one branch (and thus resolve the divergence).
<Williamson69[TFD> If anyone knows a lot about Linux and could answer my questions. Please query me. I am a very new user and want to use Linux. Please help me. If you are a Guru on Linux. I would love to talk to you. Please query
<bialix> bonsoir vila
<vila> bialix: hellllo !
<bialix> heya!
<bialix> how it's going?
<spiv> bialix: hi
<vila> bialix: I'm in Dallas, so it's still early here :)
<bialix> hi spiv :-)
<bialix> vila: I've suspected that, in some of your last mails there was -0600 timezone ;-)
<vila> bialix: how are *you* going ? Seems like I didn't "see" you for quite a long
<vila> s/long/& while/
<vila> bialix: happy new year by the way :)
<bialix> oh, yep
<bialix> happy new year to all
<bialix> :-)
 * fullermd picks vila up and waves him at bialix.
 * bialix is happy to see fullermd
 * bialix waves back and grin
<bialix> vila: haven't had too muich time for hacking
<fullermd> I wonder if vila brought this cold snap with him...
<bialix> what's about Gary?
<vila> bialix: no idea, I miss him :-/
<jelmer> vila!
<bialix> nobody else made a windows installers :-(
<bialix> heya jelmer
<bialix> HNY
<vila> fullermd: not really, I'm pretty sure it predates my arrival and afaik the wheather was going *better* bach there when I left ;)
<jelmer> hi bialix
<fullermd> A likely story.  Sounds like you've spent a lot of time planning your alibi to me...
<vila> hehe, I never spent actual time on such things, it's all occurring in the background
<fullermd> That's just what you'd say if you were a serial killer...
 * fullermd blocks up some roads and cowers in his closet.
<vila> .... you shouldn't have mentioned that you know
 * bialix hopefully will back later
<fullermd> Mentioned what?  I didn't mention anyway.  Nope, not a thing...
<vila> ...too late...
<vila> black helicopters sent
<vila> ... as a decoy of course
<vila> mgz: are you around ?
<mgz> poink.
<fullermd> Drat.  There's never a SAM around when I need one.
<mgz> ...you want to shoot me down?
<vila> mgz: do you remember the bug # about windows env vars encoding ?
<mgz> bug 262874
<ubot5> Launchpad bug 262874 in Bazaar "environment may not be in get_user_encoding() on Windows" [Medium,Confirmed] https://launchpad.net/bugs/262874
<vila> mgz: and can you remind me what your objection was against mbcs there, I thought you commented on the bug but apparently no
<mgz> It's Complicated. :)
<mgz> basically, the way the 'mbcs' codec is written in python sucks.
<mgz> doesn't do *quite* the same thing as BlahBlahA interfaces do over BlahBlahW functions
<mgz> getting bytes out should be fine whatever, but putting bytes in is liable to blow things up
<vila> jam is looking at the bzr_home_in_unicode test failure
<mgz> decoding is potentially worse as you can get u'\u0000' back out unexpectedly, but the enironment should always be given to us as something we can use, unless someone else has already broken the process
<jam1> mgz: right, but regardless cp1252 is never correct for setting into the env, right?
<jam> I think there are 2 bugs atm
<mgz> it is if that's what GetACP gives you.
<jam> 1, config_dir() isn't correctly interpretting BZR_HOME when it is unicode
<jam> mgz: GetACP?
<mgz> and yeah, that test used to fail in a different way, so it's likely there are two issues
<jam> 2, we aren't *setting* BZR_HOME correctly for it to be interpretted by config_dir()
<mgz> ctypes.windll.kernel32.GetACP()
<jam> config_dir() doesn't do any escaping/etc of the env var
<mgz> it's what locale.getpreferredencoding boils down to as well, which... is what the user encoding should be on windows
<mgz> in the general case, we can't put an arbitrary unicode path in the environment
<jam> mgz: atm I can only find a difference vs mbcs in characters that can't be encoded in cp1252
<mgz> so the test needs to pick one that works in the actual system's encoding
<jam> mgz: SetEnvironmentVariableW
<jam> mgz: I think config_dir() should be switching to use GetEnvironmentVariableW(), and the test changed to use SetEnvironmentVaribleW()
<jam> on window
<mgz> jam: right, but remember Python is using the ()A interfaces, not W
<jam> windows
<jam> mgz: it is for os.environm
<jam> but we don't have to for our stuffg
<jam> lots of windows specific stuff already for command line, might as well do it for env vars
<mgz> ...explictly? that's new.
<jam> mgz: we already have             base = win32utils.get_appdata_location_unicode()
<jam> which is find the specific unicode $APPDATA location
<jam> via the SHutils stuff
<jam> which uses                 ctypes.windll.shell32.SHGetSpecialFolderPathW
<jam> if it can
<mgz> the difference between cp* and mbcs is the implementation
<mgz> cp* codecs use tables implemented in python
<jam> mgz: so I think my point is, we shouldn't worry about it at all, we should be using the W apis on Windows wherever we can
<jam> since otherwise we're just broken anyway
<jam> I can set my HOME to an arabic path on Windows, even though I'm in cp1252
<mgz> mbcs calls mbtwc kernel functions without giving you means of setting the parameters
<mgz> jam: if you set it to an arabic path, and then run python and do os.environ['home'] what do you get?
<mgz> because I'd expect questionmarks.
<jam> mgz: I agree, but my argument is that python's os.environ is broken on Windows and we shouldn't be using it
<mgz> it's... just the way it's implemented. same problem we have with the subprocess module, and did have with the commandline as you said.
<mgz> Python 3 is 'the' fix, which then confuses a bunch of nixy things that assume stuff is arbitrary bytes, not text
<mgz> C:\>set FISH=Ã©
<mgz> C:\>echo %FISH%
<mgz> Ã©
<mgz> C:\>python -c "import os;print os.environ['fish']"
<mgz> e
<jam> mgz: yeah, that doesn't surprise me
<jam> which is why we're working around it
<mgz> that's the pain with the mbcs codec, the params it passes to widechartomultibyte does cute lossy downcoding
<vila> let's don't do that then :)
<jam> we have the functions available, just not conveniently
<jam> I think we should add osutils.get/set_environ_variable() and try to use them when we have something we want to be unicode compatible
<mgz> at least with cp* codecs, the "replace" and "strict" params let you control your error handling
<mgz> I agree somewhat jam, it's just a question of how much broken core python stuff we want to rewrite to make corner cases work rather than just fail sensibly.
<mgz> the problem at the moment is a lot of the failures aren't safe or sensible.
<jam> mgz: HOME style env vars don't really fail sensibly
<jam> they tend to just prevent people from getting stuff done
<mgz> not that everyone's trying to set their HOME to strings that aren't in their legacy encoding
<mgz> well, treating that as 'HOME is not set' would perhaps be sensible. breaking because it can't find a dir named ????? is not.
<jam> mgz: so we can change the config_dir() code to just decode os.environ and get mostly correct
<jam> it just seems sad that we're on a platform that can handle any Unicode paths/variables etc
<jam> and we are restricting it to mbcs because thats what python does
<jam> mgz: http://paste.ubuntu.com/553270/
<jam> this makes the test pass
<jam> and seems ~ correct
<jam> without resorting to unicode environment getters
<jam> what do you think?
<jam> from what I can see, the config_dir() is actually broken on Linux, since it never decodes the string
<jam> until later when it will assume the string is UTF-8 (which it almost always is, but that isn't supposed to be guaranteed)
<mgz> it is sad, but seems most practical for the moment.
<vila> +1
<mgz> just happening to work with utf-8 isn't suprising, I think bzrlib has a few spots like that
<vila> with the comment duplicated in both places
<jam> http://paste.ubuntu.com/553272/
<jam> this is the other option
<jam> which does the decode always
<jam> which has a bug the way I wrote it, because it double decodes
<jam> but you get the idea
<jam> mgz: do you know what "os.path.expanduser()" does? Is it unicode sensitive if you pass it u'~' instead of '~' ?
<mgz> my general nitpick would be the location of the code, don't really want this kind of involved platform logic in multiple places in the tree
<jam> I have the feeling very few people have non-ascii home dirs on Linux
<mgz> ^might be, I'll check
<jam> mgz: I sort of agree, but config tends to be one of the few places that we deal with environment stuff
<mgz> also I'm not conviced the actual chain of checks is really right
<jam> mgz: well on windows I think it will be very rare to not have APPDATA
<mgz> launchpadlib caught me out the other day by expecting HOME to be set, it's generally not on windows
<jam> but BZR_HOME > APP_DATA > HOME seems fine to me
<jam> actually, on new windows, I would bet that GetSHSpecialFolder(APPDATA) has to return something
<jam> or *lots* of programs would die
<mgz> yup, that much seems fine. and checking, does seem expanduser has the same ordering (but no clever unicode logic)
<dash> ahoy. i'm encountering #445690 in 2.2.2
<dash> oh. https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/445960
<dash> (tracekback on bzr unshelve)
<jam> mgz: https://code.launchpad.net/~jameinel/bzr/2.3-unicode-home/+merge/46015
<dash> i guess i oughta try it in 2.3b4?
<jam> dash: I thought we touched some fixes against PreviewTree.inventory in the 2.3 series
<jam> I would recommend trying
<jam> I think that bug is actually a dupe, but I'm not positive
<mgz> bug 389674?
<ubot5> Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory" [Medium,Confirmed] https://launchpad.net/bugs/389674
<jam> mgz: thanks
<mgz> implies it's not fixed on trunk.
<jam> yeah
<jam> there is the patch for it
<dash> aha. google didn't find that one
<jam> let me check
<jam> yeah, nobody submitted that as a merge request
<jam> I'll poke it real quick
<dash> ok. so i guess i'll apply that patch to turn my code loose from shelve
<dash> guess i'll make sure to create a branch instead of shelving next time :)
<jam> dash: shouldn't generally be a problem
<dash> sure
<poolie> hi bialix, dash, mgz
<mgz> hey poolie.
 * dash waves
<dash> aha, i see how this got triggered.
<dash> i h ad a shelved change to a file that was deleted in a revision after the shelf entry was created.
<mgz> deleted aside about os.path.expanduser from that review, but must remember to file launchpadlib bug at least.
<mgz> the bzrlib.config logic doesn't matter much as it really shouldn't reach that check like you said jam, appdata should always work.
<jam> dash: https://code.launchpad.net/~jameinel/bzr/2.3-unshelve-inventory-bug-389674/+merge/46021
<jam> mgz: I'm doing a small spike on getting the win32 test suite passing
<jam> I was going to look at test_break_lock_corrupt_info next
<jam> is there any work you've got that I should be aware of
<jam> *right* now, I'm going to lunch
<jam> mgz: email me if you have anything, since my machine will be off for food
<mgz> nope, feel free to boink that one
<mgz> it's just a pain due to how the test is constructed.
<jam> mgz: test_break_lock_corrupt was actually a genuine windows failure, because we were holding the file open while we tried to delete it.
<jam> https://code.launchpad.net/~jameinel/bzr/2.3-break-lock-corrupt-win32/+merge/46036
<mgz> yup.
<jam> it feels good to have a windows test fail because the code is actually wrong, rather than the test being wrong
<mgz> but that's only because andrew wrote the test that way, it's not usefully failing
<jam> mgz: no, it really is failing for a good reason
<jam> check the fix
<jam> force_break_corrupt was using "f = transport.get(); f.readlines()" which was holding the file open while it went and called transport.delete()
<mgz> hm!
<jam> as I said, nice to have a real failure
<jam> that leads to a real fix
<mgz> I'd misdiagnosed when I looked at it first time round then.
<jam> rather than just a test case update
<jam> mgz: yeah, I thought it was an ld vs ld2 race windows bug
<mgz> goodjobjam.
<jam> http://babune.ladeuil.net:24842/job/selftest-windows/lastCompletedBuild/testReport/bzrlib.tests.test_transform/TestTreeTransform/test_rename_fails/
<jam> is this a problem because of French windows?
<jam> vila: ^^
<mgz> I've got that one.
<mgz> it's bug 273978
<ubot5> Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978
<mgz> don't have a branch on any of the other outstanding bugs though, the random failures in particular I've not dug into.
<jam> np
<jam> out of 6 current failures, i've fixed 2, you've got the third
<jam> and 2 look transient
<jam> which I'd like to look into anyway
<jam> but we're getting close
<mgz> that one you've just done it bug 659978
<jam> mgz: especially since test_rename_fails passes here, because I don't have French windows
<ubot5> Launchpad bug 659978 in Bazaar "bt.test_lockdir.TestLockDir.test_break_lock_corrupt_info fails on windows" [Low,Confirmed] https://launchpad.net/bugs/659978
<awilkins> Zero Windows Bugs ???!?!?!?!?!!? What will we tell stories about at parties
<jam> awilkins: I'm sure there are still bugs, just not failing tests :)
<jam> mgz: thanks for the bug link
<mgz> numbers for the remaining are 581311 and randoms 681047 and 686587
<mgz> 581311 I briefly talked to vila about, it may be we just want to catch the winsock errno while still leaving the standard errno to propogate (as the semantics seem to be a little different)
<jam> bug 581311
<ubot5> Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows" [Medium,Confirmed] https://launchpad.net/bugs/581311
<jam> mgz: of course, right now, the test passes for me
<jam> but the first time I ran it, I got 10053
<mgz> hm, has been reliable for me.
<jam> I think it depends on a bit of race
<jam> and whether it fails during connect
<jam> or during read()
<awilkins> It it another test running in another thread hogging the socket?
<mgz> that sounds possible.
<mgz> ha, pile-on review approval.
<jam> awilkins: no other threads are reading from that one
<jam> but system load can change some timings
<jam> mgz: I don't see any error trapping in SFTPTransport.get_bytes(), it seems to all be in SFTPTransport.get()
<jam> which may be a reasonable hint
<jam> if SFTPTransport.get() fails to open the file, then it will catch the exception and raise it
<jam> but if f.read() fails, there is no special error handling
<jam> but I guess it shouldn't get that far
<jam> because you don't do *any* sftp chatter on the socket
<jam> just close it immediately
<jam> mgz: hm.... only HTTP raises errors.ConnectionReset that I can find
<jam> i don't quite see how the stuff ever worked
<jam> I guess the hpss stuff handles ConnectionReset...
<spiv> Yeah, it does, in medium.py IIRC
<mgz> I think the thought is either osutils.read_bytes_from_socket or smart.medium should maybe be catching that socket.error
<mgz> which presumably is always errno.ECONNRESET on nix, but not always (or ever in this case) errno.WSAECONNRESET on windows
<jam> mgz: yeah, i did finally track into the code you are talking about
<dcraven> Hi. Is it possible to make bzr --remember multiple push branches?
<mgz> ...then how would it know which one to use when you typed `bzr push`?
<dcraven> Both :)
<dcraven> I'm lazy :/
<mgz> ah.
<dcraven> I do one after the other, but sometimes I forget to update one.
<dcraven> No biggie. I just wondered if bzr could remember better than I can :)
<jam> mgz: well, it happened once, but I can't reproduce it now
<jam> but I have something that I'm fine with as a patch
<bob2> there's some old plugin...bzr multipush?
<dcraven> bob2: Hmm.. I'll have a look. Thanks :)
<jam> bob2: I think multipush is more about pushing more than one branch, each to a single destination
<jam> I could be wrong
<bob2> yeah, you're right, I misremembered
<dcraven> Yeah. Looks like that instead.
<dcraven> It's not likely all that common of a wish I suppose.
<jam> mgz: https://code.launchpad.net/~jameinel/bzr/2.3-connection-reset-581311/+merge/46043
<jam> I'm fine just treating WSAECONNABORTED as a reset
<jam> we don't have any other way to deal with it
<jam> and nobody needs to see an ugly traceback because they disconnected
<jam> (I think we get ABORTED if we write too much data on the channel, etc. But really, who cares, something broke on the network)
<lifeless> sure they do
<lifeless> its a reward for disconnecting
<lifeless> a bit like an easter egg
<spiv> Except less like chocolate and more like a great big error.
<jam> mgz: http://babune.ladeuil.net:24842/job/selftest-windows/lastCompletedBuild/testReport/bzrlib.tests.test_http/SmartClientAgainstNotSmartServer/test_probe_smart_server_urllib_HTTP_1_0_/
<jam> looks like the same WSAECONNABORTED failure
<mgz> yup, it's similar, and the branch may fix that too.
<jam> mgz: I think it needs a different fix
<jam> line 601 of bzrlib/transport/http/_urllib2_wrappers.py
<mgz> got bug 686587 on that.
<ubot5> Launchpad bug 686587 in Bazaar "Random failure on bt.test_http.SmartClientAgainstNotSmartServer.test_probe_smart_server" [Low,Confirmed] https://launchpad.net/bugs/686587
<jam> explicitly checks 10054 but not 10053
<jam> mgz: I'm just going to roll a 10053 into that code, and include it with the earlier fix
<mgz> it mildly urks me we're getting the same error there, just from the test name
<spiv> jam: there's a NEWS conflict in that patch accord to the lp diff
<jam> spiv: my favorite
<mgz> "probe" doesn't imply is should be trying to do messy disconnects unlike the other test.
<mgz> but it's probably not a real issue.
<jam> mgz: it is trying to read from .bzr/smart which shouldn't be there, I believe
<jam> mgz: note that the test passes here
<mgz> well, it's random on babune.
<jam> the other possibility is a timing thing, where the smart server is disconnecting at a particular pace that screws with the test
* mbarnett changed the topic of #bzr to: **Launchpad down/read-only from 23:00 - 00:30 UTC for a code update** Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila)
<jam> mgz: some more get().read() stuff vs get_bytes()
<jam> https://code.launchpad.net/~jameinel/bzr/2.3-per-transport-tests/+merge/46047
<jam> this in just the test suite
<vila> there is a bug for this where I commented exactly that
<mgz> you did vila, and I didn't think that was it as the refcount looks like it should do the right thing there, but it's worth changing it anyway and seeing
<mgz> ...did that make sense?
<mgz> I need to not edit my sentences half way through typing them.
<jam> mgz: I believe that sftp is a bit tricky with refcounting
<jam> IIRC, if a file handle dies due to refcounting
<jam> it does an *asynchronous* close
<jam> check paramiko
<mgz> uu, that sounds nasty. certainly worth landing then.
<jam> mgz: SFTPFile.__del__() => self._close(async=True)
<jam> def close() => self._close(async=False)
<dash> oh no __del__ :(
<vila> mgz: yup, made sense
<vila> mgz: I guess the end of your sentence was: '... if we still see this failure or not'
<jam> vila: do you know the bug # ? I'm on a roll of closing win32 bugs, it would be nice to shoot down another
<vila> hehe, searching it, unless mgz beats me to it
<mgz> bug 681047
<ubot5> Launchpad bug 681047 in Bazaar "Random failures on SFTPTransport tests on windows" [Low,Confirmed] https://launchpad.net/bugs/681047
<mgz> just reviewing now
<vila> he did :)
<jam> thanks mgz
<vila> mgz: what trick are you using to find them this quickly ? A big whiteboard in your room ?
<vila> mgz: according (and thanks) to jam, it seems you will be the one fixing the *last* windows failure. When should we expect your patch ? :D
<mgz> I filed the bugs, so they're helpfully linked on my user page by launchpad :)
<vila> doh !
<mgz> ^ a.... month ago?  ;_;
<mgz> it's slightly trickier than it looks and I'm being overly perfectionist probably.
<jam> mgz: isn't it just .decode('mbcs') for IOError/OSError? Or are you trying to do something different with setlocale?
<mgz> in essence, it's just the plumbing and specifics that make it fiddly.
<jam> mgz: we need to get your last fix by midnight in France, so tomorrow babune will be all blue
<mgz> :)
<jam> mgz: of course, that gives us 45minutes
<mgz> I will put up something that works well enough for the test even if the big picture needs a little more polishing.
<jam> and we can't land that quickly in PQM
<mgz> ...so I have minus how many minutes to finish up here? :)
<vila> mgz: stop counting, act ! :D
<mgz> okay, I'll (semi) cheat for the deadline, but this is a worthwhile change anyway.
<vila> mgz: I have no doubt about that :) I don't doubt that you will follow up too anyway :)
<mgz> okay, proposing merge now.
<mgz> https://code.launchpad.net/~gz/bzr/trivial_test_rename_fails_stringification/+merge/46055
<spiv> jam: http://webnumbr.com/bzr-pqm-queue-length
<mgz> ..oo, launchpad going away in 11 minutes
<vila> mgz: ... exactly and lp isn't showing your diff :-/
<spiv> vila: http://bazaar.launchpad.net/~gz/bzr/trivial_test_rename_fails_stringification/revision/5583
<spiv> vila: so technically lp is showing the diff :P
<vila> mgz: falling back to local review mode
<vila> spiv: :)
<mgz> ...I've misspelt 'exception'
<awilkins> Converted someone to Bazaar as an SVN client this week. Muhahahaha. Etc.
<jam> mgz: why did you check to_file in one branch, and from_file in the other?
<jam> to_path/from_path
<mgz> it's a quirk of the test, if that diff had a bit more context it'd be clear
<mgz> basically, where the limbo dance fails is slightly different depending on if we induced a permissions failure from locking the file or setting a bit on the directory
<vila> omg, this test is ugly :)
<jam> mgz: gotcha
<jam> one case it failed to overwrite the target, other case it failed to move the target
<jam> merge:approve
<mgz> I've been making it gradually more ugly by making it more reliable... really want some test helper thing for doing 'what if there's a permissions problem' cleanly
<vila> mgz: or turn it into multiple tests, each one focused on a dedicated aspect or even os specific maybe ?
<vila> mgz: could wait for another submission
<jam> submitted
<vila> indeed :)
<mgz> yup, I've done per-os tests for a similar thing elsewhere, but it's still a little funky trying to create enironment problems for testing
<mgz> I remember you had to add something because some tests were failing when run as root... because then you're omnipotent
<mgz> and unix is of the philosophy that god cannot create a rock so heavy he himself cannot lift it
<vila> mgz: yup, there is a test feature named not_root or something
<vila> well, we can always use more explosive ?
<jam> vila: the test uses it
<vila> jam: lol, you're right, I missed it :)
<vila> in retrospect, it *obviously* uses it
<jam> interestingly, setting a directory to readonly doesn't do anything on windows
<jam> since it only tracks readonly for files
<vila> I still haven't setup a babune job running as root though
<mgz> right.
<jam> I could see splitting it up into two tests
<jam> but it doesn't seem like a big gain
<mgz> am mostly interested in sharing this stuff between tests. permissions errors are not uncommon as a user stambling block, so would like more tests that check we give good feedback in various circumstances
<maxb> If anyone has a spare moment, I'd appreciate second opinions on bug 455636
<lifeless> poolie: https://dev.launchpad.net/LEP/WebservicePerformance
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 7274\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:24:51 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1
<maxb> bug 455636
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 7274\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:25:09 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1
<maxb> hrm
<lifeless> thanks ubot
<bob2> teehee
<maxb> bug 455636
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5661\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:36:56 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1
<jam> maxb: I think we already support anonymous access without using an ssh key. The one thing we could make clearer is something like "bzr launchpad-logout" which would remove the username and have him access only the anonymous side.
<jam> I suppose the other aspect is that if you are anonymous, we warn you that you should log in
<jam> so we should have a flag to also suppress that warning
#bzr 2011-01-13
<vila> bzr launchpad-logout == bzr config launchpad_username --delete
<vila> cough
<vila> bzr launchpad-logout == bzr config launchpad_username --remove
<vila> bug 455636
<ubot5> Launchpad bug 455636 in Bazaar "r/o code download with lp: prefix asks for ssh key" [Undecided,New] https://launchpad.net/bugs/455636
<vila> maxb: asking gently was the key ;)
<jam> mgz: just a heads up, your branch has a bzr-2.3.txt conflict in it vs bzr.dev
<mgz> ...it's just trunk from a few revs back.
<jam> mgz: that would be me it conflict with
<vila> mgz: blame jam for fixing all those bugs :)
<jam> we'll have to see if we can get the pqm's bzr.dev out, because of the lp downtime, etc
<jam> worst case, you can merge my patches and submit it all together
<jam> or I can
<mgz> I'm a little confused as to how it causes problems when that's a file the branch doesn't edit.
<jam> mgz: you didn't add a news entry?
<mgz> nope.
<vila> hmm
<vila> well, you should have :)
<mgz> I didn't fix any bugs! :)
<vila> what ?? You didn't file one for these failures ???
<vila> :D
<jam> mgz: I'll see if there is actually anything in a bit
<vila> mgz: if your patch turns babune blue, expect getting blamed for it anyway :)
<mgz> I reckoned the exiting bug was good enough vila, and I've not fixed that yet :)
<vila> which one is that.... ?
<mgz> bug 273978
<ubot5> Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978
<vila> oh !
<mgz> there seem to have been a lot of double pqm submits since it got fixed, was that all branch conflicts or is it still flakey?
<lifeless> that was folk hammering before it was fixed
<lifeless> treating it as a black box to analyse
<upmauro> pleas, help, i create a branch of exaile project, i register ssh key, but when i try checkout bzr checkout lp:~upmauro/exaile/0.3.x, show this exception, bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~upmauro/exaile/0.3.x/".
<upmauro> sorry my bad english
* mbarnett changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila)
<awilkins> Gah, why oh why are SVN vcs-imports on Launchpad not done with bzr-svn   <head meets desk>
<upmauro> please someone help me?
<jam> awilkins: new ones are
<jam> it is just hysterical raisons that old ones aren't
<jam> they kept the same importer that they started with
<awilkins> jam, Can you get old ones canned and redone if you ask nicely?
<vila> upmauro: lp was in maintenance, are you still encountering the issue ?
<awilkins> Not a big one, it's the protocol buffers one
<jam> awilkins: I think you have to delete the old ones, and register a new one
<jam> because they are at the same url
<mgz> upmauro: looks like you created the branch via the web interface, but didn't actually give it any content yet
<upmauro> vila, yes, still happening
<mgz> upmauro: you need to push some code there before you can pull anything from it.
<vila> upmauro: what mgz said ^
<awilkins> jam, presumably this means you have to ask nicely since they are owned by VCS Imports
<jam> awilkins: can you link it?
<jam> I might have access
<upmauro> mgz, huum, thanks, more
<upmauro> I did not understand what kind of content? after all, is a branch of the project, he should not be with the code of the project?
<mgz> generally, you do `bzr branch lp:project && cd project && hackhackhack && bzr push lp:~myusername/project/what_my_branch_does`
<awilkins> jam, tis https://code.launchpad.net/~vcs-imports/protobuf/trunk
<awilkins> jam, I only have a dinky little patch to their not-yet-merged maven plugin
<mgz> so, get a copy of the original code, make your changes locally, then push them back to launchpad
<upmauro> mgz, aaah .. thanks :P
<awilkins> jam, Just wanted to put it up on LP so I could aim them at it, but I can mail them a patch file.
<jam> awilkins: you're not ~mordred, right?
<awilkins> jam, No ; I guess that branch would have to be redone by cherrypicking the revisions into the new one if it was reconverted?
<upmauro> mgz, when I create a branch, checkout and do it the first time, he has the code of the project?
<mgz> channel: anyone know of a good first contribution guide to link to?
<jam> awilkins: a new import is pending
<awilkins> jam, Cool ... is the default output of bzr diff a suitable patch for SVN users?
<upmauro> upmauro@upmauro~/workspace$ bzr branch lp:~upmauro/exaile/0.3.x
<upmauro> Enter passphrase for key '/home/upmauro/.ssh/id_rsa':
<upmauro> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~upmauro/exaile/0.3.x/".
<jam> I think so, but I'm not 100% positive
<mgz> upmauro: I'm guessing you want to base your work on the current exaile trunk, which would be `bzr branch lp:exaile`
<mgz> only when you put your work back on launchpad does it need to live under ~upmauro and have a name saying what the branch does
<upmauro> mgz, I understand now, thank you for your patience :)
<jam> awilkins: I'm told that the backlog might be kind of big because of the rollout, so I don't know when it will actually get imported
<awilkins> jam, Ooh, new features :-)  - I've put a patch in their bugtracker for the time being.
<spiv> jam: http://webnumbr.com/bzr-pqm-queue-length has updated now :P
<jam> spiv: of course now it is wrong, since we have a q length of 3
<spiv> :)
<jam> seems their scanning and their graphing are asynchronous
<awilkins> What's the way of just showing the changes that a merge revision introduced that were not in the branches it merged?
<awilkins> e.g. changes you did to resolve conflicts
<maxb> I don't know of such an invocation
<AfC> awilkins: I've always found that really hard. It seems like it shouldn't be.
<AfC> awilkins: I think the only way to do it is manually pull out the revision numbers,
<AfC> ie if the history is
<AfC> 748
<AfC>   747.1.2
<AfC>   747.1.1
<vila> the root problem is that you can't commit a tree with conflicts so you can't compare it either
<AfC> 747
<AfC> awilkins: then you get the merge revision's changes it seems you can do
<AfC> $ bzr diff -r 747.1.2..748
<AfC> I think that's it
<AfC> awilkins: but that's all only after you commit
<AfC> it's quite annoying. I want to see my changes, not the whole branch
<AfC> (and as maintainer I frequently have to do minor cleanup at merge. Copyright years, if nothing else;
<AfC> I realize the "proper" way to do it is to take a copy of their branch, make your changes, then merge cleanly with no changes at merge, but... :(
<vila> woooohoooo, first windows full test suite passing on babune !! Champagne !
<Meths> Can you unshelve onto a different branch?
<maxb> Sorta kinda
<maxb> I believe shelves track which rev-id they were based on, so it would have to not be too diverged, I'd expect
<maxb> To actually do it, would depend on whether you shelved in a branch or a checkout
<Meths> So it's easier to just diff to file and patch the other branch?
<maxb> Probably is easier to diff/patch, unless the shelf is sufficiently complex that bzr's merging can do better
<neaj> bzr is taunting me again ..
<neaj> I did 'bzr branch bzr branch http://svn.../bigrepo/somemodule' and saw that it was reading 300000+ bits of metadata, so i hit ctrl-c
<neaj> (sorry, only one 'bzr branch')
<neaj> now when I repeat that command I get a traceback and "KeyError: 'No such TDB entry'"
<AfC> taunting :)
<neaj> i was surprized to see it beginning to reread the metadata (more than 100MB), because yesterday i branched bigrepo/someothermodule, and expected that it would reuse the metadata.
<neaj> somehow i always manage to get on bzr's bad side
<AfC> Difference module, different revisions, different svn - bzr mappings?
 * AfC has learned not to interrupt bzr branch; 
<neaj> they're from the same svn server
<AfC> wastes bytes
<AfC> one strategy is to branch at -r 1 or so,
<neaj> http://svnserver/bigrepo/{module1,module2}
<AfC> then do incremental pulls of -r $i at 100 or so a go
<AfC> Subversion is EXTRAORDINARILY slow at accessing historical revisions. Took me 2 days to get GTK out of GNOME svn a few years ago.
<AfC> and (last I looked) bzr only writes the real packs after it thinks its finished downloading. But bzr-svn metadata is separate from all that
<neaj> the thing is, this bigrepo contains 100s of unrelated modules, and i'm only ever interested in a handful at a time
<AfC> I haven't had to use bzr-svn for a while, can't provide any further insight, sorry
<neaj> looks like i should give up on using bzr for this particular repo
<knighthawk> anyone have docs on how to permanently your password handy?
<bob2> heh
<bob2> ENOVERB
<bob2> if you mean ssh, ssh keys yo
<knighthawk> thanks bob2
<bob2> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<noodles775> Hi ppl. I'm just trying to create a quick screencast of bzr pipeline, but have notice that using `bzr lp-submit` for a pipe no longer sets the pre-requisite branch automatically (at least for me).
<noodles775> Is this known, or how can I see if it's a problem local to me?
<noodles775> I'm currently looking through the plugin code, but although it does indeed provide lp_submit, it seems that another plugin does also (launchpad - which I don't want to remove :) ).
<noodles775> nm. I removed the ~/.bazaar/plugins/pipeline and installed instead and it works.
<Odd_Bloke> Hello all.  I'm trying to push a git branch to Launchpad using bzr-git, and am hitting http://paste.pocoo.org/show/319942/.  There don't seem to be any bugs related to it in either bzr or bzr-git.  Any thoughts on what's happening?  Am I doomed to failure?
<Odd_Bloke> This is using the latest revisions of lp:bzr and lp:bzr-git.
<Odd_Bloke> And the dulwich in unstable (if that matters).
<Odd_Bloke> jelmer: ^ :)
<Kamping_Kaiser> Odd_Bloke: is it a public git branch? i'm happy to try pushing it too
<Odd_Bloke> Kamping_Kaiser: It isn't, no.  Though it will be a public bzr branch, so I could put it somewhere. :p
<Odd_Bloke> Now if only I knew how to do that in git. >.<
<Kamping_Kaiser> :|
<Odd_Bloke> Kamping_Kaiser: https://bunsen.credativ.com/~dwa/quotes_opportunities_link.git/
<Odd_Bloke> Not entirely sure what the ACL on that is, so you may be blocked.
<Kamping_Kaiser> nup, fatal: HTTP request failed
<Odd_Bloke> :(
<Kamping_Kaiser> :/
<Odd_Bloke> Kamping_Kaiser: http://daniel.daniel-watkins.co.uk/quotes_opportunities_link.git/ ?
<Kamping_Kaiser> Odd_Bloke: nope, new error.
<Kamping_Kaiser> fatal: http://daniel.daniel-watkins.co.uk/quotes_opportunities_link.git/info/refs not found: did you run git update-server-info on the server?
<Odd_Bloke> Kamping_Kaiser: Try again?
<Kamping_Kaiser> sigh. even squeezes dulwich is too old for bzr-git head. can't keep up :|
<Kamping_Kaiser> Odd_Bloke: it branches, give me a few min though
<Odd_Bloke> Kamping_Kaiser: No worries.
<Kamping_Kaiser> wish you could cut the ~username/+junk out of bzr pushes.
<Kamping_Kaiser> </random complaint>
<Kamping_Kaiser> Odd_Bloke: https://code.launchpad.net/~kgoetz/+junk/oddbloke-test
<Kamping_Kaiser> Odd_Bloke: git clone your repo -> bzr push. no changes or anything
<Odd_Bloke> Kamping_Kaiser: :(
<Kamping_Kaiser> :/
<Odd_Bloke> Kamping_Kaiser: What versions are you on?
<Kamping_Kaiser> interestingly, bzr head fails. or i think its failing *g*
<Kamping_Kaiser> Odd_Bloke: versions in squeeze
<Odd_Bloke> OK.
<Kamping_Kaiser> for bzr/git/bzr-git
<Odd_Bloke> I'm using trunk for the first and last of those, so that's probably the issue.
<Kamping_Kaiser> i'll update my bzr trunk and try again
<Kamping_Kaiser> ah, i can't try trunk, bzr-git is too version specific
<Odd_Bloke> Kamping_Kaiser: Anyway, I've pushed to my own branch now.  Thanks for all your help. :)
<Kamping_Kaiser> thats a problem with bzr-* in problem
<Kamping_Kaiser> Odd_Bloke: wd :)
<Kamping_Kaiser> no problem, have fun
<Kamping_Kaiser> me, i'm off to bed ;)
<Odd_Bloke> Sleep well. :)
<Kamping_Kaiser> ta
<ManDay> I assume bzr ships in a minimal version without any gui stuff and is still fully functional, right?
<maxb> bzr itself is a command line tool. All the GUI stuff is various add-on projects
<ManDay> good
<ManDay> why is git still so dominant?
<jelmer> Odd_Bloke: hi
<Odd_Bloke> jelmer: o/
<Odd_Bloke> jelmer: Kamping_Kaiser helped me get on my way, by using older versions of everything.
<Odd_Bloke> So I _suspect_ a regression...
<jelmer> Odd_Bloke: that's odd (no pun intended ) :-)
<Odd_Bloke> :)
<jelmer> Odd_Bloke: I don't have an overrided clone_on_transport in bzr-git
<Odd_Bloke> Hmm.
<jelmer> Odd_Bloke: if you still have the setup with the newer bzr-git, can you check where the clone_on_transport is coming from?
<Odd_Bloke> jelmer: Can I get bzr to run pdb on an error?
<jelmer> Odd_Bloke: yep - set BZR_PDB=1 as env variable
<ovnicraft> hello guys i am trying to update my repo, but bzr tell that check the limbo dir in bzr/checkout/ i ls the folder its empty and i cant update it
<ovnicraft> so i delete the folder but now tell with pending-deletion
<ovnicraft> delete it and again with limbo
<ovnicraft> both folders are empty
<jelmer> ovnicraft: I think you'll have to remove both at once and try again
<jelmer> though we should never leave those around afaik
<Odd_Bloke> jelmer: http://paste.pocoo.org/show/yZt2M8INYmRRvya5aaHq/
<jelmer> Odd_Bloke: and self.bzrdir.clone_on_transport ?
<jelmer> (I'm wondering where it inherits it from)
<Odd_Bloke> <bound method LocalGitDir.clone_on_transport of <bzrlib.plugins.git.dir.LocalGitDir object at 0x23a1090>>
<Odd_Bloke> I'm not sure how to check the inheritance...?
<jelmer> Odd_Bloke: what revno of bzr-git do you have?
<Odd_Bloke> 1070
<jelmer> Odd_Bloke: an which bzr?
<jelmer> *and
<jelmer> Odd_Bloke: what kind of command are you running ?
<Odd_Bloke> 5608
<maxb> Hi jelmer. In your bzr-svn "Store short testament ..." change, you also committed a bunch of unrelated stuff to fetch.py in the area of the nevow fix, including a pdb.set_trace() call
<jelmer> hi maxb
<jelmer> maxb: oops - thanks
<maxb> np, thanks for fixing :-)
<maxb> That nevow bug was beyond my abilities at present
<jelmer> ah, it was conditional though
<jelmer> I wonder how the testsuite could've passed :-)
 * maxb is attempting to comprehend more of the arcane depths of bzr-svn
<ovnicraft> jelmer, the problem is when i try to bzr update it keeps a time then jsut tell me Killed
<ovnicraft> i think there is a bug there
<ovnicraft> i am working with 2.1.1
<ovnicraft> there is any way to see what happen while bzr update is running ?
<jelmer> ovnicraft: That suggests that there's more going on
<jelmer> ovnicraft: have you tried a newer version of bzr?
<ovnicraft> nope but now i need it bzr update always tell me killed lock my repo and create limbo and pending-deletion
<ovnicraft> this is really buggy anyway i will update my bzr to see what happen
<jelmer> ovnicraft: the limbo and pending-deletion are created during bzr updatre
<jelmer> bzr update is then killed prematurely before it can delete them
<jelmer> so the next time you run bzr it notices those files and recognizes that bzr was killed
<Odd_Bloke> ovnicraft: Could there be a large file that the update is trying to pull down?
<ovnicraft> Odd_Bloke, nop but my branch has 157 folders/ 20 files by folder
<Odd_Bloke> (I'm thinking that potentially a large file is causing bzr's memory to balloon and get OOMkilled)
<dholbach> hiya
<dorins> Hi, any qbzr devs around?
<Odd_Bloke> dorins: Don't ask to ask, just ask. :)
<dorins> I submitted a merge proposal on qbzr 3 months ago, and I'm wandering how come it hasn't been revied
<dorins> https://code.edge.launchpad.net/%7Edorins/qbzr/qdiff-changes/+merge/34710
<Odd_Bloke> dorins: Looks like bialix is who you want.
<dorins> Odd_Bloke: yes, I haven't seen him online in this irc channel in a while though
<dorins> I'll try to reach him on email I guess
<Odd_Bloke> 12:43:55 -!- bialix
<Odd_Bloke> [~chatzilla@97-8-134-95.pool.ukrtel.net] has quit
<Odd_Bloke> dorins: ^
<dorins> Odd_Bloke: thanks, hadn't checked the logs
<maxb> Anyone know about YUI? It saddens me that Loggerhead is using an ancient prerelease of YUI 3, and I'm wondering what the magnitude of an update effort would be
<beuno> maxb, not too hard
<beuno> I have a branch that brings it up to 3.0
<maxb> That would be nice
<beuno> but it needs a little bit of work
<maxb> At least it would be a released version then
<beuno> lp:~beuno/loggerhead/yui3-0-0
<beuno> taking it to 3.3 instead of 3.0 wouldn't be much different either
<beuno> I won't complain if someone steals that away from me and finished  ;)
<vila> beuno: naughty :)
<beuno> :)
<poolie> hi beuno
<dholbach> poolie, hey - which room are you hanging out at again? :)
<poolie> dholbach, hi, 516
<dholbach> sweet - I'll see you in a bit :)
<beuno> heya poolie
<beuno> poolie, I gather from the time you're around, you'e in Dallas?
<poolie> correct :)
<beuno> poolie, how are you coping with just eating things deep-fried with melted cheese?
<poolie> :/
<poolie> will find a vegan restaurant tonight, i think
<poolie> i have a car
<poolie> and California is not _that_ far
<beuno> ha!
<beuno> you can only eat the lettuce and tomato used as decoration for so long
<awilkins> Subway Veggie Block Thing.
<lifeless> poolie: bug 702255
<ubot5> Launchpad bug 702255 in Launchpad itself "openoffice.org import using excessive memory" [High,Triaged] https://launchpad.net/bugs/702255
<mgz> is launchpadlib intended to be 2.4 compatible?
<lifeless> probably not; I think bugs about that would be reasonable
<soren> poolie: There's a vegetarian place in San Antonio that serves a bunch of really good vegan stuff, to.
<soren> poolie: It's still a bit far, but not as far as California :)
<poolie> lifeless, good question about ulimits
<soren> By Texan standards, it's virtually next door.
<poolie> i'm not actually vegan or anything, i just like vegetables too
<soren> Ah.
<soren> I didn't think you were, but perhaps it was a new development :)
<mgz> it appears to be but I can't see it clearly documented anywhere and the test suite assumes 2.6
<mgz> sod it, you can have this branch sans tests.
<mgz> no way I'm getting the setuptools and dependency nightmare on my 2.7 build.
<lifeless> heh :)
<lifeless> spiv: in oops links, just do OOPS-xxx - the bug tracker will link it, and the urls ar enot found by the reference-counter
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=xxx
<mgz> if you sprint people have a launchpadlib dev to hand, please point them at <https://code.launchpad.net/~gz/launchpadlib/trivial_homeless_launchpadlib_dir/+merge/46150>
<spiv> lifeless: Uh, sure, but I haven't mentioned any OOPSes in bugs recently?
<lifeless> spiv: last night
<lifeless> spiv: bah
<lifeless> mwhudson: ^ ^ ^
<mwhudson> lifeless: ?
<mwhudson> oh
<vila> mgz: hey ! Seen the windows job turning blue on babune ?
<mgz> vila: I did, and was going to woho in here, but you'd beat me to it.
<vila> :D
<dholbach> poolie, there's "Cosmic CafÃ©" and "Spiral Diner and Bakery" in Dallas
<vila> mgz: for once... :D
<dholbach> we might go to the Cosmic CafÃ© again tonight
<mgz> vila: I was wondering if the selftest-lang-C group would now turn blue, but last run seems to have IPC issues so maybe not
<vila> mgz: I should re-try it, but the 10.5 slave is unreachable by babune as long as I sprint and I expect failures there
<vila> mgz: so for the time being I don't really expect the lang-c to be workable
<vila> mgz: but I can re-run it to refresh the data for available slaves
<yshavit> This could be a dumb question... but if I created a directory with bzr init-repo, can I mv that directory to rename it?
<yshavit> that is, just standard "mv" ? Or do I have to somehow tell bzr that I've renamed the repo?
<poolie> yshavit, you can just rename it
<yshavit> Peng: thanks
<poolie> other things that have remembered its location, eg as a default source for push or pull, might alsoneed to be updated
<yshavit> poolie: ah, okay. But that should be pretty easy, right? Just pass it in once with the --remember ?
<poolie> exactly
<yshavit> awesome, thanks!
<yshavit> My main fear was that I'd subtly break something without knowing it until a week from now things mysteriously go haywire -- sounds like that won't happen
<poolie> nup
<guest32454> yshavit: Yes
<yshavit> guest32454: thanks :)
<lifeless> poolie: fyi bug 701329 is the highest frequency oops for loggerhead
<ubot5> Launchpad bug 701329 in Launchpad itself "error: [Errno 32] Broken pipe" [Critical,Triaged] https://launchpad.net/bugs/701329
<mwhudson> interesting
<mwhudson> i really hope loggerhead doesn't timeout 10k times a day
<mwhudson> we could try to correlate the oopses with the apache logs on bazaar.launchpad.net to try to figure out what's going on
<poolie> lifeless, hooray
<lifeless> poolie: tedgould says bzr-search is great and perhaps we should recommend that in the udd docs
<jelmer> lifeless: is there any chance of having it fixed against current bzr versions?
<lifeless> jelmer: is it broken?
<jelmer> lifeless: https://bugs.launchpad.net/bzr-search/+bug/672011
<lifeless> jelmer: looks like something changed in bzr API
<lifeless> jelmer: try without C extensions
<jelmer> lifeless: https://code.launchpad.net/~vila/bzr-search/test-failures/+merge/43644
<lifeless> oh, I see a branch
<jelmer> I just noticed that as well :-)
<lifeless> sure
<jam> vila
<jam> have you released
<jelmer> vila: !!
<vila> no comment
<lifeless> jelmer: bzr-search fix merged
<rubbs> how can I change the saved pull location again?
<beuno> rubbs, --remember
<rubbs> ah, thanks
<jelmer> lifeless: \o/
<jelmer> lifeless: thanks
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b5 is frozen, time to release stable plugins and build the installers! (rm vila)
<vila> jelmer: ^ :-p
<exalt> hello
<exalt> i created a launchpad account yesterday for a project im helping
<exalt> but i cant bzr
<exalt> r I finish this e-mail, I'll upload our first package to the PPA, unless so
<exalt> hmm
<exalt> r I finish this e-mail, I'll upload our first package to the PPA, unless so
<exalt> sorry stupid selection
<exalt> http://pastebin.com/rQdYBv5K
#bzr 2011-01-14
<spiv> exalt: The problem is "Permission denied (publickey)"
<spiv> exalt: /away
<spiv> oops
<exalt> spiv, yeah but bzr whoami returns my user
<exalt> so i am logged in
<spiv> exalt: try "ssh -l YOUR_LAUNCHPAD_USERNAME bazaar.launchpad.net"
<spiv> And perhaps add -v for more debugging
<spiv> I think you'll find that those commands also fail with that error
<exalt> debug1: Server accepts key: pkalg ssh-rsa blen 279
<exalt> Agent admitted failure to sign using the key.
<exalt> spiv, ^
<JackyAlcine> Hello, I'm having an issue with pushing code to a branch.
<jelmer> hi JackyAlcine
<JackyAlcine> Give me a moment to compile necessary info to a pastebin
<JackyAlcine> http://pastebin.com/V7RJ74t1
<JackyAlcine> That's my friend's bin.
<JackyAlcine> And he can't pull code from branch lp:libopenmary-c++
<exalt> JackyAlcine, hi :)
<JackyAlcine> lol
<JackyAlcine> jelmer: exalt's the person in need of assistance.
<exalt> spiv, it seems the server accepts my key but then fails at it
<exalt> jelmer, ^
<jelmer> hi exalt
<jelmer> sorry, was not watching IRC very closely
<jelmer> exalt: it looks like you don't have the right SSH key up on launchpad
<exalt> jelmer, ive searched for my error:
<exalt> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786
<exalt> seems like min
<exalt> mine
<spiv> exalt: try running "ssh-add"
<spiv> exalt: and/or try the workarounds in the later comments.
<exalt> spiv, got it working
<exalt> thanx all
<twb> ssh-copy-id bazaar.launchpad.net ==> Not allowed to execute 'umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys'.
<twb> Is there a way to upload additional keys WITHOUT using the web interface?
<maxb> no, there isn't
<twb> OK, I'll just use the git mirror for Emacs.  I just realized bzr clone gets OOM-killed anyway.
<Miika--> Hello, does bazaar need to be installed on remote system to push / pull through ssh?
<Peng> Miika--: bzr+ssh: Yes. That's what the "bzr+" means. sftp: No, but performance isn't as good as bzr+ssh.
<Miika--> I mean, if I have bzr installed on my local, working computer, but I have only remote storage, with no bzr installed. Does push / pull work to that remote location?
<Peng> Miika--: I know that's what you meant.
<Miika--> Ok, thanks
<Peng> Installing bzr on the remote server would be ideal since, as I said, sftp's performance is inferior.
<Tak> besides - is a computer without bzr really a computer? :-P
<catphish> are revision numbers in bzr always sequential?
<catphish> by which i mean, if i find a revision called 100, are there definitely 99 ancestors?
<Peng> There could be more ancestors, of course. The "100" refers only to mainline revisions.
<catphish> what is a revision that's not mainline?
<catphish> i was working on the (possibly incorrect) assumption that bzr branches were linear like svn
<Peng> Bazaar's merging support isn't crap. Revisions can have more than one parent.
<catphish> where are the parents located?
<catphish> in another branch?
<Peng> What do you mean?
<catphish> i'm struggling to understand the structure
<Peng> The docs should explain it well enough.
<Miika--> Does bzr-git support git submodules?
<catphish> you say a commit scan have more than one parent
<catphish> *can
<catphish> one parent i assume must be the previous tip? but where does the other one point?
<Peng> catphish: Right. "bzr merge some_other branch; bzr commit". That revision's parents are the previous tip from this branch + the tip from the branch you merged in.
<Peng> Err, "bzr merge some_other_branch" *
<catphish> so a parent is either a revision number, or a url and a revision number?
<Peng> No, revisions have GUIDs. Revision numbers are just a convenient per-branch representation.
<catphish> ooo that's good
<Peng> You know how git and hg use SHA-1 hashes? Bazaar does something similar, though the format is not restricted, and they're usually just randomly-generated.
<Peng> catphish: You can pass --show-ids to "bzr log" and maybe some other commands, though it's not really very interesting.
<catphish> so it's not possible to follow a parent and find the actual commit?
<catphish> since it could be anywhere in a remote repo
<catphish> or will those parent commits actually get pulled into the branch too?
<Peng> "bzr merge" pulls the revisions into the local repo.
<catphish> i ask because i'm making a log viewer
<catphish> so i'm not totally sure what commits i can show, starting from a given revision
<Peng> Obviously lightweight checkouts and stacked branches may not have all revisions locally, but they will be in the remote repo.
<Peng> Unless they're ghosts, in which case the revision really isn't anywhere. But that's not a common situation.
<catphish> the repo i'm testing with doesn't appear to have any revisions with multiple parents sadly
<Peng> Nobody's merged? Ever? How boring.
<catphish> ah found one :)
<Peng> :D
<catphish> the merged branches seem to be inside the commit message
<catphish> *merged commits
<catphish> in the log view
<Miika--> How I can clone a project with submodules from github using bzr-git? It says about repository formats supporting nested trees
<fax8> hi guys, I recall that there was a documentation page with suggestion on how to structure a bzr repository..
<fax8> it seems that I'm not able to find it anymore.. can you guys point me to it?
<catphish> fax8: structure one? do you mean using "bzr init-repo" to create a repo then create branches inside?
<Miika--> Or, how I can change default repo format?
<Peng> catphish: Yes, that's how "bzr log" displays it.
<catphish> ok :)
<fax8> catphish: how to structure it in a smart way.. I mean creating folder and subfolders using "trunk" or folders for various stable releases.. stuff like that
<catphish> fax8: not sure, i'm a newbie here
<fax8> catphish: thanks anyway
<fax8> goodbye everybody!
<janisozaur> hello. I have two separate branches (standalone trees, 2a) that share some code, but are not tied to each other via bzr. I've done some changes to branch A, that I'd like to introduce to branch B. how can I do that? preferably keeping commit logs, though it can be done manually, as there are not many revisions
<LeoNerd> bzr replay   might be able to do it
<LeoNerd> In fact I know it can because I've used that before in this very situation
<janisozaur> LeoNerd, my bzr doesn't know such command
<LeoNerd> Applying an identical bugfix to unrelated trees
<LeoNerd> It's part of the rebase plugin
<janisozaur> LeoNerd, thanks, will see to that.
<janisozaur> also, I remember I've used 'bzr patch' once to merge in output of 'bzr diff', but I can no longer see the command. is it from a plugin or was it removed or just my memory doesn't serve me well?
<LeoNerd> I expect that's what became  bzr replay
<janisozaur> LeoNerd, ah, thanks a lot then
<LeoNerd> replay  reapplies a given patch into the current branch
<LeoNerd> bzr replay -r 123 /path/to/source/branch
<fullermd> 'bzr patch' is part of bzrtools.  But it doesn't really do anything that regular patch(1) doesn't.
<maxb> The rebase plugin is called the rewrite plugin these days
 * catphish is sad because bzr diff returns non-zero exit codes on success :(
<poolie> catphish, they have meanings
<poolie> like 'there are uncommitted changes'
<catphish> i know what they mean
<spiv> james_w: do you have time to keep working on https://bugs.launchpad.net/udd/+bug/653307 today?
<catphish> it just happens to be a problem for me that it exits non-zero on success
<james_w> spiv, should do yeah, but I have something urgent to do this morning
<spiv> james_w: ok, give me a poke or come say hello later if you want
<james_w> spiv, I can probably come up after lunch again
<spiv> Sounds good
<catphish> i will need to write a wrapper that exits zero unless the exit code is 3
<poolie> catphish, in a unix shell?
<poolie> a quick way to write it is
<poolie> bzr diff ||:
<poolie> maxb, awake, perchance?
<maxb> hello
<catphish> poolie: does that just always return 0?
<poolie> yes, it means "if this fails run :" and ":" is a builtin that returns 0
<poolie> maxb, i just spoke to pitti about SRUs
<catphish> poolie: unfortunately that's no use to me since i won't actually know if the diff failed
<poolie> ah ok
<catphish> i need some shell knowledge that returns (code != 3)
<catphish> since diff returns 3 on a failure
<poolie> so i guess you need bzr diff; [ $? -lt 2 ] || print "something's wrong"
<catphish> yes :)
<lifeless> poolie: bug 702914
<ubot5> Launchpad bug 702914 in Launchpad itself "AttributeError OOPS in codebrowse" [Critical,Triaged] https://launchpad.net/bugs/702914
<poolie> really, interesting
<poolie> lifeless, to avoid roundtrips, feel free to triage/assign etc
<lifeless> poolie: I'm guessing another thread safety issue, seems fairly low frequency atm
<poolie> k
<lifeless> may be loggerhead, may be bzr itself
<lifeless> I'm not sure if I should open a loggerhead task or not
<lifeless> jelmer: are you updating loom packages too?
<jelmer> lifeless: in the past Andrew has done the loom packages (I try to avoid packaging software I don't use for various reasons)
<jelmer> lifeless: being on the bzr team and with their importance for UDD I should probably start using them now though
<jelmer> lifeless: I'll have a look at updating the packages.
<jelmer> lifeless: thanks for the reminder
<jelmer> lifeless: did you see my reply (4 lines) ?
<jelmer> argh
<lifeless> jelmer: no
<agruman> how much size does bzr take for each file (unmodified)? (does it save a copy of the file in .bzr?)
<Peng> That's a bit complicated. Bazaar compresses everything.
<Peng> Repositories store every revision of every file, but they're compressed six ways to Sunday.
<agruman> Peng, ok, but if i have a single revision will it only take 1x the file size? (im not used to dvcs, been using clearcase and there the files are 1x and read only until checked out and modified)
<lifeless> if you have a single revision the overhead will be <= gzip(file content)
<lifeless> two revisions it will be gzip(file content + binary delta to second revision)
<agruman> lifeless, ok, but the file would be present in its uncompressed form as well? resulting in 'file + gzip(file)'?
<spiv> agruman: no
<spiv> agruman: we don't store uncompressed file contents in the repository
<Peng> Obviously the working copy is uncompressed, of course.
<agruman> spiv, ok, then im not sure i understand. How would i read the file, would i need to decompress it?
<agruman> Peng, k
<lifeless> but the working copy isn't overheaad ;)
<agruman> perhaps, depends on how you see it
<agruman> i myself find it overhead
<agruman> i would have wanted the size to be "repo + checked out files"
<agruman> or is the working copy "optional"? i suppose not, but as i said this is new to me
<lifeless> agruman: thats right
<lifeless> its optional
<Peng> agruman: Yes, you can remove the working copy.
<lifeless> on a server you want just repo
<Peng> Or not create one in the first place.
<lifeless> on a laptop you want repo + working copy so that you can work offline, edit files, do log etc
<Peng> agruman: The size is "repo + checked out files". You were asking about the specifics of "repo". And "checked out files" can be zero.
<agruman> thanks alot for the explanation :)
<agruman> would it be possible to only have a working copy and not the repo on a laptop (for file that dont change ex binary)
<spiv> It is, "bzr checkout --lightweight".  There's a pretty large performance hit if the repo for that is on a network.
<agruman> spiv, ok, thanks alot for the info
<poolie> maxb, still here?
<poolie> i spoke to pitti about our SRUs and MRE
<poolie> he said we should just upload for -proposed, or ask for sponsorship into that
<jml> jelmer: <exarkun> spiv: Can we be sure that those rev props don't get onto trunk?
<jelmer> jml: I think I miss context.
<spiv> jelmer: short version: svn users are allergic to revprops
<spiv> jelmer: because they fear breakage in commit hooks, commit mail scripts, trac, etc
<jml> and I never use bzr-svn to do Twisted stuff
<jml> because I'm afraid of exarkun getting angry at me
<jelmer> are you sure you mean revprpos, not file properties?
<spiv> Anything that looks weird and unusual, basically :/
<spiv> In this case there's a degree of discomfort about having props of any flavour in a branch
<jelmer> Can you give a bit more context in that case - be sure that those revprops don't get onto trunk when doing what?
<spiv> And deep fear about having them reach official branches like trunk
<spiv> In this case landing my bugfix branch on trunk
<jelmer> mwhudson: ooh, shiny linaro hostmask!
<jelmer> spiv: so, "svn merge" will ignore revision properties
<jelmer> spiv: is that what you're asking?
<spiv> jelmer: I'm not asking anything, really (although thanks for confirming that for me)
<spiv> jelmer: I think jml was just sharing some pain
<jelmer> ah
<spiv> jelmer: "svn merge" was my plan for landing this change
<spiv> jelmer: as soon as I figure out the right invocation, because it doesn't just DTRT :)
<jelmer> so I can feel the pain when it comes to file properties (and will require user confirmation before bzr-svn sets them in newer versions)
<jelmer> revision properties shouldn't break anything other than bzr-svn if they're incorrect,
<jelmer> and are only visible in a limited number of situations
<mgedmin> so, I look in my process list and I see that bzr-notify has 7 zombie children (all ssh processes)
<mgedmin> any clues?
<jam> vila!
<jam> vila!
<jelmer> mgedmin: wow, that's interesting. As far as I know bzr-notify should never do remote access..
 * awilkins would just turn off or filter revprop reporting on Trac or whatever
<awilkins> I agree that it looks a mess from the POV of a "pretty" changeset browser
<spiv> jelmer: AIUI the issue isn't that they break SVN, but that random tools people build on their SVN repo are fragile
<spiv> jelmer: because they have never been tested with rev props
<spiv> jelmer: in other news
<spiv> jelmer: "the right invocation" turned out to be "bzr merge URL" in my SVN checkout, because apparently I've forgotten too much svn to know how to make it be sensible
<awilkins> I could never get SVN to be sensible about merges
<awilkins> I had a crack recently because I had to give training on SVN to my peers and was able to break it's merging ability with the first test I did (although it is *slightly* less rubbish than I remember it)
<awilkins> 'tis a shame that CollabNet are so stuck on SVN having sunk so much into it ; 'tis still the only VCS they offer on their hosting services AFAIK (and guess which hosting service we signed up for ....)
<awilkins> Happily I have a shell account and root on some of the build machines so I used it to make a Bazaar mirror of the sources and I don't have to use SVN anymore except on special occasions. Hooray.
#bzr 2011-01-15
<upmauro> alguem fala portuguáº½s e pode me ajudar ?
<maxb> ouch.
 * maxb gazes sadly on the number of plugins complaining about api versions against bzr.dev
<maxb> We really need a better way for handling this
<maxb> Why was bzrlib.api_minimum_version bumped already?
<aquarius> I'm trying to branch https://code.launchpad.net/~lemoncouch/dexter-rolodex/experimental-u1-support, but when I try "bzr branch lp:~lemoncouch/dexter-rolodex/experimental-u1-support", I get bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~postler/dexter-rolodex/dexter/".
<aquarius> Possibly this means that that branch was stacked onto a branch that no longer exists? If so...how do I get the code? confused
<mgedmin> I might be wrong, but I think the only way is to ask the user 'postler' to resurrect his branch
<aquarius> that's unfortunate :(
<mgedmin> this happened to me once, when I changed branch ownership
<mgedmin> all branches that were forked from my branch became broken
<mgedmin> I had to clone the main branch back to the old url
<mgedmin> I'm pretty sure this is a launchpad bug, maybe fixed, maybe not yet
<mgedmin> #launchpad is probably a good place to talk about this
<aquarius> may give that a shot :)
<maxb> I know this problem well
<maxb> let me look at the branches concerned
<maxb> Yes, it's a classic case of the usual launchpad bug
<maxb> we need ~lemoncouch or an admin to fix the stacking location in their branch
<aquarius> that's what I was thinking
<maxb> (or if you want the content right now, it's possible to copy the branch locally via sftp, and fix the stacking location locally)
<aquarius> well, atm I'm just browsing the diff on LP, which gives me the info I need
<maxb> I've filed https://answers.launchpad.net/launchpad/+question/141568 to have the admins fix the branches. It'll probably happen on Monday or Tuesday
<dOxxx> anybody know if vila will be on today?
<james_w> dOxxx, maybe, depends if he spends all day looking round Dallas I guess
<dOxxx> thanks
<lifeless> he's on now :)
<mgedmin> so, I'm trying to learn how to use shared repositories (because waiting for the network all the time sucks)
<mgedmin> I have a mirror branch foo of lp:foo, and I accidentally pushed a different branch into this local one
<mgedmin> how can I reset it to be a pure mirror of lp:foo again?
<mgedmin> bzr pull --overwrite?
<maxb> yes, but that doesn't have anything to do with shared repositories
<dev001> hi.  i just installed bzr trunk, as well as lp:bzr-svn.  when i exec any cmd, i'm getting: "Unable to load plugin 'svn'. It requested API version (2, 3, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 0)".
<dev001>   is this likely a bug, or simply an out-of-sync/un-updated repo?
<maxb> dev001: bzr.dev recently moved to a new API version declaration. Almost every plugin that checks for API versions strictly will report errors
<maxb> vila: You there?
<vila> maxb: yup
<maxb> vila: When opening 2.4, did it really make sense to bump api_minimum_version already?
<vila> maxb: by 2 votes in favor one against and 2 abstain
<maxb> "yuck"
<vila> maxb: an option was to wait for one month
<maxb> I suppose I should broach a discussion on changing our API policies to suck less
<vila> maxb: but since we're sprinting, the expectation was that 1) most plugins can be fixed quickly, 2) this gives a slight incentive to release stable versions (and associated branch/series)  compatible with 2.3
<vila> maxb: now would be a good time for this, yes
<dev001> maxb: sounds like switching to lp:bzr/2.3 is, then, the sane thing to do for "the resst of us" ... at least for now?
<maxb> The key to which is "Are we really going to do anything at all in 2.4 which will break plugins built against 2.3?"
<vila> maxb: keeping in mind that plugins that check *strictly* are *asking* about the observed result...
<maxb> dev001: tracking lp:bzr is only for people who *want* the bleeding edge ;-)
<vila> dev001: or use a PPA
<dev001> thx!
<vila> maxb: as far as I'm concerned, I think that bumping the api is the best way to make it painful *now* to push plugin authors to do the right choice (and there are really many ways to deal with it)
<vila> maxb: we offer enough different ways to track coherent sets of bzr/plugins for users to *also* make their own informed choice
<fullermd> Wha?  Nobody ever told me I was allowed to be coherent and informed...
<vila> maxb: and until we have a better way express this compatibility story, I prefer to bump sooner rather than later
<vila> fullermd: indeed, you're a special case, go get your medics
<fullermd> Mom always told me I was 'special'...
<vila> maxb: but anyway, the above was my personal opinion, I'd more than happy to see the topic discussed more broadly
<vila> s/whatever/I'd be/
<dOxxx> vila: hey!
<dOxxx> vila: are you going to be around for a while today? I'd like to talk about the mergetools stuff.
<jelmer> dOxxx: he is one the phone :-)
<dOxxx> ok
<vila> dOxxx: still otp, but yes I'll be around
<dOxxx> vila: ok.
<vila> dOxxx: I'm back
<dOxxx> vila: hey :)
<dOxxx> vila: I'm tyring to pick up where I left off on the mergetools stuff
<vila> dOxxx: cool !
<maxb> aarrgh
<dOxxx> vila: I've replaced the Config.set_merge_tools with set_merge_tool and remove_merge_tool.
<vila> from the top of my head, I think the main point was about checking the availability of mergetools
<maxb> my bzr-svn has been doing the same thing over and over because it's not committing its sqlite cache at exit
<dOxxx> vila: the difference between user-defined merge tools and the known merge tools?
<vila> dOxxx: right, the fact that if you set known merge tools at a given point it can become obsolete, whereas if you check on demand, you're always right
<dOxxx> vila: so Config.get_merge_tools and find_merge_tool should only return the user-defined tools? So how then do clients (e.g. qconflicts) find a known merge tool? do they have to query mergetools.known_merge_tools separately?
<dOxxx> i.e. should Config methods only deal with the contents of the config file?
<vila> dOxxx: yup, I think qconflicts should query against the potential ones and find which one are available
<vila> dOxxx: and users should be able to manage the potential ones
<dOxxx> vila: okay. so I'll add a find_known_merge_tool to the mergetools module, which clients will query Config first and then mergetools.find_known_merge_tool if it wasn't find in the Config
<vila> dOxxx: yeah, something like that, maybe mergetools.check_availability
<dOxxx> well, it's meant to return the MergeTool object itself so it can be invoked since that's when it's being called
<dOxxx> check_availability implies boolean to me, so I'll stick with find :)
<vila> dOxxx: ECONTEXT, I haven't re-read the proposals yet
<dOxxx> vila: basically, qconflicts and the commandline stuff are given a merge tool *name* by the user, so they need a function to get the MergeTool object for that name. There has to be one in Config and there will need to be one in the mergetools module to get one of the predefined, i.e. 'known', merge tools, if it's not found in the config.
<vila> dOxxx: that's it
<dOxxx> cool
<dOxxx> I has a plan!
<dOxxx> :)
 * vila re-read
<dOxxx> vila: I've pushed some changes already but still making the last few changes to separate user-defined and predefined merge tools.
<vila> so, there is still duplication, remote_merge_tool is not needed now that bzr config is available,
<dOxxx> vila: it's needed by qconfig
<vila> put it there then :)
<dOxxx> vila: but then qconfig has to know that the option is called 'bzr.mergetool.<name>'. That knowledge should be in Config.
<dOxxx> then if we need to change it, it only has to change in one place
<vila> not more than knowing that it should call remove_merge_tool
<vila> dOxxx: we won't add accessors for any and all config variables, that's the point
<dOxxx> then why aren't we doing file('bazaar.conf').write('blah')?
<dOxxx> :)
<dOxxx> oh
<dOxxx> is this a change in policy?
<vila> that's where we're heading yes, even if all the pieces are not there yet
<dOxxx> so really, should I have anything in Config then?
<vila> but even the current policy only requires get acessors
<dOxxx> ah
<dOxxx> so get_merge_tools and find_merge_tool and get_default_merge_tool are ok?
<vila> get_merge_toolS is more tricky and should stay I think
<vila> get_default_merge_tool is not needed
<dOxxx> find_merge_tool is not needed either then
<dOxxx> since it's pretty simple
<dOxxx> but it does construct a MergeTool object
<vila> I'd be ok with find_merge_tool since it handle the fallback to defaults
<vila> and we don't have that piece yet
<dOxxx> hmm now I'm a little confused. by defaults you mean the predefined merge tools in mergetools.known_merge_tools, right?
<vila> exactly
<vila> now, I see you have MergeTool.is_available, so may be there is a way to get rid of find_merge_tool, not sure
<dOxxx> find_merge_tool is just looking up a MergeTool object by name
<dOxxx> either in a Config or, as I was intending to do now, in the predefined list in the mergetools module
<vila> yeah, I'm still confused about when you check the availability probably
<dOxxx> that's a function that's on the MergeTool object, once it's been found.
<vila> yeah
<dOxxx> so, user selects tool by name through command-line or GUI and says "invoke this!" we have to then find the MergeTool object for that name and then check it's availability before invoking.
<vila> I think ideally (but not now), I'd like known_merge_tools to be replaced by config options definitions providing the default value
<vila> yup
<dOxxx> vila: I see. So config is going to grow a defaults mechanism at some time
<vila> yup
<vila> dOxxx: and the lack of it right now is what makes your proposal so hard to land, sorry about that
<dOxxx> ok, so for the moment, the find_merge_tool function Config will have to fake this defaults mechanism by using the known_merge_tools info in mergetools module.
<vila> yup
<dOxxx> okay!
<dOxxx> I'll go hack on this and get back to you.
<vila> cool
<vila> dOxxx: do you think you'll be able to have a look at the osx installers too ?
<dOxxx> vila: oh yeah, I was wondering what to do about plugin versions there? just look at whatever is current stable?
<vila> dOxxx: I'm away from home so I can't build the 10.6 one (well, I *could* but there are quite a few hops to reach the right machine :-/)
<dOxxx> I can do 10.6 no problem
<vila> dOxxx: yup, making sure it's compatible with 2.3 (but I don't expect many plugins to have been upgraded to 2.4 at this point)
<dOxxx> vila: ok
<dOxxx> vila: anything that doesn't have a stable release tarball, I'll just use their trunk tip
<vila> dOxxx: and then probably posting an excerpt of config.py to list which versions are used so we can nag the plugin authors to create appropriate series or not ;)
<dOxxx> :)
<dOxxx> or rather, I'll use the revision number that is currently the most recent on trunk.
<vila> dOxxx: oh, and I didn't follow closely but should upgrade to qtx.7.y or something ?
<dOxxx> looks like I should
<vila> ok, so long compile times ahead for me :-p
<dOxxx> :)
<vila> dOxxx: just send me an email when I can pull the latest changes
<dOxxx> vila: will do
<vila> dOxxx: my tip is revno 111 so far with 'Release 2.3b4' as the commit message
<dOxxx> yah I haven't made any changes on that yet
#bzr 2011-01-16
 * jasono is away: I'm busy
<spiv> james_w`: http://package-import.ubuntu.com/status/icu.html
<Anteru> Hi, is there a way in Bzr to recover from an aborted operation? My VM crashed while trying to do a Bzr merge, and now I get: bzr: ERROR: The dirstate file (DirState(u'/home/anteru/Dev/n/src/trunk/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '7a4bfab9edc5ca5aa9d6da'
<Anteru> rendering all local data more or less unusable
<fullermd> Anteru: Not as such, no.  If you were doing a merge, that suggests you started from a clean tree though, so you can probably blow it away and just check it out fresh.
<jelmer> vila!
<vila> :)
<jelmer> vila!
<vila> jelmer: pong
<vila> jelmer: lunch ?
<jelmer> vila: we're about to head out for some food
<jelmer> care to .
<vila> coming, 2th floor o lobby ?
<jelmer> 2th2nd floor
<vila> ok
<dameero> I search for a printed book about bazaar but I couldn't find any one. Is there something available?
<brando753> guys im brand new to version control is bazaar a good choice to start with
<brando753> will probably be using bazaar explorer
<awilkins> brando753: Yes, I find Bazaar to be a good starter
<awilkins> brando753: Which OS are you using?
<brando753> awilkins,  ubuntu 10.10 been using linux for over 3 years
<awilkins> I find a combination of the CLI and the qbzr plugin to be useful for most tasks - I can't say that I've used bzr-explorer in anger
<awilkins> I do find bzr to be easier to pick up than git
<brando753> thats good :D
<awilkins> I also find it to be a better DVCS for interaction with a team using SVN than git is
<brando753> my only issue is reading the documentation on bazaar-explorer assumes you know all the terminology, which i dont :(
<awilkins> http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/introducing_bazaar.html
<brando753> awilkins, thanks will look at that
<brando753> thanks that was what i was looking for
<johnf> Should I be getting this on a bzr revert? bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~eopas-au/eopas/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<awilkins> johnf: could you paste the command ; I suspect you're trying to revert the branch instead of your local working copy
<mathrick> hiya
<mathrick> Unable to load plugin 'svn'. It requested API version (2, 3, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 0)
<mathrick> running latest daily builds
<johnf> awilkins: nm: just realised it's a co and not a branch
<awilkins> That would be why :-)
<awilkins> Where's your copy of bzr-svn installed from? the repo or a branch of the sources?
<mathrick> bzr 2.3.0~beta4+bzr5615~ppa3877+3874~maverick1, bzr-svn 1.0.4+bzr3505~ppa364+366~maverick1
<awilkins> mathrick: If you're running nightlies, you might have to run plugins from their sources and even edit them a little
<mathrick> aww
<mathrick> well, I'm pointing this out, since they're very clearly out of sync
<awilkins> mathrick: In this case I suspect you'll get by checking out bzr-svn into your ~/.bazaar/plugins folder, and maybe tweaking it's version parameters in __init__.py
<mathrick> IMHO, beta should export 2.3.0 too if anybody out there depends on it
<awilkins> mathrick: Perhaps, unless it breaks the API from the perspective of 2.3.0 (which I can't say if it does or not)
<mathrick> I guess. Is 2.3.1 considered to be compatible with 2.3.0 say when requesting bzrlib API?
<Vlad__> Hi, I've submitted my first (very tiny) patch for Bazar documentation and got one approval so far. What else do I need to do to get the patch merged into the trunk?
#bzr 2012-01-09
<lifeless> mwhudson: fullermd: that delta module is -firmly- deprecated
<poolie> jelmer, hello?
<gnuoy> vila, could you give me a ping if you've got time to talk about RT#50151: setup pqm to resolve news conflicts for bzr
<gnuoy> ?
<vila> gnuoy: ping
<vila> gnuoy: are you in budapest ?
<gnuoy> vila, no, I'm afraid not
<vila> k, no worries
<vila> :)
<gnuoy> I've got 2 relevant files, /srv/pqm.bazaar-vcs.org/pqm-config/pqm.bazaar-vcs.org.conf and /home/pqm/.bazaar/locations.conf
<gnuoy> The /home/pqm/.bazaar/locations.conf has very little in it
<gnuoy> https://pastebin.canonical.com/57866/
<gnuoy> The main config is in /srv/pqm.bazaar-vcs.org/pqm-config/pqm.bazaar-vcs.org.conf...
<vila> the former is probably irrelevant (or rather specific to pqm and unknown to bzr)
<gnuoy> fwiw, it contains: https://pastebin.canonical.com/57867/
<gnuoy> I assumed pqm.bazaar-vcs.org.conf was the relevant file
<vila> for pqm yes
<gnuoy> given those 2 files does the change need to go into /home/pqm/.bazaar/locations.conf then ?
<vila> yup
<gnuoy> vila, ok, thats simple then
<gnuoy> :)
<vila> my bet would be that {workdir} is relevant as the highest section name we want to use
<vila> as in: that's probably below this dir that the merges occur
<vila> gnuoy: moving to a new room...
<gnuoy> vila, the chroot is under /srv/pqm.bazaar-vcs.org/chroot so is this what I need to add ?: https://pastebin.canonical.com/57868/
<vila> I'll add home/pqm/pqm-workdir (without a final /)
<vila> just to make sure it applies to bzr only (even if bzr is not mentioned there...)
<AfC> What's the default branch for ancestor: ?
<vila> AfC: ancestor: applies to a branch, I don't get what default you're after O_o
<vila> I should be missing your context
<AfC> vila: I just did
<AfC> $ bzr diff -r ancestor:
<AfC> vila: and it did something. I just don't know what branch it did it against.
<vila> the current one in the directory you ran bzr diff
<vila> bzr info should tell you
<AfC> vila: bzr info says the usual useless information, like "parent" and "submit" like I'd know what the difference is
<vila> submit_branch is probably relevant
<AfC> vila: ie it doesn't mention "ancestor"
<gnuoy> vila, so the entry should be https://pastebin.canonical.com/57869/ ?
<vila> parent is where you branch from, submit is where you merge from
<vila> so 'parent' should be more relevant than 'submit', sorry
<AfC> vila: excellent.
<AfC> vila: we are, regrettably, no closer to knowing what the definition of ancestor: is.
<vila> gnuoy: yup, that sounds good
<AfC> vila: [not your fault, just a lack of polish in bzr command line interface]
<vila> AfC: I'm using submit: far more than ancestor: myself
<AfC> vila: been using ancestor:/path/to/whatever for years.
<AfC> vila: no one told me I wasn't supposed to use it.
<vila> the subtle distinction between them is... not always clear to me
<AfC> heh
<vila> in most of the cases I know they give the same results
<AfC> er. wait
<AfC> vila: ancestor: is a calculation
<AfC> vila: submit: is just a tip
<AfC> right?
<AfC> especially for branches that have far diverged
<vila> well, 'ancestor' is where you came from, 'submit' is where you want to go
<vila> so the resulting diff is often the same
<AfC> ah, interesting
<AfC> I thought submit was a location
<AfC> in fact, it is something in bazaar.conf
<AfC> whereas,
<AfC> $ bzr help revisionspec
<AfC> ...
<AfC> submit:
<AfC>         Selects a common ancestor with the submit branch.
<AfC> ancestor:
<AfC>         Selects a common ancestor with a second branch.
<AfC> wtf
<AfC> oh, right
<vila> true, but as far as diff is concerned, they both provide a revision
<AfC> the whacked out
<AfC> difference between
<AfC> :submit and -r submit:
<vila> the former is a location, the later is the tip of this location (i.e. a revision)
<vila> gnuoy: should I throw a test at pqm ?
<gnuoy> vila, yes pls
<vila> gnuoy: done, waiting for result
<vila> gnuoy: tests didn't start so probably still failing :-/
<vila> gnuoy: can find some log about the latest bzr pqm submission so we can check which dirs/branches were involved ?
<vila> s/&/you/ somewhere ;)
<blackarchon> hi all
<blackarchon> i'm wondering what "qsubprocess --bencode ..." exactly does
<gnuoy> vila, the log only seems to contain "Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt"
<vila> gnuoy: right, that confirms we failed :)
<vila> gnuoy: how about the .bzr.log file on the host (not the chroot) ?
<gnuoy> vila, nothing in the past hour
<vila> O_O
<vila> gnuoy: can you paste some of it ?
<gnuoy> vila, https://pastebin.canonical.com/57870/
<vila> gnuoy: otherwise we have to revise some belief, so may be the merge occurs *in* the chroot ??
<gnuoy> vila, I'm not sure how to determine that
<vila> gnuoy: bzr version 2.1.4 !!!
<gnuoy> vila, the date is old
<vila> gnuoy: well, the .bzr.log in the chroot will give plenty of hints about what is done there
<vila> gnuoy: or did you mean you don't know where to find this log file ?
<gnuoy> vila, I assume its /srv/pqm.bazaar-vcs.org/chroot/home/pqm/.bzr.log
<vila> sounds good
<gnuoy> vila, https://pastebin.canonical.com/57871/
<vila> ok, so only selftest runs there
<vila> but your previous log paste is not good, it says 2011-10-10
<gnuoy> yes, I saw that
<vila> gnuoy: may be you looked in the old pqm host ?
<gnuoy> nope
<vila> gnuoy: I'm lost, but there should be a .bzr.log file containing more recent events
<vila> gnuoy: may be you *could* look in the old pqm host ? ;-)
<vila> gnuoy: (never underestimate silly ideas when all the smart ones fail ;)
<gnuoy> vila, there is a bzr.log for the pqm user on the old host but I don't think its relevant, https://pastebin.canonical.com/57872/
<vila> gnuoy: you're right, doesn't seem relevant for bzr
<gnuoy> vila, I don't suppose this entry from the pqm logs is any help? https://pastebin.canonical.com/57873/
<vila> gnuoy: hmm, there is a cwd mentioned there... that I never hear about, but that may indeed be the one we're after ?
<vila> gnuoy: and it mentions bzr... (well, bazaar at least_
<vila> )
<vila> gnuoy: so if we can't find the .bzr.log file you may at least try it at the section name and do another test
<vila> gnuoy: switching room again (with  a laptop mentioning low battery while being in charge for the last hour :-/)
<niemeyer> Hello there!
<niemeyer> We were just wondering what's the state of the multiple-branches-per-directory feature
<niemeyer> Is that receiving any attention nowadays?
<jelmer> niemeyer: hi
<niemeyer> jelmer: Yo!
<jelmer> niemeyer: yes, we've been working on that for 2.5
<niemeyer> jelmer: Sweet!
<jelmer> there is an experimental format named 'development-colo' in 2.5 that adds such support
<jelmer> the plan is to eventually merge that support back into the 2a format (as it'd be backwards compatible)
<niemeyer> jelmer: Is the experimental feature "experimentable" ATM? :-)
<niemeyer> jelmer: Our workflows with Go ATM are a bit ugly and boring to deal with.. this would be quite a neat improvement
<jelmer> niemeyer: it does work, but the UI isn't completely there yet
<niemeyer> jelmer: What important pieces are missing?
<jelmer> niemeyer: at the moment you still need to address colocated branches (as they're being named) by their full URL, rather than by short names as in e.g. git or mercurial
<niemeyer> jelmer: If it's workable and won't eat our lunch, we can probably be guinea pigs for it
<niemeyer> jelmer: Ok, but what about local use?
<jelmer> niemeyer: so "bzr log file:,branch=foo" or "bzr log file:///home/jelmer/src/samba,branch=foo" rather than just "bzr log foo" if you're already in /home/jelmer/src/samba
<niemeyer> jelmer: Ok, I could live with that
<jelmer> niemeyer: I'm very interested to hear about anything else you run into
<niemeyer> jelmer: How do I get started on it?
<jelmer> niemeyer: the name we're using for it is co-located branches, the existing known bugs are here: https://bugs.launchpad.net/bzr/+bugs?field.tag=colocated
<jelmer> niemeyer: upgrade to development-colo ('bzr upgrade --development-colo')
<jelmer> niemeyer: you'd probably want to use the bzr daily builds if you do this, I think a fair number of fixes was made after beta 4
<niemeyer> jelmer: Sounds good
<jelmer> niemeyer: "bzr branches" will list the existing branches
<niemeyer> jelmer: Ah, I've seen that one elsewhere ;).. sweet
<niemeyer> jelmer: and to create / checkout new branches onto the existing tree?
<niemeyer> jelmer: If there's documentation elsewhere, I'd be happy to read rather than pestering you :)
<niemeyer> For those following at home, you'll want this: sudo add-apt-repository ppa:bzr/daily
<jelmer> niemeyer: I haven't gotten around to writing that yet unfortunately, mostly because there are still a few rough edges in the UI to fix up
<jelmer> (you have been warned)
<niemeyer> jelmer: :-)
<jelmer> niemeyer: creating a new branch should be "bzr init file:,branch=bla" to create a branch named "bla"
<jelmer> (eventually that'll be just "bzr init bla")
<niemeyer> jelmer: Just so I understand the underlying model, why the file: prefix?
<jelmer> niemeyer: mostly because of our internals
<jelmer> niemeyer: we do want to support plain colocated branch names
<niemeyer> jelmer: Yeah, I guessed that.. was just wondering what file: would cause to the internals so I can infer when to use it
<jelmer> niemeyer: we use a , for path segment parameters, but that only works for URLs at the moment, not for local file paths
<niemeyer> jelmer: Aha, gotcha, thanks
<jelmer> (we didn't want to break people who had branches with comma's in their path)
<niemeyer> jelmer: sensible
<niemeyer> jelmer:
<niemeyer> [niemeyer@gopher ~/a]% bzr branches
<niemeyer> * (default)
<niemeyer>   foo
<niemeyer> jelmer: How to reference to that "default" branch
<niemeyer> jelmer: Just trying to understand how to get started with a directory containing branches
<jelmer> niemeyer: with no branch argument you'll get the default branch
<niemeyer> jelmer: Hmm.. doesn't seem to work in this case..
<niemeyer> Hmm.. it's not clear how to check an existing branch out either
<niemeyer> If I use "bzr checkout file:,branch=foo", I get a real directory called ",branch=foo" in the current path
<niemeyer> jelmer: ^
<jelmer> niemeyer: sorry, at the platform rally atm.. was distracted for a bit
<niemeyer> jelmer: Maybe we should talk live.. :-)
<jelmer> niemeyer: ah, cool - didn't realize you were here too
<niemeyer> jelmer: :)
<jelmer> niemeyer: yeah, that might be easier
<niemeyer> jelmer: The above history is good, though.. I plan to share it
<niemeyer> jelmer: Yeah, I don't know how to switch a branch I'm afraid
<jelmer> niemeyer: the setup is a bit tricky at the moment, I'll have a look at it later today and get back to you if that's okay
<blackarchon> is there a recent manual on how to create a bzr install for windows?
<mwhudson> lifeless: not so as you can tell, but ok
#bzr 2012-01-10
<achiang> is there a way to pipe bzr log -p output through a pager that can do colorized diff? i really really like that feature from git. can less do it?
<achiang> hm, not according to 'less' man page
 * mgedmin raises hand
<achiang> colordiff
<mgedmin> here's my ~/bin/bzrdiff: http://pastie.org/3157485
<mgedmin> colorization + paging, a la git diff
<achiang> hm, nope
<mgedmin> oh, wait, -p? don't have that...
<mgedmin> oh, wait, bzr log?
 * mgedmin should stop answering questions on IRC when his brain has shut down because of excessive tiredness
<achiang> i *think* git log shows colorized diffs
<mgedmin> well, I have a ~/bin/bzrlog too: http://pastie.org/3157495
<mgedmin> spc is apt-get install supercat
<mgedmin> and ~/.spcrc/spcrc-bzr_log is ... not in my home directory
<mgedmin> ho hum
<mgedmin> my old hard disk is in a drawer and I'm too tired to go hunt for it
<mgedmin> also, supercat is a horrible horrible tool
<mgedmin> on the plus side it does what I want
<mgedmin> after I spent a few hours crafting a syntax file for it
<achiang> ah yep, 'git log -p' does similar to 'bzr log -p' except ... prettier
<mgedmin> it's as if git was written by loving people who like command-line interfaces
<achiang> more colorful, perhaps, is a neutral way to say it
<spiv> achiang: you can use 'less -R' preserves coloring (if you can get the command to emit it how you want in the first place)
<achiang> spiv: yeah, i guess the problem is, bzr won't do color control codes (a design decision, i suppose)
<spiv> Well, it can do diffs with colour
 * achiang discovers bzr cdiff
<spiv> So it's not a fundamental limitation, or a design decision against colouring.
<spiv> Yeah, I frequently use 'bzr cdiff | less -R'
<achiang> but how to make bzr log do it, so i don't have to type in every revspec?
<spiv> There's *possibly* a config option.  If not, there should be :)
<spiv> (I think there might be an option to set the default diff colouriser/formatter?  I forget.)
<spiv> IIRC plugins can register alternative diff formatters, and perhaps at worst you could have a plugin tweak the default so that log uses coloured diffs.  (as a workaround for getting that feature into bzr properly)
<achiang> thanks for the pointers. it's a little too daunting to figure out easily, so i give up
<achiang> maybe i'll try again some day
<achiang> from the bzr log man page: "GUI tools and IDEs are often better at exploring history than command line tools"
<achiang> sadface
<spiv> Well, it's difficult to draw clear diagrams of revision graphs in ASCII art :)
<spiv> Patches welcome though!
<mgedmin> diagrams are overrated, /methinks
<mgedmin> incidentally, is there a bzr equivalent of gitk --all?
<mgedmin> i.e. a diagram of merges that shows more than one branch at once?
<spiv> mgedmin: 'bzr qlog BRANCH_A BRANCH_B BRANCH_C ...'
<mgedmin> thanks, good to know!
<spiv> mgedmin: you might even be able to pass just a repo to it these days, or use a magic option, but it can certainly do it.
<achiang> spiv: personal opinion, i don't find the rev graphs to be useful in either bzr or git. the squashed "linear" history is the view i use the most in any scm (and yes, i do understand it's not truly linear, but it's often close enough)
<achiang> spiv: but i am truly appreciative of your help. #bzr is always very friendly, thanks. :)
<achiang> oh, and normally, i would use bzr qlog on my local machine, but i'm looking at something remotely
<fullermd> That's why X is network-transparent   :>
<achiang> can i get your speshul t00bs that eliminate latency too? :P
<fullermd> I've got a 386 you can borrow.  That makes network latency a non-issue...
<achiang> actually, i don't understand this line of teasing. are you truly suggesting that X forwarding from a remote openstack shell is enjoyable to use?
<fullermd> You never know.  I once ran Netscape 4 across the Internet.  Mind, it was excruciating...  but then, it was NS4, so it was hard to tell the difference.
<mwhudson> bzr qlog <remote url> probably works, no?
<fullermd> It might, but I would expect it to be...  uh...   what's the laughing-hysterical-like opposite of 'optimized'?
<mwhudson> compared to remote x? :)
<fullermd> Pfui.  FTP is never as cool as GTP   :p
<fullermd> Would certainly be more responsive interactively.  But I wouldn't be overly surprised if some of the info lookup ended up being pathologically bad.
 * mgedmin hates when vim's vcscommand.vim decides to use bzr for :VCSAnnotate in Subversion checkouts -- can you spell insaaaaaane slownesss?
<fullermd> Are ee em oh tee ee  space  ....   wait, that's your joke.
<spiv> fullermd: actually, I think qlog against a remote URL has had a least a little bit of optimisation
<spiv> fullermd: so it's probably just rather slow, rather than truly horrific.
<elmo> No branch/tags file in BzrBranch7('file:///srv/foo/bar/').  This branch was probably created by bzr 0.15pre.  Create an empty file to silence this message.
<elmo> srsly?
<elmo> Create an empty file called what?  where?
<mgz> elmo: you can get that if you `rm .bzr/branch/tags`
<mgz> provided that's all that happened, touching it and pulling will get it happy again
<mgz> but if other files have gone missing as well, you may need to branch again
<jonesy> what's the bzr command to get a rundown of files that would be changed in launchpad if I committed/pushed right now?
<jonesy> 'status' seems to show ignored files that have been modified.
<siip> is it possible to branch only a specified subdirectory (e.g.  the src subdirectory of lp:connectorj)?
<maxb> no, it isn't
<siip> thanks maxb (arg this is going to be a %#$!)
<AuroraBorealis> you really cant? thats sort of a useful thing to do in svn
<LeoNerd> Doh!
<LeoNerd> Note to self:  bzr merge -c-133 .  does _not_ mean "reverse-merge changeset 133"
 * LeoNerd reverts and tries again ;)
<LeoNerd> -r133..132  \o/
<kgoetz> hey, i'm getting a key denied (publickey) when trying to bzr branch from an lp: address. does bzr care that i'm running it as root? bzr version 2.3.4 fwiw
<jelmer> kgoetz: hi
<jelmer> kgoetz: bzr doesn't care you're running as root - if you're branching as root, do you have ssh keys set up, and your launchpad login set?
<kgoetz> jelmer: hey (:
<mgedmin> I would be tempted to check the $HOME setting
<mgedmin> if it points to /root, most likely you don't have your usual ssh keys/global bzr config
<kgoetz> no i don't. i assumed to branch from publicly available code i wouldn't need to do that ritual :/
<mgedmin> sounds like bzr thinks it knows your launchpad login, but you don't have access to the keys...
<kgoetz> since this is a server, is there a way to work around it? i'd rather not go adding ssh keys from all my hosts into my LP account
<mgedmin> IIRC lp: use bzr+ssh for performance reasons when they know what username to ssh to
<mgedmin> I'm sure jelmer will correct me if I"m wrong
<jelmer> mgedmin: you're right
<jelmer> kgoetz: check "bzr config" for the launchpad_username
<jelmer> you can unset it if you don't want bzr+ssh:// to be used
<mgedmin> hm, bzr launchpad-login lets me set my launchpad username, but doesn't provide a way to reset it (and there's no bzr launchpad-logout)
<kgoetz> thanks :)
<mgedmin> so it's bzr config --remove launchpad_username then?
<jelmer> yeah, that should work
<kgoetz> you are both correct. my launchpad_username was set (for reasons unknown), but ssh keys not set up
<kgoetz> thanks!
<kgoetz> incidentally, is there a plan to move ~/.bzr.log into ~/bazaar? i keep missing them up when tab completing
<jelmer> kgoetz: not that I'm aware of
<kgoetz> jelmer: ok, thanks
<jelmer> kgoetz: I'm not aware of a good reason not to, but also not aware of any plans to do so
<kgoetz> the argument i expect would be made is if you're going to move it you should put things in XDG_* locations
<mgedmin> if ~/.bazaar lived under ~/.config, your tab-completion trouble would be gone as well ;)
<kgoetz> mgedmin: snap (:
#bzr 2012-01-11
<sponge-> hey folks, is there a way to export a bzr repo & history into a new svn? can only find people importing svn into bzr
<mwhudson> bzr-svn can push into svn i think?
<sponge-> i wasn't sure how to use bzr-svn on an existing bzr repo, or at least svn-push isn't a valid command (using the windows installer, bzr explorer says the plugin is installed)
<mwhudson> i've not actually done it, i'm afraid
<jelmer> sponge-: just 'bzr push file:///path/to/repo/trunk'
<sponge-> will give it a shot, thanks
<sponge-> rying to push results in bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<sponge-> its a new svn repo so i'm sure i need to do some intermediate step
<sponge-> not sure if i can get bzr to just clobber everything at the destination
<sponge-> aha found --overwrite, will let this run, thanks for the help!
<jo-erlend> what is the easiest and most efficient way to keep two bzr repositories in sync?
<jelmer> jo-erlend: hi
<jelmer> jo-erlend: you would generally keep two branches in sync, rather than two repositories
<jo-erlend> jelmer, but the point is that I create and work on branches all the time and I would like to sync automatically.
<jelmer> jo-erlend: it sounds like you want to sync a set of branches rather than the actual repository
<jelmer> jo-erlend: I'm not sure if there is a command for that yet, I'm only aware of 'bzr multi-pull'
<jo-erlend> I don't really understand the difference.
<jelmer> jo-erlend: a repository is just a place where revisions are stored
<jo-erlend> the point is that my ~/devel/project-name directory (which is a repo with branches in it) should be the same on my desktop and laptop. What's the best way of accomplishing that?
<jelmer> jo-erlend: at the moment, I think rsyncing it is probably the easiest way; there might also be plugins that do this
<jelmer> jo-erlend: there is bzr-mirror, but I don't have anye  experience with it
<hallyn> poolie: bzr branch lp:ubuntu/oneiric/libvirt fails
<hallyn> (I"m here in budapest)
<hallyn> I get;
<hallyn> serge@peqn:~/bzr/new$ bzr branch lp:ubuntu/oneiric/libvirt libvirt-o
<hallyn> bzr: ERROR: Revision {serge.hallyn@canonical.com-20110914204236-fnxmfd2ca12lqd47} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<poolie> hallyn, https://bugs.launchpad.net/udd/+bug/848064
<ubot5> Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed]
<poolie> i don't have a good workaround at the moment other than just getting the source package, sorry
<hallyn> all right i'll just work on fixing up the precise tree for now
<hallyn> thanks
<hallyn> poolie: just to be sure - so i can't just take a copy of the precise tree (which so far is still at oneiric anyway) and push that to the oneiric with --overwrite, right?
<sponge-> can bzr-svn maintain the original author of the commit inside svn? pushing to svn worked flawlessly except for that
<jelmer> sponge-: hi
<jelmer> sponge-: yes, there's a configuration option you can set. IIRC it's documented in bzr-svn's FAQ
<sponge-> jelmer: great, will look into it!
<Noldorin_> ho hum
<Noldorin_> hi jelmer
#bzr 2012-01-12
<jelmer> hi Noldorin_
<Noldorin_> hey
<Noldorin_> what's new? :-)
<jelmer> not much, how are you?
<mgz> vila: did bug 905361 get merged up?
<ubot5> Launchpad bug 905361 in Bazaar 2.4 "bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO'" [High,In progress] https://launchpad.net/bugs/905361
<vila> mgz: meh, no idea :-/
<mgz> you marked it Fix Released, so assumed you knew :)
<poolie> james_w, vila, i propose to just cut out the problematic openldap package with https://code.launchpad.net/~mbp/udd/877827-blacklist/+merge/88348
<hrw> hi
<hrw> bug 904963 again
<ubot5> Launchpad bug 904963 in bzr-git (Ubuntu) "unknown command "commit"" [Medium,Triaged] https://launchpad.net/bugs/904963
<hrw> this time with extras: bzrlib.errors.NoSuchFile: No such file: 'lib64gfortran3.symbo-20110107033252-hpy57fuld7pki3s5-113'
<jml> is there a way to look at a diff and get the net number of lines added?
<Noldorin> how do i commit only selected files in bzr?
<Noldorin> exclude is commit -x
<Noldorin> but what about include?
<ccxCZ> bzr ci file1 file2
<Noldorin> ccxCZ: oh, simply arguments heh. thanks
<smrln> Good morning, noob bzr question I couldn't find(understand) answer to in bzr help.  When I'm working in branch, and I want to push it to another server for safe keeping, I use bzr push bzr+ssh, and everything works smoothly, except in that location all I have is the .bzr dir, Is there a push command to include the files themselves?
<ccxCZ> not easilly, you have to invoke bzr up on the remote side
<ccxCZ> there is a plugin that does that automatically (requires second ssh login, which doesn't matter if you have keys)
<ccxCZ> well, it's easy, but it's not as flexible as hooks
<smrln> So maybe, if I'm not actually working on the branch in the other location, I shouldn't use bzr to back it up to that location?
<ccxCZ> bzr co if that branch doesn't have working tree yet
<ccxCZ> smrln: the .bzr contains all the history, the files are there only when you want to edit them (it's called working tree)
<ccxCZ> so if you only push/pull to that location, not edit there, you don't really need the files there
<smrln> Interesting, but if I lost everything, and all I had was that working tree with no files, I could create them from the working tree?
<ccxCZ> you mean create working-tree from branch (that's stored inside .bzr)? bzr checkout does that
<smrln> great, thanks so much for your help, I understand now
<hrw> 'bzr dailydeb' should have --run-in-pbuilder option
<xnox> I have a branch on launchpad in 'Bazaar development format - group compression and chk inventory (needs bzr.dev from 1.14)'. How can I branch it / upgrade it? (upgrade on launchpad fails, branching to local fails with UnknownFormatError)
<KombuchaKip> Is anyone else finding the nautilus integration slow?
<jelmer> KombuchaKip: which nautilus integration are you using? the nautilus3 one?
<KombuchaKip> jelmer: Nautilus2 :(
<KombuchaKip> jelmer: Or is performance improved with Nuatilus 3?
<jelmer> KombuchaKip: it should be a bit better with nautilus 3
<KombuchaKip> jelmer: Glad to hear. I'm still running Maverick, unfortunately. :(
#bzr 2012-01-13
<lifeless> thomi: have you booked a cab ?
<lifeless> thomi: wgrant: 10:45
<thomi> sweet. Thanks.
<lifeless> thomi: wgrant: 6900ft for the vehicle
<lifeless> fixed price
<lifeless> thomi: wgrant: I have no cash, one of you can pay and claim fo the three of us.
<thomi> I got it
<thomi> I have exactly 7000ft left, so this will do nicely
<wgrant> thomi: What about dinner tonight?
<wgrant> I have about 10000 left
<wgrant> Which is roughly dinner+7000
<thomi> I have 3000ft, I'll probably get pizza and beer in the bar down the road.
<thomi> nothing like eating authentic local cuisine when you're overseas huh? ;)
<soren> Maybe you can get a pizza with goulash on it?
<hrw> or pay with credit card?
<hrw> 3000ft is 12.5$ so buy some gift for someone ;D
<jml> hurumph
<jml> I think I want a plugin command that switches to the top-level directory of a branch
<jml> but not enough to actually make it.
<LarstiQ> jml: `cd $(bzr root)` not close enough?
<jml> LarstiQ: I didn't know about that.
<jml> LarstiQ: I guess I can make an alias that'll work.
<Noldorin_> hi jelmer, poolie
<briandealwis> Q: is it ok to post tips or nifty hacks to the bzr blog?  (I was added to the bzr-bloggers list a while back)
<jelmer> hi Noldorin_
#bzr 2012-01-14
<AfC> Hm. Found a (minor) bug with the lp:distribution/codename/package syntax
<AfC> Where do I report that?
 * thumper found a bug in bzrlib in precise
<thumper> must get around to filing a bug for it
<thumper> hi jelmer
<thumper> are you home?
 * jelmer waves to thumper
<jelmer> no, still in Budapest.. just getting a coffee after spending the day sightseeing
<jelmer> thumper: what about you? somewhere in Asia by now?
<wgz> what did you see jelmer?
<thumper> jelmer: no, vienna
<jelmer> thumper: that's the wrong way, isn't it?
<thumper> jelmer: there is an engineering manager meeting here for a few days
<jelmer> wgz: jtv and I went to the museum about the Nazi/Soviet occupations, and I strolled around the river for a couple of hours
<jelmer> thumper: ah!
<wgz> neat.
<thumper> yay precice, battery showing 4:49 to go
<jelmer> yeah, it's a *really* significant improvement here too
<thumper> :-| dropped to 4:15 after typing
<jelmer> wgz: you made it to Norwich safely then?
<wgz> what precisely is your precise bzrlib issue thumper?
<thumper> if you start a python prompt from within a bzr branch, try
<wgz> jelmer: yup, though it was a bit of a race in schiphol and I had to jump the security queue a bit
<jelmer> I think that's spelled presaisy
<thumper> from bzrlib.workingtree import WorkingTree
<thumper> WorkingTree.open('.')
<thumper> it'll fail
<jelmer> thumper: that's fixed in bzr.dev
<thumper> however if you import bzrlib.branch first, it works
<thumper> jelmer: ok
<wgz> and will be released in 2.5b5... probably in the coming week
<jelmer> thumper: the problem is that we reduced our imports so much that the working tree module no longer imports bzrlib.bzrdir, which registers a couple of things - including the bzr native formats
<thumper> kk
<jelmer> thumper: so newer versions are explicitly importing from bzrlib.bzrdir in bzrlib.workingtree
<wgz> we do have some test coverage holes for bzrlib being imported in non-bzr-script ways
<jelmer> wgz: yeah :(
<wgz> ideally people's bzrlib-using tools test suites would help
<PCJockey> I'm new to Bazaar, so please excuse me if this answer is easily found, but I've been looking in the docs and new user info from the website. So, now I'm here to ask the experts for direction to the answer to my question. Thank-you in advance for your help!!
<PCJockey> What is the design of a Bazaar repository? My primary interest is in knowing if it offers historical cryptographic integrity like a git repository does.
<jelmer> PCJockey: hi
<PCJockey> jelmer: Hello!! I hope you are well today...:)
<jelmer> PCJockey: what do you mean with cryptographic integrity exactly? Git doesn't sign revisions in any way, though it can sign tags if you want to.
<PCJockey> jelmer: I'm referring to the idea that because of each commit being named with a hash of the contents, you can go back through full history to know bit for bit it's accurate. I.E. nobody has altered the history or no media failures have altered the repo.
<jelmer> PCJockey: bzr does have various mechanisms for verifying revisions contents, but it uses arbitrary unique strings to refer to revisions
<jelmer> we do store the hash as part of the revision, it's just not use to reference that revision
<PCJockey> jelmer: My point isn't to compare to git. Just that I know git has the feature. I also don't care what the commits are named. All I really want to know is how bazaar confirms integrity.
<jelmer> PCJockey: it stores the SHA1 of the contents and verifies that, just like git does
<jelmer> (currently it's SHA1, but we might swap that for something else in the future if more attacks against SHA1 arise)
<PCJockey> jelmer: Got it. I guess if I had just installed it the answer would have been obvioius. I appreciate your help!!
<jelmer> np
<PCJockey> I look forward to trying Bazaar out now. It looks like the community has some very cool things going on!
<fullermd> The two aren't exactly comparable.  bzr's SHA1 doesn't help much against [competent] attacks.
<PCJockey> fullermd: Oh, now that is what I wanted to know about...and I'm sorry to hear it.
<PCJockey> fullermd: So, there is no assurance of repository integrity?
<fullermd> The SHA1 in the revs gives excellent protection against accidental damage.  For intentional, you have to look to other mechanisms.  And that comes down to the eternal "what's your threat model".
<PCJockey> fullermd: Admittedly I'm not too concerned about malicous attack, but it's a nice and seemingly free thing to have in the modern era, but yes the more likely threat is non-malicious.
<fullermd> Security is never free   :)
<fullermd> The SHA1 in git doesn't provide any automatic protection against malicity (that's a word.  I just decided) either, after all.  Just that the way it's used compared to bzr gives it potential in that way.
<PCJockey> fullermd: Even so, I'm not sure it's worth giving up the feature...comes down to an argument of how important it is to me. I guess I just want it all...:)
<PCJockey> fullermd: Do you know why the bzr team made the decision not to include the capacity?
<fullermd> Because using the hash as revision identifier has various drawbacks.
<PCJockey> fullermd: I don't mean using it as an identifier, but implementing an alternate way of integrity assurance.
<fullermd> Right, but using it as an identifier is *WHY* it has potential to be useful that way in git, but not in bzr.
<PCJockey> BTW, I agree using a hash as an identifier is pretty UGLY!!
<fullermd> A hash doesn't tell you anything by itself, after all.  I could send you a bzr tarball and tell you the SHA1, and that doesn't give you any assurance that it's not actually a virus.
<fullermd> All it would tell you is that you got the file *I* wanted you to have.  To know you had the one the bzr team released, you'd have to know what that has was _supposed_ to be.
<fullermd> If I go in and maliciously change the content of some rev in a bzr history, then the SHA1 in the rev will no longer match and it'll scream bloody murder.
<fullermd> That just means I have to change the SHA1 too.  Then everything will look just fine.
<fullermd> I can do the same thing in git too.  The difference is, that since the SHA1 is the identifier, I'll be changing the identifier of the rev too, which means you're more likely to notice that it happened.
<fullermd> So in git, you have that assurance, assuming you know what the revid was supposed to be.
<fullermd> So if Linus tells you "hey, run rev 4bbc82ad2", you have [for practically, purposes, sufficiently] total assurance that you have what he meant.
<PCJockey> fullermd: I realize it's just an arbitrary code, but why can't you...I guess I'm missing something. Too many distractions at the house right now to get my thoughts out clearly...:(
<fullermd> Whereas if jelmer tells you to run revid jelmer@foo.bar-20110845183498 of bzr, that by itself doesn't prove that you have the same rev he meant.
<fullermd> Since the identifier itself isn't the same thing as the integrity check.
<fullermd> bzr's mechanism to do the same is PGP signing of revs, which conceptually gives you greater assurance.  A number of practical issues present themselves with a little thought.
<PCJockey> fullermd: I guess my point is that it seems there should be a way to solve the issue w/o using a hash as a commit id.
<fullermd> Well, if I tell you what the hash is supposed to be too, you get the same.
<fullermd> It's just that now, I have to give you TWO pieces of info (the revid and the hash).
<fullermd> With the hash being the revid, you get both automatically any time things are referred to.
<PCJockey> fullermd: I like everything I've read/seen about bzr up to now...but this seems like an issue to me. Maybe I'm worried about an improbability, but it does seem that over time data errors are likely...the issue is whether or not I'm giving it too much attention perhaps.
<fullermd> Well, the way to protect against malice is PGP signing.  That adds process burden.
<PCJockey> fullermd: Yes, burden with benefit though...:)
<fullermd> PGP signatures have the advantage that they're a lot more self-manifest than a hash.
<fullermd> With a hash, you have to know what it's supposed to be for any rev you care about.  With a signature, you just have to know what key you're expecting, then any rev with that key can be checked.
<fullermd> The principal burden with PGP is tracking which keys are expected.  I mean, I can make a key with your email on it and use it to sign things, so you'd have to somehow know which keys were really you authorizing stuff.
<fullermd> Related is that you have to know it's supposed to be there.
<fullermd> e.g., I make malicious changes to the rev, and the PGP verification will fail.  I can't make a new signature with your key that'll pass.
<fullermd> But I CAN just go ahead and throw away the signature wholesale.  And then "verification" will pass just fine, since a rev with no signature can't fail a signature check.
<PCJockey> fullermd: Yep. As, you said in the beginning...nothing is free...:)
<fullermd> You'd have to know there was supposed to be one (either specifically, or by setting a hard requirement that EVERY rev be signed) to know something was up.
<PCJockey> fullermd: Bzr is definitely has my attention now. The question is what will I do with it. How long have you been using it? Is there anything you'd like to see changed?
<fullermd> I've been using it for...  uh...  a long time.  Not too long after it first became publically available.
<PCJockey> fullermd: I really appreciate you taking the time to talk this out with me!
<fullermd> Jeez, more'n 6 years now.  Wow.  Hard to believe I've been largely CVS-free that long.  I can still feel the scars...
<fullermd> There are all sorts of things I'd like changed/fixed/etc.  With me, that's pretty much a constant with any software   ;>
<fullermd> But I chose it because I liked it better than the other VCS choices at the time.  Still using it because that decision still holds.
<PCJockey> fullermd: I must admit I'm impressed by my 2nd look. I had looked in the past pre v2, but decided it wasn't mature enough to garner a further look. This time however, we're talking about the only thing I'm struggling with...and as you have pointed out, there is a work around if it matters that much to me...I just need to figure out what to do with it from here. I should probably install and then decide on experience versus theory.
<fullermd> I've scrawled up some docs that may help you with the gestalt (not in security or internals so much, but what pieces you use and how they fit together).
<fullermd> Not a substitute for the sort of intro tutorials that are out there, but I think they're a useful second step ("OK, I can follow this cookbook to do basic interactions, but I don't really understand just what the implications of all the things I do are")
<fullermd> <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief> is intended to be a useful intro to the Repo/Branch/WT triumvirate, which underlies how everything in bzr works.
<PCJockey> Great! Are they available online?
<fullermd> (other stuff in SpotDocs talks about other things; if you're familiar with other DVCSen, you probably know a lot of it, but there's still some useful bits about how bzr deals with implications)
<fullermd> They're pretty bottom-up, so it'll probably be pretty Greek without a little preceeding hands-on time experimenting with basic usage first.
<fullermd> But IMAO it's necessary to understand those conceptual building blocks to be able to mentally model what various commands/messages/etc really mean, and so use things effectively.
<fullermd> Or possibly I'm arrogant and full of crap.  It's happened before.
#bzr 2012-01-15
<sobersabre> hi.
<sobersabre> I've run bzr uncommit, and the code changed back. but bzr status reports there are pending merge tips. how do I remove them ?
<mathrick> hiya
<mathrick> jelmer: a win32 svn bug for you :)
<mathrick> $ bzr clone http://zxing.googlecode.com/svn/trunk/ zxing-read-only
<mathrick> ...
<mathrick>   File "C:/Program Files (x86)/Bazaar/plugins\svn\cache\sqlitecache.py", line 110, in executemany
<mathrick> OperationalError: unable to open database file
<mathrick> using 2.5b4
<jelmer> mathrick: that's not really win32-specific.. you're trying to access the svn repository more than once at the same time
<mathrick> howso?
<jelmer> mathrick: sqlite has an exclusive lock for write access, and you're hitting it
<mathrick> jelmer: right, but I don't have any other instances running, so I don't see how
<jelmer> mathrick: I'm not sure either, but that's the only reason why I've ever seen that error
<mathrick> hmm
<jelmer> mathrick: alternatively, you can disable the cache entirely by setting 'use-cache = False'
<mathrick> ok
<mathrick> in subversion.conf?
<mathrick> hrmpf
<mathrick> jelmer: ok, in subversion.conf?
<mathrick> if so, I've done so, and I still get the error
<cosmint> Can I use bzr with 64 bit python in windows?
<wgz> you can if you install it yourself
<wgz> the ones we provide are 32 bit.
<wgz> get the source and run setup.py with your local python, will probably prompt you to install cython,
<wgz> if you have visual studio 9, do that, otherwise pass the option it tells you about.
<cosmint> Hmph, and I already had cython before the docs told me to install pyrex :p[
#bzr 2013-01-07
<dobey> can anyone understand why bzr builddeb would be crashing in this build log? https://launchpadlibrarian.net/127602321/buildlog.txt.gz
<mgz> dobey: /usr/bin/pristine-tar: Failed to reproduce original tarball. Please file a bug report.
<mgz> and lines preceeding that
<mgz> you can probably manually try those pristine-tar commands to see if you can get more info about why the tar it creates differs
<dobey> err, i guess s/builddeb/dailydeb/ sorry
<dobey> mgz: so, the recipe creates the source package just fine locally (though i had to chnage "debversion" to "debupstream" otherwise it breaks on that); this seems to only happen on the launchpad recipe build :(
<LeoNerd> Soo... in-place branch. Anyone have anything useful to say on the matter?
<LeoNerd> I.e. can I inplace 'branch' back to an earlier revision of my branch, make an edit, and then merge the previous HEAD, thus altering history?
<mgz> not quite sure what you mean LeoNerd, but branching an older rev, changing something, then merging a current rev will only rearrange history, not alter it
<LeoNerd> Yes.. that's fine
<mgz> it's the same as doing the change in another branch and merging that... but you flip the left-hand and right-hand ancestry
<mgz> setting append_revisions_only complains at such things
<LeoNerd> So, suppose I have 10 revisions. I want to make a change to -r4. So I can  bzr branch -r4 , edit and commit a -new- -r5, then how do I apply the old -r5 to -r10, keeping their individual identity, thus becoming my new -r6 to -r11 ?
<mgz> there's a `bzr replay` in bzr-rewrite I think
<mgz> so, you'd do that, then replay the more recent changes
<LeoNerd> Yes, I know of replay
<LeoNerd> But what do I replay? I can't just  bzr replay -r5..10 .  can i?
<LeoNerd> Because it's the wrong branch
<dobey> need to reboot again, brb
<mgz> you can specify the branch, no?
<LeoNerd> Maybe.. but how? It's a local one, no?
<mgz> well, the branch revspec would work for one end...
<mgz> need to look at the command help...
<mgz> LeoNerd: answer to your question from earlier (just got to looking at the help for replay),
<LeoNerd> Hrm, so apparently I totally misremembered, and it doesn't look like inplace branches are a thing
<mgz> `bzr replay -d target -r 5..10 old`
<LeoNerd> Yes, I'm aware of that. But that needs 'target' and 'old
<mgz> if you do `bzr branch -r4 old target` and add something first
<LeoNerd> Basically: I had to redo everything and have the branches actually -living- somewhere different on the filesystem
<LeoNerd> I couldn't do it inplace
<mgz> well, you can with co:
<mgz> but that's just the same thing with a different local arrangement
<LeoNerd> Yah
<mgz> I didn't understand what you meant by inplace to start with...
<LeoNerd> It's all made more tricky by the fact that I'm using bzr shadowing another VCS, so my workdir has two
<LeoNerd> So it's not so easy just to blow it away and get a new one
<mgz> well it's easy enough to do, say,
<mgz> `bzr branch --no-tree . /tmp/original`
<mgz> `bzr pull --overwrite -r4 .`
<LeoNerd> Wellsure.. but that needs /tmp, whereas I've actually done it with some new subdirs of the root
<mgz> ...edit...
<mgz> then replay from tmp
<LeoNerd> Yeah.. I'm quite familiar with that one. I just thought I recalled bzr now had some sort of inplace branches thing
<LeoNerd> But apparnetly not
<mgz> I've been using the core co: funcationality recently and it's mostly pretty good
<LarstiQ> LeoNerd: hmm hmm
<LeoNerd> Mew?
<LarstiQ> LeoNerd: depending on how the replay command is implemented -
<LeoNerd> er.. I mean.. wha?  *blink* you didn't see hat
<LarstiQ> LeoNerd: if you do `bzr replay -d . -r 5..0 .`, perhaps it looks up the revspec first
<LarstiQ> LeoNerd: and by that time just refers to the repository, and.. oh meh
<LeoNerd> Yes
<LeoNerd> That was my problem
<LeoNerd> In the end I just disconnected my checkout from the branch, and stored branches(plural) elsewhere
<LeoNerd> Which I felt a little sucky but an easy workaround
<LarstiQ> LeoNerd: so what about a merge directive to store the branch up to rev 10, and replay from there?
 * LarstiQ tests
<LarstiQ> which is the same as what you did, except in one fiel
<LarstiQ> file
<LeoNerd> Mmm?
<LarstiQ> LeoNerd: I had a slightly different idea, but that seems to blow up the replay code
<LeoNerd> Ah OK
<LeoNerd> Yeah, I don't think I can think of a better way :/
<LarstiQ> LeoNerd: basically, just use . for location and -r revid:..revid:
<LarstiQ> LeoNerd: still with the hope that it will just look at the repository
<LarstiQ> LeoNerd: I do think something like that makes sense, if someone was willing to work on that
<bsd> Is there a command-line command to see the info associated with a particular file-id?
<bsd> aha: 'bzr help hidden-commands' -> file-id
#bzr 2013-01-09
<didrocks> hey mmrazik, do you have some logs about the issues we are currently having in corrupted checkouts?
<didrocks> (knowing that we just started fresh from trunk)
<mmrazik> pretty much just the output of "bzr branch lp:~mrazik/libdbusmenu/xvfb-run-a"
<mmrazik> let me pastebing that
<mmrazik> err.. sorry.. output of " bzr checkout lp:~mrazik/libdbusmenu/xvfb-run-a
<mmrazik> "
<mmrazik> bzr branch works fine
<mmrazik> http://pastebin.ubuntu.com/1512096/
<didrocks> vila: jelmer: hey! would you have any idea of what can be the cause of this? ^
<mmrazik> the steps to reproduce are: 1. bzr branch lp:libdbusmenu
<mmrazik> 2. make your changes + commit
<mmrazik> 3. bzr push
<mmrazik> 4. bzr checkout (from the same location where you just pushed)
<didrocks> mmrazik: easier, bzr checkout lp:libdbusmenu has the same issue
<didrocks> so something not correct in the launchpad repo?
<vila> didrocks, mmrazik : weird, when tried locally I got an additional hint in the error message: "Run 'bzr reconcile --canonicalize-chks' on the affected repository."
<vila> which doesn't appear in your paste...
<mmrazik> vila: I tried that on my xvfb-run-a repo (locally) and then pushed to xvfb-run-a2 but it didn't help
<didrocks> vila: I don't see this hint as well
<vila> mmrazik: well, if the lp repo has the issue, fixing your local one won't help (and you may be additionally tricked if the offended repo is stacked on on lp)
<didrocks> vila: so bzr reconcile --canonicalize-chks :parent?
<vila> hmm, "bzr info -v lp:libdbusmenu" erroring is suspicious, is the lp branch properly configured ?
<didrocks> ah interesting, indeed
<vila> bzr config -d lp:libdbusmenu
<vila> branch:
<vila>   stacked_on_location = /+branch-id/590782
<vila>   parent_location = ../../../+branch/dbusmenu/
<didrocks> the project was renamed
<vila> that parent_location is really weird...
<didrocks> from dbusmenu to libdbusmenu
<didrocks> and I guess when renaming a project, trunk branch naming follows but not the configuration
<vila> but shouldn't really matter in fact
<didrocks> vila: there should be no parent location for lp:libdbusmenu, it's the real trunk
<mmrazik> I start to recall an issue with the rename. Trying to recall what additional bzr command we were running
<vila> yeah, I don't think it's ever used
<vila> anyway, can you run reconcile on that lp branch ?
<vila> if :parent doesn't work, use the lp url instead
<mmrazik> will do
<mmrazik> vila: bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/libdbusmenu/.bzr/) cannot canonicalize CHKs.
<mmrazik> btw. what we have done in CPH had something to do with unstacking but I can't figure out the exact command
<vila> CPH ?
<mmrazik> vila: copenhagen
<mmrazik> I believe we did the renaming there
<mmrazik> but then checkout of the trunk didn't work due to some stacking errors
<mmrazik> and somebody (I believe from the launchpad team) helped us with that
<vila> right, I was about to say that lp guys may have better access...
<mgrandi> that error seems really vague..
<didrocks> bzr reconfigure --unstacked
<didrocks> ?
<mgrandi> is there no more descriptive error?
<mmrazik> didrocks: yep... thats the one we were using
<didrocks> mmrazik: maybe try this on lp:libdbusmenu ?
<mmrazik> didrocks: thats what we did
<didrocks> mgrandi: I guess that's what bzr is giving :/
<mgrandi> is there a stack trace?
<mgrandi> either in the output or in bzrlog
<mmrazik> mgrandi: http://pastebin.ubuntu.com/1512096/
<mgrandi> i meant for one that says "cannot canonicalize chks"
<vila> so lp:libdbusmenu is stacked on lp:libdbusmenu/12.10 indeed so the error may be there for all we know
<vila> bah and that one is stacked on lp:dbusmenu/0.6 ...
<vila> and finally stacked on 0.5
<mgrandi> russian dolls, bzr style
<mgrandi> well having a stack trace
<mgrandi> for that 'cannot canonicalize' would help...
<mmrazik> btw. I just did the reconfigure and I can checkout lp:libdbusmenu now
<mmrazik> but bzr info -v still gives errors
<vila> mgrandi: grep shows only one call site
<vila> bzr checkout lp:libdbusmenu/12.10 succeeds
<didrocks> mmrazik: confirms about checkouting working now
<vila> having trunk stacked on another branch... is kind of wrong, you generally want trunk's repo to contain most of the history
<didrocks> vila: I think that the indicator team is normally doing at the end of a release, something like:
<didrocks> bzr branch lp:libdbusmenu
<didrocks> bzr push lp:~â¦/libdbusmenu/13.10
<didrocks> and then, set lp:libdbusmenu to â¦/libdbusmenu/13.10
<didrocks> so that's why we have branches stacked an previous releases I guess
<vila> I probably miss why you need such a workflow...
<didrocks> vila: I don't know why they are doing that, but it seems to be there one :)
<vila> but that's not the best way to use stacked branches
<didrocks> I think they don't know (and arguagly, they shouldn't have to know) about stacking
<didrocks> arguably*
<vila> anyway, you're unblocked right ?
<mmrazik> vila, didrocks: yes
<didrocks> vila: I think, yeah :)
<vila> ok, cool
<didrocks> thanks vila, mgrandi!
<didrocks> I'll try to have them changing their workflow :)
<didrocks> mmrazik: btw, it's part of the things we should write on a wiki, like process to create a new release
<vila> didrocks: sounds like a good idea
<didrocks> mmrazik: because the unity team is doing one way, the indicator team is doing anotherâ¦
<mgrandi> haha, not sure i did anything but ok
<vila> but that "canoot canonicalize" error is worth a bug report, it sounds like something really weird is going on there
<didrocks> vila: ok, we'll open one with those info, hoping that we can recreate it :)
<vila> mgrandi: well, you pointed out that the error message was weird and that's often the way to detect bugs ;)
<mgrandi> yeah
<mgrandi> why i try to always give as much info in error messages, vague stuff hurts to look at =(
<mgrandi> almost worse then microsoft saying "error code 21124124XABB"
<vila> here, the message is triggered by an attribute check on the repo object, so probably something jelmer did for foreign repos except we are dealing with a bzr repo here... so I'm a bit lost
<mgrandi> i noticed that it was saying osmething about sha1:blahblah
<mgrandi> those are for git right?
<jelmer> vila: it's not necessarily something to do with foreign repos
<jelmer> vila: just that we happened to have a known bug in bzr-svn that was related to this
<vila> jelmer: that was just a feeling ;) A bzr repo object missing a bzr method...
<vila> some borked inheritance path ?
<jelmer> vila: possibly
<xnox> Can somebody push https://code.launchpad.net/~xnox/bzr-dbus/pygi/+merge/137173 ?
<mgz> xnox: done
<xnox> mgz: thanks
#bzr 2013-01-10
<mgz> morning!
<solancer> hi guys
<solancer> how can I fork a PPA from launchpad and upload it to my personal Archive ?
<mgrandi> uhh
<mgrandi> bzr clone lp:whatever
<mgrandi> bzr push somewhere
<solancer> oops i did this instead
<solancer> bzr branch lp:unity
<solancer> it grabbed all the folders and stuff
<solancer> but I need to change the name as well
<mgz> same thing.
<solancer> so if I've understood correctly
<solancer> I've cloned the unity repository
<solancer> and now its ready for me make changes and push to my personal PPA
<mgrandi> RoR isn't having a good week
<solancer> what does upstream merge mean ?
<solancer> I've seen that on unity-revamped PPA
<mgz> solancer: what you want to do requires a reasonable understanding of development and debian packaging, you probably want to start with just getting a change done locally and working for you
<solancer> mgz, so what do i need to learn first
<solancer> I've used git in the past for creating repos on github
<mgz> solancer: well, you have a local copy of unity, I'd start by changing that and getting it working for you, ask in #ubuntu what channel unity devs hang out it
<solancer> mgz, cool
<mgz> they should then be able to give you hints about what recipes they use for their ppa and such like
<solancer> mgz, but I don't want to  install it on my local machine that would break packages
<solancer> mgz, but I can install it on my V-box machines
<solancer> anyway I can build deb file and install it on the v-box machine
<solancer> #unity
<gmarkall> if i cherrypick a couple of revisions from a branch, with the intention of later merging that picked-from branch into the current branch, am I likely to encounter any problems in the future? Or is this a relatively safe thing to do?
<mgz> it's reasonably safe.
<gmarkall> many thanks
<mgz> not great as a core part of your workflow though, as it's nice to keep the revision details for the first time code is merged, and avoid potential conflict pain
<mgz> but for ocassional things, it mostly works fine because bzr can genreally figure out (or give you a reasonable conflict) if a diff gets applied twice
<gmarkall> i need to get a critical fix that's just been applied to the branch i'm picking from, but i don't have time to merge the whole branch right now - there's been some big changes in the picked-from branch since i last merged. is cherrypick the way to go in this situation?
<mgz> right, that exactly the kind of situation where it's the right thing to do
<gmarkall> ah, great - thanks :-)
<Sonti> hi guys I have a quick question about bazaar. I want to use it locally and I'm not too sure about what to select in location when initialising. Do I set it inside the folder where my project is or do I set it up somewhere else (e.g c:\) and then add the project folder?
<LarstiQ> Sonti: the former
<LarstiQ> Sonti: so in commandline parlance, `cd project; bzr init`
<Sonti> ok thanks. My concern is that I have multiple projects under one folder ie MyProjects. Should I set it in there or MyProjects\projectxxx. I like the idea of having one version control for all of them at once in case I go back to one of my old prototypes but I'm just not sure if I should do it individually for each project folder instead.
<LarstiQ> Sonti: well, you can do it in various ways of course. I'd recommend doing it per project though.
<LarstiQ> Sonti: operations are tree wide
<LarstiQ> Sonti: you can try it out, and if you don't like it do it differently
<Sonti> LarstiQ thanks. I guess it would be neater per project. I'll do that.
#bzr 2013-01-11
<Merwin> Hi ! Can I get a shelf as a patch I could apply ?
<vila> Merwin: From a clean tree: bzr unshelve ; bzr diff >my.patch
<Merwin> Ok, that's what I thought but I hoped for a way without unshelving ;)
<Merwin> Thanks
<Merwin> vila: How to do on windows ? ">my.patchÃ© doesn't work
<vila> >-/
<vila> I can't imagine why...
<vila> anything more specific than "doesn't work" ?
<Merwin> vila: Forget, I'm stupid. Thanks ;)
<vila> never thought you were stupid ;)
<xnox> vila: wasn't there like --preview?
<xnox> bzr unshelve --preview
<vila> xnox: doh ! indeed
<vila> Merwin: better ^
 * jelmer waves to Vila and xnox
 * mgz waves to jelmer
<jelmer> hi mgz
<Merwin> thx vila :)
 * vila waves to mgz and jelmer  ;)
<vila> Merwin: np and sorry, see who's the idiot now ? ;-)
<Merwin> vila: :-)
<vila> jelmer: got a sec ?
<jelmer> vila: I'm boarding a plane in 40 min, but should be around until then
<jelmer> what's upm
<jelmer> ?
<vila> jelmer: I think I found a bug in svn_canonicalize_path (deprecated by svn_uri_canonicalize still buggy): it can return an url where ( and ) are not quoted :-/
<vila> that triggers in a parameterized test..
<jelmer> vila: yeah, unfortunately svn doesn't expect them to be quoted
<jelmer> we hit other bugs where bzr was escaping them and svn expected them not to be escaped :-(
<vila> jelmer: quite amazing considering it *unquotes* them...
<jelmer> vila: it returns its canonical version of the URL, and that means parentheses aren't quoted
<jelmer> at least, that's my understanding of it.
<vila> jelmer: ok, so there are precedents, I was wondering if I was wrongly doing something, at least I know it's not me (and I ended up in svn_path_canon... after digging from bzr-svn, hence my first ping)
<vila> jelmer: huh ?
<vila> parens should be quoted according to ... (whatever, closed the page ;)
<jelmer> vila: not according to svn ;-)
<vila> ha, ok, makes sense ;-D
<vila> jelmer: enjoy your flight ;)
<jelmer> vila: thanks (-:
<jelmer> vila: anyway, so I think bzr-svn in general could use some work to make it consistently translate between svn URLs and bzr URLs - at the moment we sort of assume that they're interchangable
<jelmer> apart from the base, that is
<vila> right, so the full story is that there is an assertion checking with startswith but the compared urls are not coherent (one is quoted, not the other, so fail), commenting out that assertion leads to a failure later, so it *seems* bzr-svn can't work around it :-/
<jelmer> well, one is bzr-quoted, the other is svn-quoted presumably?
<vila> starting with a bzr quoted one, one stays correct, the other is unquoted in _ra.RemoteAccess by svn_path_canonicalize
<jelmer> vila: that's not really "unquoted". that's svn-quoted
<jelmer> tomato, tomato I guess :)
<vila> ha right, sorry, not accustoomed yet ;)
<jelmer> i.e. this only really matters for parentheses I think
<vila> ha found the page back http://en.wikipedia.org/wiki/Percent-encoding, haven't looked in detail at svn sources but there is more than parens (see url)
<vila> but well, you can hardly fix that in bzr-svn right ?
<jelmer> vila: sure, it can be fixed in bzr-svn
<jelmer> we just need to make sure to correctly re-quote stuff that comes back from svn
<vila> ha, right, but whack-a-mole may take more time than I want to spend here :-/ I came across it while refreshing my memory in bzr-gardener running the test suite there...
<jelmer> ah, yeah - I remember that test failure
<jelmer> that said, you should have hit a fair number of other issues if you ran the bzr-svn testsuite
<vila> no, only the gardener one but since it's parametrized it grabs some svn stuff via the formats
<jelmer> svn 1.7 breaks it fairly badly; it's probably useless as-is in raring :-(
<vila> ouch
<vila> ...and compiling subvertpy mention svn_pacth_canonicalize is deprecated
<vila> but I'm still in quantal here
<jelmer> hmm, it looks like quantal actually has 1.7 too
<jelmer> I guess it might be okay if you are just running some of the code that happens to be using bzr-svn
<jelmer> the bzr-svn testsuite itself triggers an abort IIRC
<vila> yeah, that's what I'm doing
<Luke-Jr> If I have a bzr repository, and I want to add revisions prior to its initial commit, how can I do that?
<Luke-Jr> I'm aware it will likely break compatibility with the pre-rebased branches, so I've avoided publishing them so far
<LeoNerd> Luke-Jr: Make a new branch with the new initial commit, then  bzr replay  the original branch on top of it..?
<mgz> yeah, new branch, make changes there, then replay or `bzr merge -r0..-1` the original branch on top
<paultag> (sorry for the phrasing, I'm a git user) -- anyone know how I can use bzr to branch a repo similar to git's "bare" mode (but have it branched from a remote location)
<mgz> explain what that does, so I don't have to google "git bare"?
<paultag> it's a mode similar to bzr repo-init
<paultag> basically, server bits for hosting, rather then a working tree
<paultag> sorry, init-repo
<mgz> `bzr branch --no-tree`?
<mgz> or just push to a remote location, which doesn't create a working tree
<paultag> ah, --no-tree might be good
<paultag> mgz: I'm using bzr-git :)
<paultag> I had to patch it, because Launchpad chokes on signed git tags
<paultag> so I'm just going to mirror on a cron
<paultag> let's see here
<paultag> ahha! Nice, thanks mgz
<mgz> upstreaming any bzr-git patches would be nice
<paultag> ACK, it's been orphaned by jelme[r], and my patches do the wrong thing (ignore it, rather then handle it with grace)
<paultag> but I'll see if I can't find a better long-term solution and see if it'll get upstream'd
<mgz> that would be ace.
<paultag> ruddy brilliant, thanks mgz.
<paultag> everything works nicely
<qengho> I seem to run into "different rich-root support" more than most people. I think something might be wrong.
<qengho> So, I have two local branches.  Both say "Standalone tree (format: unnamed)" with "bzr info" on bzr 2.6b2, but they have d r-r s. I'm not sure what to do.
<mgz> qengho: use `bzr info -v` in both?
<qengho> http://pastebin.ubuntu.com/1520703/    mgz, I see.  Different branch and repo formats.
<qengho> mgz: that higher version is the odd man out, so I think I want to downgrade its format.
<mgz> right, either upgrade everything, or make sure you use the same old format
<mgz> the thought of chromium not using 2a is somewhat terrifying
<qengho> It's just packaging.  They use Svn and some wrappers and some git thing somehow for the code.
<mgz> all those nice performance fixes to large-branches going unused...
<qengho> as the "bzr info" says, 71 files, in 800 revisions.
<mgz> ah, it's literally just the packaging?
<qengho> mgz: Yes.
<qengho> mgz: "bzr upgrade" takes an argument, but "bzr info" doesn't actually name a format.
<qengho> Or, it names four.
<qengho> if a numberis a name.
<mgz> qengho: you probably want to look on the bazaar mailing list for threads about this back from when the 2a switch was done :)
<qengho> Ew, email.
<fullermd> There isn't a way to backgrade to poor roots.
<mgz> fullermd: but you can bring the changes over to a old-format branch via one hack or another
<fullermd> Potentially, yeah, but the hacks get real grody real fast.  Gonna be simpler to just pile up some diff|patch-ery unless you're talking about hundreds of revs or something.
<jelmer> paultag: ignoring sigtag will almost certainly cause checksum errors at some point in the future
<fullermd> And if you are, it's time to catch up to 2009 and just move everything to non-ancient formats anyway   :p
<paultag> jelmer: erm, hurm.
<paultag> crap.
<jelmer> paultag: basically, whenever git has a delta base that is a commit object with gpgsig
<paultag> Ohhh, I see it now.
<paultag> Hurm, OK
<paultag> well I'll be sure not to do that ;)
<jelmer> paultag: as bzr-git won't be able to generate the right git object from the bzr data
<paultag> ACK
<paultag> jelmer: is this something I could patch around sanely if I spent some time on it, or is it a lost cause to fight that
<paultag> (and end up stripping git tags for the bzr branch import)
<paultag> (and here I thought I was being clever with a 2 line patch)
<jelmer> paultag: one sec, let me grab my laptop
<paultag> jelmer: don't spend too much time, on me it's a silly silly thing, I was just trying to get dput-ng nightlies, I can totally work around it
<jelmer> paultag: ok, back
<paultag> thanks jelmer, sorry!
<jelmer> (phones are terrible for non-trivial IRC conversations..)
<paultag> yeah, sorry, sorry
<paultag> I didn't mean to bug you
<paultag> (tried to avoid a ping)
<jelmer> paultag: I don't think there really is a way to fix this properly without spending a day or two on it
<jelmer> paultag: that's quite alright :) it would be nice if somebody fixed this, as it's going to be hitting more and more bzr-git users
<jelmer> paultag: but I don't think there is an easy fix like a two-liner :-/
<jelmer> paultag: another alternative is to actively strip the gpgsig data from the git repository involved (so the git sha1s change appropriately)
<paultag> I'd not mind fixing it, I know dulwich fairly well (used it for $WORK a few times to track DB changes), but is it going to involve going wrist-deep into bzr internals?
<paultag> (I'd also be happy to fold it into a QA upload against your package, which I see is now O'd)
<jelmer> it is going to involve a fair amount of bzr-git internals. you'll have to chuck the gpgsig data in a bzr revision property, and possibly deal with older bzr-git versions that handle that data well.
<jelmer> s/that handle/that don't handle/
<paultag> ack
<paultag> oh, I see.
<paultag> hurm.
<paultag> right, and trying to trick it into convering a signed â unsigned should (rightly) blow it up
<paultag> Oh, OK, I see where this would break.
<paultag> yikes.
<jelmer> paultag: yes, because that changes the commit SHA1
<paultag> right, ack
<paultag> ok, so the fact this is working now means I'm really, really, really lucky :)
<jelmer> well, bzr-git only generates the old git object text from the bzr data when it receives a delta with that data as base
<paultag> and since commits are based on the thing the git tag ref's, that's not been the case
<paultag> I see, I see.
<paultag> (still think it's more luck then anything else now ;) )
<jelmer> yes, luck is a big part of it (-:
<paultag> thanks jelmer, you've been a huge help :)
<paultag> sorry to keep bugging you with this!
<jelmer> paultag: sure, not a problem. sorry I couldn't give you better news on your 2-liner...
<paultag> nah, it's fine, I was shocked I could just drop an if / exception and not have everything blow up, so I was kinda expecting this
<iamvshal> hi I am trying to get this branch
<iamvshal> bzr branch lp:openobject-addons/6.1
<iamvshal> however it always gives and error after some time
<iamvshal> Write failed: Broken pipehing revisions:Inserting stream:Estimate
<iamvshal> 182361/182487
<iamvshal> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and
<iamvshal> permissions, and report a bug if problems persist.
<iamvshal> I did search but did not find anything usefull
#bzr 2013-01-13
<tomprince> https://bugs.launchpad.net/bzr-svn/+bug/882705
<ubot5> Launchpad bug 882705 in Bazaar Subversion Plugin "dpush revisions make unnecessary change to branch root" [High,Triaged]
<jelmer> tomprince: what about that bug?
<jelmer> thanks wgrant
<wgrant> jelmer: np
<wgrant> Thanks for fixing the other bits
<tomprince> jelmer: It's causing issues, and seems to be caused by bzr-svn not obeying dpush.
<rsajdok> I have problem in merging. Any suggestion about this question? https://code.launchpad.net/~ris/loco-team-portal/fix-552762/+merge/142553
<rsajdok> https://code.launchpad.net/~ris/loco-team-portal/fix-552762/+merge/142553/comments/308685
#bzr 2014-01-06
<Guest81537> hello, ther eis some place where found a good step step guide for use bazaar explorer?
<Guest81537> I not understand well how I can sync one folder trunk with the official trunk
<LeoNerd> Hrm. I can't partially unshelve...?
<Guest81537> bzr: ERROR: exceptions.AssertionError: Root entry should be supplied to record_entry_contents, as of bzr 0.10. ?
<thumper> LeoNerd: no
#bzr 2014-01-07
<quicksilver> LeoNerd: you can unshelve and then partially reshelve
<Eduard_Munteanu> Where can I find a definition of the 'lp' transport? I want to know if it uses a secure channel like https or ssh.
<fullermd> Technically it's not a transport, it's a directory service.
<fullermd> Pretty sure it resolves to http if you're not lp-login'd, and bzr+ssh if you are.
<SamB> yeah
<rozzin> Eduard_Munteanu: I think it's in the "launchpad" plugin.
<rozzin> Eduard_Munteanu: On my Debian installation, this appears to be in /usr/lib/python2.7/dist-packages/bzrlib/plugins/launchpad.
<Eduard_Munteanu> Thanks.
<Eduard_Munteanu> I guess I should use the account and add the ssh key.
<SamB> the plugin ships with bzr, though
<Eduard_Munteanu> SamB: yes, but I don't want to fetch stuff over plain http or without some signature
<SamB> it's odd, there's no mention of "http" anywhere in /usr/lib/python2.7/dist-packages/bzrlib/plugins/launchpad/lp_directory.py
<SamB> Eduard_Munteanu: it looks rather as though launchpad itself resolves the lp: URLs in the non-SSH case ...
<SamB> Eduard_Munteanu: I suppose there's not really much you can do besides that, realistically; launchpad could theoretically be changed to resolve that to https, but that might break existing deployments if they can't validate the SSL keys ...
<SamB> (because they don't have the needed CA certs installed/trusted)
<Eduard_Munteanu> SamB: yeah... I ended up downloading a tarball through the web interface
<rozzin> I do vaguely recall looking into how "lp:" URLs get resolved, at some point, and finding that there was some series of redirects from lauchpad.net.
<rozzin> I remember being confused by it; I also remember it making slightly more sense after looking at how a user configures branches/series on the launchpad.net website.
#bzr 2014-01-08
<Zoohouse> Hello everyone
<Zoohouse> I'm looking through the bzr man pages but I'm confused on how to remove a project. I just ran bzr init-repo iiu but I want to remove it and start over. How do I do that?
<LeoNerd> It's just files on your disk. rm them.
<Zoohouse> i want to undo init-repo iiu
<Zoohouse> LeoNerd, but would bzr still have the uii project in mind?
<LeoNerd> ?
<LeoNerd> "in mind" ?
<Zoohouse> bzr created a dir where the project should go. Can I remove the directory and then run 'bzr init-repo iiu' again with no problems?
<LeoNerd> Yes; all the data is stored inside the .bzr directory. If you remove that then there's nothing left.
<Zoohouse> Oh ok, that makes sense now
<Zoohouse> thanls
<Zoohouse> thanks*
<Zoohouse> LeoNerd, now I get his error after I deleted the dir: [user@manjaro trunk]$ bzr init-repo iiu
<Zoohouse> bzr: ERROR: [Errno 2] No such file or directory
<Zoohouse> sorry, missed the return carriage char
<LeoNerd> ... did you kill the .bzr directory..?
<Zoohouse> acually, forget the question, I understand what happend
<LeoNerd> (also I usually just do it on CWD)
<Zoohouse> yeah I did but I was still in the dir in term, i deleted the dir via gui
<Zoohouse> it's good now
<Zoohouse> thanks again
<LeoNerd> Anyone heard from Jelmer lately..? Some bzr-git plugin issues still piling up
<fullermd> 'ccording to my logs, he hasn't been around since mid last month.
<fullermd> But I'm not sure he's much interested in b-g anymore anyway   :|
<LeoNerd> Hrm. Well, regardless: It plain does not work currently, so -someone- neesd to fix it
<fullermd> Unfortunately, that turns into a pretty short list.
<LeoNerd> :/
<fullermd> And I just ran into cvsps-import being broken with 2.6+ too.
<LeoNerd> Boo
<rozzin> Is cvsps-import perhaps less relevant since esr did the `cvs-fast-export' thing?
<fullermd> I'm not immediately clear on what cvs-fast-export is that the fastimport stream variant of cvs2svn wasn't, so I don't think it changes anything there.
<fullermd> But it does still have the incremental issue sewn up with a nice little bow.
<fullermd> ...  OK, an ugly-ass giant festering turd of a bow.  It IS CVS after all.  But still.
<fullermd> And at any rate, all of them were more trouble than I ever wanted to bother with, since the fastimport plugin called for the fastimport python lib, which wasn't packaged for my OS, whereas cvsps is, so...
<rozzin> Which OS is that?
<fullermd> FreeBSD
#bzr 2014-01-09
<Arc> hey
<Arc> does anyone know where bzr is on python3 support?
<SamB> I don't think it's gotten anywhere really
<Arc> its odd that while almost the entire python community has finished migrating now the vcs tools are still lagging
<SamB> bzr is pretty dead-ish
<SamB> did you see jelmer's blog post?
<Arc> no
<rozzin> Arc: Is Python 3k really supposed to entirely supersede 2.x?
<maxb> That's the intent, as I understand it
<Arc> rozzin: yes. 2.7 was released to aid in migration, but no more features will be added to 2.x
<SamB> rozzin: they dropped the k, and I assume they were hoping to stop doing security updates to 2.7 at some point ...
<Arc> there will never be a 2.8 so says guido, and i agree with that.
<rozzin> Meh.
<Arc> ive been using py3 as my /usr/bin/python for years just fine
<Arc> and with both gnome and kde making the switch, and the major python web frameworks, etc... its only a matter of time before /usr/bin/python2 becomes unnecessary
<Arc> im trying to trim down a raspberrypi image and looking at the things that rely on python2, it'd be a boon to be able to cut it out entirely
<rozzin> It's like hearing "C++ is expected to replace C. All C developers are expected to migrate to C++", for me.
<maxb> It's not really comparable, IMO
<maxb> Although I have to admit I haven't even started writing Python 3 myself yet
<Arc> rozzin: more like "Perl5 is expected to replace perl4.  All Perl developers are expected to migrate to Perl5"
<maxb> Partly because I have to still deal with some ridiculously old installations at work
<Arc> maxb: the differences are so subtle as to be almost ignorable.
<Arc> its akin to going from python 2.4 to 2.6
<Arc> a bigger jump than a minor, but no more than 2 or 3 minor revisions
<rozzin> Arc: I don't know. Never knew Perl4.
<maxb> At some point I'm probably going to have to sort out backported packages for Debian oldoldoldstable, if I'm going to use it at work :-/
#bzr 2014-01-10
<rozzin> Is it possible to do a lightweight checkout of a remote git branch using bzr-git?
<SamB> I heard bzr-git was unfinished, with no plans to finish it
<zyga> hi, I ran the trunk test suite on 14.04 and got 8 failures, is that expected?
<zyga> this is a part of the failure log (gee, thanks gnome-terminal for insane default of 512 lines of backlog): http://paste.ubuntu.com/6728629/
<rozzin> I'm not even sure how to read that log and identify what the 8 things are.
<zyga> rozzin: I'm getting a fresh run with all of the failures
<zyga> rozzin: a few were caused by missing python-lzma, now installed
<zyga> rozzin: what remained now are tests related to gpg
<zyga> rozzin: note, this is stock trunk on python2.7, nothing fancy yet
<zyga> full failure log: http://paste.ubuntu.com/6728825/
<rozzin> zyga: It looks like the ones that failed due to missing python-lzma were excluded from the `8' count, though.
<rozzin> zyga: Do you know which 8 tests are actually the ones referred to be "failures=8"?
<rozzin> zyga: I'm not really all that familiar with how any of this is implemented, but I'm willing to dig in and try to help. I used to be a Python programmer.
<zyga> re
<zyga> rozzin: I guess each of FAIL is one test
<jderose> zyga: so i wont have time to dig into anything till this weekend, but i'm highly excited about your python3 porting effort :)
<jderose> zyga: also, those failures seem (mostly) related to python-gpgme, so i'd first see if its tests pass on trusty - http://packages.ubuntu.com/search?keywords=python-gpgme
<jderose> possibly related to gpg 1.4.15 being in trusty, dunno - http://packages.ubuntu.com/search?keywords=gnupg
<zyga> jderose: thanks, I was suspecting the same thing
<zyga> jderose: I'm looking at the code now, I think the first attempt will cut a lot of functionality, I'm quite surprised by how much stuff is inside bzr, I think that some strong decisions to drop things could make the (huge) effort doable but I'm not yet sure about what to consider dropping
<jderose> if it is a python-gpgme issue, you should ping James Henstridge (dunno his IRC nick) - https://plus.google.com/u/0/+JamesHenstridge/posts
<zyga> jderose: I'm currently removing lazy imports so that 2to3 can be more productive
<zyga> jderose: once I get --help to run I'll post my code
<jderose> sweet :)
<jderose> i think there are areas that should probably be trimmed, but dropping support for any old formats kinda scares me :P
<zyga> jderose: this is a fork, you can still use bzr --upgrade for old stuff
<jderose> true
<zyga> jderose: and the game is lost anyway, so it's not about keeping what we have, it's about making something that people want
<jderose> good point
<zyga> jderose: or what we can still *have*
<jderose> does bzr still use pyrex? (been a while since i've looked at the bzr code)
<zyga> jderose: yeah
<zyga> jderose: more scary stuff for me ;)
<jderose> how's that as far as python3?
<jderose> hehe
<zyga> jderose: not sure, I never wrote any, I'm considering dropping that if needed
<zyga> jderose: as there are pure python versions too
<zyga> jderose: right now I want to see bzr --help
<jderose> might be something that would be better replaced with c extensions
<jderose> yeah
<jderose> sorry, getting ahead of myself... especially considering that fact that i haven't done anything yet :)
<zyga> jderose: hey, I didn't do anything at all :) I just want to :>
<jderose> i'm pretty sure you're a lot closer to `bzr --help` than i am :P
<zyga> I wonder if some parts of bzr could be dropped/replaced by existing libraries, I feel that a lot of bzr is actually now available as readily-available modules that we don't have to maintain
<zyga> especially a lot of the network code
<fullermd> I'd not worry overmuch (at least at the moment_ about the server shutdown failure.  I think that's a somewhat touchy area in general, so...
<zyga> fullermd: thanks!
<zyga> fullermd: as long as trunk fails the same way as my neutered version I'm happy
 * zyga reads the launchpad plugin code
<fullermd> And the builddeb stuff...  well, shoot, nobody uses that "deb" thing anyway.
<zyga> the single most important plugin
<jderose> fullermd: yeah, speak for yourself :P
<fullermd> Naturally; I always speak for all right-thinking people   :P
<jderose> zyga: i think for the HTTP/HTTPS transport stuff, yes, the standard lib could replace a lot of things. BTW, I have a lot of experience with the Python3 `http.client` module.
<zyga> OOHHH
<jderose> hehe
<zyga> so lp_api_lite
<zyga> that's so sweet, no lauchpadlib
<zyga> jderose: for all networking I was hoping to use requests, it's nice and shiny and has lots of usage, it seems to handle auth very well out-of-the-box
<jderose> zyga: but there is also the custom SSH implementation (can't recall the python package name)... that might be a lot harder to replace
<zyga> jderose: paramiko
<zyga> jderose: yeah
<jderose> right
<fullermd> paramiko isn't actually used most of the time.
<zyga> jderose: I haven't looked at that yett
<jderose> zyga: er, requests? is that part of httplib2?
<fullermd> Only on Windows sometimes I think, unless you forcibly call it.  Usually just calls the command-line ssh.
<zyga> jderose: I don't think so: http://docs.python-requests.org/en/latest/
<jderose> fullermd: so even when using the SSH transport (say, with launcphad), paramiko isn't used all the time?
<fullermd> Er, wait, maybe paramiko is still used for sftp.
<zyga> fullermd: ah, good, something that can be dropped then
<fullermd> But yeah, bzr+ssh calls ssh(1).
<zyga> fullermd: TBH, I only care about lp and local work, everything else is gone
<jderose> gotcha, then that's easy to replace
<fullermd> Or even putty or something on Win, I think.
<zyga> fullermd: I don't care for windows yet, lots of issues for no gain for now
<fullermd> But thinking about it, it probably IS used for sftp.  How common that still is, I dunno; it's probably mostly OBE when the smart server came in, but I'll bet there are still niches.
<jderose> fullermd: what is this "Win" you right-thinking people speak of? :P
<zyga> jderose: the thing with metal bars ;)
<fullermd> It's a recursive toy.  You get Win so you can toss it out a Win, for the Win   :p
<jderose> fullermd: i think if you have a launchpad account, most tend to use SSH as the transport. stuff like lp:foo automatically gets transformed into a bzr+ssh URI when you've set your launchpad username
<jderose> hehe
<fullermd> Oh, sure.  I'm not even sure LP still supports sftp (though of course it used to)
<fullermd> But people do once in a while use bzr on something other than LP   :p
<jderose> launchpad definitely supports SSH still
<fullermd> You mean sftp, or bzr+ssh?  They're two vastly different things.
<jderose> er, yeah, i mean bzr+ssh:// not sftp://
<jderose> not sure about the later
<fullermd> Yeah, bzr+ssh [almost] always calls out to a command-line ssh(1) if it can.  Pretty sure sftp is all done via paramiko though.
<jderose> interesting... i would have guessed the oposite
<jderose> but dropping a dependencies is always good :)
<fullermd> Well, over ssh it just uses it as a tunnel to blat bytes over.  It could probably be made to support bzr+rsh in about 2 minutes if somebody wanted to.
<fullermd> But sftp, you'd have to interactively script a program or something to call out like that, which is icky.
<jderose> gotcha
<fullermd> I'm not sure that e.g. OpenSSH's sftp(1) even lets you do all the stuff bzr tries behind the scenes.  The sftp protocol is hyuge compared to the 2 or 3 things 99% of the uses do.
<zyga> mmm
<zyga> I'm quite interested in what github did
<zyga> with their move to abandon git:// and ssh and use https for everything
<zyga> they still support that but actively discourage it
<fullermd> Obviously, got hold of some very good drugs.  They went with git, after all.
<zyga> fullermd: indeed
<zyga> git has a very simple model and no content type conflicts ;)
<jderose> plus their excellent security track record :D
<zyga> jderose: who cares, they are being used
<jderose> i'm pretty sure these days you can replace "who" with "governments, large companies, non profits, etc..." :P
<zyga> jderose: the same ones that run java and winxp
<fullermd> No, I'm pretty sure nobody cares about security, just like the last 20 years...
<zyga> jderose: I agree that security is good but secure dead software is not useful
<jderose> true
<zyga> they care about wiretaps but they don't really care that $vendor got owned $number of times as everyone gets owned once in a while
<zyga> jderose: if security was important we'd be running solaris, not linux ;)
<fullermd> Nah, I'd vote for AIX.
 * zyga is too young for that
<fullermd> When I _adminned_ an AIX box, I could never get it to do what it was supposed to.  How's somebody who's not root gonna pull it off?
<zyga> btw, is knit a word I should know or some fancy invention?
<fullermd> Well, I'd expect you to know it as a word in general.  The application into version control is a bit of an analogical invention.
<zyga> fullermd: I'm not familiar with it
<zyga> fullermd: what does it mean?
<jderose> fullermd: knit was a specific repository format, right?
 * zyga is google lazy while reading python on the next monitor
<fullermd> The way you make socks and sweaters and scarves and such?
<zyga> aaah
<zyga> from tiny threads and such?
<fullermd> In bzr, it was a history storage format, succeeding weaves.
<jderose> fullermd: is knit the current history format then?
<fullermd> (hence the choice of naming; knits are like weaves, but append-only instead of constantly re-weaving, and since you knit purely from a top end...)
<fullermd> No, [pure-]knit was replaced by pack-0.92 which used knits internally, and that was replaced by 2a.
<jderose> ah, gotcha
<fullermd> I still come across pack-0.92 stuff occasionally, but it's gotten pretty rare.
<jderose> ah, i remember when pack-0.92 was the new hotness :P
<fullermd> The re-weaving with weaves was crazy expensive.
<fullermd> I remember back when bzr.dev was still in weaves, and I had to carefully time my daily pulls, because they would nail up the CPU for about 20 minutes.
<jderose> hehe
<fullermd> (the crazy-slow reputation bzr still carries may be almost totally historical, but it sure was earned at one time...)
<jderose> yeah, i do remember those days
<fullermd> knits were a huge improvement.  packs made a number of things better too; for one thing, I could take annoying hacks out of my Apache config to avoid interpretting the knit filenames.
<zyga> well
<zyga> it's not crazy slow
<zyga> but noticeably slower than git on anything
<zyga> and pushing is dead slow
<fullermd> Try it with weaves; you'll get a great appreciation for how fast it is now  :p
<zyga> not sure if lp or bzr are to blame there
<zyga> hehe
<zyga> I remember all the old versions of bzr
<fullermd> But it is python, so stuff like startup is always gonna be way slower.
<zyga> I was using it from the start, almost
<zyga> way before I joined Canonical
<fullermd> Those lazy imports you were talking about were a major improvement in that.
<zyga> yeah, I know
<zyga> now I'm just killing the magic to get 2to3 to see stuff
 * fullermd pictures you with a 7 foot spear standing over a dead unicorn...
<zyga> fullermd: but they are full of candy inside
<zyga> ;)
<fullermd> I have vague memories of 2to3 experiments a couple years ago.  Seems like a few bumps were hit and then it was set aside due to nobody caring enough at the time.
<fullermd> Probably far enough back now that whatever lessons were learned are pretty stale.
<zyga> fullermd: I think that 2 and 3 codebase is hard
<zyga> fullermd: especially since bzr still supports really old code syntax
<fullermd> I think the really old stuff is gone (or at least not necessary); think the last few major releases have been 2.6+ only.
<fullermd> (3 being a major reason behind that)
<zyga> fullermd: the code is full of 3.0 incompatible syntax though
<zyga> fullermd: one thing I learned to like about recent pythons
<zyga> fullermd: is that I can drop hacks
<fullermd> Oh, sure.  But dropping 2.4 meant we could dump a lot of _required_ 3.0 incompatible stuff.
<zyga> fullermd: drop static copies of stuff I needed but wasn't around
<zyga> fullermd: and that my code kept getting smaller and easier to follow
<zyga> fullermd: I think that 3.2+ is good enough though 3.3 could be sweeter as it has even more goodies that can replace bzrlib home-grown code
<fullermd> I'd bet there's a lot of stuff hiding around in bzrlib that's still 2.4 compatible but doesn't have to be.
<zyga> yeah
 * zyga just read 'this is not present in python2.2 so here's a copy' in one file
<zyga> 2.2
<zyga> configobj.py
<fullermd> Hey, it's a palindromic version.  Gotta support those.
<zyga> what is rio
<fullermd> Serialization format, I vaguely remember?
<zyga> hmm
<zyga> relevant?
<fullermd> I _think_ it was something from old formats, like pre-pack knits and before.  But that's very vague memory.
<zyga> one thing I always liked about bzr is that it was a promise of pythonic api for vcs'es
<zyga> but it was so complex that I never really got to like it or felt it was simple
<zyga> and the layers of layers of indirections were a major factor each time I tried following the code
<fullermd> Hey, don't tell that to me; I'm the guy who doesn't like OO wholesale   :p
<zyga> python2.4 support is alive and strong in some files :)
<fullermd> Looks like it was the 2.4 release series that officially dropped py2.4 and 2.5 support.  Appropriate.
#bzr 2014-01-11
<zyga> hey, so what's the chance of dropping 2.6 support in bzr trunk and only having 2.7 code?
<zyga> I'm trying another strategy, as apparently lazy_import is not optional anymore, it's a required feature, due to circular import dependencies
<zyga> so I'm PEP8 cleaning up the code to have less spurious warnings from flake8
<zyga> and I'll de-lazify all external imports, which should make it possible for 2to3 to fix all the boring urllib* changes
<zyga> but I won't touch bzrlib internal imports
<zyga> so long story short
<zyga> some of my patches could be merged upstream
<zyga> but I'm really no inclined to do 2.6 compatible code anymore
<fullermd> I don't think I'd have any terribly strong objections to it.  But my vote is pretty far off in a corner.
<fullermd> Seems like what's around in long-term supported releases of Ubuntu/Red Hat/etc has traditionally set a minimal floor.
<zyga> fullermd: thanks
<fullermd> Bringing it up on-list will hit a wider audience; I think most packagers are on it, or at least were.
<KI7MT> Is this the correct channel for discussing issues with bzr branching, merge proposals / bug fixes etc?
#bzr 2015-01-05
<croepha> hello
<croepha> anyone know of an easy way to pull from an upstream mainline?
<croepha> what I do now, is bzr branch head; cd head;  bzr merge ../mybranch; bzr commit; cd .. ; rm -rvf mybranch; bzr branch head mybranch; rm -rvf head
<fullermd> That...  doesn't seem an obviously meaningful action.  Can you elaborate a bit more higher-level what you're wanting to do?
<croepha> so, there is a mainline âheadâ, and my project branch âmybranchâ is to be merged into âheadâ by the âheadâ maintainer at some point in the future, but for now, I would like to bring other changes that have been made to the head, and bring them into my project.  I would really like to bring those in withourt adding any new commits
<croepha> fullermd: ^
<fullermd> Well, you can't do it "without adding new commits".  You've got two separate streams to reconcile, so there has to be a merge revision.
<croepha> right
<fullermd> Just 'bzr merge head' in your branch.
<fullermd> All you're doing with that dance is clumsily manually implementing[1] 'merge --reverse' to swap around the order of the heads, which isn't what you'd want in this case anyway.
<fullermd> [1] (which of course is all you can do, since nobody's written --reverse, but still)
<croepha> well, I think there should be a commit that brings mybranch into head, but not head into mybranch, because later on, when people look at the mainline log, they will see people doing these extra commits that were just to get head code into project branches
<fullermd> When mybranch finally lands, it'll be merged into head.  When you're continuing mybranch but keeping up with head, you're merging head into it.
<croepha> ok, there wont be any cris-cross warnning doing that?
<croepha> warnings*
<fullermd> No, that's all fine.  Criss-cross merges are something else entirely.
<fullermd> That has to do with merges lacking a unique MRCA.  You can't get that with "separate branch, occasionally merging trunk, eventually merged into trunk"
<fullermd> You usually get it with two branches repeatedly merging each other, or one branch repeatingly merging another, plus both of them merging a third.
<fullermd> But in your case, all the merges go one way until the end, so there's no crossing.
<croepha> if there was continous merges on both sides, a way to solve it would be to do a bzr pull head  before doing another commit on mybranch
<croepha> ?
<croepha> not merges, commits
<croepha> if there were continous commits ..
<fullermd> Once you make a criss-cross, there isn't any way to resolve it but to plow through it (either by manually dealing with spurious conflicts, or using a different merge algorithm that doesn't notice such, etc)
<fullermd> You can't pull once there's divergeance, so you could do "pull, then commit" before you make your FIRST separate commit on mybranch, but it's not useful after.
<fullermd> (someday, I'll train my fingers how to spell "divergence"...)
<croepha> so, once head merges your branch, you throw away your branch and start with a new one
<fullermd> If the job of that branch is done.  Otherwise there's no reason not to keep running with it.
<fullermd> You could also just 'pull' in that branch then (since head is a superset of what you have).  Not much different than "rm -rf ; re-branch", but less running around the block to do it.
<croepha> well, some times merges happen early, to get some partial new functionality
<fullermd> You don't get a criss-cross _any_ time two branches merge each other, only in particular cases.
<croepha> ahh
<croepha> ok
<fullermd> In the 2-branch case, it can be roughly expressed as "merging each other at the same time"
<fullermd> e.g., I'm at rev 60, and you're at rev 70.  I merge your 70 to make my 61, you merge my 60 to make your 71.  Now we have a criss-cross.
<croepha> ok, thanks a bunch
<fullermd> If you merged my _61_, there wouldn't be a cross.
<croepha> excellect
<fullermd> (gets a little harder to describe, and more likely to happen, when you have 3 or 4 or 15 branches involved; it's a lot easier to get crosses that way)
<croepha> it seems like you will have a bunch of commits in the log for head that dont actually contribute any changes to the head, but i can probably live with that
<fullermd> But as long as you have a fairly hierarchical set of branches where you're not crossing the streams, it won't come up much.
<fullermd> Well, they'll be in merge commits, so you won't see them in the mainline log unless you expand out the merges.
<croepha> yea
<fullermd> Just like in mybranch, you don't see the details of all the things in head in that merge unless you expand, you just see the 'merge head'.
<fullermd> Of course, if the 90% of the  commits in mybranch end up being "merge head"...     but that's probably more a sign of your workflow screaming in pain.
<croepha> eh, it will probably be 10%
<croepha> Thansk for all the hellp,  btw, i just want to mention, that bzr is awesome, im not sure why git is so popularâ¦.  I have tried to get non developers to use version control for graphics and web content, and git is very difficult to explain, but everyone in my org finds bzr pretty easy to use
<fullermd> That's why I'm here instead of in #git    8-}
<LeoNerd> I much prefer bzr. Mostly for monotonic integer revision numbers, and the fact I know it actually remembers renames
<croepha> yea
<fullermd> I find the CLI a lot less obnoxious.  But if I had to pick one overriding reason, it'd be respecting and using the chirality of merges.
<fullermd> I get the impression that git occasionally makes small steps in that direction.  Maybe someday...
<croepha> yep
<croepha> i think that in the future there will be something that just watches a directory for changes and automatically makes commits, and then the user will occasionally label those commits
<LeoNerd> Hellno
<LeoNerd> I want it to commit -only- when I want it to
<fullermd> I think that's called "VMS"   ;p
<croepha> i know that seems like a bad thing, but for non developers it would be a drop in vc solution
<LeoNerd> The only -major- thing I miss from git is  rebase -i  but I'm sure there'll be a plugin somewhere with it... right? ;)
#bzr 2015-01-09
<croepha> so, me and my buddy both branched from the same head, then we bounded to the head
<croepha> and then I told him, our branches are now in a commited relationship
#bzr 2016-01-17
<Peng> `bzr selftest --parallel=subprocess` is the reason I can remember it's not spelled "paralell". Thanks, Bazaar. :D
<fullermd> Well, bzr is the reason I can't spell "bar" anymore.  Thanks, Bazaaar   :p
<Peng> Heh, same
#bzr 2017-01-09
<nicoulaj> Hi all, any idea about this stack trace ? http://pastebin.com/raw/XKAx8Eb4
#bzr 2017-01-10
<jonh> HEY EVERYONE NOOB HERE!1 Sorry, wait, no, I can type. Quick, assuredly dumb question. I'm working on some improvements to Inkscape, and want to fetch the bzr repo so I can eventually commit changes.
<jonh> I created a launchpad account, username jonhdotnet.
<jonh> https://login.ubuntu.com/ shows me logged in with that username.
<LeoNerd> If you just want to fetch, you don't need a login
<jonh> (Ah, but I was planning ahead as suggested on https://inkscape.org/en/develop/getting-started/)
 * LeoNerd nod
<jonh> jonh@selah:~/inkscape-hacking$ bzr launchpad-login jonhdotnet
<jonh> bzr: ERROR: The user name jonhdotnet is not registered on Launchpad.
<jonh> But bzr doesn't believe me.
<LeoNerd> Ah, not sure on that myself. I don't use any of the LP integration things
<jonh> This must be a shallow mistake, so I'm embarrassed to ask.
<jonh> Alright. Perhaps I'll just fetch anonymously, and then ask more enthusiastically once I have a patch ready for review.
<LeoNerd> Perhaps best
<LeoNerd> It gets you started at least
<jonh> (And I guess I'll ask the inkscape folks, since this seems to be lp specific.)
<jonh> Thanks for letting me drop in and cause trouble. :v)
<LeoNerd> Well, here itself is fairly ontopic for LP generally. I'm just not *personally* familiar with it
#bzr 2018-01-10
<gour> hello, just watched a talk about breezy...it's nice that bazaar gets some new life...after darcs (which i liked a lot), i used bazaar for all my personal projects, but seeing the state of the project moved to fossil eventually. now while waiting to see what will happen with Pijul, there are news about Breezy. :-) How do (brz devs) see Breezy in the light of e.g. Fossil/Pijul? personally, i don't like git at all
<gour> since it, as drh said, burns too many brain cycles of its users to be operated safely which could be used more efficiently for the work itself, so my git-usage is minimal (mostly cloning stuff from github to be built). what is going on with bzr explorer, iow. what about brz's gui? i always like(d) simplicity (of bzr) and nice to see nw life in the project
<gour> *new life
<Peng> :O
<gour> fossil devs do work on interoperability with git, but it's not there (yet), so brz should have that advantage, right? what about performance? bzr was plagued with the label that it's generally too slow?
<gour> of course when we speak about Explorer, we must remember Ian - such a great soul!!
<mgz> gour: thanks for your interest (and watching my talk!)
<mgz> I'm EOD at work, but will be on later this evening
<gour> ok. ;)
 * gour is utc+1
<mgz> okay, I sent mail to the list with a few suggestions for breezy changes that can be picked up and worked on
#bzr 2018-01-11
<gour> morning
<gour> is there any repo having brz package for fedora?
<mgz> morning!
<mgz> I'm not aware of a fedora package, was going to bug a mate of mine to make one, but haven't yet
<mgz> jelmer and I are both on the debian side of the divide
<gour> i see...what is the status of bzr-explorer? still usable with brz?
<gour> another concern of mine is whether bzr/brz can be used as 2-way bridge with git, iow. to clone from github, pull/push etc.? that's not possible with fossil and although i use it for personal projects, one has to change gears when contributing to git(hub) projects. having brz to serve such purpose as higher-level tool would be awesome
<gour> should brz-3.0 have complete python3k support?
<mgz> explorer should be portable, but will require quite a few name changes
<mgz> I think the answer for clean github integration is using the git format locally,
<mgz> rather than trying to have bzr format on disk then convert back and forth from git
<mgz> brz 3.0 is aimed to be full python 3 compat, I have a good way to go yet
<gour> based in what i see, the blessed gui will be qbrz, right?
<gour> nice to hear about 3.0 and py3k
<gour> i'm not clear in regard to git(hub) integration...bzr/brz cannot use git format (yet), right?
<gour> having 'clean github integration' would be big 'pro' for me to migrate from fossil to brz...
<jelmer> hi gour
<jelmer> gour: I did some work to create a qbrz, in the hope that somebody picks it up
<jelmer> mostly because it's in a better state than bzr-gtk, and works on all of our platforms
<jelmer> I'll reply to your email about git integration
<gour> jelmer: ok, i remember you well from the glories days of bzr. ;) btw, thanks to you, i've found out about m.css - I like such stuff :-)
<gour> jelmer: bzr-explorer is too old code to be revived?
<mgz> bzr-explorer depends on qbzr
<mgz> so, qbzr is step #1
<gour> i was not using gui a lot with bzr, but it was always great selling point when introducing bzr to not so tech-savvy people
<jelmer> gour: :)
<gour> ahh, i forgot about that, thanks mgz
<gour> i'm sure that dvcs-world deserves something better than just git
<jelmer> gour: I'm hesitant to revive any of the GUIs myself, as I don't use them. It would be great if somebody could revive their development.
<gour> btw, i'm also looking which static-site-generator to use (to repalce my PHP-CMS sites) and between hugo (go-powered) and nikola (python-powered), I'm leaning towards the latter...moreover, python seems to be better investment of my time for hobby programming than Golang
<gour> ...although few days agi i read a post from the rinohtype author complaining that 'Python is fast-enough' for some projects, even with PyPy or cython (http://www.mos6581.org/python_need_for_speed)
<jelmer> I've been very happy with pelican, but haven't tried the others you mention
<gour> Nikola is very nice (https://getnikola.com/)
<gour> it is funny how many people tend to choose/use worse option...lp's email interface was so better than github's, but the flock went into another direction :-(
#bzr 2018-01-13
<gour> for the sake of experiment tried to convert some git repo to bzr and got: bzr: ERROR: exceptions.ImportError: cannot import name single_plural
<gour> any hint?
<mgz> gour: can you run with -Derror and paste the traceback?
<gour> mgz: https://paste.fedoraproject.org/paste/tA1XtbXr9kWDqCZGo4BF8Q
<mgz> gour: going by https://bugs.launchpad.net/ubuntu/+source/bzr-fastimport/+bug/1360924 should be fixed in some later version of fastimport?
<ubot5> Launchpad bug 1360924 in bzr-fastimport (Ubuntu) "ImportError: cannot import name single_plural" [Medium,Fix released]
<mgz> it's fine with the breezy embedded version of fastimport at least
<mgz> so, you can install from trunk and do `brz fast-import` instead?
<gour> ok, will try that
<gour> how would install bzr-git from the trunk?
<mgz> gour: from https://code.launchpad.net/~jelmer/brz-git/trunk
<gour> bzr branch lp:brz-git will pull the trunk?
<mgz> yes
<mgz> the trunk with the breezy imports, more importantly
<gour> do you have any rough eta for 3.0?
<mgz> not really, depends how many weekends I can steal for breezy time
<mgz> likewise for jelmer
<gour> i've tried to pull latest bzr-fastimport in the attempt to use it with latest bzr, but get the following: https://paste.fedoraproject.org/paste/5gDEc8NaC-fnKVLNLVCvSA
<mgz> you need to do what it says on the tin for that
<mgz> renamed the directory
<gour> btw, it would be great to have some brz package for fedora...
<gour> ahh, now recall that, no '-' in module names :-(
 * gour is converting gnucash repo to bzr
<gour> conversion with bzr-fastimport's trunk failed with: https://paste.fedoraproject.org/paste/wQNLvwQT~PIqd1NkB3Ocqg
<teknopaul> Hi all , cant find this in the docs,  if I run a server with   bzr serve --directory=/srv/bzr/repo on port 4155  is this a secure protocol? (for use over t'Internet)
<Peng> No
<Peng> Use one of the other protocols
<teknopaul> Peng: OK thanks
<teknopaul> BTW you know you are getting 500s  from the wiki today and yesterday e.g  http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<teknopaul> Is it really true that there are no serverside commit|push hooks in bazaar?  I need to build code after its submitted.
#bzr 2018-01-14
<gour> teknopaul: have you seen this: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html ?
 * gour is doing breezy pip install
<teknopaul> gour:  that page was not much help.  I used the source code and api docs.  Is there any way I can contribute to that page? It needs to doc which hooks run on the server and/or the client. Docs could do with details of the hook arguments .  RSVP to teknopaul@gmail.com if I can help, going dark for a week.
<gour> when i try to pull repo from github i get: ImportError: cannot import name RepositoryAcquisitionPolicy
<gour> is it some known issue?
