[00:03] how do I set up the default maintainer email so that "bzr send" doesn't need an email address? [00:06] SmileyChris: according to the help, submit_to is the configuration key to set [00:06] lifeless: yep, i got that far... how do you set configuration keys [00:07] the help wasn't very clear on that [00:07] the user guide has documentation about that [00:08] basically just edit a config file depending on where you want the setting to apply [00:08] globally/url/branch are the three choices [00:12] lifeless: thanks for the explanation. So I can attach this setting to the branch itself or is it a client-side only configuration? [00:13] Hmm, that reminds me [00:13] I wonder if it makes sense to have a UI command for modifying the branch configuration? [00:13] including some way to list the available settings [00:14] hrm... i see there's a .bzr/branch/branch.conf - i wonder if that's where it should go [00:15] the guide isn't very clear on this [00:17] SmileyChris, yep, that's where it should be [00:17] jelmer: cheers [00:17] jelmer: does it need to be in a [DEFAULT] block? [00:17] SmileyChris, yep [00:17] good to know [00:21] actually, i see in my local branch.conf there isn't a default block [00:21] probably doesn't need it, it's a branch specific conf anyway [00:25] :( bzr: ERROR: No mail-to address specified. [00:25] seems it can't be server-side, unless i'm doing something wrong [00:25] which is more than likely :P [00:25] SmileyChris, it can be server side [00:25] set child_submit_to on the server side [00:25] ah [00:34] only affects new branches though I believe [00:36] how do i create a branch of a particular format in a test? [00:36] make_branch only takes a format for the bzrdir, unless i'm misreading things [00:38] i guess make a bzrdir and initialize a branch of the desired format on it? [00:42] mwhudson: format=knits etc [00:43] mwhudson: tests/test_repository.py shows nearly every variation [00:43] some fugly, some not [00:45] thanks [00:45] * mwhudson reads [00:46] bzrdir.format_registry.get('knit')() seems reasonably clear for this purpose [00:46] self.make_branch('foo', formamt='knit') is the most pithy [00:49] ok [00:57] The bzr user's guide says "Checkouts are source trees that are connected to a branch" - is that strictly accurate? Isn't a checkout a "bound branch"? [00:57] (it doesn't qualify with 'lightweight') [01:00] markh: its strictly accurate [01:00] bound branches are still connected to a branch [01:01] "source tree" implied "working tree" to me [01:01] what is a "source tree"? [01:01] I'd guess a tree you edit your code in ?:) [01:01] note that a bound branch with no tree object is not a checkout of any shape or form [01:02] hrmph - the docs for "bound branches" define it as being exactly a "checkout" [01:02] (I'm trying to get my head around a few of the subtleties I've been happily glossing over) [01:04] so I'm not trying to be painfully pedentic. Given that http://bazaar-vcs.org/BzrUsingBoundBranches defines "bound branch==checkout", I'd expect the user's guide to be stated as "Checkouts are branches that are connected (or "bound") to another branch" [01:06] bound branch + working tree = checkout [01:08] right. So the users guide is slightly misleading ("source tree" is vague) and BzrUsingBoundBranches is also slightly misleading (makes no reference to working trees) ;) [01:08] is there a ane usecase for a bound branch without a working tree? [01:08] sane [01:22] markh: yes [01:23] markh: one in particular is quite fun: [01:23] master [01:23] how about s/sane/common/? [01:23] mirror bound master (no tree) [01:23] lightweight checkout of mirror [01:23] I think that one is quite common for shared trunks [01:23] on C style projects where you want only one tree and to reuse build products [01:26] right - so I'm thinking of "bound" as being mainly useful for checkins. Why would 'mirror' use a bound branch, rather than just pulling from masteR? [01:29] markh: so that you can checkin to trunk when you want to, but still access what trunk looks like offline [01:30] right - "mirror" is writable. [02:13] does anyone use graphical diff/merge tools w/ bzr? if so, which ones? [02:14] teratorn: Not very often, but `meld` comes in handy once in a while. [02:14] was just looking at meld.. gotta try it out [02:14] ideally I would like a tool that can also let me do cherry-picking and then shelve or commit those selections [02:15] emacs! [02:40] huh what that's crazy talk [03:37] I see 'info' agrees that a bound-branch must have a tree to be reported as a 'checkout'. On a similar vein, when would be come across a 'branchless tree'? [03:39] a branchless tree does not exist [03:39] to open a branch you must have a reository object [03:39] to open a tree you must have a branch object [03:43] right - "info" explicitly handles that case, but it should never hit it in real life? [03:44] or only upon misused of that api I guess... [03:49] the API won't let you construct this [03:49] checkout --lightweight generates a branch references [03:54] I mean misuse of 'info.describe_layout(), which takes the repo, branch and tree as 3 sep args. but thanks for confirming that isn't another state I need to worry about :) [05:00] markh: ping [05:00] Verterok: hi [05:00] markh: hi [05:01] markh: are you building the standalone bzr.exe? [05:01] yep [05:03] markh: I'm wondering if it's possible to include SimpleXXMLRPCServer in it [05:04] Verterok: I'm sure it would be for 1.7 I guess. [05:04] markh: some bzr.exe users, also use bzr-eclipse and xmloutput plugin (that need SimpleXMLRPCServer) [05:04] great! [05:04] * Verterok dances [05:06] markh: if I can help, just drop me a line. I'll be glad to ;) [05:06] how will I know if it works? :) I can add that line to the 'includes' option to py2exe, but I'm not sure what to do after that... [05:07] I know - once 1.6 is out, just ping me and I'll hack up a binary and you can test it ;) [05:08] markh: bzr branch lp:bzr-xmloutput and bzr start-xmlrpc :-D [05:08] heh - ok [05:08] markh: if that is the only py2exe trick, I can try to build a binary and run some tests [05:09] its likely to also need 'xmlrpxlib' nominated in 'packages' [05:09] rpclib [05:09] it would help if you could do that - then just submit a merge request and I won't need to do anything at all ;) [05:10] but if you don't and I remember, I'll have a go when 1.7 is getting closer [05:10] markh: I can try :). do I need a custom enviroment to build bzr.exe? [05:11] markh: easier, any wiki/doc telling how to build it? :) [05:11] theoretically not :) It might complain about a few things missing, but should succeed [05:11] 'make installer' if you are *really* lucky ;) [05:12] obviously need py2exe installed, but most other things are optional [05:12] * Verterok fires up virtualbox and waits [05:13] xmlrpclib appears to be a simple module and is already in the package. [05:13] as is SocketServer - so if you are extremely lucky, you could just stick SimpleXMLRPCServer.pyo in library.zip and it would work ;) [05:14] nice :) [05:17] I'll give py2exe a try, if I'm lucky enough...I'll send the patch [05:20] markh: thanks for the guidance :) [05:20] np [05:55] hello [05:56] does bzr support checkouts of only portions of a source tree? or do you have to get the whole thing? [05:56] i haven't been able to get a straight answer :/ [05:56] no [05:56] where source tree = branch [05:58] we host multipule projects in our suppository, it would be possible to create branches for each of the projects, right? [05:58] *repository [05:58] i genuinely typo'd that >_> [05:59] yes [05:59] ah i see. [05:59] bob2, and you can check out each branch independently if my understand is correct, right? [05:59] yup [05:59] horray [05:59] thanks [06:26] markh: bzr.exe with xmloutput, worked like a charm :D [06:27] Verterok: excellent ;) [06:27] * Verterok sends the patch [06:28] Verterok: cool [06:28] indeed :-D [07:04] * Verterok heads to bed [07:05] seeya later [07:54] abada abada abada, thats all folks [10:43] finally, hi all [10:43] How to get the changes from the initial revision? [10:43] (using the bzrlib api) [10:45] Leonidas: current tree vs revision 1? [10:45] lifeless: but that does not show me what was added in revision 1. I need to use something like: [10:45] bzr diff -r ..1 [10:46] so I need the first revtree and the revision 1 revtree [10:46] repository.revision_tree(NULL_REVISION) [10:47] ahh! Where is NULL_REVISION defined? [10:49] bzrlib.revision.NULL_REVISION, ok === mark1 is now known as markh === mark1 is now known as markh [11:21] Hello all, can someone please tell me what's happening here? http://paste.ubuntu.com/40393/ [11:25] bad stuff :P [11:25] (hi mate) [11:25] Kamping_Kaiser: hi. [11:34] jpds: You can't upgrade over bzr+ssh [11:35] RAOF: So what do I do? [11:35] jpds: You can over sftp, but that takes quite some time; there's an open bug on the bzr-launchpad integration for a "upgrade this branch" button. [11:36] Be warned: remote upgrades over sftp aren't exactly lightning fast. Bring a packed lunch :( [11:43] hello [11:44] whenever i do bzr upgrade i get this error and a corrupted repo: bzr: ERROR: Cannot convert to format . Does not support rich root data. [11:48] you want to upgrade to --rick-root-pack (probably) [11:48] and corrupted repo in what way? [11:50] luks: i move .bzr.backup back to .bzr and it doesn't recognise it as a repo [11:50] so my only option then is to delete the whole thing [11:51] "doesn't recognise" isn't very specific [11:51] bzr: ERROR: Not a branch [11:51] it upgrade corrupts anything it's a serious bug [11:51] let me do it again [11:51] what's inside the .bzr directory? [11:51] *if [11:52] let me reupgrade to tell you for sure [11:52] oh it works now [11:52] that's odd [11:52] well, not the upgrade, but the backup [11:53] is rich root pack better than the one i have currently? [11:53] i don't understand why it fails, though [11:53] it succeeded upgrading to that, if i push will the other repo also get upgraded? [11:54] it isn't better [11:54] why upgrade to that then? [11:54] but if you need to support branches from bzr-svn, you need to use it [11:54] oh [11:54] is it worse? [11:54] no [11:55] ah, okay then [11:55] it just supports a feature needed by bzr-svn [11:55] ah [11:55] eventually the default format will support something like that too and everyone will stop getting confused :) [11:55] Stavros: and no, push will not upgrade it [11:56] luks: ah, thanks === mark1 is now known as markh [12:14] hello [12:15] i'm made a branch trunk/foo, but when i go to do something like bzr co http://example/trunk, foo doesn't show up [12:16] if your branch is trunk/foo, you should checkout trunk/foo :) [12:16] lifeless, i want the whole thing though (trunk/foo included) [12:17] no, it doesn't work like svn [12:17] :( [12:17] is there any way i can make a branch that behaves that way? [12:17] Spaz: you want a branch that contains other branches? [12:17] lifeless, yes, but i want those branches to also be able to be checked out not just individually, but all at once [12:18] Spaz: bzr really isn't gear to do that [12:18] *geared* [12:18] :( [12:18] (none of the modern DVCS's are) [12:18] "bzr multi-pull" can help. [12:19] On the client side, at least. [12:19] RAOF, is this a plugin of sorts? [12:20] lifeless: well, git and hg can do that, but it's not as streamlined as in svn [12:20] It's in bzrtools, I believe. [12:20] bzr multi-pull will pull all the branches under the current directory. At least that's how I use it :) [12:20] having a bzr extension that does something like http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html would be nice [12:20] Isn't that subtree support? [12:20] another question [12:21] luks: they don't do the same thing [12:21] I may have got that wrong, though. [12:21] luks: gits nested tree is similar to bzr's, hg's is very different [12:21] wait nvm [12:21] luks: and none are analagous to svn's system [12:21] i was going to ask if bzr had plans for arbitrary checkouts, but i'll just use nested branches for now [12:21] lifeless: git's submodules are not bound to specific revision, as far as I know [12:22] luks: they are refs [12:22] so it works kind of like svn:externals [12:22] Ah, so submodules appear to be svn externals. Which isn't what he's after, anyway. [12:22] bzr multi-pull works :) [12:22] luks: "Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit." [12:22] uh oh [12:22] sorry then [12:22] its ok :) [12:23] so it's the same principle as bzr subtrees, but not as integrated [12:23] while it's kind of an "argh >_<" thing for me, it's not like "argh let's go back to svn" kind of thing [12:23] but I'm not prone to random wrong statements:> [12:23] actually I think git and bzr subtrees/submodules will be nearly identical [12:23] we've got very similar model in this regard [12:23] I'd like more something like svn externals [12:24] yeah, we have a second iteration planned that will be closer [12:24] Spaz: we have plans for arbitrary checkouts [12:24] shouldn't be hard to do as a plugin using git submodule's UI though [12:24] lifeless, :o [12:24] Spaz: 'views' is what we'll call them [12:25] hrm views? [12:25] sounds like it's read-only [12:25] >_> [12:25] no more than any other operation [12:25] oh nice [12:26] it will just select a subset of the tree to put on disk [12:26] :D [12:26] the same amount of history will be needed locally etc etc [12:26] ah ok [12:26] because to merge full trees you need access to the full tree metadata [12:26] any clue about what version this might happen? (i'm asking for mere speculation, i'm not asking for "when will it be done" etc.) [12:26] its *why* DVCS works efficiently [12:26] 1.8/1.9 [12:27] ah ok [12:33] can somebody quickly help... I installed bzr on my server. I can commit my files... But an other user when he want to commit gets "Cannot lock LockDir" How can I solve this? [12:35] enquest: permissions I would say [12:35] enquest: does he have write permission ? [12:35] I made a group "admin" and added him and me to that group [12:36] what should I do more? [12:36] check the permissions on the contents of .bzr/ [12:36] I bet its wrong group or some such [12:37] lifeless, the permissions on the .bzr is drwxr-xr-x [12:38] and enquest:admin [12:38] so I should give write permissions to admin? [12:39] is that correct lifeless [12:42] I would say so :) [12:51] hi [12:53] The bzr faq says that there are other version control systems better suited for binary files (such as images), but it gives no references. Does anyone has a good suggestion? [12:54] I don't know of anything that has a smart delta compression of compressed data [12:59] luks: thanks. Just the way the FAQ is written, it suggest that such tools exist. I use bazaar for coding, but I want something similar for my projects which consist of only images. [13:00] there are systems that handle binary data better in general [13:00] but for compressed content, such as images or video, it doesn't help much [13:02] luks: are some of these systems free? could you give some names? [13:02] svn does binary xdelta compression [13:03] but what exactly are you doing? [13:04] well, I am a visual artist, so the result of my projects consist of images [13:04] some are generated by self written code, some are manipulated in gimp, ... [13:05] what format are they in? [13:06] I mostly use png for generated images, as it is compressed without quality loss [13:06] anyway, I don't think you will see any significant differences between most VCSes [13:06] but some are also in svg [13:07] are svg files typically gzipd? [13:07] no [13:08] I generate svg through pycairo [13:09] I'd personally just use bzr if you already know it [13:10] I wouldn't use bzr only if the files are huge [13:10] it doesn't handle that well === andreas__ is now known as ahasenack [13:26] Hi. I have a local branch from a shared repository and I would like to add the branch to the main repository, while keeping it a branch. How do I do that? [13:28] not sure what do you mean by that [13:28] that is 'the main repository'? [13:28] *what [13:29] by main repository I mean the remote, shared repository which contains the trunk branch [13:29] just push it there [13:29] if you push it to a location under the repository, it will automatically use it [13:29] I see, thank you [13:31] So do I specify bzr push sftp://remote/reporoot/mynewbranch or do I omit "mynewbranch"? [13:31] including mynewbranch, the command is correct [13:32] thanks again === thunderstruck is now known as gnomefreak [14:16] I have a problem using bzr-gtk, namely the visualize command, on my gentoo box. I am using bazaar 1.1.0 with bzr-gtk 0.94.0 I installed it by extracting the tarball into /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk Error is pasted here: http://rafb.net/p/P9TdMc24.html [14:17] you need newer bzr [14:18] luks: Ok, I will try, just thought it should work with these versions cause http://bazaar-vcs.org/bzr-gtk said bzr-gtk 0.94.0 should work with >=1.0 [14:18] 1.5, probably [14:18] looks like a lie :) [14:19] hm, no [14:19] looks like the personal taste of gentoo developers prevented a stable program to get into stable tree, once more :/ [14:19] iter_ancestry was added earlier [14:19] hm... [14:19] still worth a try to upgrade [14:19] there is a bzr overlay for gentoo [14:20] https://launchpad.net/bzr-gentoo-overlay/ [14:21] bzr 1.5 is already in the portage tree, but tagged as ~x86 not x86 [14:21] Easy to just add it to portage.keywords [14:22] I know gentoo, and I did so, but it is not a nice solution because mixing arch with ~arch sometimes breaks things [14:23] My package.keywords is as long as my arm :) [14:23] I prefer to use stable generally, but push certain things along as I need them. [14:24] what does the ~ mean? [14:24] arch-masked [14:24] Effectively the 'unstable' branch [14:24] so, "doesn't work on x86"? [14:25] More like they're not confident, not sufficiently tested, they can't be arsed etc [14:26] gnome basically stays in ~ for about six months after release [14:26] pickscrape: it's more a question of the maintainers taste. e.g. pidgin 2.4 was already very long in portage (~x86) but it became x86 not because it was said to be stable enough but just because 2.3 did not work anymore [14:27] cfchris6: == can't be arsed :) [14:27] just ~x86? what about all the other platforms? [14:28] Freaky: In general it was ~arch, for more exotic ones I don't know [14:29] Other arches could be quicker or slower. They have dedicated arch teams, so it depends on how on the ball they are when compared to the maintainer of the package itself. [14:30] anyway, with bzr-1.5 it works now, thank you [14:32] The only downside of the bzr gentoo overlay is that it includes beta packages. It would be nice to have a stable version of the overlay [14:50] * vila wonders who put water into his gusty -> hardy upgrade after midnight [14:50] vila: I put sugar in the tank, but I didn't have time to get water. Must have been someone else. [14:51] I guess so, but the last gremlin needed a .xmodmaprc to get killed. though one :-/ [14:52] Check the power cord to your clock. [14:52] lightbulb ! The clock damn it ! Skewed again ! [14:53] vila: I'm just waiting for your next hhtp patch [14:53] :-) [14:53] hm... it seems beuno isn't around yet [14:53] time to get the 1.6-final out the door [14:53] anyone have any blockers? [14:53] Last chance [14:55] the last days were all about reorganizing my hardware and the associated softs, I just have to commit now. [15:02] siretart, thanks, much appreciated :-) [15:03] * jelmer hopes this is also the first step towards loggerhead on bzr.debian.org.. [15:06] jelmer: well, we almost got webserve on there, but it missed etch, and then the project seemed to stall, so I refrained from packaging it [15:08] ahh [15:09] so it looks like we'll be out of luck again, since we're already past freeze time :-/ [15:09] yeah, though they may be willing to use a backport once it is actually in === cody-somerville_ is now known as cody-somerville [15:15] james_w: ah, cool, that's definitely worth asking for [15:16] I agree [15:17] jelmer: I think they prefer packages from backports.org, but asking might be a good idea anyway [16:07] bug 5 [16:07] Launchpad bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] https://launchpad.net/bugs/5 === cody-somerville_ is now known as cody-somerville === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.6-final is out !!! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [17:50] yay :) [17:50] no more RCs [17:50] whoah [17:51] Woah. [17:51] Wait, so there was no rc7? Damn! [17:51] Congrats on the release. :) [17:51] * Peng_ has to run. [17:58] I'm trying to merge this branch https://code.launchpad.net/~richies/hypernucleus/richie into this branch https://code.launchpad.net/~manuq/hypernucleus/manuq but the two branches have different revision histories (I creaed mine wrong!). How do I merge them? [17:58] It gives me this error: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. [18:10] RichW, the two branches you're trying to merge are not related [18:11] RichW, are you really sure you'd like to merge them? [18:11] RichW, if so, just specify -r0..-1 to "bzr merge" [18:14] * mw starts his bzr 1.6 for opensuse packages [18:14] So... what is the proper debian string for the 1.6 release? [18:15] "1.6~bazaar1" sorts before "1.6~rc5..." [18:15] Should it be "1.6-1~bazaar1" [18:15] 1.6-1~bazaar1 [18:15] or "1.6~1~bazaar1" ? [18:15] thanks luks [18:16] 1.6~bazaar1 would mean a native debian package [18:16] err, surely it's just 1.6-1 ? [18:16] yes, but not for ppa packages [18:17] oh, right, PPA [18:19] jelmer: ok il try it, some things happened and it all went wrong :) [18:20] RichW: honestly, with such branches I think diff/patch is the best you can do [18:23] luks: ok, I tried your method to build the package, care to try it out? [18:23] It is in my ppa [18:23] one sec [18:23] https://launchpad.net/~jameinel/+archive [18:23] did you upload the packages? [18:24] * luks doesn't see them [18:24] jelmer, james_w: If you want to give it a poke, too. I'm using bzr-debbuild for this [18:24] luks: upload just finished [18:24] ah, it will take a moment then [18:24] jam: I just uploaded 1.6-1 to Debian sid [18:25] s/sid/experimental [18:25] jam: What branch is the ppa build created from? I can't instal the package here, but I can look at the changes. [18:26] jelmer: it is built from the tarball [18:26] Or you mean the "debian" branch? [18:26] I just have that locally [18:26] jam: yeah, the debian branch [18:27] It is originally branched from luks work [18:27] because I'm just playing with it for now [18:27] I'll switch to the "official" ones later [18:27] jelmer: I'll push it real quick [18:27] well, I didn't change anything but fixing the watch files [18:28] jelmer: when it finishes: lp:~jameinel/+junk/packaging-hardy [18:28] * jelmer wonders if the ppa branch shares any ancestry with the pkg-bazaar debian team branch [18:28] luks: well, and you "released" ~bazaar2 [18:28] etc [18:28] jam, thanks [18:28] oh, yes :) [18:29] ah, looks like it was based on the Debian packaging branch, it's just diverged since then [18:29] luks: LP has just accepted my submission and is building now [18:29] jelmer: seems like we should mostly keep them in sync [18:30] lamont: I know you had concern about our earlier packaging, would you care to take a look at my attempt at a 1.6-final package? [18:30] jam: my build just finished. :-) [18:31] luks: Would you know why, export FOO="a b c"; for foo in $FOO; do echo $foo; done always gives them all at the same time? [18:31] luks: I'm trying to use your documentation [18:31] but it seems ZSH doesn't do "for" like bash/sh [18:32] jam: gives me 3 lines of output.... [18:32] jam, package looks good to me [18:33] lamont: I don't know if that is good or bad [18:34] jam: it's correct. :-) [18:34] and yeah, package looks fine [18:34] yay \o/ [18:34] the 3 lines was wrt $FOO above [18:34] jam, there's not a lot of differences with the debian debian package [18:34] lamont: using zsh or bash? [18:34]