[00:15] thumper: yes [00:19] working on ppa now [00:20] New bug: #209450 in bzr "The error message for "can't find bzr on remote server" when using bzr+ssh is now scary." [Undecided,New] https://launchpad.net/bugs/209450 [00:21] bob2: thanks [00:23] I was a bit suspicious of r3313, but reverting to 3312 didn't help [00:24] bob2: I'd probably be suspicious of 3309 [00:41] New bug: #209458 in bzr-loom "combine-thread doesn't result in correct tree parents" [Undecided,New] https://launchpad.net/bugs/209458 [01:06] vila, what is ~bzr-upload-devs? [01:49] There will be a short interruption to bazaar.launchpad.net and the ubuntu wiki to deploy a fix for the performance problems. [02:47] how do I push a branch into a new svn: repository branch? [02:50] uniscript: I use "svn cp" to make the branch in the repo, then "bzr push" to that [02:50] but bzr push says I have to merge [02:50] uniscript: there's a bzr-svn bug (https://bugs.launchpad.net/bzr-svn/+bug/203368) you can hit if you do it directly [02:50] Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed] [02:51] Hmm, I'm not sure why that would be. Perhaps you did "svn cp" from a different revision of the source branch? [02:51] I should explain I branched an svn: repo from repo1 but want to push up to an empty dir on repo2 [02:51] Oh. [02:51] I don't know much about different SVN repositories. [02:51] any suggestions on how I can achieve this? [02:52] Or rather, about using bzr-svn with them. [02:52] It's not something that SVN is really designed to support, so I'd expect bzr-svn to struggle with it too. [02:53] But if you mail the bazaar list, Jelmer might be able to help. [02:54] does that mean I have to join another list :( [02:55] You could mail Jelmer directly, I guess (I think his address is in the bzr-svn README file), but I think the list is a better forum, so other people can help and/or learn from the post. [02:56] uniscript: you could join the list, but then set your mailman settings to disable mail delivery. That way you can post unmoderated, but you won't get a flood of messages to your inbox. [03:01] err where is the mailing list? Can't find it on launchpad :( [03:01] New bug: #209490 in bzr-loom "bzr-loom does not make it obvious when to use "bzr record"" [Undecided,New] https://launchpad.net/bugs/209490 [03:01] uniscript: https://lists.ubuntu.com/mailman/listinfo/bazaar [03:02] uniscript: (it's linked from http://www.bazaar-vcs.org/) [03:02] sorry, just being frustrated with launchpad. Never seem to be able to find what I want there [03:03] the classic is: this package keeps it's bug tracking somewhere else, but doesn't say where that somewhere else is [03:46] How would I ignore a file ".foo" in every directory of my branch? [03:48] bzr ignore **/.foo [03:48] probably quoted: bzr ignore '**/.foo' [03:50] Thank you! [03:53] lifeless: hi [03:53] If i merge a branch, does the .bzrignore file merge as well? [03:53] awmcclain: yes [03:53] Verterok: hi [03:53] No reason it wouldn't. [03:53] Great. [03:54] lifeless: do you have time for a quick question about my patch for custom properties in log? [03:54] sure [03:54] I not sure what I should fix in the docstrings of the show_properties method [03:54] the gmane thread is: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/38101 [03:56] lifeless: I already added the tests for error case and added error handling code in the show_properties method [03:56] Is "no handlers could be found for logger "bzr" a bzr message? [03:58] awmcclain: its coming from pythons logging framework [03:58] awmcclain: are you using the bzr frontend or some other script ? [03:58] lifeless: I'm running bzr automatically from capistrano. [03:58] Maybe I have an unmet dependency on the box? [04:03] awmcclain: no sure; whats capistrano ? [04:04] lifeless: A nifty automated deployment framework. Basically I'm sshing into a minimally configured ubuntu box and running bzr up --lightweight, and I'm getting back that message (everything is working though) [04:04] hmm, could be a missing thing I guess [04:05] please file a bug, for extra credit with how-to-reproduce [04:05] lifeless: Okee doke. I've read on launchpad that it may be related to a lock file? Could that be? [04:05] doubt it [04:05] Yeah, me too. [04:06] Sounds like a dependency thing. [04:06] I'd guess race condition with the logging infrastructure setup [04:06] lemme try logging in directly [04:06] and see [04:10] lifeless: Ok, it's not a capistrano thing. [04:11] lifeless: I had a bit of a play with bzr-loom. It is quite useful, although the UI doesn't quite feel right [04:11] jamesh: I saw your bug - thanks. [04:11] perhaps that's just because I'm not used to it yet [04:12] lifeless: is there any reason why the unrecorded loom state is in the branch rather than working tree? [04:16] jamesh: yes, its branch related not tree related [04:16] lifeless: I guess I'd see the last recorded loom state as being branch related, but the unrecorded state as working tree related. [04:18] awmcclain: Not lock file, log file. [04:18] You probably don't have permission to write ~/.bzr.log [04:19] abentley: Actually, I was talking about lock, as described here: https://answers.launchpad.net/bzr/+question/19988 [04:21] abentley: That's exactly it. The .bzr.log file is owned by root! [04:21] Happy to help. [04:21] Must be because the first time I run bzr I sudo? [04:21] hrmmm [04:22] I suppose I could just touch .bzr.log before I start. [04:22] Yay! [05:54] jelmer: Should I back up .bazaar/subversion.conf? If it's lost, will I have to fix the branching scheme next time I pull or something? What if I keep subversion.conf but svn-cache gets deleted? [08:21] anyone understand this? http://pastebin.ubuntu.com/6253/ [08:23] ubuntudoc was converted from svn [08:23] so needs to be branched into a "rich-root"-supporting repository [08:23] alas bzr co doesn't realise that [08:24] you mean that the downloader has got a shared repository set up there with a different format? [08:24] no, bzr co defaults to one that doesn't support rich-root [08:24] hmm. [08:25] is rich-root the same as "dirstate-with-subtree"? [08:25] that's the one we have [08:25] afaik the work around is "bzr init-repo --rich-root-pack ubuntu-doc ; bzr co http://launchpad-asdjfhsaldfhas/trunk ubuntu-doc/trunk" or similar [08:25] rich-root is a feature some formats support. === mwhudson__ is now known as mwhudson [08:26] spiv: and dirstate-with-subtree supports it? [08:26] dirstate-with-subtree is one format that supports that (and also some experimental feature); rich-root-pack is the newest and best format for rich-root support. [08:27] is there a converting tool between the two? [08:27] "bzr upgrade"? [08:27] bzr upgrade will convery branches [08:27] but that doesn't help that person [08:27] I tried that, it failed and trashed my branch [08:27] And you can generally "bzr pull" etc revisions into a compatible repository. [08:27] I couldn't even restore the backup [08:28] I should have written down the error [08:28] that's quite bad, since the backup is done by more or less "cp -r" [08:28] or was it mv [08:29] I wonder if I was trying to restore it to the wrong place, I had a shared repo at the time [08:29] bob2: there's a bug in upgrade in some situations involving shared repos [08:29] ah [08:29] double ah [08:29] bob2: that can leave things in a busted (but recoverable by hand) state [08:30] anyway, I don't think the upgrade worked [08:30] There's a bug report about that somewhere. lifeless knows the full details. [08:31] .bzr/repository is renamed to .bzr/repository.backup or something, and there is no new .bzr/repository. It's entirely safe to just rename it back in that case. [08:31] I'm definitely interested in trying to convert these branches to the "official" bzr format though [08:31] You could've experienced another problem, of course. [08:31] if it's possible, i would like to do it [08:31] mdke: Rich roots are The Future. [08:32] the problem is that they aren't The Present. [08:32] mdke: And converting from rich roots to non-rich roots is not supported, because that would throw away certain meta data. [08:32] jamesh: Heh. [08:32] mdke: you can do the upgrade manually, by doing "bzr init-repo --rich-root-format new-repo", and then manually "bzr branch"ing each branch from the old to the new, then renaming the repos "mv repo old-repo; mv new-repo repo". [08:33] what is The Present? [08:33] spiv: "--rich-root-pack", not "--rich-root-format" [08:33] mdke: Non-rich roots. [08:33] Peng: right, thanks. That's what I get for typing commands direct into IRC :) [08:33] :) [08:33] I understood that the format we have now is not the best format at the present [08:34] Indeed. [08:34] (and maybe you need to do "bzr init" + "bzr pull" instead of "bzr branch" for subtree -> rich-rich, I forget) [08:34] * Peng shrugs. [08:34] I don't know that. [08:34] spiv: I will save those commands and give them a try later on [08:34] Um. [08:34] spiv: thanks [08:34] I did something like that recently. [08:35] I think we'd be content with trying to get up to The Present [08:35] (https://bugs.launchpad.net/bzr/+bug/145812 appears to be the bug I mentioned earlier, btw) [08:35] Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] [08:35] Right. [08:35] I bzr branched from dirstate-with-subtree to rich-root-pack, and it worked, but it was ridiculously slow. [08:36] I'm patient :) [08:36] Haha. [08:37] It took 5.5 hours for a ~1300 revision, ~200 MB repo. [08:37] ah, overnight then [08:38] That was over bzr+ssh over the Internet.. [08:38] Doing it locally would be faster, of course. [08:38] But there's no way it should take nearly that long. [08:39] that's fine. If it's the right thing to do, I'm happy to wait :) [08:40] bbias [08:44] mdke: Going from subtrees to rich roots is safe in many situations (subtree support more features, but if they're not being used), but it's not possible to go from rich roots to non-rich roots without losing some meta data. [08:46] Peng: does one want to go from rich roots to non-rich roots? [08:46] I just want to go to the best current supported format [08:49] mdke: There's not much need. [08:50] mdke: The only problem is that the default format does not support rich roots, so users can get confusing errors when doing "bzr init-repo" and then trying to branch a rich root branch into it, and that "bzr checkout" problem. [08:51] Peng: could I upgrade to the "default format" instead? [08:52] that would still be faster than the current one, right? === doko_ is now known as doko [08:52] mdke: Current one? [08:52] the dirstate-with-subtree format [08:52] mdke: Oh. [08:53] mdke: Like I said, you can probably go from dirstate-with-subtree to rich-root-pack, but not to a non-rich-root format. [08:57] Mmm, netsplit. [08:57] lagged out, sorry [08:58] last thing I have was the "isn't it a bit odd" question [08:59] anyway, got to go to work now. thanks all for the info [09:02] "isn't it a bit odd"? [09:02] I didn't get that. [09:16] New bug: #209570 in bzr "http cannot tunnel smart protocol" [Critical,New] https://launchpad.net/bugs/209570 [09:40] hi, does the bzr extension for nautilus from bzr-gtk work for anyone? [09:40] hi thekorn [09:40] hi james_w [09:40] I heard someone saying the other day that it didn't work for them [09:40] so it sounds like their may well be a regression there. [09:41] hmm, the python bindings for nautilus does not seem to work at all, so there might be the problem [09:42] ah, you're just trying from a python console? [09:43] no, within nautilus, no clue howto test it in a console-session [09:43] it's bug http://bugzilla.gnome.org/show_bug.cgi?id=518824 [09:45] thekorn: thanks, I'll open a bug in Ubuntu [09:47] james_w, okay, thanks, can you please subscribe me? :) [09:48] done [09:48] do you want to use your bugcontrol powers on it? [09:48] https://bugs.launchpad.net/nautilus-python/+bug/209580 [09:48] Launchpad bug 209580 in nautilus-python "python-nautilus doesn't work with latest nautilus" [Undecided,New] [09:51] james_w, yes, will set the importance to medium [09:53] isn't it critical for that package if it doesn't work at all, or do I misunderstand? [09:56] james_w, critical for this package, but not for ubuntu, as the number of users affected by this is not that big, I think [09:57] ah, ok. I thought the severity was per package [09:58] should there be a split for the severity against the package and severity for the release? [10:01] I'm not sure, maybe the gnome bug needs a higher severity, [10:02] it's critical I think [10:02] I looked again and found an existing bug for this, so I've duped it [10:05] james_w, I've no clue about FFe and the related process, I will discuss this bugreport with people in #ubuntu-bugs later today [10:06] I don't think we need an FFe to fix this, I'm not sure though. [10:06] there's a workaround patch described in the bug report, we can add that to the package for the release I think [10:07] New bug: #209580 in nautilus-python "python-nautilus doesn't work with latest nautilus (dup-of: 44704)" [Medium,Confirmed] https://launchpad.net/bugs/209580 [11:25] I know I asked this before, but I can't remember how to do it... can I make bzr diff --diff-options=-p the default for bzr diff? [11:26] pbor: yes, with an alias [11:26] ah, ok [11:26] I thought there was some way inside bzr [11:26] a bzr alias, not a shell alias, I mean [11:26] ah [11:26] * pbor looks that up [11:27] thanks dato [11:28] is bzr alias a plugin? [11:28] bzr help alias gives me an error [11:28] nope, it's core [11:28] but [11:28] I don't know if you can add an alias from the command line, with a command [11:28] I *think* you have to edit the configuration file [11:28] no, you can't [11:29] thumper proposed a patch to do that, but I don't know what happened to it [11:29] pbor: so, like this: [11:29] % head -n 2 ~/.bazaar/bazaar.conf [11:29] [ALIASES] [11:29] up = update [11:29] ah, ok, I can live with that :) [11:29] thanks [11:29] I think there was discussion about whether it should work like the shell builtin alias, or more like bzr in terms of command line parsing [11:29] Why have you aliased update? =) [11:30] bzr up = bzr update with aliasing it :) [11:30] without* [11:30] frsk: I probably added it when the "up" alias didn't exist in core [11:30] and didn't clean up afterwards [11:30] dato: Aha [11:55] hello [11:56] i need to pull the changes from a remote repository up to and including a tagged release, and substitute all my local working copy with that release. what is the correct command line? [11:56] Stavros: do you have local commits_ [11:56] ? [11:57] dato: no, it's a production server [11:57] i may have some local edits which i want overwritten [11:57] aha. so, `bzr revert && bzr pull -r tag:TAGNAME http://...` ? [11:58] aha, that should work, let me try it [11:58] do i need to do something like "revert -r"? [11:58] oh wait, nm :/ [11:58] no, you don't [11:58] how about pull --overwrite? [11:59] that's for when you have local commits [11:59] ah [11:59] but not local working copy changes? [11:59] nope [11:59] those are reverted with revert [12:00] hmm, it said something about conflicting tags... [12:03] aw man, i'm in the front page of reddit [12:03] no wonder the server is hammered [12:05] Stavros: which, learn python in 10 minutes? [12:05] yeah :/ [12:08] so, any idea what this talk about "conflicting tags" is? [12:08] Stavros: there is a tag that is set to one revision in your branch and another revision in the other branch [12:09] or two tags with the same name on two different revisions if you like [12:09] james_w: that's odd, don't tags get moved if they already exist? [12:09] Stavros: I think so, what does the rest of the message say? [12:09] it just shows me the tag I just set [12:09] does it stop the pull, or just warn you? [12:09] it just warns me, from what i can see [12:09] does it say which one was kept? [12:10] i.e. did it keep your tag, or use the other one? [12:10] no, but apparently the server has it on a different release than on my machine [12:10] that's odd [12:10] i have it on 247 and the server on 246 [12:14] shouldn't it update the tag on pull, even though it already is on a revision on the server? [12:15] hmm, --overwrite works [12:17] yep, it's a conflict, so you need to specify what you want to happen [12:19] ah [12:19] hmm, why does it not update? because i set it on the server? [12:21] yes, the tag points to two different places, and so bzr doesn't know which one you want. [12:22] ah, so --overwrite should fix any future conflicts, yes? [12:23] yes, I think so, though it's not necessarily a good idea to always use --overwrite [12:23] why do you think you will have more conflicts? [12:24] i don't really think i will, but i'm pretty sure i won't have any changes there i want to keep, so it's the safe bet [12:24] that reminds me I should file a bug report about adding --overwrite-tags [12:24] oh, that would be quite useful [12:30] well, thank you all very much for your help, it works quite well now === mrevell is now known as mrevell-lunch [13:31] I'm wanting to copy an svn branch/tree from one repo to another where I don't have server access to the repos. I wonder if bzr-svn can help with this? [13:31] I've branched the source using bzr-svn now how do I push it up to the target? [13:35] uniscript: bzr svn-push is probably what you want [13:35] uniscript: the branch doesn't exist in the second repo, correct? [13:35] correct [13:36] if I try svn-push it wants to merge [13:36] yeah, svn-push is the answer I think. [13:36] I tried push --overwrite but that's not implemented yet :( [13:38] bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [13:39] the target directory exists in the repo and is empty [13:39] is that a problem? [13:42] testing... [13:47] seems happy. So that was the problem, can't branch into an empty directory, svn-push has to create the branch dir. OK. Thanks === mrevell-lunch is now known as mrevell [14:36] Is there a way to do a push-or-pull operation..? Given two bzr branches, push updates from whichever is newer, to whichever is older? (obviously it'd break for diverged history)... [14:52] LeoNerd: No, I don't think there is such a thing. A branch and a checkout of that branch comes close, though. [14:53] I just wanted to put it in cron.hourly in a "foreach BRANCH in `bzr branches`; ..." command [15:05] New bug: #209688 in bzr-gtk "The branch history window should use a status bar" [Undecided,New] https://launchpad.net/bugs/209688 [15:05] New bug: #209689 in bzr "KeyError in transport close _file_streams while pulling into a bound branch" [Undecided,New] https://launchpad.net/bugs/209689 === mw|out is now known as mw [16:01] bzrlib.tests.test_revisionnamespaces.TestRevisionSpec_date.test_yesterday failed [16:01] yesterday [16:02] err, no sometimes around 0.01 this morning [16:02] ha ha, so funny [16:02] Anyway, I just demonstrated that this test *is* fragile :) [16:02] (-: [16:34] can bzr export make python eggs from my project? [16:36] like bdist_egg? no. [16:36] there's a setuptoolsbzr thing, tho [16:36] bob2: is that a bzr plugin? [16:37] no, a setuptools one [17:04] are there any guides on how to use bzr to automatically increment the version number in a setup.py file [17:07] piedoggie: there's the version-info command that might help you [17:07] I think it's something like bzr version-info > _version.py and then import that in setup.py and grab the revno [17:07] version-info --python or something actually [17:08] is that what you meant? [17:09] something like that [17:11] I still need a figure out how this would affect the version number seen when you run setup [17:11] also need to figure out how to include it, generate a new one on every commit etc. [17:11] well setup.py is python, so you can do all this, and then pass it to the function that you call in there. [17:12] ah, on commit, that's different [17:12] you could use some sort of hook I think [17:12] my nickname is Mr. forgetful. I can't tell you the number of times I've created new packages and then fold them up with a single commit for just the version number change [17:12] oh yeah, I do that all the time as well [17:13] version-info --template might be of help [17:13] hi LarstiQ [17:13] hey james_w, piedoggie [17:14] afternoon [17:16] well, I can see the auto version number update will take a bit more thing time to make it right (or least documented) [17:16] ... a bit more think time... === Pilky__ is now known as Pilky [17:21] LeoNerd: Maybe you could do "bzr pull && bzr push;"? I.e. try to pull from "other", and unless that fails, try to push revisions from "this" to "other". [17:21] hmeland_: Hmmm... That might work... Though if both fail, how to tell between "sides are identical" from "sides have diverged" ? [17:23] Quick test shows that "Nothing to do" will succeed for "bzr pull", at least. [17:24] Ah OK. :) [17:26] You can apparently also use "bzr pull -q", which will give an ERROR if the branches have diverged. [17:27] OK. That's probably good enough then === kiko is now known as kiko-fud === kiko-fud is now known as kiko [19:45] jelmer: around? [20:07] abentley: hi === mw is now known as mw|food [20:47] jelmer: We're trying to track down what happened when you got an OOPS error yesterday [20:47] It looks as though you tried to register a branch with the name .bzr, but of course that doesn't make much sense. [20:48] ah [20:49] abentley: please ignore those [20:49] Well, this is an internal error. Users really shouldn't ever get those. [20:49] abentley: I mass-registered a bunch of branches [20:50] Oh, shell-scripting glitch? [20:50] I've got a particular directory structure on my server that I relied on [20:51] I've got a plugin that allows short URL access to those branches and can auto-register them [20:51] It looks like it tried to register all the files in a working tree somewhere [20:51] Ah, okay. [20:52] abentley: It would be nice to get a clearer error, but I doubt it would ever happen to a normal user. [20:52] Cool. [20:55] It would of course also be nice if launchpad could do recursive finding of branches under a particular URL... [21:02] 'lo [21:02] james_w: the alias patch has been sitting idle as I haven't written appropriate tests yet [21:02] what should I do when I merge and something is going bad ? [21:02] thumper: ah, ok, thanks [21:03] I resolved the conflict and cleared it [21:03] but now I am stuck with "pending merges" [21:03] james_w: I really should get around to finishing it [21:03] it would be nice to have [21:05] nobody ? :( [21:05] xma: commit? === mwhudson__ is now known as mwhudson [21:05] hum [21:05] what is the merge command purpose then ? [21:05] xma: to merge in changes [21:06] xma: it doesn't commit them [21:06] really ? [21:06] to bring the other branch commits in, you still have to check they are merged well and then commit [21:06] yes, it is a feature [21:06] oh I see :) [21:07] will it take the commit message from the merge patch ? [21:07] no [21:07] ok [21:07] I will have to generate it from my branch then [21:13] lifeless: around? [21:18] are there any python-mode users around ? [21:19] james_w: is it normal that my merge+commit added stuff not by me ? [21:19] james_w: there were many lines touched outside of my scope [21:19] james_w: I only modified 4 files and it seems latest commit did more than that [21:19] xma: they were changed in the branch you merged? [21:20] james_w: dunno [21:20] james_w: when I bzr status, only my files were marked as "modified" [21:21] and now I see many lines touched in many other files in the commit [21:21] and then where do you see the other lines changed? [21:21] no files were marked as added? [21:22] james_w: ok I think I know why :) bzr send -o mypatch was not enough [21:22] james_w: I have to add the revision number to [21:22] o [21:23] I'm interested in getting some information about the rich-root-pack format. Is it documented anywhere? Are there any obvious disadvantages to using it? Is it expected to be the default bzr format, and if so, how far away is that? [21:23] hum no, it is not [21:24] mdke: non-rich root repositories don't allow you store a normal file-id for the root of a repo. [21:24] This means that they all have the same root id [21:25] this, for instance, isn't satisfactory for bzr-svn [21:25] I don't think that is a feature we currently use, although I suppose we might like to [21:25] james_w: how do I know what a particular rev contains ? [21:25] james_w: I want to see what is in the rev 3318 for instance [21:25] mdke: it will not be the default format, though the default format will have rich roots [21:26] mdke: perhaps bzr-1.4 will have a new default format with rich-roots [21:26] james_w: rich-root-pack will never be the default format? [21:26] mdke: no, but an evolution of it will [21:27] james_w: will an upgrade from it be supported? [21:27] xma: bzr log -v -r 3318 [21:27] xma: bzr diff -c 3318 [21:27] mdke: yes [21:27] james_w: thank you [21:28] mdke: however I don't think downgrade from rich-root to non-rich-root is supported, as that would throw information away [21:28] sure [21:28] mdke: I don't think that would be part of your considerations though [21:28] is this for the docs? [21:28] ubuntu-docs [21:28] yeah, we've heard you're not happy with the current state of things [21:28] they currently use dirstate-with-subtree [21:29] james_w: that's not true, I'm very happy; I'm just trying to figure out what to upgrade to... === mw|food is now known as mw [21:29] mdke: they should be able to use --pack-0.92-subtree [21:29] that'll at least give them packs [21:29] and I thought it could work to -subtree too, albeit very slowly? [21:29]