[03:59] <lszyba1> hello, I did:  bzr tag -r 77 datahub-release-0.7  now how do I push this to launchpad?
[03:59] <lszyba1> Do I have to recommit and push? "No new revisions to push."
[04:02] <spiv> lszyba1: no, the push worked
[04:03] <spiv> lszyba1: the message is confusing (there's a bug open about that), but the tag will have been pushed.
[04:04] <spiv> lszyba1: $ bzr tags -d lp:datahub
[04:04] <spiv> datahub-release-0.7  77
[04:05] <spiv> lszyba1: so you can see the tag is there :)
[04:06] <spiv> (bug 164450 appears the bug number)
[04:16] <lszyba1> thanks, is there a command to list tags  bzr lstags  ??
[04:16] <bob2> just 'bzr tags'
[04:16] <lszyba1> bzr tags ..found it
[04:17] <lszyba1> thanks,,updated my manual..http://lucasmanual.com/mywiki/Bazaar
[04:20] <lszyba1> anybody knows if launchpad shows tags anywhere?
[04:24] <spiv> Not that I know of.
[04:32] <jfroy|work> jelmer: ping
[04:33] <jelmer> jfroy|work, pong
[04:33] <jfroy|work> jelmer: OK, so I thought I understood, but bzr-svn (or me) just did something I'm not sure I understand.
[04:34] <jfroy|work> Basically, what are you supposed to do again when bzr pull from the subversion branch tells you the branches have diverged? I did a merge, commit, push operation.
[04:35] <jfroy|work> And although that mostly worked, bzr-svn committed, as far as I can tell, the same set of changes that someone else had committed via svn (which caused the branches to diverge in the first place).
[04:35] <jfroy|work> Is that expected, or did I do something wrong?
[04:35] <jelmer> jfroy|work, yes - see the bzr-svn FAQ
[04:36] <jelmer> you may want to use bzr rebase rather than merge
[04:36] <jfroy|work> Ah right, I remember that...
[04:37] <jfroy|work> Hum, I see, I forgot I wasn't working with a Subversion checkout, but rather a branch
[04:37] <jfroy|work> (since committing on a checkout is broken in 1.9)
[04:37] <jfroy|work> A checkout would not have normally allowed by commit which caused the branch to diverge.
[04:37]  * jfroy|work is unconfused
[04:37] <jfroy|work> *allowed my
[04:38] <jfroy|work> The amazing thing is, no conflicts were generated.
[04:38] <jfroy|work> It's as if the same set of changes were applied twice without a problem.
[04:39] <jelmer> yes, that's correct - the revision that was moved to the right hand side is no longer on mainline
[04:40] <jfroy|work> indeed, it got moved to the right-side of the merge commit.
[05:47] <tetha> uhoh. "Device not ready" while trying yo read the kernel is no nice greeting in the morning
[06:00] <poolie> spiv, still around?
[06:01] <spiv> poolie: yeah
[06:03] <poolie> i'm going to finish up in a bit, about 5:30 or 6, and go out
[06:03] <spiv> jelmer: if I have the latest stable branch of bzr-svn installed I can't branch from http://bzr.arbash-meinel.com/branches/bzr/1.10-dev/revision_stream
[06:04] <poolie> mwh reported a new bug with those checks i put in for stacked branches
[06:05] <poolie> i'm just thinking about whether to get on to that now or keep going with john's merges
[06:05] <poolie> probably the second is better, as it's already work in progress
[06:06] <poolie> and then i can take an uinterrupted go at 302968
[06:06] <poolie> how did you go?
[06:06] <spiv> 302968?
[06:06] <poolie> correction bug 302698
[06:07] <spiv> I saw mwh's bug, it seems to still be noticing the problem a bit too late.
[06:07] <poolie> yeah
[06:07] <spiv> Sooner than the next push, at least :)
[06:07] <poolie> right
[06:07] <poolie> i'm happy with the check there
[06:07] <poolie> and it should be fairly possible to just work backwards and see what should be done
[06:08] <spiv> It's weird that the autopack's _check_references trips over, but the push itself didn't.
[06:08] <spiv> Oh, unless an earlier pack that's part of the autopack has the dud record(s).
[06:09] <spiv> If that's the case then it might just be a matter of waiting until a report of that error comes in that isn't from an autopack.
[06:10] <spiv> I agree that at the moment doing work that will make the rc1 tomorrow better is probably the best bet.
[06:10] <poolie> indeed, but what would that be? :)
[06:12] <spiv> Heh.
[06:12] <poolie> i'll look at your tweak for 'avoid extracting revision texts' and merge it
[06:12] <spiv> Landing already reviewed/proposed patches.
[06:12] <poolie> the patch makes sense to me
[06:12] <spiv> I'm doing that one atm, actually :)
[06:12] <poolie> oh ok
[06:12] <spiv> Just waiting for my push to finish then I'll hit pqm-submit (so only a few seconds)
[06:13] <poolie> then i'll look at 'retry 2/3', as no one has reviewed that yet
[06:14] <spiv> That'd be good.  I took a glance at it but the diff seemed a bit odd, and merging bzr.dev gave some irritating criss-cross conflicts.
[06:15] <spiv> ("odd" as in "looks like it shows unrelated changes that are already in bzr.dev")
[06:22] <poolie> i might try that merge then
[06:24] <spiv> poolie: oh, and Mary would be happy if http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640811181423hc9a2628y4b0bae4dd1f6e7fd%40mail.gmail.com%3E makes it into 1.10
[06:26] <spiv> poolie: there's a newer patch that makes _get_nick into a public get_nick as suggested by the review, but that newer patch is stalled while waiting for tests to be written for that new public API.
[06:26] <spiv> poolie: so probably we should just merge the initial patch (with _get_nick) for 1.10
[06:27] <poolie> +1 from me
[06:27] <spiv> poolie: I can do that if that sounds -- great :)
[07:02] <vila> hi all
[07:04] <poolie> hey vila
[07:34] <poolie> ok, i've fixed up jam's retry patch and sent it to pqm, and now i'm signing off
[07:34] <vila> pfeww, finally the fix for bug #277537 is ready to be used or should I run yet another mammoth 34h bzr check ? :-/ :-) :-\
[07:36] <spiv> poolie: cool.  I've got jam's pack re-order patch with PQM too, so I think we've merged all the important stuff he wanted to have merged.
[07:37]  * spiv goes for a swim
[08:44] <loxs> folks, bzr+ssh doesnt work with the setup installer for windows. So I decided to install python and paramiko and then bzr. Paramiko now works on its own. I try to install with the "simple" installer, but now bzr is not in the system path. And I can't find the exe. Where is it installed?
[09:32] <speakman> how is nested trees developing going?
[09:47] <_mathrick> hey
[09:48] <_mathrick> what is the best repo structure to have a dev branch, and another branch which is dev + local conf (DB/host settings in this case)?
[09:49] <_mathrick> ideally, all changes would be pushed into dev unless I specifically say not to
[09:49] <_mathrick> ie. I'd like to avoid manual sync as much as possible
[10:07] <SteveA> poolie, spiv: hi.  do you need any help getting the branches that are still causing a problem for online services?
[10:07] <spiv> SteveA: more details certainly wouldn't hurt
[10:08] <spiv> SteveA: is it easy to make a tarball of the offending branch(es) + plus instructions to reproduce the problem with the tarball?
[10:13] <_mathrick> um, how can I export a shelf?
[10:14] <SteveA> spiv: I think we only see it when talking to Launchpad
[10:14] <SteveA> spiv: best thing is if I give you access to the private branches, I think
[10:16] <SteveA> spiv: I just added you as a member of a team.  You should be able to get the branches now.
[11:05] <james_w> jelmer: hey just discussing how to make --export-upstream work better for someone, and I think we may be able to solve your problem at the same time
[11:29] <Lo-lan-do> Hey there
[11:30] <Lo-lan-do> Can I get bzr branch (or bzr checkout) to not create a working directory but only to fetch the revisions?
[11:31] <Lo-lan-do> I'm trying to setup a "mirror" repository on my laptop with branches bound to those on my server's repository.
[11:31] <james_w> hey Lo-lan-do
[11:31] <james_w> you can do it if you create a --no-trees repository
[11:31] <Lo-lan-do> But even though the local repository is --no-trees, bzr branch creates working copies :-/
[11:32] <james_w> oh
[11:32] <james_w> that's odd
[11:35] <Lo-lan-do> (This is bzr 1.5-1.1 on Debian unstable, by the way)
[11:35] <Lo-lan-do> But anyway, I'll do some shell magic with bzr reconfigure.
[11:36] <james_w> I'm pretty sure --no-trees should work
[11:36] <james_w> you might have found a bug
[11:37] <james_w> Lo-lan-do: thanks for working on loggerhead for alioth
[11:37] <Lo-lan-do> You're welcome.  You'll probably notice it doesn't Just Work quite yet :-)
[11:39] <Lo-lan-do> (I reported the bugs last night)
[11:40] <Lo-lan-do> I'm off to lunch, but I'll be back to discuss them afterwards :-)
[12:12] <jelmer> james_w, ah, cool - how?
[12:12] <james_w> jelmer: do you use export-upstream in merge mode, or not?
[12:13] <jelmer> james_w, no, I don't use merge mode anymore these days
[12:13] <james_w> jelmer: to add a new mode, so one can just re-use the tarball if already present
[12:15] <james_w> we could also make it a but easier as well, as when you are not in merge mode the upstream branch is not necessary to retrieve the revision in question, as you will have merged it
[12:15] <james_w> though noting the upstream branch will still be useful
[12:15] <james_w> I haven't thought it all through yet though
[12:17] <phoenix3051> anyone know why on ubuntu hardy, bzr depends on  python-central (>= 0.6.7) but only 0.6.5ubuntu1 is available
[12:19] <jelmer> james_w, Is there a good use case for "export-upstream" without "export-upstream-revision" ?
[12:20] <james_w> jelmer: it was intended for nightly build
[13:26] <CardinalFang> Three lines:  $ bzr upgrade \nFormat <RepositoryFormatKnit1> for file:///blah/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance \nbzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.\n
[13:26] <CardinalFang> "please change!  sorry, nothing to do!"  Why?
[13:27] <beuno> CardinalFang, maybe the repo is old format?
[13:27] <beuno> are you using shared repos?
[13:27] <CardinalFang> Yes, I am.
[13:28] <beuno> CardinalFang, then you have to upgrade bith the branch and the repo
[13:28] <CardinalFang> Hrm.  Ugly.  Okay.
[14:32] <goshawk> hi
[14:32] <goshawk> is there a command to remvoe unknow files?
[14:32] <goshawk> from the repo?
[14:32] <goshawk> *remove
[14:33] <Odd_Bloke> goshawk: `bzr clean-tree`, though that may be in bzrtools.
[14:33] <goshawk> tahnks
[14:33] <goshawk> thanks
[14:33] <goshawk> works great!
[14:33] <goshawk> :)
[14:34] <goshawk> wait... it deleted the whole repo...
[14:38] <Odd_Bloke> goshawk: That's surprising.  Are you sure that you had added the files you were expecting to keep?
[14:38] <_mathrick> goshawk: repo or tree?
[14:38] <goshawk> wait
[14:39] <_mathrick> also, bzr serve just tried to murder my RAM, why does it hate my RAM?
[14:40] <_mathrick> it used up above 500M or so, unsure how much exactly, because I was too busy killing it before it took all the mem
[14:41] <_mathrick> the repo has only 2 revisions, although it has quite a few files
[14:41] <_mathrick> 10K files, ~150MB working tree
[14:42] <_mathrick> how do I find out what's up?
[14:51] <goshawk> Odd_Bloke: it was my fault
[14:58] <goshawk> how can i revert before deleting?
[15:00] <goshawk> done :)
[17:08] <CaMason_> hi guys. About to try about bzr for the first time
[17:10] <CaMason_> does bzr support keywords at all? I namely want to use the $id $ feature of svn if possible
[17:13] <james_w> CaMason_: not currently, it is in development though
[17:13] <CaMason_> james_w: ok. It's not that important for me at the moment :)
[17:14] <CaMason_> I love the fact this is portable. I can now continue my dev and commits whilst on the train :D
[17:14] <CaMason_> I did like tortoiseSVN though. I'm on vista x64, so I can't use the gui
[17:14] <CaMason_> although the eclipse plugin seems good
[17:14] <Lo-lan-do> I thought there was a TortoiseBZR too?
[17:15] <CaMason_> yes but it doesn't support x64, I believe
[17:16] <Lo-lan-do> Ah.  Pardon me for being ignorant of these things, I haven't touched Windows for years.
[17:17] <CaMason_> there's only a couple of things holding me back in windows, and thats the Adobe suite, and better multi-monitor support
[17:18] <CaMason_> I need access to the Adobe stuff, and there's no elegant working solutions for the suite. Also, I use 3 or 4 monitors, and the support with distro's like ubuntu isn't as good as the windows implementation, yet
[17:19] <Lo-lan-do> I wasn't tryng to elicit a discussion on that subject, just apologising, really ;-)
[17:19] <CaMason_> Lo-lan-do: I was just voicing my dissapointment with Adobe's lack of linux builds, as usual :)
[17:21] <CaMason_> hrm.. I've got a couple of symbollic links in my project. I just did a bzr add, and commit. Now 'bzr status' shows those 2 links as 'unknown' with @ appended
[17:21] <CaMason_> Any ideas on the best approach now?
[17:26] <james_w> CaMason_: what happens if you "bzr add <symlink>"?
[17:27] <CaMason_> it seems it added the folder, but not contents (desired)
[17:27] <CaMason_> and commit succeeded :)
[17:37] <CaMason_> What's the preferred mechanism for seperating lines/sentences with a commit message?
[17:41] <james_w> CaMason_: I like to do a one line summary, a blank line, then paragraphs explaining it
[17:41] <CaMason_> sorry for my lack of understanding. How would I insert a newline when I'm typing at command line? (linux)
[17:41] <james_w> that works well with things like bzr log --line, loggerhead etc.
[17:42] <james_w> oh
[17:42] <james_w> don't pass -m
[17:42] <james_w> and don't type a message
[17:42] <james_w> it is possible at the command line, but if you do that you will be given an editor in which to type
[17:43] <CaMason_> oh I see! and thanks to uncommit, I can go back and try it on a real commit :D
[17:43] <CaMason_> liking bzr already
[18:20] <LaserJock> james_w: congrats on the Ubuntu package branches
[18:57] <sohail> hi, anyone know the status of bzrp4? Is the bzr -> perforce functionality available to test/hack?
[19:22] <james_w> thanks LaserJock
[19:36] <LaserJock> james_w: I was looking at a failure and see:   UnicodeDecodeError: 'utf8' codec can't decode bytes in position 286-291: unsupported Unicode code range
[19:36] <LaserJock> james_w: isn't that a common problem?
[19:37] <james_w> yeah
[19:37] <james_w> it assumes debian/changelog is valid utf-8
[19:37] <james_w> I'm going to try and remove that assumption or relax it somehow
[19:38] <Dvyjones> Is there anything like SNV's $Id$ (I think that's how it is in SVN at least) in bazaar?
[19:39] <james_w> Dvyjones: not currently, but it's in development
[19:50] <Dvyjones> And there's nothing like CIA(.vc) in Bazaar?
[19:50] <beuno> Dvyjones, sure, check out the CIA plugin: http://bazaar-vcs.org
[19:50] <beuno> er
[19:50] <beuno> http://bazaar-vcs.org/BzrPlugins
[19:59] <LaserJock> james_w: this one seems a bit weird: bzrlib.errors.NoSuchTag: No such tag: upstream-ubuntu-0.12
[20:00] <Dvyjones> Do oyu know any good PHP software management softares / CMSes that support showing last bazaar pushes?
[20:23] <james_w> LaserJock: yeah, that's the most common one, it's a logic error I haven't had chance to look in to yet
[20:24] <LaserJock> james_w: something about the way it figures out what the upstream release is I suppose
[21:46] <poolie> hello
[21:46] <pygi> hello poolie
[21:55] <thumper> poolie: hi
[21:55] <thumper> poolie: I was trying to remind myself of the --fixes syntax, and went `bzr help bugs`
[21:56] <thumper> poolie: I was somewhat surprised not to see a launchpad example in there
[21:56] <thumper> poolie: it had three or four other examples, but no lp :(
[21:56] <poolie> that sounds like a bug
[21:56] <poolie> i wonder why
[21:57] <poolie> ah so it does talk about lp, but doesn't give a good example
[22:15] <grettke> Hi guys. I've got a shared-repo with a project in it that I no don't need. I want to delete it. Should I just rm -rf it, or use bzr commands to do so? It has never been branched, just created is all.
[22:15] <poolie> if it has nothing else in it that you want, you can just rm it
[22:16] <grettke> Ok.
[22:17] <grettke> If I were to delete and recreate that project, as far as the shared repo is concened, it is not the same as the old one?
[22:19] <poolie> right
[22:20] <grettke> thanks poolie. bye.
[22:25] <spiv> poolie: huh!
[22:25] <poolie> mm?
[22:25] <spiv> poolie: that change used to pass tests, but now it trips on your new consistency chekc
[22:26] <poolie> ah
[22:26] <spiv> (the change to remove "len(self.target._fallback_repositories) > 0")
[22:27] <poolie> yes, that's what i understood you to mean
[22:27] <poolie> good thing that check was there i guess
[22:27] <spiv> I guess that makes sense, it can't be a straight pack-to-pack copy, some delta records have to be fulltexts.
[22:40] <poolie> thumper, spiv: just <http://pastebin.ubuntu.com/77542/> or anything more?
[22:40] <thumper> poolie: fixes rather than addresses perhaps?
[22:40] <thumper> but yes, that is all I was looking for
[22:41] <poolie> i'd kind of like to say what effect this will
[22:41] <poolie> have
[22:42] <poolie> but, that's mostly defined server side and may go out of date
[22:43] <poolie> and i'm not sure off hand what will happen
[22:45] <spiv> poolie: that looks reasonable to me
[22:46] <poolie> thumper: i just got subscribed to a very active project using code reviews etc
[22:46] <poolie> so, congratulations on your feature's popularity
[22:46] <spiv> Off hand I believe --fixes lp:NNNN causes that branch to be associated with the bug, and that association's status is set to "Fix Available".  I think "addresses" is an ok way to summarise that ;)
[22:46] <poolie> but it's also an eyewatering amount of email
[22:46] <poolie> and i don't really really care about it
[22:46] <poolie> possibly i should fix this in my mail client
[22:47] <poolie> but i wonder, if i unsubscribed (if i can) whether I'd get a good replacement through the web
[22:47] <poolie> basically a timeline view of all merge proposals, comments, and landings
[22:55] <spiv> poolie: so I've updated my original InterPackRepo.fetch hack for bug 294479 to add a comment and a NEWS entry.
[22:55] <spiv> poolie: I'm just running a full test suite now, in case there's something unexpected, but I don't expect there to be.
[23:03] <poolie> so this is setting it through a callback?
[23:03] <poolie> i think a comment about why we're doing it, and maybe also something on the constructor parameter to say we don't really want it would make sense
[23:03] <poolie> i sent that doc patch to pqm
[23:04] <spiv> poolie: right.
[23:04] <spiv> poolie: I'll add a comment to the constructor too.
[23:29] <jml> you know what would be great?
[23:29] <jml> being able to re-order threads in a loom
[23:30] <jml> (I guess doing it properly depends on proper cherrypicking, but I'd be happy with a half-arsed solution that was a joy to use)
[23:46] <Glenjamin> hey guys, i've just installed bzr1.9 on windows, and i'm getting the error "Unable to load bzr-svn extensions - did you build it?" "cannot import name client"
[23:46] <Glenjamin> anyone know what this actually means?
[23:47] <lifeless> jml: its in todo I think, file a bug, yada yada yada
[23:51] <awilkins> Glenjamin: It's a packaging bug
[23:51] <awilkins> Glenjamin: You installed the python2.5 version?
[23:51] <Glenjamin> yes
[23:51] <awilkins> Glenjamin: Delete c:\python25\lib\site-packages\bzrlib\plugins\svn
[23:51] <awilkins> Unless you actually want to use bzr-svn, of course
[23:52] <Glenjamin> and if i want svn i should just install it?
[23:52] <awilkins> "just install it" is relative on windows
[23:52] <awilkins> It's rather tricky to get it built
[23:52] <Glenjamin> ah
[23:52] <Glenjamin> i probably dont need it for now
[23:52] <awilkins> For windows I think you are going to be looking at prepackaged binaries
[23:52] <Glenjamin> yeah, i'm fine with that
[23:53] <Glenjamin> while i'm here, i dont suppose anyone knows how to get tortoisebzr working on 64bit windows?
[23:58] <spiv> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081127231800.GH23611%40steerpike.home.puzzling.org%3E is the updated patch, btw