[00:19] jelmer: http://yellow5.com/pokey/archive/pokey80_3.gif [00:43] james_w`: around? [00:44] Bazaar just took up 765 MB of ram [00:48] TDJACR: you're adding some large files to bzr? === james_w` is now known as james_w [01:03] lifeless: briefly [01:04] nvm, filed a bug [01:09] spiv: No, I branched launchpad [01:11] TDJACR: oh, right. That's a very large branch, we've been working on improving the memory use in bzr's trunk [01:13] TDJACR: bzr's trunk plus a couple of patches that will land shortly uses roughly 2/3rds of the memory of 2.0.1 I believe, and that should keep improving as we work towards 2.1 [01:15] TDJACR: (there's ~65000 revisions in Launchpad's history last time I checked, and about 7000 files!) [01:16] TDJACR: so, basically, known problem, but we're working on it [01:20] vila: buildbot trunk has my subunit patch [01:59] back [02:48] lifeless: so, how far away is a proper fix for the --subunit issue that's preventing PQM from rejecting test failures? [02:49] lifeless: I'm wondering if we should temporarily remove the --subunit option until we figure out a better fix. [02:49] spiv: I'm hoping to start on the cleanup this avo [02:49] just want to get one of the dx ppa builds up first [02:50] still solving teething problems [02:50] lifeless: cool, "this arvo" is a good enough answer for me. [02:51] lifeless: mind if I assign the bzr bug to you? [02:54] * spiv updates the bug description [02:55] spiv: uhm [02:55] spiv: I don't particularly care, but its a different bug I think [02:55] spiv: and its not my top priority, I'm just trying to squeeze it it [02:55] *in* [02:56] Hmm. [02:57] right now I don't recall how messy the badly mapped things are [02:57] basically need to un-messy them and get detection out of the TestResult and back to the TestCase [02:57] it might be an hour, it might be a day [02:59] and then we'll need the subunit in the pqm updated? [03:00] possibly. I won't try to depend on the latest, but I may have to. [03:00] have a look at the code ;) [03:00] Ok. I think I will temporarily disable the --subunit option then. The niftiness isn't quite worth the discomfort, and it'll be easy to turn back on when it's sorted. [03:01] Thanks. [04:33] * spiv has a late lunch [04:43] spiv: subunit doesn't need improving [04:43] spiv: I've tried to correct this meme in the bug, but its not seeming to stick, so I'm coming direct :) [04:44] lifeless: please feel free to edit the description and summary directly :P [04:45] lifeless: I wrote the most recent comment before seeing yours about it not being subunit that needs improving, though. [04:45] spiv: kk [04:45] spiv: I'm not stressed, I just want to fix the meme :) [05:06] <_Andrew> hi [05:07] <_Andrew> I'm getting the error "These branches have diverged. Use the missing command to see how." [05:07] <_Andrew> What's the "missing" command and if it's missing how do I use it? [05:08] "bzr missing" [05:08] <_Andrew> ah, I was doing it wrong.. --missing [05:08] And you'll probably want to use "bzr merge" rather than "bzr pull" to combine the different changes made on the two branches. [05:09] <_Andrew> ah ok [05:09] <_Andrew> Yes that's working [05:10] <_Andrew> Since I'm already here could you tell me what "M*" means? It's that a conflicted merge? [05:10] See "bzr help status-flags" [05:11] M means the contents of the file have changed (been modified), * means the execute bit changed. [05:12] <_Andrew> ok thanks for the help! :) [05:35] <_Andrew> Actually I have another question, sorry. Say I have branch A with a file and I want to merge changes from branch B, but I don't want branch A to merge changes from a specific file, how do I do that? [05:52] _Andrew: You can do "bzr merge path/to/branch-A/some/file" [05:52] (IIRC) [05:54] _Andrew: note that cherrypicking a change like that won't be tracked by bzr though, i.e. bzr won't remember that you've done that merge (unlike most merges), so it might cause conflicts next time you merge from that branch. [05:56] <_Andrew> Can't you just lock the file or something? [05:56] <_Andrew> It's an image and I don't want the images to change [06:36] _Andrew: oh, you want to ignore changes to a specific file [06:37] _Andrew: you can do "bzr revert that_file" after the merge [06:37] (sorry, I misread your question) [06:38] _Andrew: in general there's no way to say "only these parts of this branch should change". You can split a project into multiple branches, though, which may help. [06:45] Question: for shared repositories to work, do you need to have them be subdirectories in the shared parents root? Or could I have them (on Windows for instance) as far apart as on different drives? [06:47] KhaZ_: you need the branches to be inside the shared repository directory, but you can have the working tree(s) for those branches anywhere. [06:49] Fascinating. I never thought about separating the branch from the working dir, but I suppose that's always been the case; I just assumed they were one in the same. [06:49] [Branches inside a shared repository are tiny; the things that take up space are the history (which is inside the shared repo) and the working copy that you can edit (which does not have to be co-located with the branch)] [06:50] If you do "bzr init-repo --no-trees" (or later "bzr reconfigure --with-no-trees"), then branches in that repo by default will have no working tree. You can then do "bzr checkout /path/to/repo/branch" from any directory you like. [06:51] Er, [06:51] "bzr checkout --lightweight ..." [06:51] The --lightweight is important, otherwise it will make a full copy of the history rather than use the branch's repo :) [06:52] Interesting. So say I currently have two repos that (I believe) are 'standalone', but they really are just clones of each other that I do work in. I can use reconfigure to change it to a shared repository scheme? [06:53] Yes, I believe you can do "bzr reconfigure --use-shared", although I don't know the precise details. [06:54] Hrmm, I'll have to read into that. Do shared repo's have any other benefit besides space saving? [06:54] Just space-saving, really. [06:54] (Although that can in turn lead to speed improvements) [06:54] well branching is quicker inside it because you don't have to copy as much [06:55] right yes [06:55] e.g. the time to do "bzr branch" will be much much faster, as dash says :) [06:56] Right. Hrmm, maybe I'll put it on the backburner then... Don't do much branching luckily. :) Still, good to know. [06:56] KhaZ_: If you have two branches inside a parent, and you cd to that parent and do "bzr init-repo ." then you should be able to cd to each branch and do "bzr reconfigure --use-shared". [06:57] s/inside a parent/inside a parent directory/ [06:58] But literally the parent - not just any common ancestor, yeah? [06:58] I currently have two paths that could be shared, but they're basically about four levels apart from each other (I'm versioning the contents of my work (Perforce) repo, but source code only, is why I ask). [06:59] (On a side note, shazbot is sourceforge's git cloning slow!) [07:00] I'm not sure how fussy bzr reconfigure is. [07:00] Interesting. I might try that then. [07:01] I suppose you could always make the repo in the immediate parent and then after the reconfigures move the .bzr of the repo up a few levels. [07:01] hi all [07:02] Hey vila [07:03] vila: I've disabled --subunit in make check for now until lifeless figures out what needs to be done to make it do what we need [07:03] vila: so hopefully babune will stay nice and green from now on [07:04] spiv: I've read that and lifeless replies and announce that it will work on it on the bzr side, thanks [07:06] spiv: well, babune has a bad flu since a couple of weeks with the leaking tests and then the terminal width saga took me a while to figure, so it's good to know *that* failure source is closed :-) [07:22] hi vila [07:59] what's this babune thing people are talking about? [07:59] jelmer: buildbot test server that vila runs [07:59] ah, thanks [07:59] hi vila [08:00] hi Ian ! [08:00] jelmer: BAzaar BUild botNEt [08:01] :-) [08:02] jelmer: https://launchpad.net/bzr-buildbot-net and http://babune.ladeuil.net:26862/ for the full monty [08:03] * igc dinner - night all [08:05] g'night Ian [09:09] Just a quick question, how do I install the bzr explorer (and run it?) [09:09] I executed the setup.py install, tried "bzr explorer", but the explorer plugin cannot be loaded... === weigon__ is now known as weigon [09:32] Ok, reinstalling qbzr fixed the issue ^^ [09:33] cpf_: what OS/versions are you using ? [09:37] vila: debian, python 2.5.4, bzr 2.0.1 [09:38] cpf_: ok, so you're installing the plugins system-wide and not in your ~/.bazaar directory ? [09:39] cpf_: and when you said "but the explorer plugin cannot be loaded" did you get a proper message telling you about an unmet dependency on qbzr or just a "can't load plugin" kind of message ? [09:42] vila: Uh, 10:32 < cpf_> Ok, reinstalling qbzr fixed the issue ^^ [09:43] I ended up installing in ~/.bazaar/plugins, but it's all the same now, it works like a charm XD [09:45] vila: Oh, and no message about an unmet dependency. Just: "Unable to load plugin 'explorer' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'" (When it was installed globally) [09:45] cpf_: ha, that was my fear, hence my question [09:46] cpf_: can you file a bug against bzr-explorer on lp mentioning your versions so that a better error message can be issued [09:46] and by the way, what made you suspect qbzr ? [09:46] http://doc.bazaar-vcs.org/explorer/en/install-source.html << End of page [09:46] I had all the rest... [09:46] Thought I had qbzr already (used to have it at least) [09:46] Must've lost it somewhere xD [09:48] either bzr-explorer setup.py or __init__.py should report it more nicely IMHO :-/ [09:49] I agree, but __init__.py looks scary :( [10:34] Can BZR_PLUGIN_PATH point directly to a directory that contains a single plugin or should it point to a directory that contains other directories with plugins (like ~/.bazaar/plugins)? [10:35] The latter. [10:35] :( [10:36] Maybe you can trick it with some symlinks? [10:37] vila: what do you think of allowing a path to name a plugin [10:38] I think I'll have to. I am developing a plugin. Right now the development is in a subdir of ~/.bazaar/plugins/. But I'd like to move it to another local repo (point 1) and use the pipelines plugin that creates a serires of directories/branch (point 2). [10:38] e.g/ foo:pluginname@directory [10:39] lifeless: I think it's an inferior solution if you want to test a specific version of a plugin *because* that plugin may depend on other plugins [10:39] vila: well yes, but its a recurring request [10:39] so I think it's better to create a dedicated directory for the tests where you put symlinks to whatever plugins you want [10:39] lifeless: true [10:39] may be we should add two command lines options: --plugins and --single-plugin ? [10:40] adding the command-line option is more or less missing right now (I use BZR_PLUGIN_PATH=-site all the time and far more typing than --plugins=-site [10:40] vila: I'd rather come up with a good syntax to specify in the path [10:41] lifeless: like a leading-but-otherwise-forbidden char ? [10:41] Maybe the semantics of BZR_PLUGIN_PATH could be changed to mean: if the directory itself does not contain a module at the top level, then it act like it does not. Otherwise, if the BZR_PLUGIN_PATH contains a plugin in the top level, then load that without recursion [10:41] gioele: can't do that [10:41] gioele: 8-( [10:41] need a plugin name [10:42] lifeless: why? [10:42] (btw I cannot find a complete example on the use of BZR_PLUGIN_PATH in the documentation, just quick references) [10:42] gioele: because plugins get loaded into bzrlib.plugins.NAME [10:43] gioele: there is, wait [10:43] gioele: which makes them regular python packages/modules rather than 'different' things [10:44] lifeless: can't you say "load the python module that lies in exactly that directory"? [10:44] gioele: load it as what [10:44] what would its name be? [10:44] gioele: http://doc.bazaar-vcs.org/bzr.2.1.0b1/en/user-reference/index.html?highlight=bzr_plugin_path#bzr-plugin-path [10:45] lifeless: basename `dirname $path` [10:45] hi all [10:45] lifeless: +plugin: ? [10:45] gioele: that would be wrong far too often [10:46] vila: something; too tired to thing through consequences; my sketch was the one with @ before [10:46] hmm, using ':' is bad here :-/ [10:46] vila: oh, I was looking into the dev documentation. Thanks for the link [10:46] oh, that was a skecth, sorry, didn't realize [10:47] hmm, so you could override the dir name, right, that should be optional though, but I see the point [10:51] lifeless: @ is a good idea and since '+' is already mandatory, I think +[name]@directory will do fine, but the main problem I can see is that it's not a real PATH spec and will need special handling [10:52] vila: whats the + for? [10:53] +/- is used to add or remove from BPP (BZR_PLUGIN_PATH), see url abov [10:53] vila: + isn't needed then [10:53] vila: unless soeone wants to edit the path [10:53] by default you start with +user:+core:+site so if you say BPP=-site you ends up with +core [10:54] because +user is the default value for BPP [10:54] it's needed to identify magic values [10:54] I dispute that [10:54] its just code [10:54] oh, you mean when using @ [10:56] lifeless: look at the tests: [10:56] ['myplugin'], ['myplugin', '-user', '-core', '-site'] [10:57] ['myplugin', '+core', '+site', '+user'] [10:57] the former is myplugin only, the later is myplugin first [10:57] vila: I don't understand your point [10:58] lifeless: what are you disputing (I may misunderstand that :-) ? [10:58] that + is needed to use @ as I propose it be used [10:58] yes, my latest remark, + is not needed for @ [10:59] well, your latest remark was telling me tolook at the tests [10:59] because - makes no sense [10:59] so, you can understand my confusion [10:59] lifeless: sorry, I meant my remark after you said 'I dispute that' [11:00] so, I don't understand your point *after* that remark [11:00] why are you telling me to look at the tests === rml_ is now known as rml [11:00] what do I have wrong [11:00] lifeless: forget it then, I thought you disagreed with 'you mean when using @' [11:01] vila: I didn't ssay *anything* after that, except to express confusion [11:02] lifeless: ok, let's reset at: '@ does not need +' ok ? [11:02] * spiv expresses confusion with a confusing expression ;) [11:02] ok === weigon_ is now known as weigon [11:49] hello, all. I develop in a project which uses svn as main repo. I previously worked with it through git-svn and now due to general dev move to bzr I move to it too. I imported my git stuff with bzr-git but now I find myself unable to merge anything coming from bzr-svn with anything coming from bzr-git. Any help? === lamont`` is now known as lamont === mtrudel_ is now known as cyphermox [13:52] I'm having a bit of trouble figuring out how bazaar works, can someone help me out? I've created my repository, and comitted the initial files, now I don't know how working on a remote repository works. Sure I can connect fine, but in the xplorer when I connect it says its on revision one and that there are no working branches. [14:02] morning all [14:02] hello jam [14:03] Bear10_: read tutorial from this section and down http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp === davidstrauss__ is now known as davidstrauss [14:12] thanks [14:14] bialix, okay I understand this concept, but are all branches you create first local? then you upload the whole branch, and it then creates that branch on the server for others to work on it? [14:15] Peng_: the chk_map patch is on its way to pqm [14:15] vila: let me know if there is babune fallout [14:15] Bear10_: you can create branch on server first [14:15] bialix: would you by chance know how to import git-svn to bzr and have same ids on files as bzr-svn'ed branches? [14:15] it does not realy matter [14:15] * jam needs to go wrestle bzr-rewrite into submission so I can officially announce 2.1.0b1 [14:15] morning jam ! [14:15] sorry im new to this heh read everything i could now its a matter of putting it into practice [14:16] jam: if you ping me as soon as it lands, I'll make a run just for you [14:16] Bear10_: you can do it either way [14:16] jam: or if I happen to see it lands before you ping me, I'll telll you [14:16] phcoder: I can't say for sure. Try asking jelmer, jam, vila and lifeless [14:16] *I* tend to create branches locally, and then push them when I'm ready for it [14:16] hi guys [14:16] hey abilx [14:17] phcoder: svn => git => bzr is going to be very difficult to get identical to svn => bzr [14:17] jam, that seems most logical (to me) [14:17] lol [14:17] I would recommend using "git dpush" back into svn, and then pulling from there [14:17] vila: :-# [14:17] Bear10_: of course, I create *lots* of branches, and push fairly regularly [14:17] wow, how did I typoed that.... [14:18] jam: you mean dcommit? It could work. I need to setup local svn for this [14:18] jam, where is the "main" build / revision of the app stored? in a branch? the root? [14:18] phcoder: right [14:18] dcommit [14:18] Bear10_: I don't quite understand the question [14:18] what "app" ? [14:18] jam, the project [14:18] sorry Alexander, I meant to type bialix, may be I should use the completion more :) [14:18] vila: I was under impression it was intended [14:19] vila: anyway you made me good lol [14:19] not at all, no idea how it occurred :-/ [14:19] jam: Great. :) [14:19] ha good :) === EdwinGrubbs is now known as Edwin-afk [14:19] vila: everything is fine [14:19] :-D [14:19] phcoder: note, though, that I think you need the *same* svn UUID, and some other such bits [14:19] Actually git preserves svn ids. Can I perhaps somehow hack bzr-git to use them to create IDs? === mrevell is now known as mrevell-lunch [14:21] okay i think i understand this now [14:21] I think a recent revision of bzr-git has some git-svn stuff. [14:22] the last line in log entries looks like " git-svn-id: svn+ssh://svn.savannah.gnu.org/grub/trunk/grub2@2618 d0de0278-0dc1-4c01-8a07-af38b3205e46" [14:22] Peng_: oh. Looks like my sid is outdated. Going to find bzr dev repo [14:22] jam: official announce will be good. it becomes bad habit to wrap tarball, build installers and then announce after a month [14:22] jam: no pun intended [14:23] bialix: well, since the 2.1.0b1 installer still doesn't work [14:23] I haven't announced [14:23] I was hoping jelmer would release an updated bzr-rewrite [14:23] but he didn't seem to notice my queries [14:23] phcoder: Note that I didn't claim it will work or anything! :P [14:23] so I'm going to have to do it myself [14:23] jam: I know. But they to gold almost 2 weeks ago [14:24] *going to gold [14:25] Peng_: I guess I'll have to find out and hack if needed. Can someone provide me an insight on how file UUIDs are generated? [14:25] or a link to dev doc should be ok [14:29] phcoder: it depends on the source and converter [14:29] I believe bzr-svn's codebase is where you want to look [14:29] IIRC it was something like branch@revno+path [14:30] I think the syntax might be a little different, but that's basically it. It includes the repo UUID. [14:30] (I think?) [14:30] How can I look at File IDs in my repo? [14:30] phcoder: Various commands accept a "--show-ids" argument. "inventory" might. [14:32] vila: what is the status of: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 [14:32] Did you decide to abandon it? [14:33] huh ? Certainly not, but you said you wanted it to be discussed, so I'm waiting :-) [14:34] Well, may be I should have summarize some more ideas I had since, but I thought there was already some meat (and code !) to start the discussion === mrevell-lunch is now known as mrevell [14:34] like, we may want to move some parts of that into bzrlib.ui.... [14:36] ...fater our discussion friday, I wasn't sure about the outcomes, having thought a bit more about COLUMNS, it seems that if we see it in os.environ, it means the user set it, so I stand by my design to obey it if present (unless proved wrong, but all my tests on various OSes so far...) [14:36] s/fater/after/ damn fingers [14:37] * vila removes his boxing gloves [14:41] bzr is downloading at 2 KB/s on otherwise decent connection. What may be the cause? [14:41] jam: what were you referring to in 'Peng_: the chk_map patch is on its way to pqm' ? [14:42] vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-chk-map/+merge/13740 [14:42] using StaticTuple in the CHKMap code. [14:43] pqm queue is empty... [14:44] phcoder: bzr ls --show-ids [14:46] bialix: already found it, thanks. When I'll download bzr at this 2KB/s I'll get hacking on it. [14:46] I'll probably go with lightweight checkout [14:47] you can get tarball then [14:47] jam: so you didn't submit it to pqm yet ? [14:47] vila: it is submitted, and going through testing now [14:47] unless it got rejected... [14:48] hmm.... I sent it, I'll try again, I guess [14:48] may be some delay between you and pqm... [14:49] No, I'm just full of it [14:49] I realized I wanted to update NEWS before submitting [14:49] and then forgot to push and then submit [14:49] happens :-/ [14:51] Tarball downloading is at 400KB/s. Checkout is at 2KB/s. Why is this? Unfortunately I have the same problem on grub2 bzr too [14:52] phcoder: what version of bzr? [14:52] vila, Peng: now it is *really* there [14:53] phcoder@debian:~/repos$ bzr version [14:53] Bazaar (bzr) 2.0.1 [14:53] jam: ok [14:54] jam: I haven't read the patch in detail, so just a quick check: it doesn't makes the C extension mandatory right ? (Welll babune *will* tell, but you're faster :-) [14:55] vila: it isn't supposed to. It *is* supposed to make using one of the StaticTuple implementations mandatory [14:55] errrr, I thought spiv said he desactivated --subunit on qpm but I'm still seeing the progress report... [14:56] ohhh, I missed more than I thought then, you made python and C impls. for StaticTuple ? [14:56] I thought you keep using tuple for python... [14:57] link here http://bazaar-vcs.org/BzrPlugins to bzr-svn is broken can somone provide me the good one? [14:58] vila: he did, and it is a different progress indicator [14:58] hence why it says "0%" [14:58] vila: _static_tuple_py.py inherits from 'tuple' [14:58] rather than wrapping it [14:58] so that you don't get 2x memory *bloat* when not running the extensions [14:58] ok [14:58] phcoder: 'bzr branch lp:bzr-svn' ? [15:00] jam: BTW, when using _static_tuple_py, does intern() intern forever? [15:00] jam: by the way, one of the expected outcome from reducing memory consumption was also to reduce time spent handling it, did you see some significant performance improvement there ? [15:00] Peng_: yes, I can't mutate the refcount of native python objects [15:00] jam: worked. Thanks [15:01] vila: 'time bzr branch launchpad' went from 10-11m => 8.5m [15:01] jam: nice ! [15:01] vila: I think it is mostly from removing GC objects [15:01] which I *think* has a quadratic effect [15:02] everytime you allocate N gc objects, it does a gc sweep [15:02] and then you have +N objects [15:02] jam: ...That's kind of bad. [15:02] often more than linear yes [15:02] so after doing 100k objects, you have triggered 100k / 700 sweeps, and each one at 700 objs, 1400objs, ... etc [15:04] anyway, I expect small to no improvement for "bzr branch bzr" but a modest improvement for 'bzr branch lp' [15:04] and probably an even bigger on for "bzr branch mysql"... probably quite significant for "bzr branch OOo" [15:06] is there a way to tell the webdav plugin to remember user and pass ? [15:09] visik7: yes, use authentication.conf [15:10] vila but I need to specify the user/pass in that file ? [15:11] what's the difference of specifying if in branch.conf as http+webdav://username:password@domain/path ? [15:11] visik7: well, either that or you type them [15:11] I would a way to autosave from the command line when I first branch/checkout [15:12] autosave is a can of worms nobody want to open now [15:12] visik7: but patches welcome ! [15:13] specifying them in branch.conf is more risky and branch specific whereas authentication.conf will allow you to specify them *once* for each host [15:13] or even a whole domain depending on your usage, see the doc [15:14] ok [15:14] visik7: http://doc.bazaar-vcs.org/development/en/user-reference/index.html#authentication-definitions [15:28] $ bzr upgrade --format=rich-root-pack [15:28] bzr: ERROR: Cannot convert from format Branch format 7 to format . No converter [15:28] am I out of luck? [15:28] with bzr 2.0.1 [15:30] nyu: that is a downgrade, is there a reason you want to do so? [15:30] jam: I want to remain compatible with bzr 1.5 [15:32] nyu: I guess that isn't something we specifically worked on. let me check the code a bit [15:34] yeah, i think Branch7 was introduced in bzr 1.6... [15:34] * nyu screams vendor lock-in ;-) [15:34] is there a reason 1.5? [15:34] well [15:34] I use 1.5 myself, as it comes in debian lenny [15:35] and I wouldn't want to make it harder for all lenny users to access the repo [15:35] nyu: just make it available via svn / git as well..? [15:36] actually it comes from svn, but we only have trunk there [15:36] uhm. I guess most users can live with just trunk [15:37] nyu: do users use svn / bzr? [15:38] well, I was thinking more s/users/casual contributors/ [15:39] the kind of people who send a patch once and are never seen again [15:39] nyu: well, it is trivial to do the downgrade [15:39] we just didn't implement it [15:39] I think it will be about a 10-line plugin [15:39] give me a sec [15:39] oh [15:39] phcoder: sounds like an easier approach [15:40] nyu: what an effect when a GNU maintainer asks ;) [15:40] hey, I wasn't asking [15:40] just suggesting :-) [15:41] want me to give up with 1.5 completely? [15:42] nyu: what project is this btw ? [15:42] d1b: GRUB [15:42] oh. [15:42] grub uses bzr? [15:42] to some extent yes :-) [15:42] i only see svn on the site tho. [15:43] maybe we end up switching completely [15:43] oh, haven't had time to update it [15:43] besides, the website is still in *CVS* [15:43] nyu: plz do provide another version control system to download stuff via tho :) -> im also on lenny and don't want to update foo just to get the dev current stuff [15:43] etc. [15:44] nyu: well, I looked at implementing a converter, but it looks like the upgrade code doesn't want to do it cleanly. So I'll give you the real secret way [15:44] echo "Bazaar Branch Format 6 (bzr 0.15)" > .bzr/branch/format [15:44] nyu: as long as you aren't using stacking, format 6 is identical to format 7 [15:44] jam: lol [15:45] ok :-) [15:45] the format bump was mostly a 'compatibility' flag. [15:45] We didn't want older bzr's to think they could write to a stacked branch [15:45] and then bork the content [15:45] if I don't know what stacking is, does that mean I'm not using it? [15:45] 'bzr branch --stacked' [15:46] I doubt you are using it [15:46] possibly on Launchpad, but that doesn't sound like where you are doing this stuff [15:46] $ bzr branch sid/mips [15:46] bzr: ERROR: Unknown working tree format: 'Bazaar Working Tree Format 6 (bzr 1.14)\n' [15:46] uhm [15:47] nyu: 'bzr2.0 remove-tree' 'bzr1.5 co .' [15:48] actually, I think "bzr remove-tree; bzr co" would do just fine with 2.0 [15:49] still same error [15:49] note this branch is an import from git [15:51] nyu: well, if you just do "bzr remove-tree" then it shouldn't be possible. Though I'm wondering if there is another WT somewhere that is confusing it. [15:52] WT? [15:52] well, this branch is inside a rich-pack [15:52] and I'm branching to outside of it [15:53] same problem when branching to inside the rich-pack [15:57] WT == working tree [16:04] jam: babune run started [16:18] vila: thx === sdboyer is now known as agentrickards_lu === agentrickards_lu is now known as sdboyer === deryck is now known as deryck[lunch] [16:49] which API function is used to add a file to a repo? === beuno is now known as beuno-lunch [16:57] I'm using WorkingTree.smart_add [17:10] hello, is there a documentation somewhere how to handle binary conflicts? [17:11] mv file.ext.OTHER file.ext causes 'unknown file.ext' message to status, so that sounds like a bad idea. [17:19] Milo-: That's odd - Are you sure you did not have a typo. [17:19] it gives two messages to status [17:19] "removed file.ext" and "unknown file.ext" [17:20] and when you finally hit bzr resolve, it says all is fine, but when you commit is says "missing file.ext.OTHER" [17:20] Milo-: If not confidential, please pastebin the actual output [17:20] I'm thinking I should move file over another like that. [17:20] I shouldn't* [17:21] can't, team mate handled that conflict [17:21] with my instructions. [17:21] and he used windows's bazaar integration.. === deryck[lunch] is now known as deryck [17:21] Milo-: "missing file.ext.OTHER" - that sounds like "file.ext.OTHER" was committed. [17:22] GaryvdM indeed :/ [17:23]