[00:00] <tolstoy> Hm. Not sure.
[00:01] <tolstoy> I "fixed" it, but it's still bad. Time for some radical action here.
[00:03] <GaryvdM> james_w, mwhudson, jam: I got it working. Tests show a 44% improvement. Patch in the mail :-)
[00:04] <james_w> woo!
[00:16] <poolie> hello
[00:17] <mwhudson> hi poolie
[00:31] <GaryvdM> If you do bzr log FILE, it does graph.iter_ancestry twice. In get_view_revisions and in _filter_revisions_touching_file_id
[00:32] <GaryvdM> If you could reuse the parent_map from get_view_revisions in _filter_revisions_touching_file_id, it would be a huge saveing
[00:32] <GaryvdM> I'm not sure how one would do that without changing the api?
[00:55] <tolstoy> If you do a merge, but don't want it (because you didn't know about preview), is there a way to "unmerge" to get rid of all the changes you just pasted in?
[00:55] <tolstoy> Ah. bzr revert.
[00:55] <tolstoy> Well, there you go.
[00:55] <pygi> :)
[01:01]  * Foskasse <Red_Khmer_> FUI UM DOS PRIMEIROS A TESTAR O IRC BETA
[01:02]  * Foskasse <Red_Khmer_> e tinha 212 irc cops a trabalharem para mim
[01:30] <ferrum> Hey guys, I'm trying to check out the Gnash trunk to work on it. The guys who usually help us aren't present at the moment..
[01:30] <ferrum> It's hosted by Savannah; I'm using the commands on https://savannah.gnu.org/bzr/?group=gnash , but they all exit immediately with "ERROR: Not a branch"
[01:30] <ferrum> any help would be appreciated
[01:35] <bob2> they somewhat lie - you need to append the branch name
[01:36] <bob2> e.g. 'trunk'
[01:36] <ferrum> bob2: ah, works. thanks
[01:38] <pygi> funny thing ... bzr viewer is broken because of that too xD
[02:21] <mwhudson> beuno: are you here?
[03:05] <libwilliam> I am having trouble with C/Python with the BugTracker class I hope someone can help me with. Here is my current code
[03:05] <libwilliam> This is more a problem with me having a hard time understand the C/Python part
[03:06] <libwilliam> I can get the class but I don't know how to get an instance of that BugTracker class to call the methods on.
[03:08] <Verterok> libwilliam: BugTracker() ?
[03:09] <libwilliam> i am both happy and pissed it is that easy ;)
[03:09] <Verterok> libwilliam: sorry, just looking at the code
[03:09] <Verterok> libwilliam: the "right" way to do it, is using the registry
[03:09] <Verterok> 'tracker_registry'
[03:10]  * igc lunch
[03:10] <libwilliam> Verterok, thanks, I will try that out
[03:11] <Verterok> libwilliam: somethign like: tracker_registry.get(key='gnome')
[03:11] <Verterok> np, glad to help :)
[05:11] <lifeless> hi
[05:12] <arjenAU> yeye
[05:30] <ToyKeeper> Hmm, having trouble getting 'bzr.dev selftest -v blackbox' to finish.
[05:30] <ToyKeeper> It just gets stuck forever on ...test_outside_wt.TestOutsideWT.test_url_log
[05:39] <mwhudson> hi libwilliam
[05:39] <mwhudson> no
[05:39] <mwhudson> hi lifeless
[05:39] <libwilliam> hey
[05:40] <mwhudson> libwilliam: sorry :)
[05:41] <libwilliam> haha, no prob
[05:45] <ToyKeeper> D'oh, sent a message before my list subscription was finished, so now it wants moderator approval.
[05:46] <ToyKeeper> (just a quick fix for bug 247150)
[06:44] <sm> evening all
[06:55] <Odd_Bloke> Moin.
[06:56] <Odd_Bloke> Waking up with light outside feels weird...
[07:07] <lifeless> moin
[07:38]  * ToyKeeper finally gets back to the bzrk-with-diffs thing
[07:39] <ToyKeeper> I got most of the issues fixed, but haven't yet taken care of DiffWidget not wanting to update.
[07:39] <ToyKeeper> For now, it's worked around by destroying and creating a DiffWidget every time its contents need to change.  Yuck.
[07:45] <beuno> mwhudson, I am now  :)
[07:46] <beuno> thanks for the search review, I'll try and address the concerns today
[07:47] <mwhudson> beuno: ok, cool
[07:47] <mwhudson> (that's what the ping was about unsurprisingly)
[07:48] <beuno> :)
[07:48] <beuno> I'm off to get breakfeast
[07:50] <lifeless> ook
[07:50] <lifeless> my machine just oopsed
[07:51] <lifeless> bbiab I hope
[07:59] <salubrium> I have a php project (vtiger) that was developed using Unix line breaks, then some developers have added quite a bit of modifications and many files are using Windows line breaks. Bazaar is detecting all these files as modified even though their content is the same
[08:00] <lifeless> salubrium: hi, you want the EOL conversion feature; this hasn't quite landed yet but you can probably get the pieces and test yourself. Hhowever - running a script before commit to force the line endinds to unix should ba  goo dwork aorund
[08:00] <lifeless> I would say that 1.7 will have what you need without workarounds
[08:01] <salubrium> I am new to Bazaar, by the way. I am trying to use it to perform a code-comparison to see what the previous developers have hacked. I tried using dos2unix to convert back to Unix.. but it seems that base Vtiger must use some windows line breaks in some libraries
[08:01] <lifeless> salubrium: ah, that would be annoying
[08:01] <salubrium> thanks lifeless.. do you know if Git or Mercurial have a "ignore line break" option?
[08:02] <lifeless> they do; I can't comment on how easy to use etc
[08:02] <lifeless> salubrium: well, to be more precise, they have a feature for during commits
[08:02] <lifeless> salubrium: I don't think thye have an arbitrary ignore-after-the-fact, but I may be wrong
[08:05] <Odd_Bloke> ToyKeeper: On the "init-repo ." bug report you mentioned sending a merge request.  Is my mail server being dodgy, or has it not quite been sent yet?
[08:06] <salubrium> Thanks for your help lifeless
[08:06] <lifeless> salubrium: no problem; sorry I couldn't help more -
[08:07] <ToyKeeper> Odd_Bloke: I sent it to the bazaar list, but it was sent a few minutes before my list subscription was completed...  so it's probably waiting in the moderator's queue.
[08:07] <ToyKeeper> Odd_Bloke: I could re-send if desired.
[08:11] <Odd_Bloke> ToyKeeper: Don't worry about it, I was just wondering what had happened. :)
[08:12] <ToyKeeper> It's a tiny patch for an unimportant bug, so I figured it could wait.  :)
[08:14] <Odd_Bloke> lifeless: If you have time to merge one branch into pqm.dev, the fix-tests branch which you've already reviewed would be good.  ATM I'm having to merge it into just about every branch I create myself, and I don't think I can submit branches which depend on it to BB without confusion ensuing.
[08:15] <lifeless> Odd_Bloke: you can submit branches with it - just use cherrypicks from it to your tip :)
[08:16] <lifeless> Odd_Bloke: that said, whats the url for fix-tests; I'll see what I can do
[08:16] <Odd_Bloke> lifeless: http://bzr.daniel-watkins.co.uk/pqm/fix-tests/
[08:22] <lifeless> Odd_Bloke: tests fail
[08:22] <lifeless> bzrlib.errors.FileExists: File exists: u'/tmp/testbzr-Tm95nh.tmp/tmp2Rh46g/work/bzrbranch/.bzr': [Errno 17] File exists: '/tmp/testbzr-Tm95nh.tmp/tmp2Rh46g/work/bzrbranch/.bzr'
[08:24] <Odd_Bloke> lifeless: I can't replicate here.
[08:25] <lifeless> 'make check' ?
[08:29] <Odd_Bloke> lifeless: I'm still not seeing it.  I get "exceptions.IOError: [Errno 13] Permission denied: '/usr/lib/python2.4/site-packages/twisted/plugins/dropin.cache.new'" from trial itself, but the tests then go on to pass.
[08:34] <lifeless> Odd_Bloke: ok, was a bzr version skew thing I think
[08:35] <Odd_Bloke> lifeless: OK.  I'm using 1.5 here.
[08:41] <ToyKeeper> Okay, got the most annoying bugs fixed in the new 'bzr vis' diff panel.
[08:41]  * ToyKeeper ponders whether to submit a merge request now, or wait until after he's added something to remember panel/window sizes
[08:41] <lifeless> ToyKeeper: now!
[08:41] <ToyKeeper> 'k, I'll send it.
[08:58] <ToyKeeper> D'oh, forgot to commit NEWS first.
[09:04] <Odd_Bloke> Hmm, unit testing HTML is annoying.
[09:06] <Odd_Bloke> I want to make sure that the SimpleTAL template that I'm about to write produces equivalent HTML to the Mako template I already have, but don't care about irrelevant whitespace being the same.
[09:07] <neobug> Odd_Bloke: you could use BeautifulSoup to parse generated HTML
[09:07] <neobug> and compare the tree with the one from Mako template
[09:07] <Odd_Bloke> neobug: Yeah, that's in the back of my mind.
[09:07] <lifeless> Odd_Bloke: I would prefer simpletal please
[09:09] <Odd_Bloke> lifeless: Yup, I'm working on that this morning.
[09:38] <mgedmin> where could I find a version of bzr-svn that works with the current stable bzr (i.e. 1.5)?
[09:38] <LarstiQ> mgedmin: bzr-svn 0.4.10 I believe
[09:38] <mgedmin> bzr-svn in hardy is too old, http://people.samba.org/bzr/jelmer/bzr-svn/stable wants bzr 1.6
[09:39] <LarstiQ> mgedmin: http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions 0.4.10 works with 1.4 and 1.5
[09:40] <mgedmin> thanks
[09:40] <mgedmin> now I only have to find it somewhere...
[09:42] <mgedmin> found the tarball on launchpad
[09:47] <Odd_Bloke> I'm really struggling to get my head around SimpleTAL.
[09:48] <beuno> Odd_Bloke, let me know if I can help. I went through that phase recentely
[09:52]  * mgedmin can't wait for history horizons to become available...
[09:55] <Odd_Bloke> I think this all boils down to my basic hatred of SGML-based markup languages.
[09:56] <Odd_Bloke> Perhaps I was abused my Tim Berners-Lee as a child.
[09:58] <Odd_Bloke> More seriously, the issue seems to be that Mako's macros are much more expressive than SimpleTAL's.
[09:58] <Odd_Bloke> And I can't work out how to deal with that.
[10:06] <nandersson> Sorry if this is a bit off topic, but I would like to know if OpenSUSE Build Service would be of any use to Ubuntu, or if it's a competing platform with Launchpad.
[10:06] <nandersson> I'm curious as I write for Swedish tech-mag TechWorld Open Source
[10:10] <mgedmin> what was the name of that bzr plugin that lets you publish branches using avahi?
[10:10] <james_w> nandersson: #launchpad might be a better place for you to ask that
[10:10] <james_w> mgedmin: bzr-avahi?
[10:11] <mgedmin> right
[10:11] <james_w> mgedmin: bzr-dbus and bzr-gtk are also useful to have if you are using it
[10:11] <mgedmin> my mistake was searching on bazaar-vcs.org rather than on google
[10:11] <nandersson> james_w, ok. I'll check!
[10:12]  * mgedmin wishes the bazaar ppa had these useful plugins in it
[10:12] <Odd_Bloke> beuno: So ATM I'm passing in a list of dictionaries representing messages.  Is there any way I can get the length of that list, or do I need to pass that in separately?
[10:13] <beuno> Odd_Bloke, you can do inline python with:    python: len(list)
[10:13] <beuno> withing an attrbute
[10:14] <beuno> you want to show the amount of results/list length?
[10:15] <mgedmin> okay, I'm beginning to think the pain involved in installing bzr-avahi (and then trying to get someone else how to do that, but this time on Mac OS X) is more than the potential gain...
[10:16]  * mgedmin is at a sprint for a project that uses svn and would have liked to try DVCS for sharing prototypes
[10:22] <mgedmin>  oh, the latest bzr-avahi doesn't work with the latest bzr-dbus anyway
[10:22] <mgedmin>  from bzrlib.plugins.dbus.server_mainloop import MainloopThread
[10:22] <mgedmin>  ImportError: No module named server_mainloop
[10:25] <james_w> mgedmin: it looks like it may require https://code.edge.launchpad.net/~jamesh/bzr-dbus/kill-broadcast-daemon then
[10:26] <jamesh> yeah.  I've got to go over a few changes lifeless suggested and get it merged ...
[10:27] <mgedmin> hm...
[10:27] <mgedmin> I managed to get the plugin to work after rm -rf avahi; bzr co -r 32 lp:bzr-avahi avahi
[10:27] <mgedmin> what is the bzr-speak for "svn up -r 32" when I have a bzr checkout?
[10:28] <mgedmin> i.e. getting the working tree to match an older revision?
[10:28] <mgedmin> anyway, bzr serve claims to work now, although bzr browse finds nothing when I run it on the same machine
[10:28] <mgedmin> should it?
[10:29] <mwhudson> mgedmin: svn up -r == bzr revert -r
[10:29]  * mgedmin will try to remember
[10:29] <mwhudson> mgedmin: also 'bzr share' not 'bzr serve' ?
[10:29]  * mwhudson is not here
[10:30] <mgedmin> bzr: ERROR: unknown command "share"
[10:30] <mgedmin> bzr help avahi says I'm supposed to use bzr serve
[10:30] <mgedmin> and all I needed to do was bzr advertise!
[10:30] <jamesh> mgedmin: I'd suggest running the above bzr-dbus branch and up-to-date bzr-avahi instead
[10:30] <mgedmin> yey!
[10:32] <jamesh> mwhudson: current bzr-avahi uses hooks to run out of standard "bzr serve"
[10:32] <mgedmin> jamesh: do I really have to?
[10:32] <mgedmin> now that I got the older ones working?
[10:32] <mgedmin> also, is it hard to get bzr-avahi running on Mac OS X?
[10:32] <mgedmin> or even possible at all?
[10:33] <jamesh> mgedmin: well, if the old version does what you want, go for it.
[10:33] <jamesh> mgedmin: but if you have problems I'd suggest upgrading
[10:33] <mgedmin> okay
[10:33] <mgedmin> what I want is to share the branch easily with someone sitting right next to me, who has a Mac laptop
[10:34] <Odd_Bloke> beuno: Thanks, that's helped a lot.
[10:37] <poolie> lifeless: ok so the problem is that the RepositoryPackCollection also knows about fallback repositories, but add_fallback_repository doesn't tell it when one is added
[10:40] <beuno> Odd_Bloke, you're welcome. Although, abusing that defeats the purpose of separating code from presentation, so use wisely  :)
[10:51] <poolie> lifeless: ping?
[10:53] <james_w> hi poolie
[10:53] <LarstiQ> ok, online again
[10:53] <james_w> hi LarstiQ
[10:53] <james_w> are you sprinting today?
[10:54] <poolie> hello james_w, LarstiQ
[10:56] <Odd_Bloke> beuno: I'm using <div>s in most places which require content to be replaced, but this causes linebreaks around it.  Is there a better element to use, or do I need to add 'tal:omit-tag=""' to all of them?
[11:05] <LarstiQ> james_w: yeah
[11:05] <LarstiQ> james_w: neobug, emilis_info, cyberix and mhammond are also here right now.
[11:06] <LarstiQ> james_w: The two Italians (I don't know their names unfortunately) are having lunch.
[11:06] <emilis_info> :)
[11:10] <beuno> Odd_Bloke, well, span elements won't add line breaks
[11:11] <mgedmin> Odd_Bloke: use <div tal:replace="new content" />
[11:11] <mgedmin> instead of tal:content=...
[11:32] <LarstiQ> neobug, emilis_info: so how are you doing? :)
[11:34] <neobug> LarstiQ: I fixed that bug with spaces in editor path, now writing the test
[11:36] <LarstiQ> neobug: cool
[11:38] <lifeless> poolie: hi; I'll ring you in a minute
[11:50] <LarstiQ> emilis_info: to summarize, you're looking at bug 109115, you're looking at code to see what the codepaths are that call bytes_to_gzip()?
[11:50] <emilis_info> LarstiQ, yep
[11:50] <emilis_info> I'm trying to find the correct place to show the error
[11:51] <LarstiQ> right
[11:51] <emilis_info> now int repository.py ... record_entry_contents()
[11:51] <emilis_info> s/int/in/
[11:53] <james_w> emilis_info, LarstiQ: rockstar was looking at that bug the other day. I think he was working out how to test it.
[11:54] <emilis_info> james_w, I have some shell code that reproduces it
[11:56] <LarstiQ> rockstar: ayt?
[11:57] <lifeless> Jc2k: ping
[12:37] <ChristopheT> Hi.  What is the best way to put a local bzr branch into a new branch on a pristine svn repository (no branches yet).  I tried push but got "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
[12:39] <jelmer> ChristopheT: bzr svn-push
[12:40] <jelmer> ChristopheT, There's an open bug about this
[12:41] <ChristopheT> jelmer: indeed, I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ('Delta does not fill the target window', 185003)"
[12:41] <jelmer> ChristopheT: Hmm, that bit is not expected actually
[12:41] <jelmer> ChristopheT, What version are you running?
[12:42] <SteveA_> LarstiQ: hi
[12:42] <ChristopheT> bzr 1.6b3, bzr svn 0.4.11exp0.  I will pull the lastest version of bzr-svn
[12:42] <jelmer> ChristopheT: This is most likely a regression in 0.4.11
[12:44] <ChristopheT> jelmer: I still eget the same exception
[12:44] <jelmer> ChristopheT, is this a public branch you're trying to push?
[12:44] <jelmer> ChristopheT: With 0.4.10?
[12:44] <SteveA> hi jelmer :-
[12:44] <SteveA> )
[12:45] <ChristopheT> jelmer: I am trying to push to svn+ssh://svn.forge.ocamlcore.org/svnroot/pa-do/trunk
[12:45] <jelmer> SteveA: Hoi Steve
[12:45] <ChristopheT> I have the rights to do so
[12:45] <jelmer> ChristopheT: What branch are you trying to push?
[12:45] <olleolleolle> jelmer: Hi, interested in bzr2svn here. SteveA said it'd be... useful.
[12:45] <jelmer> olleolleolle: Hi
[12:46] <olleolleolle> Thinking of using its API to avoid lotsa munging and collecting SVN metadata. bzr2svn could be a friend in that case, I hope.
[12:47] <jelmer> olleolleolle: What sort of metadata would you ike to gather?
[12:48] <jelmer> ChristopheT: What branch are you trying to push?
[12:48] <olleolleolle> "Gimme all the diffs from rev 0 to now," so I can visualize it nicely. I had started with "svnadmin dump" output.
[12:48] <jelmer> ChristopheT: Can you run with BZR_PDB=1 set?
[12:48] <olleolleolle> is bzr2svn a Tailor script?
[12:49] <ChristopheT> jelmer: I did a "svn co https://pa-do.svn.sourceforge.net/svnroot/pa-do" and a "bzr branch my-branch trunk"; can I just add, commit and push?
[12:49] <jelmer> olleolleolle: bzr-svn is a bzr plugin, there's also svn2bzr which is a python script
[12:49] <jelmer> ChristopheT, yeah, you should be able to
[12:50] <ChristopheT> jelmer: BZR_PDB=1: I am in the debugger.  Now what do I do?
[12:50] <olleolleolle> Thanks, jelmer.
[12:50] <jelmer> olleolleolle: Are you interested in the unified diffs as text or rather the semantical information?
[12:50] <SteveA> jelmer: my thought was, if they're working on visualizing revision history, then using bzr's API is going to be a good thing to use.
[12:51] <olleolleolle> (unified diffs as text, I think. I am kinda making a "terrain map of my code")
[12:51] <jelmer> SteveA: Ah, that makes sense
[12:51] <SteveA> jelmer: and, as it's reasonably easy to either convert a SVN repo to bzr format, or to interact with it using bzr-svn, then that makes it a good plan.
[12:52] <ChristopheT> jelmer: It starts with
[12:52] <ChristopheT> **** entering debugger
[12:52] <ChristopheT> > /home/trch/.bazaar.dev/plugins/svn/commit.py(539)commit()
[12:52] <ChristopheT> -> lock.unlock()
[12:53] <jelmer> olleolleolle,SteveA: Just running "bzr viz" on a Subversion repository should work
[12:53] <jelmer> ChristopheT, Can you pastebin the backtrace ("bt") somewhere?
[12:53] <SteveA> jelmer: I'm flying back to amsterdam shortly.  see you later.  olleolleolle's going to keep hacking on this here :-)
[12:54] <jelmer> SteveA: Ah, you're at EuroPython? Have a good flight
[12:55] <jelmer> olleolleolle: Are you looking to just browse the history of your project or actually generate a report with all the diffs, etc?
[12:55] <olleolleolle> generating a report, painting a picture, using that information, yep.
[12:56] <olleolleolle> Dumb q: When I install the bzr-svn plugin, is it enough to do "sudo python setup.py install"? Or is there a step I am missing?
[12:56] <ChristopheT> jelmer: .bzr.log: http://pastebin.com/d2a21fd36
[12:57] <jelmer> olleolleolle: No, that should be sufficient if you've also got bzr itself installed
[12:57] <olleolleolle> I installed bzr 1.5 using the Installeer for OS X 10.5.
[13:00] <jelmer> olleolleolle: You will also need to have the Python Subversion bindings (with several patches) installed if you're using a released version of bzr-svn
[13:01] <jelmer> This is a bit of a pain at the moment, but necessary because there are several bugs in the bindings that bzr-svn otherwise hits
[13:01] <olleolleolle> Oh, thanks. The reason I tried to avoid MacPorts was that... I have a functioning Python that I don't want to break. I'll go look for the bindings now.
[13:01] <jelmer> Alternatively, you can use the development version of bzr-svn which only requires the (vanilla) Subversion development headers are present
[13:02] <olleolleolle> Sounds good to me.
[13:03] <jelmer> ChristopheT, thanks
[13:25] <jelmer> blegh, annoying netsplits...
[13:25] <jelmer> ChristopheT, Hmm, doesn't help much determining what's wrong  :-/
[13:26] <uws> jelmer!!
[13:26] <uws> jelmer: je werd genoemd!
[13:26] <jelmer> uws!!1!!!!1!1!!ONEONE!
[13:27] <uws> jelmer: ging over bzr-svn en bzr mirror van gnome
[13:27] <poolie> hello uws
[13:27] <uws> hi poolie
[13:27] <jelmer> ah, cool
[13:27] <jelmer> hey poolie
[13:28] <uws> you're at europython?
[13:28] <jelmer> uws, is de beslissing al gevallen?
[13:28] <jelmer> uws, no, I'm in dublin
[13:28] <jelmer> uws, @ wilmers
[13:28] <jelmer> dinner
[13:28]  * uws at guadec
[13:29] <poolie> night
[13:31] <olleolleolle> http://people.samba.org/bzr/jelmer/bzr-svn/ Is the development version "trunk" or "bzr.dev" ?
[13:31] <olleolleolle> (Am looking for bzr-svn, still.)
[13:40] <a_c_m> support?
[13:40] <a_c_m> humm no bot then.
[13:40] <a_c_m> :)
[13:40] <kgoetz> sorry, i just filed a bug (which may be a dupe). if its a dupe hope one of you lot can pick it :)
[13:43] <kgoetz> 247270 (fwiw). ineternet connection just let the bug through :|
[13:46] <ChristopheT> jelmer: "doesn't help ...": anything else I can send you?
[13:46] <Odd_Bloke> a_c_m: Hi. :)
[13:47] <a_c_m> Odd_Bloke: hey, just formulating a massive message asking my question ;)
[13:47] <Odd_Bloke> a_c_m: Cool.
[13:48] <a_c_m> ﻿I have what i hope is a common situation that i'm looking for a nice solution for - which i hope bzr is. We are a small, but growing drupal development shop, So we depend on CVS updates from drupal.org. We also want to have our own mini versions of the core drupal.org CVS which our projects looks to as thier source e.g.    drupal.org --[updates]-->our drupal version--[updates]--
[13:48] <a_c_m> >our projects
[13:48] <a_c_m> is such a thing possible / easy to do?
[13:50] <james_w> hi a_c_m
[13:50] <a_c_m> hi james_w
[13:50] <james_w> at https://code.edge.launchpad.net/drupal launchpad provides an import of drupal CVS you could base your work on
[13:50] <james_w> you can also see branches other people have made based on that
[13:51] <james_w> what you could do is branch the main copy and make your changes, and then distribute that for your shop to base their work on
[13:51] <LarstiQ> poolie: I think there should be two mails to the list that need approval, could you approve them?
[13:51] <james_w> then every day or few days you can grab the latest from drupal CVS with "bzr merge lp:drupal"
[13:52] <a_c_m> james_w: exactly! so that when a new version comes out, we update our branch and test it, before pushing it out to the sub projects
[13:52] <james_w> that should work nicely
[13:52] <a_c_m> james_w: i think we will only ever take releases from the drupal.org upstream (is upstream the right term?), as otherwise it could become a lot of work
[13:53] <james_w> in that case you can just run "bzr merge" when upstream releases.
[13:53] <james_w> I don't know drupal's release strategy, do they release from trunk, or do they make branches?
[13:54] <a_c_m> james_w: branches... i think as trunk is waaaay ahead of where the stable release are
[13:54] <james_w> hmm, not sure how cscvs deals with branches
[13:55] <james_w> you may want to enquire about launchpad mirroring the stable branches as well for you, as that may suit you more
[13:56] <a_c_m> james_w: humm... wouldnt it be simpler just to import the drupal.org branch myself?
[13:56] <a_c_m> james_w: locally?
[13:57] <LarstiQ> olleolleolle: I'm currently a bit wound up, but if you want to grab me later to discuss things here at EP, you're welcome :)
[13:57] <james_w> a_c_m: possibly, I have no experience with importing CVS to bzr, and how painful or not it may be, so I thought that if launchpad could do it for you it may save you some work.
[13:58] <a_c_m> james_w: heh, fair enough - seems like somthing people might use too, drupal is quite popular ;) do you know who i would need to talk to?
[13:58] <olleolleolle> LarstiQ: sure
[13:58] <a_c_m> james_w: but also do you know any good tutorials on setting up that kind of staged upstream system?
[13:59] <jelmer> olleolleolle, http://people.samba.org/bzr/jelmer/bzr-svn/0.4
[14:00] <james_w> a_c_m: there are a couple of people that hang around here, but they are at the wrong end of the world for you at the moment I expect
[14:01] <a_c_m> k well i will hang about in here for a while, guessing the are US based right?
[14:01] <james_w> a_c_m: there is #launchpad, but I think one of the best ways might be a question on launchpad on the launchpad-bazaar project.
[14:01] <james_w> a_c_m: the best person to ask is actually antipodean, but one of the US guys might know
[14:02] <a_c_m> james_w: going to do some more reading and a bit of playing now - sink a few hours into it;)
[14:02] <james_w> kgoetz: hi, are you using a proxy by any chance?
[14:03] <kgoetz> james_w: i *shouldnt* be
[14:03] <lamont> bzr log foo/ --> shows me the initial import of the directory.  bzr log $(find foo/) gives me an error.
[14:04] <kgoetz> james_w: i dont seem to be ($http_proxy and $HTTP_PROXY are both empty)
[14:04] <lamont> so... how do I get a log of all the changes to all the files in a directory?
[14:04] <lamont> "iteration" is not the answer I want to hear
[14:06] <LarstiQ> lamont: I'd think bzr log foo/ would do that. Hmm.
[14:06]  * beuno has seen this discussion before, but can't remember the outcome
[14:06] <lamont> LarstiQ: that was also my foolish notion
[14:07] <markh> lamont: so what does it show for you?  Just a single log entry that reflects the initial import?
[14:07] <james_w> lamont: there is a long open bug about that
[14:08] <james_w> https://bugs.edge.launchpad.net/bzr/+bug/97715
[14:08] <lamont> markh: yep
[14:10] <a_c_m> james_w: seems like bzr-fastimport might be of use to me...
[14:10] <james_w> a_c_m: yup
[14:13] <ChristopheT> jelmer: I have this error "bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'lstrip'" when I do "bzr log --line" on a svn co (http://pastebin.com/d7e817d3c)
[14:17] <Odd_Bloke> beuno: Thanks for the speedy suggestions. :)
[14:18] <stewart>  anybody got an idea on why it takes 4 or 5 hours to push a mysql branch to launchpad? (even when it's my 2nd branch). Does launchpad not use a shared repo ?
[14:19] <pax> hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos...
[14:19] <pax> ?
[14:20] <thekorn> hi, I've once again a 'is it a bug or a feature'-question:
[14:21] <thekorn> when I do   bzr log -r -2..  i get the text of the last two changes
[14:22] <thekorn> when I run  bzr diff -r -2.. I get the diff from the last commit until now
[14:22] <beuno> Odd_Bloke, glad to help  :)
[14:22] <thekorn> for me it looks like inconsistency
[14:22] <uws> jelmer: No decision yet
[14:22] <awilkins> Could someone try pulling http://www.datadictionary.nhs.uk/software/dd-publish for me?
[14:23] <thekorn> so it looks more like a bug, any opinions?
[14:24] <hmeland> thekorn: Not sure I understand what you think is inconsistent, but log is a repository-querying command, while diff can peruse both repository and working tree.
[14:24] <james_w> stewart: no, it does not, there is development right now to make this much quicker
[14:24] <stewart> james_w: that'd be nice. as right now it's unusable for collaboration, 5+hrs is a long time.
[14:25] <james_w> hi thekorn, there is reasoning for this I believe, I'm just trying to dig it out of the depths of my brain.
[14:25] <thekorn> hmeland, ok, but this is something I as a user do not know, I expect '-r -2..' to return not confusing results
[14:26] <thekorn> james_w, hey, ok, thanks :)
[14:26] <james_w> hmeland: it's not due to the working tree, the effect is visible even with no uncommitted changes
[14:26] <hmeland> Ah, I didn't spot that you said "the last" on "diff -r -2..".
[14:26] <pax> hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos...?
[14:26] <james_w> hmeland: make it -r-2..-1 and you get the same discrepancy
[14:27] <james_w> pax: not currently, no
[14:28] <thekorn> my usecase is: a contributor tells me he changed something in his last two commits, so I run  bzr log -r -2..  to see his messages,
[14:29] <thekorn> and after this I would like what he changed, so I intuitively run bzr diff -r -2..
[14:29] <hmeland> I still think the repository-only/repository-and-tree difference is relevant, though.
[14:30] <james_w> thekorn: yeah, I can't remember the reason, sorry. I imagine that if you change this you get some weirdness showing up elsewhere
[14:31] <hmeland> Say you commit a change, push it, then decide you want to revert it.  You bzr revert, but want to verify that your tree now really doesn't have any differences wrt. how it looke before the erroneous commit.  What options should you give to bzr diff?
[14:31] <james_w> though I do think having log not show the start of the range would be reasonable.
[14:32] <james_w> hmeland: "bzr diff -r-2.." isn't it?
[14:32] <hmeland> james_w: So "bzr log 1.." shouldn't show the first commit message?
[14:32] <james_w> hmeland: correct
[14:33] <james_w> that's one thing that would be weird at least
[14:33] <james_w> thekorn: you could file a bug, I have a hunch it would be closed, but at least you would get a reason :-)
[14:33] <thekorn> :)
[14:34] <thekorn> ok, will do
[14:34] <thekorn> thanks hmeland and james_w
[14:35] <hmeland> james_w: Yes, exactly -- "diff -r -2.." gives you the diff from *just before* the most recent commit until the current tree state.
[14:35] <thekorn> atleast it is maybe a documentation issue: both help (bzr help diff and bzr help log) are refering to "help revisionspec"
[14:36] <thekorn> and a difference is not mentioned there
[14:36] <james_w> yeah, mention that in the bug
[14:37] <james_w> revisionspec mentions nothing about ranges as far as I can see, and the individual command should probably mention how they interpret the range
[14:39] <awilkins> Anyone serve Bazaar repos from IIS?
[14:41] <hmeland> revisionspec says that "-2 is the second-to-last commit", and bzr help diff says that "bzr diff -r1..2" is the difference between rev 2 and rev 1.  Doesnt that infer that "diff -r-2..1" is the difference between the second-to-last commit and the current tree, i.e. for an unmodified tree the changes introduced by revision -1?
[14:41] <hmeland> I think there's something I'm not getting here... :-)
[14:42] <hmeland> Sorry, s/-r-2..1/-r-2../
[14:43] <radix> hmeland: when you leave off the second revision, it means "the state of the working tree"
[14:43] <hmeland> Yeah, hence my "for an unmodified tree" reservation.
[14:43] <radix> but if you use -1, it means "the most recent revision", so the distinction is whether it includes uncommitted changes
[14:43] <radix> hmeland: what you said sounds right
[14:44] <ToyKeeper> hmeland: If you want the diffs from the past two revisions, try -r-3..-1 instead.  (it's off by one)
[14:45] <radix> yeah, "the difference between the second-to-last revision and now" won't include the change that *caused* the second-to-last revision
[14:46] <hmeland> I'm just trying to understand why people think the difference in the amount of revisions included in the reports "bzr log -r -2.." vs "bzr diff -r -2.." is a bug.
[14:46] <hmeland> They both appear sane to me.
[14:50] <awilkins> I like the way .pack files are named for their md5sum
[14:51] <awilkins> Ok ; I'm trying to dumb-serve a repo from IIS ; why am I getting "Expected a boundary" errors
[14:51] <awilkins> Expected (q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl) line, got '--<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>
[14:51] <awilkins> It looks really close, anyone know what the problem is?
[14:51] <james_w> awilkins: is there a proxy involved?
[14:51] <stewart> question: how come i'm getting moved files reported as removed and added?
[14:52] <awilkins> james_w: If you wget the file, it matches it's MD5
[14:52] <stewart> more importantly, how will this affect merges
[14:52] <james_w> stewart: did you move them with "bzr mv"?
[14:52] <stewart> james_w: i think so... but may have accidently run "bzr add" on them...
[14:52] <ToyKeeper> hmeland: Since log shows 3 revs worth of changes and diff shows 2, it could be considered confusing.
[14:52] <awilkins> james_w: There is a proxy, probably
[14:52] <stewart> james_w: (after having bzr mv)
[14:52] <awilkins> james_w: I am not privy to the secret machinations of the NHS network provisioning team
[14:53] <stewart> james_w: any way to retro-actively bzr mv (i haven't committed yet)
[14:53] <james_w> stewart: if you used "bzr mv" first then "bzr add" wouldn't have done anything
[14:53] <james_w> stewart: try "bzr mv --after"
[14:53] <james_w> stewart: if that doesn't work then "bzr rm --keep" the new name and then "bzr mv --after"
[14:54] <james_w> awilkins: I'm thinking of https://bugs.edge.launchpad.net/bzr/+bug/198646
[14:54] <james_w> awilkins: bzr is used in the NHS? :-)
[14:54] <awilkins> james_w: Well, the project isn't finished yet, but yeah, I guess it is.
[14:55] <awilkins> james_w: I'm going to add it to the Hall of Fame when I get a sign-off on this project
[14:55] <stewart> james_w: seems to be working, thanks!
[14:56] <james_w> awilkins: cool
[14:56] <awilkins> james_w: bzr AND bzr-eclipse :-)
[14:56] <james_w> stewart: did you have to "rm"/
[14:56] <stewart> james_w: yes, did have to "rm --keep" and then mv --after for each one
[14:56] <james_w> stewart: good to know, thanks.
[14:57] <awilkins> james_w: Plus bzr-gtk (local branch thereof)
[14:57] <awilkins> james_w: We're using my home-built 1.6b2 ATM because it's so much faster than 1.5
[14:57] <awilkins> james_w: But I've been tracking the tip of many things ....
[14:59]  * CardinalFang waves to guilhembi.
[15:00] <guilhembi> Hi CardinalFang , but what's a Fang?
[15:01] <CardinalFang> guilhembi, The name is a Monty Python reference.  It seemed fitting in #python a few years ago.
[15:05] <hmeland> ToyKeeper: I see your point, but I don't think it holds up; for example, I find it entirely reasonable that "bzr log -r1..1" reports one revision, while "bzr diff -r1..1" reports no changes.
[15:20] <rockstar> LarstiQ, I am now.
[15:22] <jam> a_c_m: By the way, if you are trying to use Bazaar + Drupal, they do have conversions available: http://drupal.org/node/45368
[15:24] <a_c_m> jam: thanks... but thats just head, which is version 7 atm... were working with version 5, so its not so helpful. But i think bzr does hold the key - i just created a test local repro, added one of our sites and then updated it to a new version of drupal, by hand - without bzr missing a beat (unlike SVN which just wont do it).
[15:46] <a_c_m> james_w: just asked in #launchpad :)
[15:58] <awilkins> Gah, this is SOO annoying
[15:58] <awilkins> I'm trying to dumb-serve a bzr repo out of IIS. Through a debugging proxy, chained to our main proxy, it works fine
[16:00] <awilkins> Heh, ISA works, FreeProxy doesn't
[16:01] <awilkins> MS finally does something right
[16:01] <ToyKeeper> hmeland: Yeah, I don't claim the diff/log behavior is wrong, but I can see why someone might find it confusing.
[16:05] <mtaylor> if I do bzr log --gnu ... and I get "no such option gnu" for some people, but it works for me.
[16:05] <mtaylor> where is the --gnu coming from?
[16:05] <awilkins> mtaylor: A plugin that overrides the log options?
[16:05] <mtaylor> hrm.
[16:05] <awilkins> mtaylor: The help should list the option and which plugin it comes from
[16:06] <mtaylor> :)
[16:06] <mtaylor> howabout the gnulog plugin
[16:36] <ChristopheT> Something is strange.  When I do  bzr.dev merge https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/
[16:37] <ChristopheT> I get: "Nothing to do."
[16:37] <ChristopheT> But when I try: "bzr push https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/"
[16:37] <ChristopheT> it replies with the error: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
[16:38] <luks> umm, push over https?
[16:38] <luks> oh, it's svn
[16:38] <james_w> what does "bzr missing https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" tell you?
[16:40] <kiorky> yo guys, does bazaar supports something like in-working-copy-branches from git or namedbanched "ala" mercurial?
[16:41] <luks> no, but it does support branches without working trees, and a way to switch a working tree to a different branch
[16:44] <ChristopheT> james_w: "bzr missing" tells me that I have 3 extra revisions (basically merges from that repo).  So I guess I branch from https://pa-do..., merge in my revisions and pull, right?
[16:44] <kiorky> lazy1: so if i have a/ as a bazaar repo, it has two branches 1/ and 2/ , a/ can be switch on 1 and 2, so why isnt that different from  "in-working-copy-branches"?
[16:44] <kiorky> s/lazy1/luks/
[16:45] <ChristopheT> s/pull/push/
[16:45] <kiorky> luks: the prolem i got is that mercurial deceived me with the namedbranches :p, i cant delete them, i cant rename them
[16:45] <james_w> ChristopheT: if you have 3 extra revisions then push should not say that have nothing to do
[16:45] <james_w> maybe there's some interaction with svn that I'm not getting though
[16:46] <james_w> kiorky: it looks pretty similar to working-copy-branches, but you do have external branches
[16:46] <ChristopheT> james_w: it is "merge" that says "nothing to do".
[16:46] <james_w> the distinction matters to some people, not others
[16:46] <james_w> ChristopheT: ah, sorry.
[16:47] <james_w> ChristopheT: ok, so you shouldn't be told that they have no common ancestor, again unless there is some bzr-svn subtelty I am missing
[16:47] <kiorky> james_w: the use case is integration with svn, i want to have in my repo the svn branch, and features branches
[16:47] <james_w> ChristopheT: but your solution should work
[16:48] <kiorky> james_w: can the rbranches be local, i mean: can the branches not be pushed on a central repo ?
[16:48] <james_w> kiorky: absolutely.
[16:48] <kiorky> whow !=
[16:49] <kiorky> features i miss on mercucrial :)
[16:49] <kiorky> james_w: now, for the integration with the existing stuff i have. Is there something to do as the mercurial forest extension to organize a bunch of repos
[16:50] <james_w> I'm not familiar with forest
[16:50] <kiorky> ok
[16:50] <kiorky> let me a moment
[16:50] <kiorky> james_w: Overview
[16:50] <kiorky> The Forest extension allows operations on trees with nested Mercurial repositories, called forests. Those to some degree correspond to multi-project CVS/Svn/... repositories.
[16:51] <neobug> kiorky: I don't see why you should push branches to the central place in mercurial
[16:51] <kiorky> james_w: you have a tree with sub mercurial repos, that you can serve, this solve the partial checl out problem for example
[16:51] <james_w> ah, I got it
[16:51] <james_w> no, bzr doesn't have that yet
[16:51] <neobug> doesn't it depend on the style the developers are using the mercurial?
[16:51] <kiorky> neobug: if you make named branches, they are pushed
[16:51] <neobug> oh
[16:51] <ChristopheT> james_w: Ack! "bzr.dev branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" starts downloading the revision bu then tells "bzr: ERROR: The branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/ has no revision None."
[16:52] <neobug> I probably missed this detail
[16:52] <james_w> ouch
[16:52] <ChristopheT> james_w: .bzr.log: http://pastebin.com/d5fbaed93
[16:53] <kiorky> neobug: :), frustrating isnt it ?
[16:54] <kiorky> neobug: do not try the localbranch extension it is quite unusable
[16:54] <james_w> ChristopheT: not sure what's causing that. It's an odd level to get that message from though
[16:54] <neobug> well, I haven't used named branches so it's hard to say :-)
[16:55] <kiorky> james_w: so how can you organize large repo?
[16:55] <kiorky> james_w: my structure is there for example : http://hg.minitage.org/
[16:56] <ChristopheT> james_w: Worth to file a bug?
[16:56] <james_w> ChristopheT: probably
[16:56] <james_w> kiorky: you mean how should it be organised without an equivalent to the forest extension?
[16:57] <kiorky> james_w: yep
[16:57] <kiorky> james_w: i m used to have tree based organization
[16:57] <kiorky> james_w: so i dont know how to make in an other way
[16:57] <james_w> kiorky: I'm not sure, unfortunately if you require the forest-like behaviour you are pretty stuck
[16:58] <james_w> you can make each of those in to branches fine, there is just no way to grab the top level and get them all, say.
[17:01] <kiorky> james_w: ok, tahts not a problem
[17:01] <kiorky> james_w: i just want to organize/have partial checout
[17:01] <kiorky> james_w: but then, how can i make a branch of a sub branch?
[17:04] <james_w> you can make separate branches in the same way as you have separate repos in hg, you just can't define the structure like you can with forest
[17:04] <james_w> it has to be done up front though, there's no partial checkout facility either
[17:05] <semslie> I've managed to leave bazaar in a locked state by killing the gcommit process before actually committing. Is there a way to unlock it?
[17:06] <gour> semslie: bzr break-lock?
[17:07] <semslie> gour: thanks!
[17:11] <kiorky> james_w: i will try to get a tree structure this evening
[17:12] <Jc2k> lifeless: ping
[17:15] <ToyKeeper> Oh, that reminds me...  I was having gcommit issues I should take a closer look at.
[17:16] <ToyKeeper> ... or not.  Works fine after pulling updates.
[18:10] <cyberix> Is there a transport neutral way to find out whether some path is pointing to a directory or just an ordinary file?
[18:11] <cyberix> local transport has _check_mode_and_size, but that's just the local transport
[18:58] <alecwh> One of our team members pushed to our repository, in Launchpad, but he didn't have the latest changes to begin with. When he attempted to push (after he commited his changes, he had 3 commits), the branch warned him that he needed to "merge", so he did this: "﻿bzr merge lp:phpns". Now I want to undo what he did. How?
[18:59] <james_w> alecwh: he pushed after?
[18:59] <alecwh> Sorry, he didn't push, he just did a "merge"
[18:59] <james_w> and commit?
[18:59] <alecwh> He TRIED pushing
[19:00] <alecwh> yes
[19:00] <alecwh> 3 commits.
[19:00] <alecwh> here is the repo: https://code.launchpad.net/~phpns-team/phpns/head
[19:01] <james_w> hmm, I'm not sure I understand, you're trying to fix that branch, or just the one on this developer's machine?
[19:02] <alecwh> we're trying to fix the branch. It looks like we lost several commits from me.
[19:02] <alecwh> We just want to "revert" to before he merged.
[19:02] <alecwh> so everything will be normal again.
[19:03] <james_w> so he did push after?
[19:04] <alecwh> let me check.
[19:04] <james_w> is "	kyle's EE in. Ready for packaging (if no more fixes)" the revision that you had as the tip beforehand?
[19:04] <alecwh> Yes, I believe so!
[19:05] <james_w> cool, if you have a branch locally you can do this:
[19:05] <james_w> if you run "bzr log -r -1" then you will see your revisions merged in, the number of the top one of these (the indented ones) should be 26.1.4
[19:05] <alecwh> I have a copy of the branch (the one with the merge) on my desktop
[19:06] <james_w> so, if you run "bzr pull --overwrite -r 26.1.4 ." then it will put your copy of the branch back on that revision.
[19:06] <james_w> If you then run "bzr log" you should see it as it was before.
[19:07] <james_w> you can then push that back to lp:phpns. However, it won't let you do that as you have changed history, so you need to pass --overwrite there as well.
[19:08] <james_w> You should check that you have what you want locally before you push though. The situation wouldn't be unfixable, but it's better to catch it early
[19:09] <james_w> once your happy with that I can help you get the other developer's changes merged properly
[19:12] <olleolleolle> LarstiQ: Eh, are you still in the... room?
[19:12] <olleolleolle> No.
[19:13] <alecwh> james_w: okay, I just pushed the changes with --overwrite, but it isn't showing up on Launchpad. This is just lag, right?
[19:13] <alecwh> it did say "Pushed up to revision 30."
[19:13] <james_w> yeah, I think so
[19:13] <alecwh> that worked great then!
[19:13] <james_w> do you understand how the other developer should have merged to avoid this?
[19:14] <alecwh> Okay, now, that developer (Kyle) still has those 3 commits we want to put in
[19:14] <alecwh> james_w: no, how?
[19:15] <james_w> ok, so with this style of development each developer should keep a mirror of trunk on their machine that they only run "bzr pull" in normally (using a shared repository will make this very cheap for them).
[19:16] <james_w> they then have at least one other branch that they do their work in. You can have loads, or you can just have one, it works the same.
[19:16] <james_w> when you are at a stage where you want to push your work to launchpad you "cd ../trunk; bzr merge ../my-branch"
[19:17] <james_w> this merges in all your changes, you fix up any conflicts and then commit
[19:17] <alecwh> okay.
[19:17] <james_w> you can then push directly to launchpad
[19:18] <james_w> the chances of colliding with someone else when doing this are very small, but if it keeps happening then there are ways to avoid it, but it's probably better to keep it simple for nwo
[19:18] <james_w> this means that you only ever have merge commits on the trunk, and my work doesn't "swallow up" your work like just happened
[19:19] <james_w> I can help you to do this for the three commits if you like, as you won't be able to see them in your branch at the moment
[19:19] <alecwh> so, assuming the branch is now fixed (merge was removed), I think I'll have HIM clone the branch, and just copy over his "changed" files (because he still has a copy of that merged branch that we fixed), and just commit/push
[19:19] <alecwh> there is no need to branch, because it's all tested and fine.
[19:20] <james_w> that would work, but we can preserve history if you would like
[19:20] <alecwh> okay, but those 3 commits he made are gone from the LP repo, correct?
[19:21] <james_w> they'll still be in the repo, but won't be visible, and won't be copied in when grabbing the code
[19:21] <james_w> bzr doesn't delete revisions, even if you do something like we just did. It's a small cost.
[19:22] <james_w> I mean it's a small cost that they are there even though they are not needed to have some safety about not losing them.
[19:22] <alecwh> okay, can we get those "visible" as concurrent revisions? So, his would be revs 31, 32, 33?
[19:23] <james_w> yes, that's a "rebase" operation. You would need a plugin to do that.
[19:23] <james_w> I can easily tell you how to resurrect them and then merge them so they would just be rev 31, but would show as merged revisions still
[19:23] <alecwh> Hm, I think it would be easier with what I said above
[19:24] <alecwh> james_w: okay
[19:25] <james_w> ok, so first we need to pull his commits out in to an old branch.
[19:25] <alecwh> so, I need to grab the last commit before he made his?
[19:25] <james_w> For this we will need the revision id of the tip when the branch was messed up. we need the revision id as the revisions are no longer present in the history of your branch, and so won't be given revision numbers.
[19:26] <james_w> I just so happen to have the relevant id here: k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8
[19:26] <james_w> so if you run "bzr branch -rrevid:k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8 your-branch/ new-branch/
[19:27] <alecwh> okay, great. This will give me the branch before we fixed it?
[19:27] <james_w> then run "bzr log" in "new-branch/" you will see the branch being back to it's broken state
[19:27] <james_w> yes, exactly.
[19:28] <james_w> now you can "cd ../your-branch; bzr merge ../new-branch"
[19:28] <alecwh> Branched 29 revision(s).
[19:28] <james_w> once you commit you can examine "bzr log" to see what this looks like
[19:29] <james_w> when you are happy you can again push, and you won't need the --overwrite here, as you didn't modify history, just appended to it.
[19:30] <alecwh> what does:  M* inc/config.php
[19:30] <alecwh> mean?
[19:30] <alecwh> the *
[19:30] <james_w> permission change I believe
[19:30] <james_w> a "bzr diff" should say
[19:31] <james_w> "bzr help status-flags" mentions it
[19:32] <alecwh> alecwh@alecwh-laptop:/var/www/websites/phpns_2.2.3$ bzr push lp:phpns
[19:32] <alecwh> Pushed up to revision 31.
[19:32] <alecwh> james_w: you are a life saver! Thanks so much, seriously, this fixes everything
[19:33] <james_w> great, glad to be of help
[19:43] <sm> I'm so confused.. might there be a page describing PQM and Bundle Buggy ? who develops them, who uses them and how they relate to each other ?
[20:08] <Klaas111> hi all
[20:08] <jasper> When I send patches to bzr-gtk@lists.canonical.com the right target_branch is not set (see bzr-gtk mailing list today). Maybe someone knows how to improve the given answer of setting ~/.bazaar/locations.conf?
[20:08] <Klaas111> hoping that dummy questions are ok here
[20:09] <jam> jasper: I think you want to not set "...:policy=appendpath"
[20:09] <Klaas111> I'm using bzr with bzr-svn because I'm tied to a svn repo
[20:09] <jam> I hope you can see that through the smiley
[20:09] <jasper> what smiley :)
[20:09] <jasper> Ok, I'll try
[20:09] <Klaas111> there's a couple of config files that are part of the project (checked in)
[20:10] <Klaas111> but I'd like to have local modifications without checking them in and annoying my colleagues.
[20:11] <Klaas111> what's the proper way to do this? that is, without having to manually exclude them each time, or move them away
[20:13] <MvG> jelmer: Yet again I'm trying to pull from the inkscape repo using bzr-svn, and every day there is something new. As the delete item bug has been fixed now I get a loop in "finding branches 2/3". The progress bar stays fixed most of the time, but occasuonally it jups back 7 chars and fills those up to the previous position. Seems like there was no progress. Can I provide any useful debug information here?
[20:16] <jasper> Jay!, had to work around some local testing cruft, but I now have ' target_branch: https://code.launchpad.net/~bzr-gtk/bzr-gtk/trunk'. Is this ok, or should I loose the trunk bit?
[20:18] <jam> I'm curious why that is the recommend URL, versus http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk or https:/code.launchpad.net/bzr-gtk, or any of the multitude of ways of referring to that branch.
[20:18] <jam> But that is between BB, abentley, and the bzr-gtk group :0
[20:20] <jasper> True.. but with the locations.conf file I don't have to worry about it anymore. I can just use 'bzr send -o bla.patch' again
[20:33] <jasper> jam: thanks for the help! I have written a mail with the (I hope) proper workflow to the list
[20:37] <jasper> So, what are the chances for a bzr-gtk release in the near future?
[20:38] <beuno> jasper, I believe jelmer plans to release this week
[20:38] <beuno> and, also, I believe I promised I'd review patches
[20:38] <beuno> which I haven't been able to yet  :/
[20:39] <jasper> time or access rights?
[20:39] <beuno> time, unfortunetly
[20:39] <beuno> access rights is much easier to fix  :)
[20:40] <radix> oh, sweet, rc2!
[20:40] <radix> ahhh, I need to switch to a new PPA
[20:42] <jasper> beuno: only the queued ones on BB or the whole bunch recently merged?
[20:43] <beuno> jasper, just the queued ones, the other are, well, already merged  :)
[20:45] <jasper> well.. I know of 4 easy one liners in the queue :)
[20:46] <beuno> jasper, yeah, hopefully I'll have some time tonight
[20:56] <Odd_Bloke> sm: I dunno if you're still around, but if you have a more specific question about BB/PQM, I could try answering it.
[20:56] <sm> thanks Odd_Bloke
[20:57] <sm> are these two parts of one system, or two competing/complementary systems ?
[20:57] <sm> both come from within canonical I assume
[20:58] <sm> or maybe one came from canonical/launchpad, and one from bzr ?
[20:58] <Odd_Bloke> sm: They're complementary.
[20:59] <Odd_Bloke> sm: Neither come from Canonical, originally.  BB is Aaron Bentley's creation, so that a bzr background.
[21:00] <Odd_Bloke> sm: PQM comes from Arch/Baz, so does have some Canonical involvement.
[21:00] <Odd_Bloke> That's about as much of the history as I know.
[21:00] <sm> that helps reduce my confusion, thanks
[21:00] <james_w> hey Odd_Bloke
[21:01] <sm> I think currently both are used by basically two teams - launchpad and bzr
[21:01] <james_w> they don't have any direct interaction currently, but they could, it would be good to have, and it might well happen.
[21:01] <james_w> I'm not sure that launchpad use BB for their development
[21:01] <Odd_Bloke> sm: bzr certainly use both.
[21:02] <Odd_Bloke> james_w: Hi. :)
[21:02] <jam> james_w: They don't use BB, afaik
[21:02] <james_w> hey jam
[21:02] <jam> They *do* use PQM
[21:02] <jam> they actually use a coordination point of a wiki
[21:02] <james_w> Odd_Bloke: nice patch flood :-)
[21:02] <jam> I don't know if they are dogfooding the Launchpad review queue
[21:02] <jam> stuff
[21:02] <jam> I know they want to get away from a wiki where they post changes to be reviewed, etc.
[21:03] <sm> and basically PQM handles background pre-commit testing, and BB provides a web/email interface for patch review & voting, would that be right ?
[21:03] <jam> sm: There are several Bazaar projects (bzr-gtk, bzr, pqm, etc) that are using Bundle Buggy. But it was pretty much just developed because we were getting too many patches to have a simple mailing list keep us from dropping stuff.
[21:03] <jam> So Aaron basically codified our working practice around the mailing list
[21:04] <jam> presenting a nicer UI, etc.
[21:04] <jam> sm: correct
[21:04] <sm> and both are available for other projects to use ?
[21:04] <Odd_Bloke> james_w: Thanks. :)
[21:05] <Odd_Bloke> sm: Yes, both are GPL, I believe.
[21:05] <sm> great.. much clearer, thanks for the answers
[21:05] <sm> one more I guess, have y'all found them to help a lot ?
[21:06] <jasper> from a 'user' perspective, BB looks like a great system
[21:06] <Odd_Bloke> BB is great.
[21:07] <Odd_Bloke> I'm spending the summer working on getting PQM somewhere up to that standard.
[21:09] <james_w> sm: BB has definitely helped with the process I would say
[21:10] <james_w> I don't have PQM rights to know if it's a pain at the moment, but it does give something to the project, similar to what you get if you start using continuous integration in a project.
[21:10] <hmeland> Hmmm.  In my bzr.dev mirror branch, when I do "bzr log dir-or-file", the output always includes a few revisions, no matter which directory or file I supply.  Are anyone else seeing anything similar?
[21:12] <james_w> extra revisions? the same revisions every time?
[21:13] <hmeland> Yup, apparently... I'll pastebin, hold on.
[21:13] <Odd_Bloke> It's hard to imagine how the bzr project would function without BundleBuggy.  Without PQM, we'd just have to have a human patch queue manager.
[21:16] <sm> Odd_Bloke: why not just post/discuss/vote on patches on the mail list, and merge by one or more human gatekeepers when appropriate ?
[21:16] <sm> like eg the linux folk ?
[21:16] <sm> just curious
[21:17] <sm> that's what I do in my smaller project, but I'm wondering how to make the process more robust
[21:17] <sm> I guess so that you can handle a greater volume of patches without confusion
[21:18] <luks> sm: it's easy to miss patches that way
[21:18] <Odd_Bloke> sm: Well, BundleBuggy helps to make sure things don't get lost.
[21:18] <Odd_Bloke> Heh.
[21:18] <hmeland> james_w: http://pastebin.ca/1068483
[21:19] <james_w> hmeland: sorry, pastebin.ca doesn't work for me, can you use another?
[21:21] <hmeland> I first tried pastebin.com, but my output tripped their spam filter... any others you'd recommend?
[21:22] <Odd_Bloke> ubottu: paste
[21:22] <Odd_Bloke> hmeland: ^
[21:24] <hmeland> http://paste.ubuntu.com/26528/
[21:27] <james_w> so there's a problem with directories that it normally only shows the revision in which the directory itself was created
[21:28] <james_w> I guess here they may be some funky stuff going on in early history that mean that you get multiple entries
[21:28] <james_w> though some of it isn't that old
[21:28] <hmeland> I know about the non-recursive directory log thing.
[21:30] <hmeland> I'm more worried about the revisions that get printed for both contrib/ (line 1-55) and bzrlib/ (line 56-109).
[21:30] <MvG> jelmer: I added some mutters to repository.py and now found out what inkscape was doing here. I got it to print, among others, the value of bp in the loop in SvnRepository.find_tags. While I pull from inkscape/trunk (relative to the root of the repo), it seems to examine not only inkscape/tags/* but */tags/* for possible tags. And as that is a lot of unrelated history, this operation seems to take quite a while. Wouldn't it make sense to try determine
[21:31] <hmeland> But, is this only something that I'm seeing here, or are others getting similar output?
[21:31] <MvG> jelmer: Sorry, of course that's bzr-svn doing that, while pulling inkscape, not the other way round.
[21:32] <hmeland> I've tried with --no-plugins, btw -- and saw no difference from what's on the pastebin.
[21:59] <jasper> I just upgraded bzr to 1.6b2, and just as in 1.5 I get SmartTCPServerHooks deprecation warning when checking out from lp. Do I have to remove some conf foo somewhere?
[21:59] <james_w> jasper: do you get it with --no-plugins
[22:00] <jasper> no, but the lp: functionality is gone too in that case
[22:01] <jasper> old bzrtools version?
[22:01] <Odd_Bloke> jasper: What does 'bzr plugins' show?
[22:02] <jasper> avahi 0.3.0dev0, bzrtools 1.5.0, gtk 0.95.0dev1 launchpad
[22:02] <jasper> hmm.
[22:02] <jasper> must be the launchpad plugin
[22:02] <Odd_Bloke> jasper: It'll be avahi.
[22:02] <jasper> doh :P
[22:03] <Odd_Bloke> I think the latest trunk has the fix.
[22:03] <jasper> you are right
[22:10] <jasper> hmm.. 'bzr checkout lp:bzr-avahi avahi' in ~/.bazaar/plugins/ now gives me 'Unable to load plugin 'avahi' from (..)' messages
[22:11] <james_w> -Derror will tell you why
[22:11] <james_w> perhaps that you need bzr-dbus
[22:19] <jasper> seems there is a server_mainloop missing from dbus according to avahi
[22:21] <jasper> more importantly, the MainloopThread from server_mainloop
[22:33] <james_w> jasper: yup, you need a different branch of bzr-dbus for latest -avahi
[22:33] <james_w> apparently revision 32 of -avahi will work with the trunk of -dbus
[22:35] <jasper> Ok.. thanks. But since I don't think I'll use both I'll just move them out of the way for now
[22:37] <jasper> on a different note, I made bzr 1.6b2 bork with MemoryError >:) (bzr checkout lp:mysql-server/6.0 on a P4 2.4 GHz, 512mb ram)
[22:47] <poolie> good morning
[22:48] <poolie> jasper: if that was pulling over bzr+ssh you should try using sftp instead
[23:02] <jasper> I'll try with sftp another time. Time to go now. Bye all.
[23:23] <RAOF> It seems the gstreamer project will be moving from cvs to $DVCS.  Currently the sole contender is git, because there are a couple of people who will actually do the migration/support work for git.  Is this interesting to anyone here? :)
[23:24] <jam> poolie: guess what... I get more conflicts if I don't sort the merges by their ancestry order when inserting into the weave
[23:25] <jam> poolie: So it seems that the dependency ordering into the weave file really does matter
[23:25] <jam> poolie: of course, my test case keeps breaking when I fix other things because suddenly topo_sort emits the revisions in a different order
[23:26] <jam> (It will return the right parent first, if the right parent has no more ancestry, otherwise it returns the left parent first)
[23:27] <AfC> RAOF: you might send that in a brief email to the mailing list. There are a lot of people travelling right now. "Possible opportunity to advocate Bazaar to GStreamer" or something like that.
[23:34] <pygi> RAOF, we can help with the bzr questions, sure
[23:38] <AfC> pygi: it doesn't sound like there are going to BE any bzr questions. :(
[23:39] <pygi> RAOF, does anyone from Gst community uses bzr?
[23:40] <LarstiQ> pygi: some people at Fluendo afaik, although not Thomas himself
[23:41] <pygi> LarstiQ, we can't really push for bzr outside
[23:41] <pygi> it has to be done inside, we can only be a helping force
[23:41] <LarstiQ> pygi: they're pretty much in the Gst community
[23:41] <pygi> well, I know, thus make them push for bzr, and we can eventually help them :P
[23:42] <LarstiQ> we actually talked about that today
[23:42] <RAOF> There are certainly people on the gstreamer list who express a preference for bzr, and more who are concerned about git's poor windows support
[23:43] <RAOF> The stated preference for git is because someone has volunteered to actually do the migration/answer questions, and a desire to move away from cvs _now_.
[23:45] <LarstiQ> RAOF: I'm pretty sure we can help with migrations.
[23:45] <pygi> and we can answer the questionss
[23:45] <RAOF> That's what I was thinking, reading the discussion.
[23:45] <LarstiQ> RAOF: considering other migration help with mysql and gnome in the recentish past.
[23:46] <Peng> beuno: Ping?
[23:46] <beuno> Peng, at your service
[23:46] <Peng> beuno: Just a random Loggerhead idea that I wanted to throw out there.
[23:47] <beuno> shoot
[23:49] <Peng> It isn't necessarily a good idea, but anyway... Currently, when you visit /some/branch/, you get redirected to /some/branch/changes. It might be neat if Loggerhead showed a regular directory listing just like the web server would, with a link to the changes view.
[23:50] <beuno> Peng, right, the Files view
[23:50] <beuno> there has been some discussion around what's the best default
[23:50] <Peng> Ah, I forgot about that. I meant an actual directory listing of the directory, not the Bazaar data.
[23:50] <Peng> My use case is that I serve my branches at /bzr/some/branch/, and have Loggerhead at /loggerhead/some/branch/. I occasionally throw up a file or two in the branch directories (usually a 'bzr send' patch), and am wondering...I dunno.
[23:51] <beuno> ah, I see
[23:53] <beuno> well, I personally don't have a use case for it, but I can see why you would want that
[23:53] <beuno> I don't think it would be too hard
[23:53] <beuno> and since I want to be able to serve branches from LH, directory listings will be needed on the logic
[23:53] <beuno> so, feel free to file a bug requesting it
[23:55] <poolie> jam, hi
[23:55] <poolie> interesting
[23:55] <jam> poolie: and that's not all.... :(
[23:55] <jam> It seems the ordering I "happened" upon in my earlier patch is the most optimal
[23:56] <jam> but it isn't quite anything as far as I can tell
[23:56] <jam> I'm still investigating
[23:56] <jam> I had a bug in one of my functions
[23:56] <jam> so it wasn't returning things in the order I thought it was
[23:56] <jam> and then I was using tsort
[23:56] <jam> and combined, that gives the fewest conflicts
[23:57]  * jam is quite sad that non-deterministic ordering was winning