=== oubiwann_ is now known as oubiwann | ||
maxb | hmm, I wonder how long it takes to rebase 1500 revisions | 00:04 |
---|---|---|
maxb | this is one scenario when bzr's speed is a bit lacking | 00:05 |
maxb | Gaaaaah | 00:07 |
maxb | I bet rebase-foreign is picking the file-ids from the wrong side | 00:07 |
maxb | cjwatson: What's the aim with the debian-cd branches? End up with the ubuntu branch retrofitted with debian file ids and on top of the debian history? | 00:08 |
cjwatson | maxb: Debian used to use svn and now uses git; I want to rebase/merge/whatever across that change | 00:11 |
cjwatson | the Ubuntu branch was created when it used svn (or maybe even CVS, but I think it was svn) | 00:11 |
maxb | hmm... how come both branches have arch-style revids? | 00:12 |
lifeless | cscvs to tla | 00:12 |
cjwatson | cancel "rebase/merge/whatever", I specifically want to merge forward, but I'm happy to use something rebase-like to pretend that my history was always based on git | 00:12 |
maxb | But lp:debian-cd is still a svn import | 00:13 |
maxb | urgh, it died again | 00:19 |
maxb | that's immensely irritating. the rebase died 4 revisions short of finishing | 00:22 |
lamont | maxb: but only one or two more bugs to fix, right? | 00:42 |
maxb | I'll let you know when it finishes another attempt :-) | 00:42 |
cjwatson | maxb: hmm, I think I mean "Debian used to use cvs and now uses svn", then | 00:49 |
cjwatson | maxb: so the current Ubuntu branch was created when it used cvs | 00:49 |
cjwatson | apologies for that confusion | 00:49 |
cjwatson | the change was years ago | 00:50 |
maxb | assuming it doesn't explode again, I'll push some results in 10 mins or so | 00:54 |
maxb | although given how confusing I found the code, you probably want jelmer to review my hacks to bzr-rewrite before you trust its output | 00:54 |
maxb | lp:~maxb/bzr-rewrite/ubuntu-debian-cd-rebase-foreign succeeds in the rebase. I can't push my rebased branch because grrrrrr I did it in a shared repo and now have different rich-root errors | 01:01 |
lamont | so these blob files... how big do they get? | 01:05 |
maxb | huuuuuuge | 01:05 |
maxb | As they store the literal content of every revision of every file | 01:05 |
lamont | is it basically a concatenation of every single output-format commit ever? | 01:05 |
lamont | 375MB cvs tree, 4.7GB of blob and counting | 01:06 |
maxb | yup | 01:06 |
lamont | oh rapture. | 01:06 |
maxb | disk is cheap, right? | 01:06 |
lamont | now, where _are_ my scissors. | 01:06 |
lamont | .... | 01:07 |
maxb | It gets worse - if you pass the data on stdin to fast-import, it caches the blobs in memory! | 01:07 |
lamont | git and bzr? or is bzr the only thing silly enough to do that? | 01:07 |
lamont | svn being in the "totally do not care" category | 01:08 |
maxb | I'm assuming just bzr | 01:08 |
maxb | It's really silly, it could just keep track of a revid+fileid and get the content back that way if it needed it again later | 01:08 |
Phil_Bordelon | Hello there. | 01:18 |
maxb | and pushed: lp:~maxb/debian-cd/ubuntu-rebased | 01:18 |
Phil_Bordelon | Does anyone know if there's an equivalent to svndumpfilter available for bzr? | 01:18 |
maxb | There's bzr fast-import-filter | 01:19 |
cjwatson | maxb: cool, thanks! I'll have a look .. | 01:19 |
Phil_Bordelon | Awesome. Just what I needed. Thanks, maxb. | 01:20 |
Phil_Bordelon | I'm a writer, and I have stuff in an 'incubator' repo in bzr that I occasionally want to split off into its own repo. This'll do just that. :) | 01:20 |
Phil_Bordelon | (same with code.) | 01:20 |
Phil_Bordelon | <3 You and Ian C. made my evening. | 01:22 |
mtaylor | abentley: didn't you say that there was a ppa that had bzr 2.1beta in it? | 01:25 |
abentley | mtaylor: Sure, and either the beta ppa or the nightly ppa should. They don't? | 01:26 |
mtaylor | abentley: I don't see them on the ~bzr page... | 01:26 |
abentley | mtaylor: They were started before a user could have multiple ppas, so they have different users. | 01:27 |
maxb | the beta ppa is rather out of date. It has versions older that the ~bzr ppa | 01:27 |
maxb | *than | 01:27 |
abentley | mtaylor: https://launchpad.net/~bzr-beta-ppa/+archive | 01:28 |
abentley | mtaylor: https://launchpad.net/~bzr-nightly-ppa/+archive | 01:28 |
mtaylor | abentley: AWESOME | 01:28 |
mtaylor | abentley: thankx | 01:28 |
=== arjenAU2_ is now known as arjenAU | ||
jml | abentley, you know what would make me like remerge a whole lot more? | 02:17 |
* igc lunch | 02:27 | |
lifeless | jml: what would | 02:59 |
=== timchen119 is now known as nasloc__ | ||
jml | lifeless, oh, I spoke w/ abentley IRL | 03:03 |
jml | lifeless, a way of seeing what it actually changed, especially wrt files that used to conflict. | 03:04 |
=== Adys_ is now known as Adys | ||
lifeless | vila: https://code.edge.launchpad.net/~vila/subunit/gtk-filter-fixes can you mark this as obsolete? | 04:13 |
abentley | lifeless: ping | 06:22 |
vila | lifeless: it's already marked as merged, anything more needed ? | 07:14 |
vila | hi all ! (by the way :) | 07:15 |
GaryvdM | Hi vila. | 08:11 |
vila | hey GaryvdM ! | 08:12 |
vila | That was short... | 08:12 |
vila | hey GaryvdM ! (Was I saying when your client quit :) | 08:13 |
bialix | heya bzr | 08:14 |
bialix | igc here? | 08:14 |
bialix | hi garyvdm | 08:16 |
garyvdm | hmm - something wrong with my keyboard config and xchat. when I press "q" it takes it as ctrl + q | 08:18 |
garyvdm | hi bialix | 08:18 |
vila | hey garyvdm ! (Third time :) | 08:18 |
bialix | vila and gary meet each other. finally | 08:19 |
bialix | hi vila! | 08:19 |
vila | hey bialix :-D | 08:19 |
* vila LOLs :) | 08:19 | |
bialix | :-D | 08:19 |
garyvdm | vila: just wanted to say: I've replied to your question about the qbzr test suit, | 08:19 |
vila | garyvdm: now that's timely :D Thanks a lot | 08:20 |
vila | garyvdm: hmm, I already spend far too much time administering my zoo, but it's good to know it will go away soon | 08:21 |
bialix | garyvdm: just info: I will be unable to work on qbzr till February | 08:21 |
garyvdm | bialix: Ok - np | 08:22 |
vila | garyvdm: at worst the test can be tagged as requiring pyqt-4.6.1... | 08:22 |
vila | s/test/tests/ | 08:22 |
vila | garyvdm: but waiting for a karmic upgrade is good enough for me | 08:22 |
garyvdm | vila: that is a good idea. | 08:22 |
garyvdm | or a known failer | 08:23 |
vila | garyvdm: know failure will be harder, skip may be good enough | 08:25 |
garyvdm | ok | 08:25 |
vila | bialix, garyvdm : Congrats for the qbzr-0.18 release by the way ! | 08:26 |
garyvdm | :-) | 08:26 |
bialix | vila: thanks, I'm appreciate the congrats | 08:26 |
vila | garyvdm: since you're there, are you still working on the unicode-bom-detect stuff ? | 08:27 |
garyvdm | Not for the moment, but I will get back to it. | 08:27 |
vila | garyvdm: I was thinking that since you can't do that unconditionally (as abentley pointed out) you may think about implementing the feature in some read-only mode as a first step | 08:28 |
bialix | vila: can I ask about bzr itself? | 08:28 |
vila | bialix: don't ask to ask, ask :D | 08:28 |
garyvdm | vila: " some read-only mode" == command line paramater? | 08:38 |
vila | garyvdm: no, at the API level | 08:39 |
garyvdm | Ok | 08:39 |
vila | AIUI you need this patch for read-only operations (diff, cat, etc) | 08:39 |
vila | there may be a way to have additional methods that these read-operations can use and avoid the problems mentioned by abentley | 08:40 |
vila | garyvdm: I haven't look in detail so take the suggestion with a grain of salt | 08:41 |
garyvdm | vila: I also need to go into some details | 08:41 |
vila | garyvdm: ok | 08:42 |
bialix | vila: any ideas about https://bugs.launchpad.net/bzr/+bug/244291 | 08:42 |
ubottu | Ubuntu bug 244291 in bzr "NoSuchRevision error from "bzr info -v"" [Medium,Confirmed] | 08:42 |
bialix | I've offered to provide the repo where this bug present | 08:43 |
bialix | is it needed? | 08:43 |
bialix | or I should not ask to ask? | 08:43 |
bialix | I'm worrying a bit because this repo is no more actively using by me: I'm switching to use colo | 08:44 |
bialix | so I can delete it one day accidentaly | 08:45 |
* vila reading | 08:48 | |
vila | bialix: hmm, this looks like a plain branch, how did you end up with an out-of-date working tree ? | 08:53 |
bialix | this branch was used as master for light checkout | 08:54 |
bialix | it was easy | 08:54 |
* garyvdm -> work | 08:56 | |
vila | bialix: so the bialix@ukr.net-20091128210111-wlxjvzkuj72ze9mi revisions is not in the repo yet the branch references it, how weird... DId you implement some gc without telling us ? :-D | 08:58 |
vila | bialix: more seriously do you use some stacked branches ? | 08:58 |
bialix | I'm sure this revision in the repo | 08:58 |
bialix | because qlog works without errors | 08:59 |
* vila blinks | 08:59 | |
bialix | I don't made gc | 08:59 |
bialix | and don't use stacked | 08:59 |
bialix | (stacked seems evil for me) | 08:59 |
vila | hmm, let me guess, that revision is in the branch history but *not* a mainline revision ? | 08:59 |
vila | qlog should show you that quite easily :D | 09:00 |
vila | bialix: hmm or somehow that revision went completely out of the branch history after some 'uncommit' or 'push --overwrite'... but let's check if it's still in the branch history first | 09:03 |
Anteru | Hi | 09:05 |
Anteru | I've just switched a repository from SVN to Bzr (using bzr svn-import), and we're running into weird issues. First of all, a bzr check told us that we have 250 broken parents or so | 09:05 |
Anteru | This could be fixed by using bzr reconcile | 09:06 |
Anteru | Unfortunately, diff's regularly fail with NoSuchRevision ... | 09:06 |
vila | Anteru: hmm, bzr-svn is the recommended way for that AFAIK, but for context, what versions are you using ? | 09:07 |
Anteru | Commit works, but diff fails (before/after the commit) | 09:07 |
Anteru | Running bzr 2.0.3 | 09:07 |
Anteru | (latest stable) | 09:07 |
Anteru | Server is running bzr 2.0.3 as well, and we're publishing right now using sftp due to issues with bzr serve/fastcgi | 09:07 |
Anteru | basically, the problem is that when we try to diff, we get "bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///V:/proj/.bzr/repository/') has no revision dev@anteru.net-20100109162623-iqh9at1lxqx8n38p" | 09:08 |
bialix | vila: this revision is the revision of working tree | 09:08 |
* bialix preparing screenshot! | 09:09 | |
vila | Anteru: try bzr reconcile first | 09:09 |
Anteru | We did reconcile | 09:09 |
Anteru | It's also not for all files, for some, diff works perfectly, but for some, we get the error above | 09:10 |
vila | bialix: yes (because most probably info -v starts from the actual tip), but the wt is out-of-date and it seems that doesn't play well here | 09:10 |
vila | Anteru: weird, is 'bzr check' happy now ? | 09:11 |
Anteru | 20 ghost revisions, let me run it again just to get the output | 09:11 |
bialix | vila: http://launchpadlibrarian.net/38124517/qlog-bug-244291.png | 09:11 |
* bialix -> work | 09:13 | |
vila | bialix: great, so it *is* in the branch ancestry, that narrows down the problem | 09:13 |
Anteru | (this will take some while, 2.6k revisions) | 09:13 |
Anteru | OT: Is check going to become faster some day? | 09:14 |
vila | bialix: and I presume that the error goes away if you run 'bzr update' ? | 09:16 |
bialix | maybe, I did not try | 09:17 |
vila | Anteru: for some value of some, yes. There are plans to implement more options to allow finer-grained checks | 09:17 |
bialix | vila: tried in the copy: yes, error go away after up | 09:17 |
Anteru | vila: check output: http://pastebin.ca/1758667 | 09:18 |
vila | bialix: that would help the diagnosis (I'll need to write the test otherwise :-)... YES ! | 09:18 |
bialix | added to bug comments | 09:18 |
bialix | thanks | 09:19 |
vila | bialix: me too :) | 09:19 |
vila | bialix: lol, we added nearly the same comments :) | 09:19 |
vila | Anteru: yeah, ghosts... | 09:20 |
Anteru | Any way to get rid of those, if they're causing these issues? | 09:20 |
Anteru | I have no problem to fiddle around with the repository, as long as no information gets lost (as we have already some commits in there) | 09:21 |
vila | I'm pretty sure it's related to svn-import/bzr-svn then, but you need someone more experienced than me with the svn conversions then, try to find jelmer or better file a bug on lp or write an email to the bazaar list | 09:21 |
vila | Anteru: if you go away from svn, these ghosts need to filled | 09:22 |
vila | s/to filled/to be filled/ | 09:22 |
Anteru | Any idea how/where to start? | 09:22 |
vila | AnMaster: A ghost is a revision that exists but bzr is not aware of its content | 09:23 |
vila | Anteru: not really, that sounds like a genuine svn-import bug to me though | 09:23 |
Anteru | Which sounds like a very serious issue to me, as we can't go back to svn that easily now :/ | 09:24 |
vila | Anteru: that's why I said it's a bug | 09:24 |
Anteru | I'll try the mailing list and cross my fingers that the repository/history can be rescued. Damn, I wonder why we didn't run earlier into this. | 09:25 |
Anteru | Just now, after fully switching :/ | 09:26 |
vila | Anteru: the first thing is to get the list of the ghosts revisions, look into .bzr.log or re-run 'bzr check -v' and look again | 09:26 |
vila | from there you'lll have to find out what theses revisions are.... and inject them into the repo (how to do that with svn-import is a different story...) | 09:27 |
vila | Anteru: did you use bzr-svn before switching ? | 09:27 |
Anteru | Yes | 09:28 |
vila | Anteru: Do you use shared repos ? | 09:28 |
Anteru | I used it locally for some time (200 revisions?), but we finally decided to fully move and started from scratch (i.e. ran svn-import on the server, and branched from there) | 09:28 |
Anteru | bzr.log contains loads of errors: http://pastebin.ca/1758676 | 09:28 |
vila | All the 'Unable to open' errors should be harmless as long as you don't see them in the console (I'm pretty sure that's bzr-svn trying to find an svn repo in wrong places and failing) | 09:30 |
Anteru | That is, the usage previously was that one developer (me) who used bzr locally, by doing svn-import, binding to svn, and branching/merging locally. The other dev was using SVN (but I think it was only like 2-3 commits) | 09:31 |
Anteru | Now we scrapped all local bzr copies, and simply ran import again, and I branched off the new repository. | 09:32 |
vila | argh ! | 09:32 |
Anteru | ? | 09:32 |
Anteru | We should have done everything differently? | 09:32 |
vila | I was hoping to find the ghosts in your previous bzr branches ! | 09:32 |
Anteru | IIRC, I had some ghosts revisions in my first local import (i.e. the first time I ran svn-import) | 09:33 |
vila | Anteru: you could have started with your bzr branch instead which was presumably complete instead of re-running svn-import | 09:33 |
Anteru | The original branch already had these ghost revisions (and I think, even the same number -- I was asking here if this is normal that I'm like 10 revisions behind the SVN, and I was told yeah.) | 09:34 |
Anteru | Running bzr check -v now | 09:35 |
vila | Anteru: Then I'm a bit lost... AFAIK bzr-svn create ghosts only for bzr revisions that can't be exported to svn, so you need at least two people using it to encounter the problem... | 09:35 |
vila | or two branches that don't share a repo | 09:36 |
Anteru | Well, I didn bzr svn-import on two machines | 09:36 |
Anteru | Which would solve that issue | 09:36 |
Anteru | I.e. explain how the ghost revisions appeared, but as I said, I had them right away | 09:36 |
Anteru | The first time I did svn-import, I was 10 or 20 revisions behind, with some ghosts. | 09:37 |
vila | Anteru: I confused svn-import (which *is* part of bzr-svn) and svn2bzr. You definitely needs jelmer here | 09:40 |
Anteru | bzr check -v gives the ghost revision ids | 09:40 |
vila | AnMaster: and you lamost certainly needs the bzr repos where the ghosts were created | 09:40 |
lifeless | vila: it has unmerged changes that won't be merged. it needs to be marked obseleted or whatever. its showing up in branch listing. | 09:41 |
lifeless | abentley: pog | 09:41 |
lifeless | abentley: pong | 09:41 |
vila | from there, branching from the repo that contains the revisions into the repo where they are ghosts should filled them | 09:41 |
Anteru | Great, as we don't have them :/ | 09:42 |
abentley | lifeless: I couldn't remember whether we were doing code review for bzr-pqm or just pushing. In the end, I requested a review. | 09:42 |
Anteru | Ah well, something is always going wrong. I wonder where they came from as we did a fresh svn-import | 09:43 |
=== loxs_wrk is now known as loxs | ||
lifeless | abentley: ok, I shall review in the morning if thats ok | 09:47 |
abentley | lifeless: That's fine. | 09:49 |
Anteru | vila: Yeah, looks like the merges are the culprit (i.e. local bzr getting merged into SVN) | 09:50 |
vila | Anteru: yes, that create ghosts because svn can't represent them so bzr-svn store the revids in some svn property to be able to roundtrip safely | 09:52 |
Anteru | (at least, I count 17 merges, and some might have 2 or 3 revisions) | 09:52 |
Anteru | Gosh, I would be happy to get rid of them (i.e. I don't worry if the fact that it was a merge is lost) | 09:52 |
Anteru | and just treat them as normal commits to the trunk | 09:53 |
vila | Anteru: then there should be a way but that requires some voodoo knowledge of bzr-svn internals, file a bug | 09:53 |
Anteru | Ok. Any idea if there is a way to get it fixed on the bzr repository directly :) ? | 09:54 |
lifeless | night | 09:58 |
vila | Anteru: Hopefully yes, but whether it's only deleting them from the parent list or if more is required, I can't say | 09:58 |
vila | lifeless: done | 09:58 |
vila | lifeless: g'night | 09:59 |
Anteru | Ok, cool. I'm going to write a _long_ writeup to the mailing list. | 09:59 |
Anteru | I.e. explain all the problems we created ;) | 09:59 |
vila | Anteru: too bad you didn't keep the bzr repos around for a while, are you sure you don't have a backup somewhere ? | 09:59 |
Anteru | Pretty sure, unfortunately, as I had like 10 repos during testing, and got rid of them all at once. | 10:00 |
Anteru | (testing means only locally to check performance etc.) | 10:00 |
Anteru | Sent | 10:08 |
Anteru | Let's see if someone has an idea (fingers crossed) | 10:09 |
Anteru | vila: Thanks! | 10:13 |
vila | Anteru: you're welcome! Your experience should at least help us better document the process so those ghosts don't get lost the next time :-/ | 10:14 |
vila | Anteru: Another way to fix the problem *may* be to try bzr-replay and see if it can cope with the ghosts | 10:15 |
Anteru | Yeah, I'm also going to blog about this, in the hope that it will help other people to migrate from SVN to Bzr (because I'm really happy with Bzr) | 10:15 |
vila | Anteru: you will end up with a repo with *different* revids though, so be prepared to resynchronize every people involved | 10:15 |
Anteru | That's no problem | 10:15 |
Anteru | I can simply delete the repository on the server, recreate it, and tell everyone to branch again :) | 10:16 |
Anteru | Trying bzr replay of all revisions, let's see if/when this finishes ... doesn't look too fast (pegging one core @ 100% and reading like 2 KiB/s) | 10:24 |
l2m | hi ^^ | 10:47 |
l2m | could anyone help me to understand why the bzr commit does not works with the --fixes switch ? | 10:47 |
l2m | i've added in the config file the line trac_mysite_url = http://www.mysite.com/trac | 10:48 |
l2m | and nothing seems to happend when i do a bzr commit --verbose --fixes mysite:106 -m'test___' | 10:48 |
bialix | if you run qlog you'll see it there | 10:49 |
bialix | what you expect actually? | 10:49 |
l2m | qlog ? | 10:49 |
bialix | qlog is the part of qbzr plugin | 10:50 |
bialix | it's wonderful gui | 10:50 |
bialix | --fixes store special metadata attached to committed revision | 10:51 |
bialix | it's not quite visible | 10:51 |
bialix | qlog makes it clearly visible | 10:51 |
l2m | but why is --fixes not calling trac ? | 10:51 |
bialix | --fixes does not change the status of actual bug | 10:51 |
l2m | i can't see anything in trac | 10:51 |
l2m | ok :) | 10:51 |
bialix | it's just metadata inside bzr | 10:51 |
l2m | not possible to fix in trac an opened bug ? | 10:52 |
bialix | trac-bzr plugin does not process such metadata yet | 10:52 |
bialix | in theory it's possible to close bug in trac via post-commit hook | 10:53 |
bialix | there is special API in trac for this, xml-rpc IIRC | 10:53 |
bialix | but in practice nobody wrote such hook yet | 10:53 |
l2m | hehe ... :) | 10:53 |
bialix | yep | 10:53 |
l2m | ok so where looking for this guy ;) | 10:54 |
l2m | we are sorry | 10:54 |
bialix | imagine if you commit locally without access to trac | 10:54 |
bialix | what should bzr do? | 10:54 |
bialix | I mean offline | 10:54 |
l2m | yep .. but in our case, we have all in local network | 10:55 |
bialix | yes, but bzr don;t know this ;-) | 10:55 |
l2m | so, many thanks for help bialix ... we gonna look for an other solution | 10:55 |
bialix | if you find it, I'd like to know too | 10:56 |
bialix | we're using trac at work too | 10:56 |
l2m | wel .. so the fixes switch work well with launchpad or bugzilla .. or same limitations ? | 10:59 |
bialix | lp don't change status of the bug | 11:03 |
bialix | it just link the branch to the bug | 11:03 |
bialix | so in lp this info used just as flag: here is branch where possible fix exists | 11:03 |
bialix | as you can imagine the fix can be wrong or incomplete | 11:04 |
bialix | that's basicall y main reason why bzr don't try to change the status of the bug | 11:04 |
Anteru | hm, I cannot get bzr replay to work, complains about no WorkingTree | 11:08 |
Anteru | vila: replay fails with conflicts?!? | 11:41 |
vila | Anteru: for the merges ? Are they the same conflicts that you did resolve at that point in the past ? | 11:43 |
Anteru | it fails on revision 40 or so | 11:43 |
Anteru | that's in 2004, when we were using svn 1.0 or so | 11:43 |
* vila summons quicksilver that played a lot with bzr-replay lately :-) | 11:43 | |
Anteru | I don't think we had conflicts back in that day :) | 11:44 |
quicksilver | all I have to offer about bzr replay is that I could only make it replay simple revisions | 11:44 |
quicksilver | that is, no merge involved. | 11:44 |
vila | Anteru: may be you don't use bzr-replay with the right starting branch (don't start from origin but maybe just before the first merge) | 11:44 |
maxb | yeah, no support for merges | 11:44 |
quicksilver | if there is a way to make it do something sensible with merges I didn't find it. | 11:44 |
quicksilver | I must finish that long email I was writing to the bzr list though | 11:45 |
maxb | actually most of bzr-rewrite fares poorly if you ask it to rewrite a merge | 11:45 |
Anteru | hm | 11:45 |
Anteru | Seems my repository is totally hosed | 11:45 |
vila | quicksilver: oh, finishing that mail ? Good idea :) | 11:45 |
Anteru | It's not only ghost revisions that are missing. Just sent again to the ML :/ | 11:45 |
Anteru | Bah, that's a migration :( | 11:46 |
* vila lunch time, bbl | 11:46 | |
=== gerard_1 is now known as gerard_ | ||
jam | morning all | 14:14 |
jam | hopefully irc will get sorted out... | 14:14 |
=== mrevell-lunch is now known as mrevell | ||
vila | morning jam ! | 14:41 |
=== salgado is now known as salgado-afk | ||
=== salgado-afk is now known as salgado-lunch | ||
Lo-lan-do | Hi all :-) | 14:50 |
rubbs | hello | 14:50 |
Lo-lan-do | Question about bzr switch. I have a lightweight checkout of ~/repo/branch, which is bound to bzr+ssh://remote/blabla/branch | 14:51 |
Lo-lan-do | Is there a way to have "bzr switch otherbranch" switch to ~/repo/otherbranch rather than bzr+ssh://remote/blabla/otherbranch? | 14:52 |
rubbs | I don't think so, the only way is to type out the whole path... on the other hand, I seem to remember reading something about intents... | 14:55 |
* rubbs runs of to the documentation... | 14:55 | |
rubbs | mmm... seems like intents are more for shortcutting authorization to branch locations rather than shortcuting the branch locations themselves. | 14:57 |
rubbs | you could make an alias... | 14:57 |
rubbs | bzr alias otherbranch="~/repo/otherbranch" | 14:57 |
rubbs | that way when you do your switch bzr will expand your path for you. | 14:58 |
Lo-lan-do | Hm, yes, that would work if I had only one repo. | 14:58 |
rubbs | ah. | 14:58 |
rubbs | not sure what the best solution is. | 14:59 |
Lo-lan-do | I have several branches named similarly, in the same repo, too. | 14:59 |
Lo-lan-do | fusionforge/patches/$client1/fixes, fusionforge/patches/$client2/fixes, and so on. | 15:00 |
rubbs | that makes sense. Does bzr switch ../otherbranch work? | 15:00 |
Lo-lan-do | bzr: ERROR: Not a branch: "bzr+ssh://remote/blabla/otherbranch/". | 15:02 |
Lo-lan-do | So, no. But nice try :-) | 15:02 |
Lo-lan-do | Uh, it's even worse, actually, it's bzr+ssh://remote/bla/otherbranch/ , with bla being blabla/.. (blabla's parent dir) | 15:04 |
rubbs | mmm... | 15:06 |
Lo-lan-do | I'm fetching the source, I'll see if I can add a parameter to change the default behaviour. | 15:07 |
rubbs | that might work. | 15:07 |
rubbs | I'm out of ideas other than that. | 15:07 |
rubbs | unless someone like jam or vila have an idea. | 15:07 |
jam | Lo-lan-do: bug #506177 | 15:08 |
ubottu | Launchpad bug 506177 in bzr "switch sibling should check for lightweight checkout first" [Medium,Confirmed] https://launchpad.net/bugs/506177 | 15:08 |
jam | basically, while 'bzr switch $PATH" defaults to switching the lightweight checkout before the bound branch the "bzr switch local" lookup does the bound branch lookup first | 15:09 |
jam | for now | 15:09 |
jam | use bzr switch ~/repo/otherbranch | 15:09 |
Lo-lan-do | I see. Thanks for the pointer. | 15:10 |
Lo-lan-do | Oooh, colocated branches now! | 15:12 |
Glenjamin_ | hi guys, is there any plan for a os x 10.5 installer for the newer versions of bzr? | 15:21 |
Glenjamin_ | or, a more relevant question - how do i use bzr-keychain? | 15:35 |
Glenjamin_ | it appears to have installed correctly and is in the plugins list | 15:35 |
Glenjamin_ | but i have no idea how to make it prompt for keychain access | 15:35 |
Lo-lan-do | Does "bzr help keychain" say anything? | 15:36 |
Glenjamin_ | "Use the Mac OS X keychain as a credential store for authentication.conf." | 15:38 |
Glenjamin_ | bzr 2.0.1 btw | 15:39 |
=== salgado-lunch is now known as salgado | ||
Lo-lan-do | Glenjamin_: No idea from me, actually. I'm not a Mac user, I was just suggesting. | 15:48 |
Glenjamin_ | no worries | 15:49 |
Glenjamin_ | bzr-svn can read plaintext stores from svn fine - but doesnt seem to be able to read from the svn keychain store :s | 15:49 |
=== weigon is now known as jan|break | ||
=== jan|break is now known as weigon | ||
vila | Glenjamin_: I think jfroy know about bzr-keychain, let's try to summon him | 15:59 |
=== bigjools is now known as bigjools-otp | ||
Glenjamin_ | i'm guessing jfroy is the bzr-svn guy? | 16:12 |
vila | jam: can you review https://code.edge.launchpad.net/~vila/bzr/per-file-merge-hook/+merge/17754 ? | 16:12 |
vila | Glenjamin_: no, it's the bzr-keychain guy :) | 16:12 |
Glenjamin_ | oh | 16:12 |
Glenjamin_ | thats works too :) | 16:12 |
jam | vila: I'll try to take a look at it today | 16:19 |
vila | jam: thanks, unless you object, it would be nice to include it in rc1 since there seems to be agreement that it's low risk | 16:21 |
vila | jam: but I will *not* push more since it needed to be completed at the last minute by the pp instead of the original author... | 16:22 |
vila | jam: hmpf, passport, damn | 16:24 |
=== bigjools-otp is now known as bigjools | ||
jam | vila: already approved | 16:25 |
jam | yeah passport thing is just strange | 16:25 |
jam | for whatever reason neither of us connected the dots until it was in the mail | 16:25 |
jam | anyway, I'm going to head to a coffee shop for a while, I'll see if I have net access there | 16:27 |
vila | jam: small error big consequences... :-/ We will miss you if you can't make it :-/ | 16:27 |
vila | jam: huh ? What about your expresso machine ? | 16:27 |
Lo-lan-do | I was going to ask what's new in 2.1, but reading the release notes, I'm sold already. | 16:30 |
Lo-lan-do | "bzr unshelve --preview" is something I've wished for quite some time :-) | 16:30 |
Glenjamin_ | anyone around who works on bzr-svn? i'm looking at the authentication code, and it appears to have hooks into all the subverpy auth providers, but not use any of them in the Credential Store implmentation | 16:32 |
=== davidstrauss_ is now known as davidstrauss | ||
AnMaster_ | <vila> AnMaster: A ghost is a revision that exists but bzr is not aware of its content <-- wrong nick? | 17:07 |
vila | AnMaster_: yeah, sorry about that | 17:08 |
* vila lectures Xchat: see ? Can't you check which nick you propose ! | 17:09 | |
AnMaster_ | vila, for xchat iirc you can set "most recently to speak completed first" kind of thing | 17:11 |
vila | which I did AFAIR, let me check | 17:12 |
vila | here we go, lost setting... | 17:12 |
vila | AnMaster_: thks for the heads-up | 17:12 |
AnMaster_ | vila, if you use /set iirc you have to save it by some other command | 17:14 |
AnMaster_ | was a while ago I used xchat last | 17:14 |
vila | AnMaster_: I track changes on the xchat.conf file.... at least I was but somehow my setup has been broken :-/ | 17:15 |
=== AnMaster_ is now known as AnMaster | ||
AnMaster | mhm | 17:15 |
vila | ha, got it, xchat creates a new xchat.conf when some pref is modified which breaks my tracking :-/ | 17:18 |
=== oubiwann__ is now known as oubiwann | ||
Tak | what happens when one bzr unbinds a lightweight checkout? | 18:42 |
fullermd_ | One doesn't; the operation doesn't make sense. | 18:45 |
fullermd_ | unbind operates on a branch, not a checkout. So what would happen would be that it would perform that operation on the branch you have a lightweight checkout of, which is statistically probably not bound in the first place. | 18:46 |
=== fullermd_ is now known as fullermd | ||
Tak | ok | 18:47 |
Tak | that's what I figured | 18:47 |
Tak | although I kind of hoped that it would create an alternate universe where magical unicorns would keep track of my local revisions until it was time to rebind | 18:48 |
keithy | hi | 18:50 |
keithy | How can I debug a bzr+ssh connection | 18:50 |
keithy | the sftp connection works | 18:51 |
Tak | is bzr installed on the remote side? | 18:51 |
keithy | yes | 18:52 |
fullermd | Tak: Magical unicorns were going to be in 2.1, but the patch was rejected for not having tests :( | 18:54 |
Tak | meh, I'm still running 2.0.3 anyway | 18:56 |
Tak | keithy: what kind of error are you getting? | 18:56 |
keithy | if I ssh to the mc, I can run bzr | 18:56 |
keithy | bash: bzr: command not found | 18:58 |
keithy | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 18:58 |
mwhudson | keithy: where is bzr on the remote machine? | 18:58 |
mwhudson | if it's not in /usr/bin, /bin or just a very few other places you might have to set BZR_REMOTE_PATH | 18:58 |
keithy | hmm | 18:59 |
keithy | doesnt the Mac os x installer do the right thing? | 18:59 |
mwhudson | no idea! | 18:59 |
mwhudson | log in and 'which bzr' | 18:59 |
keithy | its in /usr/local/bin/bzr | 18:59 |
mwhudson | yeah, that's probably not in the default path from ssh | 19:00 |
mwhudson | you can set the path as an environment variable or in the config | 19:01 |
keithy | but if I use ssh manually it is | 19:01 |
mwhudson | it's probably in some file your shell executes | 19:02 |
keithy | k | 19:02 |
mwhudson | there's no shell involved if you run ssh $host bzr | 19:03 |
keithy | ok Ill try that | 19:03 |
mwhudson | if bzr+ssh fails, that will fail | 19:03 |
keithy | yep bingo | 19:04 |
Tak | sweet, I'm up to 1g memory used for a lightweight checkout | 19:04 |
Tak | I hope it's over 50% done... | 19:04 |
keithy | ok so... someone needs to tell the mac os x installer people that their move doesnt work | 19:05 |
keithy | it used to be in /usr/bin/bzr | 19:05 |
fullermd | Er. Yes there is a shell involved... | 19:07 |
fullermd | bash will read different rc files for an interactive vs. non session though, so you may need to set $PATH somewhere else. | 19:08 |
* Tak Out of memory - terminating application. | 19:12 | |
* Tak cry | 19:12 | |
keithy | ouch | 19:12 |
lifeless | Tak: what bzr version ? | 19:19 |
Tak | 2.0.3 | 19:21 |
lifeless | hi jam | 19:42 |
jam | hi lifeless | 19:46 |
jam | you seem to be up early | 19:47 |
lifeless | I'm in NZ | 19:47 |
jam | is LCA in a differnt T? | 19:47 |
jam | ah | 19:47 |
lifeless | abentley: could you link the branch to review, I can't find it in mail./ | 19:47 |
abentley | lifeless: https://code.edge.launchpad.net/~abentley/bzr-pqm/lpland/ | 19:49 |
jam | lifeless: you seem to be having a good time at LCA | 19:51 |
=== salgado is now known as salgado-afk | ||
igc | morning | 20:18 |
=== menesis1 is now known as menesis | ||
=== mwhudson_ is now known as mwhudson | ||
keithy | hi | 20:36 |
keithy | how to you set access rights to a repo | 20:37 |
keithy | or make it read only? | 20:37 |
keithy | for checking out only | 20:37 |
Lo-lan-do | keithy: I usually stick it into a location accessible through HTTP. | 20:38 |
keithy | hmm | 20:39 |
keithy | is there a checkout readonly? | 20:39 |
Lo-lan-do | Meaning? | 20:39 |
keithy | if people use that then there is no chance of them accidentally checking in | 20:40 |
keithy | i.e. deploy | 20:40 |
Lo-lan-do | Well, no, the plain HTTP server only has read access to the files in the repo. | 20:41 |
keithy | I set up ssh | 20:41 |
keithy | and bzr+ssh | 20:41 |
keithy | setting up http is a pain. | 20:42 |
keithy | can I just chmod it | 20:42 |
Lo-lan-do | You can chmod -R the repo, yes. | 20:42 |
keithy | k, thall have to do | 20:43 |
Lo-lan-do | That's how I do access control on my repos: each project has its group, and the repos are chgrped+chmodded. | 20:43 |
Lo-lan-do | So only members of group foo can commit to repo foo. | 20:43 |
keithy | k | 20:43 |
Lo-lan-do | Others can read only, or nothing, some repos are private (and therefore rwxrws---). | 20:44 |
Lo-lan-do | keithy: There's an administrator's guide on the website, as I found out today, with interesting points about common problems. | 20:47 |
keithy | k ty | 20:48 |
=== oubiwann is now known as oubiwann_ | ||
=== mwhudson_ is now known as mwhudson | ||
=== Chex_ is now known as Chex | ||
=== mwhudson_ is now known as mwhudson | ||
Glenjamin_ | is there something other than the -D flags i need to use to get debug information? | 23:00 |
Glenjamin_ | "bzr -Dhttp -Dauth update" isnt giving me any additional output | 23:00 |
lifeless | check ~/.bzr.log | 23:03 |
Glenjamin_ | yeah, i realised that now, unfortunately it hasn't enlightened me on the problem at all :( | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!