[00:00] igc, spiv: call now [00:04] jelmer: could i get you to review the latest seahorse-integration? [00:14] finally [00:15] core vf files passing tests with finished largely gone [00:15] wtg! [00:17] schierbeck: sure, one sec [00:38] jelmer: okay, another iteration coming your way -- we'll land this tonight! [00:38] schierbeck: feel free to just merge - I voted bb:tweak [00:39] okay [00:39] ather than bb:resubmit [00:39] I trust you are able to remove that one line :-) [00:42] hehe :) [00:42] jelmer: by the way, i've got this in the works: lp:~dasch/bzr-gtk/branchview-selected-row-color/ [00:43] we seem to be better on track than bzr.dev this week though ;-) [00:43] it adds a stroke of white around the line graph when selected [00:43] jelmer: yeah, they seemed panic-stricken [00:44] schierbeck: any chance you can have a look at my mime patch? [00:44] jelmer: sure [00:47] jelmer: i've got an actual patch icon, if you'd like it [00:47] tango styled and everything [00:47] i see you use the bazaar icon [00:48] yep [00:50] jelmer: i'll mail it to you [00:55] lunch break for me [00:56] jelmer: can you receive over irc? [00:56] f00k it, i'll jsut mail them [00:58] * igc reviewing spiv's patch for #207558 now [01:00] jelmer: this is also a possibility: http://tango.freedesktop.org/User:Dobey#Tango_Icon_Theme_Icons_.28CC-By-SA_2.5.29 [01:01] jelmer: oh, just found where i got the icons i sent you from: http://www.quantum-bits.org/?page_id=3 [01:18] schierbeck: ah, thanks [01:41] * igc reviewing spiv's nosmart+ decorator patch [01:49] * schierbeck is going to bed [01:52] abentley: yes, please merge that [01:52] Already in PQM [01:52] sorry I missed the assert issue - here's to jam's good catch on that one [01:52] great [02:05] New bug: #211122 in bzr "bzr help cherrypick would be useful" [Wishlist,Triaged] https://launchpad.net/bugs/211122 === mw is now known as mw|out [02:14] * igc reviewing the arch-independent site directory patch now [02:21] garh test_35_wait_lock_changing [02:21] _so_ fragile [02:23] lifeless: you can kill it [02:24] i think my branch to add another exception class makes it possible to write a much cleaner test but i have not yet done so [02:24] spiv: nosmar +1 from me too [02:25] poolie: ok, that's enough good enough for me. Thanks! [02:25] this should be rarely used anyhow [02:25] we hope [02:25] Right. [02:28] I was hoping for http-bzr [02:28] just for cool factor [02:28] ? [02:28] surely that would be the opposite? [02:28] http minus bzr :) [02:28] oh i see [02:29] standards, pfft [02:29] presumably we should use the unicode MINUS SIGN which looks almost but not quite like a dash? :) [02:29] I'm so totally unsure that that would be valid in the scheme [02:30] lifeless: it might not be valid, but "standards, pfft" ;) [02:34] indeed [02:34] though being able to type it in++ [02:35] it will avoid people using it accidentally :) === kiko is now known as kiko-zzz [02:51] * poolie is merging the test progress fix [03:07] lifeless: could I get your feedback on my "Playing with Stacked Branches" post? [03:09] yeah for some reason gmail thinks the time is 'undefined' [03:09] i wonder if i should reboot google? :) [03:13] abentley: do you have a moment to discuss cygwin/symlinks (re: bug 209281)? [03:13] Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,Invalid] https://launchpad.net/bugs/209281 [03:14] matthewlmcclure: Sure. [03:14] i'm not sure how to proceed since several people have expressed concerns. here are the concerns i understand: [03:15] (1) you'd like "nice" pathhames, e.g., 'old' and 'new' [03:15] (2) martin disliked forking a process to dereference the 'new' symlink [03:16] (3) i want a windows diff program to find the files it needs to diff; and it can't dereference directory symlinks or understand cygwin full paths [03:17] (4) you said you thought my original patch addressed (3) in the wrong place [03:17] re: (4) do you have a suggestion where is the right place? [03:18] _try_symlink_root [03:18] it seems to me also that (1) and (3) are fundamentally in conflict, but maybe you have a better idea than anything i've come up with [03:19] They aren't in conflict. You just make a copy of the file with a nice name. [03:19] ah, right... i can do that; it's a reasonable compromise, but it doesn't address: [03:20] ( 5) i'd like the right side of the diff to be the working copy (so it can be tweaked in the diff program) [03:21] Well, we could provide that as an optional mode, and sacrifice (1) in that case. [03:22] But mainly, we shouldn't be creating symlinks if we don't want to use them. [03:24] ok... i understand now that your primary concern is not to create the symlinks if they'll only be dereferenced [03:25] That's right. [03:25] so we have a choice: ( a) copy the right side files and get nice pathnames, or ( b) use the working tree directly and get editability [03:26] there's a precedent for ( a) on native Windows [03:26] The dereferencing was far more involved than fixing it at the source would be. [03:26] matthewlmcclure: Personally, I would prefer to make a) the default, and b) an optional mode. [03:26] ok... i'll do ( a) in one patch, and worry about an option for ( b) separately [03:27] Well, maybe I'm being hasty. [03:27] You're the first person to ask for this. [03:27] Both a) and b) are analogous to our existing Unix behavior. [03:28] a) is the same as our windows behavior. [03:28] abentley: sure [03:28] Yeah, let's do --use-real-path as a second step. It should affect both Cygwin and Windows. [03:29] lifeless: thanks. [03:29] ok, will do. [03:29] thanks for your time [03:30] matthewlmcclure: no problem [03:35] noob question: Say I pull a "pristine" tree from a public server, then pull a "working" directory from that pristine tree. If I made a bundle from the "working" tree, the bundle references the local path to that pristine tree. Is that a problem? Do I need to tell 'bundle' what the real public tree is? [03:36] eg, if I want to send the bundle to the bazaar list as a merge request ;) [03:44] didn't Google just unleash some sort of "customize your time" thing? [03:47] They also announced their partnership with Virgin to set up a colony on Mars. [03:47] markh: You should put the public location in the merge directive, either by specifying it, or by setting the "public_branch" config value on your local copy. [03:47] abentley: ah, config value makes sense - thanks [03:49] np [04:03] poolie: I've written a nanny script for Bundle Buggy to restart it if it gets a lock error. [04:03] Obviously, this is a stopgap. [04:03] yay [04:03] thanks [04:03] No problem. [04:04] I'm going to try moving it to Postgres, which I've wanted to do anyhow. [04:06] so [04:06] sqlite does document its locking policy; like I said I think there is something crackful in the python bindings; they open new transactions implicitly AFAICT. [04:28] lifeless: It could be. [04:29] It could also be a hung thread, right? [04:31] New bug: #211139 in bzr "add reports partial success incorrectly" [Undecided,New] https://launchpad.net/bugs/211139 [04:42] abentley: possibly; if it is a hung thread one would expect contention in posgresql too [04:42] abentley: I would like bb to continue to support sqlite; pgsql is a lot harder to deploy [04:43] I don't intend to stop supporting sqlite, but I want to use postgres for myself. [04:45] cool [04:45] But schema migrations are way too painful in sqlite. [04:46] they are ? [04:48] Sure. In order to add a foreign key column, you have to create a new table with the new schema, copy the data over from the original, delete the original, rename the new one into place, and re-create some indices. [04:54] weird; sqlite supports alter table ... add column [04:54] lifeless: Yes, but as far as I can tell, that doesn't support foreign key relationships. [04:55] it supports anything create table supports [04:55] http://www.sqlite.org/lang_altertable.html [04:57] I have tried it. I couldn't get it to work. [04:59] Note that the foreign key relationship is not specified as part of a column definition. It's some kind of suffix on the CREATE TABLE command. [05:00] what syntax are you using [05:01] It has been a while since I tried it. [05:01] What would you suggest? I've got an sqlite prompt open. [05:03] Here's something that doesn't work: ALTER TABLE vote ADD COLUMN dogbert INTEGER, FOREIGN KEY(dogbert) REFERENCES tg_user; [05:04] so, while playing around locally, a couple of my local branches show "public branch" and "submit branch" values have been remembered as "related branches". How do I remove or change them? [05:04] so abentley, before trying to debug it, why are you using foreign key there at all - sqlite doesn't support foreign keys last I heard it. [05:05] http://www.sqlite.org/omitted.html [05:05] It certainly acts like it does, [05:06] https://pastebin.canonical.com/3816/ [05:08] theres nothing in there that suggests anything more than accepting the syntax [05:09] Well, I would like to add more columns that give such an impression. [05:11] Enforcing the constraint would be kinda nice, too. [05:14] and depending on what I try, I can manage to get my bundles showing both 'target_branch' and 'source_branch'. Am I correct that I just want target_branch pointing at the public branch and no value for 'source_branch'? [05:15] http://www.justatheory.com/computers/databases/sqlite/ [05:15] abentley: I think the add column syntax is infact invalid [05:15] abentley: but i'm not sure immediately how to work around that [05:18] markh: If you are not publishing branches, you want no value for source branch. [05:19] abentley: thanks [05:19] the submit_branch is remembered by merge and send, the public_branch is remembered by send only. [05:19] how can I "unremember"? [05:20] There is not "unremember". You may be better off just editing ./bzr/branch/branch.conf [05:20] it only seems to remember first time [05:20] ok [05:20] markh: If you want it to remember when it already has a remembered value, you can supply --remember. [05:20] ah - thanks [05:20] But by default we assume it's a temporary override. [05:21] I do remember seeing that now - my head is kinda exploding still though :) [05:22] lifeless: The page you gave already says that columns with unique constraints and primary keys can't be added. I think they just forgot to mention foreign keys. [05:26] abentley: sounds plausible [05:56] jml: Incidentally, hooray for bzr-svn. [05:57] oh? [05:57] After the initial branch, it makes working with banshee much nicer. [05:58] ahh :) [05:58] I need a new plunger :( [05:58] jml: yours has taken it's final plunge? [05:58] I just got a mouthful of wet coffee grinds [05:58] Mmmm, coffee grounds! [05:59] Yeah, it sucks when they get soggy; all the crunch is lost. [05:59] heh heh [05:59] i'm having trouble getting "bzr viz" to work on my Windows machine. i keep getting the error "PyGTK not installed". PyGTK *is* installed, and i'm able to run use it in a python shell. [05:59] i'm also having problems installing tortoiseBZR that might be related. when i try to do so, it says it can't find bzrlib and it needs to be in PYTHONPATH. i've tried setting this to several different things and can't get it to work. should this be set to "C:\Program Files\Bazaar" or something else? [06:00] Angelic13: I'm no Windows expert, but your PYTHONPATH should be set to the directory that contains 'bzrlib' [06:00] Angelic13: How did you install bzr? [06:00] and what does bzrlib look like in windows? [06:01] i see a bzrlib in python/Lib/site-packages/bzrlib [06:01] this only has a plugins directory and nothing else though, so i'm not sure if that's what it wants [06:01] *interesting* [06:01] fullermd: i believe i installed it with the bzr installer. it's been somet ime [06:02] I think this comes up with some regularity from using the standalone installer... [06:02] c:\Progam Files\Bazaar has the program files, and it has a lib directory, but nothing called bzrlib in there [06:02] i've searched through the whole system, and the only place there's a bzrlib is the directory in site-packages [06:04] trying an install again with the python bzr installer [06:04] that sounds like a broken install to me. [06:04] (note: I have never used Bazaar on windows) [06:04] No, I think that's what you get with the standalone installer. [06:04] fullermd: really? [06:04] is it py2exed or something? [06:04] fullermd: where does it find the libs? [06:04] With that, it doesn't use any external python stuff, it's all bundled up together. And that doesn't work with external stuff like bzr-gtk etc. [06:04] ahh [06:05] so what do you do if you want to use plugins? [06:05] ah this intaller put some more stuff into the bzrlib directory [06:05] * fullermd doesn't use Windows either; just going by what he's seen here and on the list [06:05] maybe that's what i needed [06:05] * fullermd nods at Angelic13. [06:05] i used bzr-setup-1.3.exe before i think [06:06] i just used bzr-1.3.win32-py2.5.exe now [06:06] okay yay i can import bzrlib now ^_^ [06:06] that must have been the problem. i didn't see any documentation anywhere saying to stay away from that particular installer though [06:06] Yah. AIUI, that installs normal python stuff. [06:07] ok installing tortoisebzr worked. bzr viz still isn't working, but perhaps another reinstall of pygtk will help [06:20] still can't get bzr viz to work, but tortoisebzr seems to work for now, so i guess that's good enough [06:21] if you start a python shell, can you import bzrlib and pygtk? [06:24] yes [06:24] but bzr viz keeps saying PyGTK isn't installed [06:25] right now i have bzr-gtk in "c:\Documents and Settings\user\Application Data\bazaar\2.0\plugins\gtk", and i *think* that's right [06:26] Angelic13: I think that's right. If it wasn't, you'd get a different error (bzr: ERROR: unknown command "viz") [06:26] moving it to "C:\Program Files\Bazaar\plugins\gtk" doesn't seem to work [06:27] that is, it isn't working in the same way [06:33] also can't run scripts/olive-gtk directly :/ [06:36] hi all. how can i bring a branch in line with a new upstream head? i want to blow away any unknown files/changes/pending merges etc and replace it [06:46] kgoetz: bzr revert; bzr pull --overwrite [06:48] hmm seems like i had to download libglade separately and put it into my gtk directory. that was missing from some of the docs. [06:48] so now i can run olive with scripts/olive-gtk [06:48] but bzr viz still doesn't work [06:49] abentley: thanks. [06:49] ah but olive crashes with a GtkWarning *sigh* [06:49] bzr gtk only claims to require glade, gtk and bzr [06:50] bazaar-vcs.org/bzr-gtk only says you need bazaar and pygtk though [06:50] in the windows install section [06:53] this is the most informative doc i've found so far http://faq.pygtk.org/index.py?req=show&file=faq21.002.htp [07:01] poolie: The nanny just restore BB successfully for the first time. [07:01] What breaks BB exactly? [07:28] abentley: way to go [07:29] abentley: great! You may now enjoy your local timezone ;) [08:28] igc: have a good holiday [08:28] thanks spiv [08:56] What could one have done to do a merge, commit it - but not have the revisions consisting of the contributed patch not appear in the history? [08:57] cherrypick, or revert --forget-merges [08:57] (I had to do the merge again, resolve a conflict, and then the contributor's branch showed up - but all the files were otherwise present) [08:57] yes, it said something about cherry pick. [08:57] What would have caused that? [08:57] I just did the usual [08:57] bzr merge ~/Desktop/contributed.patch [08:58] That being a merge directive? [08:58] yeah [08:58] "merge request" :) [08:59] Then it would come from the person making it, making it as a cherrypick. [08:59] AH [08:59] (really) [08:59] (huh?) [08:59] Wait a minute. I did the same [08:59] bzr merge ~/Desktop/contributed.patch [08:59] both times. [09:00] It was only after I had committed it and run `bzr viz` that I realized something was wrong [09:00] doing it a second time resulted in the revisions showing up. [09:00] I would guess you did something in between that filled in enough of the 'missing' revs that it could be applied directly. [09:00] (I realized something was wrong when I tried to see the parents of the merge, and saw only one) [09:00] fullermd: fair enough, but [09:00] * AfC is horribly confused, and his confidence is shaken. [09:02] Well, that's why I'm here :) [09:11] Remember that when you merge a MD, it's not the same as merging the branch; in the latter case, you do the merge you ask for, but in the former, you do the merge that the MD creator asked for. [09:11] Actually, I'm 3/4 way to being serious. I did a merge, and it decided NOT to merge the revisions. This is astonishing to someone who has been, for better or for worse, been trained by Bazaar in its behaviour. [09:11] Hm. [09:11] Well, if it's doing a cherrypick, it can't merge the revisions, because there's nowhere for the graph to hook up. [09:12] night all. I'm away on leave until the 14th now so happy Bazaar'ing while I'm gone. :-) [09:12] If you look in viz, what I suspect you'll see is that one of the revs in that merge has a parent that wasn't in your graph at the time of your previous attempt. [09:12] This is one of the reasons the terminology behind "merge directive" has always distressed me. It's not a directive, because contributors cannot «tell» me to do anything. It's a patch, and I am considering it for merging, or not. [09:12] fullermd: no. It shows no parents whatsoever. [09:13] Urr? An unrelated branch? [09:13] I wish I knew what happened, so I could tell this contributor not to do whatever they did again. Better yet, I wish Bazaar wouldn't have permitted it in the first place. [09:13] fullermd: EXACTLY [09:13] changes got committed, but not revisions. [09:13] I carried on as normal, no problem, la ti da [09:14] * fullermd goes cross-eyed. [09:14] Start over. [09:14] An unrelated branch would have revisions with number like 0.1.x. [09:14] That's the only way (aside from the left path, of course) you ever get revs with no parents; at the start of an unrelated merge-in. [09:14] Whatever. Grab the branch yourself and look: [09:14] bzr viz bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ [09:15] revno 461.1.1 [09:15] Where are the revisions of the contributed patch? [09:16] The code delta is there, for sure. [09:16] But I had to do the merge _again_ revno 465 to make the revisions appear. [09:17] It's called 461.1.1. That means that when you did that merge, you were at rev 461. [09:17] I would be thrilled if I could identify what I [presumably] did wrong. [09:17] But if you look at the revs when the merge worked, the merge revs are 463.x.x, which means those revs are children of rev 463. [09:17] Thus, where you did that merge the first time, you didn't have the revs in your branch, that were the parents of the revs to be merged. [09:18] Thus, they couldn't be attached into the tree 'normally', and become a cherrypick. [09:18] Hm. [09:18] That means the cause is probably not actually the sender requesting a cherrypick in the MD creation, but rather that your branch was 'old' where you did the merge. [09:18] Hm [09:19] Yes, ok, I can see that. [09:19] weird [09:19] {shrug} [09:19] It speaks highly of the quality of your contributors that they keep so up to date, that _you're_ the one behind ;) [09:19] so what gets me is that those revisions didn't "appear" (or whatever) when I subsequently merged it to 'mainline' at 464 [09:20] fullermd: nah, I had a 'cairo' branch lying around, and so did it there. I evidently forgot to pull from mainline first. [09:20] Still. [09:20] Because it was too late at that point; when you committed 461.1.1 (or 462 as it was called on the branch when you merged it), those revs couldn't be hooked to the tree, so they weren't included. [09:21] So when you got around to merging it in in mainline:464, there was no longer any link to them to be reconnected. [09:21] So I merged a second time to "fix" it, but is there something else I should have done instead? [09:21] Well, the 'rightest' thing would have been to stop when it told you it was cherrypicking, and figure out whether that was what should be happening. [09:22] [this will teach me not to do integration merges on 'mainline', but anyway] [09:22] fullermd: ah [09:22] fullermd: interesting. [09:22] Once that's committed and stuck onto mainline (and you don't want to uncommit and dump that rev), there's no way to rewrite the rev to say "Oh, this was a parent of mine". [09:22] * spiv isn't really here, but as a drive-by comment, this sounds like surprising behaviour, so probably there's a bug to be fixed somewhere. Probably the original "bzr merge ..." should have made more fuss about the fact that the base revision referenced in the merge directive wasn't present? [09:22] spiv: I think so [09:23] Well, it's tricky. Cherrypicks can be intentional. [09:23] spiv: I think that's where I got off track [09:23] (and optionally, maybe, provide a way to say, "no, this isn't a cherrypick, just a ghost..."?) [09:23] I don't think MD's explicitly say whether they were intended to be cherrypicks. [09:23] fullermd: put another way, I haven't knowingly done a "cherrypick" since, oh, 0.91 [09:23] Well, mostly I'm glad to hear that it wasn't Vreixo who screwed up, it was me. I can handle that. [09:24] Well, that goes back to the 'directive' part; when you merge a MD, the 'intention' is expressed by the person making it. [09:24] * spiv -> really gone [09:24] AfC: :) [09:24] fullermd: ... which is ass-backwards for anything other than a bot receiving it. [09:24] Using 'send -rx..y' can express an intent to cherrypick (in the case that rev 'x' isn't in the upstream already) [09:25] fullermd: I hadn't realized that cherry picks were that far along. I gather there is still a way to go, however. [09:25] fullermd: (it's that whole partial implementation thing you and I were talking about, I think) [09:25] Well, it's where they've been since... I dunno. 0.6 or something. [09:25] _really_ [09:25] Hm [09:25] Pretty much the same place they are in everything but darcs. [09:25] Well. [09:26] fullermd: so that branch is now "safe", you think? [09:26] "bzr send -ofile -rx..y ; cd $UPSTREAM ; bzr merge file" gives the same result as "cd $UPSTREAM ; bzr merge -rx..y $OTHER" [09:27] fullermd: yeah, ok, I can buy that [09:27] Oh, yes. That -2 rev may have wacky files compared to what you wanted, but the branch is fine. [09:27] Then "fix merge bug" is a surprisingly accurate commit message, it seems :) [09:28] fullermd: thank you for your time. [09:28] Prescient :) [10:16] New bug: #211209 in bzr "bzr 1.3 fails with a ValueError" [Undecided,New] https://launchpad.net/bugs/211209 === mwhudson_ is now known as mwhudson [11:56] Anyone got any ideas how I can work around this? https://bugs.launchpad.net/bzr/+bug/181855 [11:56] Launchpad bug 181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Medium,Confirmed] [11:58] the annoying thing is, I'm sure this worked a couple of weeks back [12:00] I'm beginning to wish I hadn't chosen bzr to work with a visual studio project... there's no working VS integration yet afaik, cygwin bash + cygwin bzr has the above bug, cygwin bash + windows bzr has problems with sftp and doesn't work, and the windows command line is loathsome [12:01] you could argue that the mistake was using visual studio/windows rather than bzr and I probably wouldnt put up much of a fight [12:14] hmm the original reporter got no answers at all on the cygwin list === kiko-zzz is now known as kiko [12:59] hi [12:59] http://pastebin.us/?show=m2d341b75 <-- bzr died when I tried bzr revert. Please help, I need to revert. [13:00] Bazaar (bzr) 1.1.0.candidate.1, Debian Sarge (package from backports.org) [13:01] muszek: you might do well to just install Bazaar manually. 1.1.0rc1 is a bit old. [13:02] muszek: (assuming no one has a Debian package of bzr 1.3) [13:03] AfC: the one from hardy probably wouldn't install, right? [13:03] muszek: you won't know until you try. [13:03] rgr [13:03] muszek: We don't use Ubuntu at our company, sorry. [13:04] AfC: what do you use? (just curious, feel free to ignore me) [13:06] muszek: we run Gentoo on our systems [13:06] Anyway, good luck to you [13:06] * AfC heads to bed. [13:06] AfC: thanks, good night [13:06] hi [13:07] how do I find out whether remote branch format matches the local branch format? [13:07] my commits are taking ages ... [13:08] ignas: bzr info URL [13:08] bzr info . [13:09] :/ can't do that while commiting apparently [13:09] :( [13:09] so i'll have to look at it in 5 minutes [13:09] and it's a 1 line change in .bzrignore :/ [13:10] ignas: for what it's worth, I'd encourage you to maintain a branch locally and work there and commit there. You can then push your changes to the remote repo separately. That should work much better for you. [13:10] AfC: release managing requires a lot of pushing [13:10] ... and if you have to merge, well, {shrug} you merge. [13:10] so i actually need my changes to appear in the remote repository [13:10] as soon as I do them [13:11] ignas: you've got a modern 3rd generation distributed revision control system at hand. You would do well to take advantage of it. [13:11] when developing - yes i can work on an isolated branch [13:12] but i need to do the push after merging and it is taking way too much [13:12] I assume you've got bzr 1.3 on both sides and that you are pushing via bzr+ssh. If not, try upgrading and changing protocols. [13:12] hmm Repository branch (format: unnamed) [13:12] remotely [13:13] and Checkout (format: dirstate-tags) [13:13] locally [13:13] what should i do to fix that? [13:13] and no it's not 1.3, it's the version that is available as debs for ubuntu gutsy... [13:14] 1.0 i think [13:14] though maybe i should switch to bzr PPA instead of using the old deb package repository [13:14] ignas: well that's your first problem, depending on Ubuntu to give you up to date software. The hackers here maintain a "PPA" (whatever that is) which gives you more modern packages. [13:15] ignas: don't use bzr+ssh url for `bzr info` [13:15] As for what to do, after upgrading to Bazaar >= 1.3.0, run something like `bzr upgrade` (probably `--default` on a test branch and see if that helps. [13:15] bzr+ssh hides the real format [13:15] and what about the remote repository? [13:15] luks: oh [13:15] luks: how strange [13:16] makes sense [13:16] ignas: upgrade it too [13:16] you can use bzr+ssh with old versions of bzr [13:16] ignas: (again, modulo testing and backups etc) [13:17] Repository branch (format: pack-0.92) [13:17] that's the problem then [13:17] if i want to upgrade a repository not just the branch [13:17] upgrade your local repository [13:17] i should run bzr upgrade in the repository [13:17] yes [13:18] will it upgrade all the branches inside? [13:18] not sure about that [13:19] hmm, bzr upgrade says it's the most recent format already [13:19] what version of bzr? [13:19] 1.0 [13:19] so it seems i will have to fix apt sources :/ [13:19] hm [13:20] this makes sysadmins so much more enthusiastic about bzr ;) [13:20] what does bzr info say in the local repository? [13:20] the remote repository [13:20] i have a local checkout [13:20] of a branch that is in a shared repository on a remote server [13:20] no local repository? [13:21] then you need to upgrade the checkout [13:21] no, don't need it, i am working on a single checkout at the moment [13:21] the remote side is already using pack-092, which is the most recent format [13:21] hmm [13:21] i see [13:21] bzr upgrading local one [13:22] neat, would have never managed to find out which one [13:22] pack-092 or dirstate-tags is more recent [13:24] you should call the next version gruntmaster-6000 ;) [13:25] {grin} [13:27] yippie it's only 60 seconds not 5 minutes! [13:28] still too slow [13:28] i know, i have a weird sense of humor ;) [13:28]