| === Chex changed the topic of #bzr to: Bazaar version control | Launchpad will be down/in read-only from 23:00 UTC up to 02:00 UTC for a code update | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers! | ||
| lamalex | Hi, I just installed bzr-builddeb and got a debconf dialog about postfix | 00:53 |
|---|---|---|
| lamalex | I know I can basically ignore it, but is there some way to set it up to work with gmail? | 00:53 |
| lifeless | bzr's email stuff can | 00:54 |
| lifeless | but I don't think thats what installed postfix | 00:54 |
| lifeless | it will be debuild's dependencies bringing it in | 00:54 |
| lamalex | right | 00:55 |
| lamalex | is it a known bug that bzr branch lp:<project> isn't working in lucid? | 01:04 |
| lamalex | oh, maybe this is because lp is read-only right now | 01:04 |
| lifeless | lamalex: lp is down right now, for code hosting. | 01:06 |
| lamalex | lifeless, thanks | 01:12 |
| === Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers! | ||
| igc | hi all | 02:12 |
| parthm | hello. I was wonder if "Bazaar Developers" received a review request for bzr-grep for https://code.launchpad.net/~parthm/bzr-grep/bzr-grep-first-review/+merge/20613 | 02:51 |
| lifeless | I get an oops looking at that page | 02:52 |
| lifeless | thumper: ^ | 02:52 |
| thumper | lifeless: yep | 02:52 |
| thumper | lifeless: we kknow | 02:52 |
| thumper | works on prod | 02:52 |
| thumper | edge has a misconfiguration | 02:52 |
| spiv | parthm: I haven't received an email about it, so I guess not | 02:53 |
| parthm | spiv: weird. the maintainer is bzr devs so i assume it should have worked. | 02:54 |
| parthm | for bzr-grep | 02:54 |
| parthm | spiv: i did 'request another review' with reviewer as 'bazaar developers'. i though the maintainer would be the default reviewer. | 02:56 |
| spiv | parthm: FWIW, it's listed at https://code.edge.launchpad.net/~bzr/+activereviews | 03:00 |
| spiv | Although bzr's reviews actually go to ~bzr-core, not ~bzr | 03:00 |
| lifeless | spiv: they do ? | 03:00 |
| spiv | Oh, I might be wrong? | 03:00 |
| lifeless | they go to subscribed teams | 03:00 |
| lifeless | anyhow, ~bzr is in ~bzr-core | 03:01 |
| lifeless | so there is issue if ~bzr-core is the one subscribed to lp:bzr | 03:01 |
| lifeless | s/is/is no/ | 03:01 |
| spiv | My mail archives suggest that review requests for bzr go to bzr-core | 03:02 |
| parthm | spiv, lifeless: ok. as long as its in activereviews :-) next time on i can add bzr-core. | 03:05 |
| lifeless | parthm: please don't | 03:05 |
| === samurai is now known as samiam | ||
| lifeless | the folk in bzr-core *explicitly do not want* to know about bugs or code in plugins. | 03:05 |
| lifeless | ~bzr is the right team, always, for working with stuff in plugins. | 03:06 |
| spiv | parthm: what lifeless said | 03:06 |
| parthm | lifeless: sounds fine. | 03:06 |
| spiv | parthm: but unfortunately I haven't actually received a mail about your review request, so I wouldn't have known it was there without you saying on IRC :( | 03:06 |
| parthm | spiv: thats what i was confused about. its probably listed only because i added ~bzr explicitly. shouldn't maintainer (~bzr) be the default reviewer? lp bug? | 03:07 |
| spiv | parthm: I'm as confused as you are. | 03:08 |
| lifeless | parthm: who owns the branch | 03:08 |
| === samiam is now known as samurai | ||
| parthm | lifeless: ~parthm owns the branch, ~bzr is the maintainer for bzr-grep. | 03:09 |
| lifeless | maintainer doesn't mean anything | 03:09 |
| lifeless | branch owner does | 03:09 |
| lifeless | if you want - and its up to you - bzr-grep to be team maintained (which your desire for code review suggests), then change the owner of lp:bzr-grep (the target branch), to be ~bzr | 03:10 |
| parthm | lifeless: that was it. fixed. https://code.launchpad.net/~bzr/bzr-grep/trunk | 03:11 |
| parthm | lifeless: thanks. | 03:11 |
| * igc lunch | 04:29 | |
| spiv | lifeless: btw, regarding bug 531667, see http://jcalderone.livejournal.com/54911.html | 04:34 |
| ubottu | Launchpad bug 531667 in subunit "There is no version attribute anywhere in subunit" [Undecided,New] https://launchpad.net/bugs/531667 | 04:34 |
| lifeless | spiv: patches appreciate | 04:36 |
| spiv | lifeless: Good to hear they appreciate rather than depreciate in value :) | 04:37 |
| marv | I was reading through the man page and I don't see any way to do the equivalent of "svn up -rxxx [file]", i.e. switch a file or the tree to some previous revision | 04:38 |
| lifeless | so, seriously. I'd love a patch | 04:38 |
| SamB_XP | spiv: what happened to the "p"? | 04:38 |
| spiv | marv: in bzr 2.1 both update and switch take a -r option | 04:38 |
| marv | ah. i seem to have 2.0.2, which is apparently what ubuntu 9.10 makes available to me | 04:39 |
| spiv | marv: for individual files, perhaps you just want "bzr revert -r NNN some/file", though? | 04:39 |
| marv | spiv: that was my next question, i read about the "revert" command, but the man page didn't make it clear if it just changed the working copy, or actually uncommitted the files. all the stuff about it making backups makes me think the latter | 04:40 |
| spiv | marv: note that bzr commits entire trees, not just individual files, so there isn't really any concept of "fileA at rev 99, but rest of tree at rev 101" | 04:40 |
| spiv | marv: revert just changes your working tree | 04:40 |
| marv | ok, thanks | 04:42 |
| spiv | marv: if you want to try 2.1 for ubuntu 9.10, you can try the bzr PPA: https://launchpad.net/~bzr/+archive | 04:42 |
| Peng | marv: revert doesn't actually change the meta data from "r101" to "r99", though. It's "r101 + the files have been modified and coincidentally happen to look like r99". That's often perfectly fine, though. | 04:42 |
| marv | Peng: yeah, i could just revert them again to be back at head. and that behavior actually matching what svn users want half the time when using -r with update, at least in my experience | 04:44 |
| Peng | :) | 04:44 |
| jtv | Anyone got a moment to enlighten me on bzrlib's export function? | 04:54 |
| jtv | I thought this would be the most lightweight way of getting the contents of the current revision of a branch. | 04:54 |
| jtv | But when I use it from within my Launchpad branch, it seems to ignore the URL I pass it and always retrieve a Launchpad branch instead. | 04:55 |
| jtv | Is this the wrong function to use when I just want to get the current contents of a branch given by URL? | 04:55 |
| lifeless | jtv: there isn't a really lightweight way to get a remote branches tip revision content. | 04:57 |
| lifeless | jtv: export is 'ok', as is using the tree functions. But tell me what you want to do - gimme a full lifecycle use case. | 04:57 |
| jtv | lifeless: I want to get the current contents of a given branch, do stuff with them, take the results of the stuff away, and forget all about whatever I did with bzr | 04:58 |
| jtv | (in other words, delete the directory where I got the branch contents) | 04:58 |
| lifeless | jtv: more detail | 04:58 |
| lifeless | will you be querying the revision graph | 04:59 |
| lifeless | will you be diffing files | 04:59 |
| lifeless | will you be doing other things | 04:59 |
| jtv | I'll be running intltool. | 04:59 |
| jtv | Which afaik doesn't care one hoot about bzr and even if it wanted any of its features, doesn't know how to. | 04:59 |
| lifeless | thaats it ? | 04:59 |
| jtv | That's it. | 05:00 |
| lifeless | will it be over the internet | 05:00 |
| lifeless | or a LAN ? | 05:00 |
| jtv | Read the branch contents as a bit of filesystem. | 05:00 |
| jtv | This is LP build slaves talking to the codehosting server, so pretty much LAN. | 05:00 |
| jtv | No private branches now, and for this way of obtaining the branch, probably ever. | 05:01 |
| lifeless | ok | 05:01 |
| jtv | The preferred protocol is http. | 05:01 |
| lifeless | export should be alright for your use case | 05:01 |
| lifeless | so whats happening | 05:02 |
| jtv | My code: | 05:02 |
| jtv | branch, subdir = Branch.open_containing(branch_url) | 05:02 |
| jtv | rev_tree = branch.basis_tree() | 05:02 |
| jtv | export(rev_tree, branch_dir) | 05:02 |
| jtv | . | 05:02 |
| jtv | This creates branch_dir as it should, but in there, gives me the contents of a Launchpad branch. | 05:03 |
| jtv | Regardless of what URL I pass. | 05:03 |
| mwhudson | what is branch_url? | 05:03 |
| lifeless | what do you mean 'Launchpad branch.'? | 05:03 |
| jtv | mwhudson: http URL where the branch can be found. | 05:03 |
| spiv | jtv: do you mean it gives you the entire contents of the branch, not just a subdir that you are identifying in the url? | 05:04 |
| jtv | lifeless: a branch of the Launchpad source. | 05:04 |
| SamB_XP | ! | 05:04 |
| jtv | spiv: no, I'm asking for a completely different, non-LP-related branch and am still getting the LP source tree instead. | 05:04 |
| spiv | jtv: you are running this command while your cwd is a launchpad checkout? | 05:04 |
| mwhudson | that sounds a little strange | 05:04 |
| jtv | spiv: exactly | 05:04 |
| lifeless | jtv: provide a failing url | 05:04 |
| lifeless | jtv: please | 05:04 |
| jtv | Now, it may just be an unintended consequence of the way I'm running this. | 05:04 |
| jtv | lifeless: lp:unpaste | 05:05 |
| mwhudson | jtv: oooh | 05:05 |
| lifeless | ok, /not/ an http url. | 05:05 |
| lifeless | jtv: in future, please don't be vague :) | 05:05 |
| mwhudson | jtv: make sure bzr plugins are loaded | 05:05 |
| lifeless | jtv: you need to load bzr plugins - the launchpad one specifically | 05:05 |
| lifeless | import bzrlib.plugin | 05:05 |
| lifeless | bzrlib.plugin.load_plugins | 05:05 |
| lifeless | - or - | 05:05 |
| mwhudson | jtv: but yeah, best to use http:// urls | 05:05 |
| SamB_XP | shouldn't that just FAIL if the plugins are missing ? | 05:05 |
| lifeless | import bzrlib.plugins.launchpad | 05:05 |
| jtv | I did try with an http URL at one point, but don't remember how it failed | 05:06 |
| lifeless | SamB_XP: no, because open_containing is a heuristic - it walks up | 05:06 |
| mwhudson | jtv: because lp: name resolution is done by talking to the appservers, which buildds won't be able to do | 05:06 |
| lifeless | SamB_XP: and finds '.', 'lp:unpaaste' | 05:06 |
| SamB_XP | lifeless: ah | 05:06 |
| lifeless | jtv: I suggest that you don't want open_containing either | 05:06 |
| lifeless | jtv: for what you're doing, 'open'. | 05:06 |
| * jtv experiments | 05:07 | |
| lifeless | open_containing is for dealing with user input | 05:08 |
| lifeless | 'there is abranch around here somewhere' | 05:08 |
| lifeless | and 'I want the relative path to something in that branch' | 05:09 |
| SamB_XP | like "bzr diff", yeah? | 05:09 |
| lifeless | neither of which apply to your case AFAICT | 05:09 |
| lifeless | SamB_XP: right | 05:09 |
| lifeless | and bzr merge | 05:09 |
| lifeless | bzr log | 05:09 |
| lifeless | bzr cat | 05:09 |
| SamB_XP | bzr dog | 05:10 |
| SamB_XP | bzr moo | 05:10 |
| jtv | Okay, it works when I try it with open_containing on an http URL. Obviously I'm still doing something wrong with the URL though, because I get "BzrBranch7 object is not iterable" when I use open. | 05:11 |
| lifeless | jtv: open returns the branch | 05:11 |
| lifeless | jtv: no subdir | 05:11 |
| lifeless | jtv: see pydoc bzrlib.branch.Branch.open | 05:11 |
| lifeless | SamB_XP: $ bzr dog | 05:11 |
| lifeless | Command 'dog' not found, perhaps you meant 'log'? [y/n]: | 05:11 |
| lifeless | $ bzr moo | 05:12 |
| lifeless | Command 'moo' not found, perhaps you meant 'move'? [y/n]: | 05:12 |
| SamB_XP | oh. "this bzr does *not* have super-cow powers." | 05:12 |
| spiv | open_containing returns (branch, left_over_url_portion) because it has to perform guesswork. open either finds the branch or fails, no ambiguity, so no need for left_over_url_portion. | 05:12 |
| SamB_XP | oops | 05:12 |
| lifeless | SamB_XP: install bzr-guess :P | 05:12 |
| jtv | ...and that works! | 05:13 |
| jtv | Thanks for your patience with my screwups. | 05:13 |
| spm | lifeless: tsk tsk: $ bzr love ==> bzr: ERROR: unknown command "love" ;; leaving me to ask, where's the love!!! | 05:37 |
| lifeless | ~$ bzr love | 05:37 |
| lifeless | Command 'love' not found, perhaps you meant 'move'? [y/n]: | 05:37 |
| lifeless | spm: install bzr-guess, you can find the love :> | 05:37 |
| spm | I find that a bit creepy that bzr love === bzr move. | 05:38 |
| lifeless | I've been meaning to ask. We can delete thelove@canonical.com now, surely. | 05:38 |
| lifeless | spm: there ain't no love without movement. | 05:38 |
| spm | probably; RT requests accepted. | 05:38 |
| spm | that's the creepy part.... | 05:39 |
| spm | lifeless: somewhat less seriously; managed to briefly grab lamont; he is reaching new levels of bafflement and bewilderment on the subunit stuff. the build for intrepid; drop in hardy question remains open. | 05:39 |
| lifeless | spm: I'm happy with a manual install: I just want it done </user> | 05:40 |
| spm | yeah... trouble is we've been down that path before and pain awaits in the fairy garden at the end. But he is aware of it, so I remain hopeful of a solution soon. | 05:41 |
| lifeless | thanks! | 05:41 |
| bob2 | goodbye, thelove! | 05:43 |
| spm | alas poor love, I knew him/her/it well.... | 05:44 |
| jtv | spm: we're being very Shakespearian this week, aren't we? | 05:46 |
| jtv | Or Hamletic really, since it's all from the same monologue | 05:47 |
| spm | one (badly mis)quote and I'm labelled?!!?!? :-) | 05:47 |
| lifeless | to commit or not to commit, that is the question | 05:47 |
| jtv | (Hmm... "monologue"—that's a good word for a dialogue-that-just-holds-everything-up-until-you-click-OK) | 05:48 |
| jtv | spm: I did most of the bad quoting as I recall | 05:48 |
| jtv | "whether 'tis nobler in the channel" | 05:48 |
| jtv | "to suffer the guns and roses of outrageous fortune" | 05:48 |
| spm | jtv: ahh my bad, you said "we're". apologies for the excess of self-ego issues | 05:48 |
| * jtv is going dyslexic and read that as self-lego issues | 05:49 | |
| jtv | Must be also why I typed "bzr sty" just now, but in my defense, that _should_ be a valid command | 05:49 |
| SamB_XP | jtv: I didn't know Self came with Legos! | 05:49 |
| SamB_XP | or is that the issue ? | 05:49 |
| spm | jtv: so what I'm getting there is that a monologue is a language exclusive lock? or perhaps I've spent too much time earlier today staring at postgres logs.... | 05:49 |
| jtv | SamB_XP: I'll completely ignore the reference and answer, "it depends on who self is" | 05:50 |
| jtv | spm: hey, it beats sniffing glue. What's a _language_ exclusive lock though? | 05:50 |
| spm | jtv: and technically, it could be argued, I do have self-lego issues. seeing as I started stock piling lego for a boy when he was ~ 2-3 months old. which now he's 6 works *really* well :-D | 05:50 |
| SamB_XP | you know, that language-whose-implementation-does-not-wish-to-build-on-x86/with-modern-G++? | 05:50 |
| spm | s/a boy/our boy/ | 05:51 |
| jtv | spm: that pretty much meets my definition of being one of the very few people _without_ lego issues | 05:51 |
| spm | hahahah | 05:51 |
| jtv | Two, if you count the boy | 05:51 |
| jtv | SamB_XP: I _said_ I'll completely ignore the reference. :-P | 05:51 |
| * SamB_XP gives jtv a morphic drip to correct the problem | 05:52 | |
| jtv | a whu'!? | 05:52 |
| SamB_XP | Morphic is the name of Self's UI framework | 05:53 |
| jtv | ah | 05:55 |
| jtv | and the drip? | 05:56 |
| jtv | (damn this trait of curiosity!) | 05:56 |
| SamB_XP | you know, an IV | 05:56 |
| SamB_XP | like a morphine drip, only morphic ;-P | 05:56 |
| jtv | YKYBPTLW you miss a reference to morphine because morphic seems such a normal word | 05:57 |
| SamB_XP | normal word? what the? | 05:58 |
| spiv | Well, if YBPTL, it might seem to be ;) | 05:58 |
| SamB_XP | have you been on Squeak or something ? | 05:58 |
| spiv | (I'm guessing P == Pratchetting) | 05:58 |
| SamB_XP | also, YRU using all these crazy things starting with Y? | 05:59 |
| marv | the what's new in 2.1 page linked me to http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html which seems to 404 | 06:03 |
| fullermd | Y? Y! | 06:03 |
| poolie | hi all | 06:03 |
| poolie | thanks for pointing that out, marv | 06:04 |
| spiv | Hi poolie | 06:05 |
| poolie | hi spiv, how are you? | 06:08 |
| marv | i wish http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion would have linked to http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html the latter seems much more useful but I had a harder time finding it | 06:10 |
| poolie | marv, it's a wiki so please feel free to add a link | 06:10 |
| spiv | poolie: pretty good, although I just got a surprising and hopefully unreproducible test failure... | 06:15 |
| bialix | igc: ping | 06:24 |
| igc | hi bialix | 06:24 |
| bialix | hi igc | 06:24 |
| bialix | qbzr 0.18.3 is ready for you | 06:24 |
| igc | bialix: thank-you | 06:24 |
| bialix | :-) | 06:25 |
| igc | marv: that 404 is a bug in the plugin guide. I need to generate a new one | 06:25 |
| bialix | igc: anything else needed? | 06:26 |
| igc | bialix: not that I know of. hopefully .3 fixes most of the treewidget issues in explorer | 06:26 |
| bialix | okay, I'll be online again later | 06:27 |
| * bialix disappears | 06:29 | |
| poolie | igc, marv, i'll just run an update on escudero | 06:34 |
| poolie | it may just be out of date? | 06:34 |
| poolie | no, that's not it, so i'll leave it with you igc | 06:46 |
| sttng359 | Hello | 06:57 |
| poolie | hello | 06:58 |
| poolie | biab, rebooting | 07:00 |
| sttng359 | I have a bazaar repository made with 1.13.1 that I'd like to clone to be able to use with Bazaar 1.6.1. | 07:01 |
| sttng359 | Can I use the newer Bazaar to clone it in a way compatible with the older Bazaar? | 07:02 |
| RAOF | sttng359: This depends on what format the repository is in. If I remember correctly, the default format of 1.13.1 should be compatible with 1.6.1, so you should be good to go. | 07:03 |
| RAOF | If you used a non-default format, then you may have problems. | 07:03 |
| sttng359 | It was created using the bzr-svn plugin. | 07:03 |
| sttng359 | I get Unknown repository format: 'Bazaar RepositoryFormatKnitPack6RichRoot (bzr 1.9)\ | 07:03 |
| lifeless | sttng359: you are _much_ better off installing a new bzr. | 07:04 |
| sttng359 | with the older Bazaar. | 07:04 |
| lifeless | sttng359: is that not possible? | 07:04 |
| RAOF | sttng359: I think you could get around that by serving the repository over the smart-server, but newer bzrs are cooler. :) | 07:04 |
| sttng359 | My work is using an Ubuntu 8.10 server with has 1.6.1. | 07:04 |
| Peng | RAOF: Probably not -- bzr still does a lot of VFS access. | 07:04 |
| Peng | sttng359: So use the PPA to install a newer one. https://launchpad.net/~bzr/+archive | 07:05 |
| Peng | Then you can upgrade to a newer, smaller, faster repo format too. :D | 07:05 |
| sttng359 | The options like 1.6.1-rich-root don't seem to affect branch. | 07:06 |
| Peng | sttng359: Downgrading is certainly possible, but...why would you want to use an older, suckier format in an older, suckiet bzr? | 07:06 |
| sttng359 | I don't have root on my work server. | 07:06 |
| Peng | sttng359: Ooh. Well, do you have the sysadmin's phone number? :D | 07:06 |
| spiv | sttng359: you can do 'bzr upgrade --1.6.1-rich-root' | 07:06 |
| Peng | You _could_ still run bzr from source. | 07:06 |
| sttng359 | They are planning on upgrading to Ubuntu 10.04, I think, but it's currently 8.10. | 07:06 |
| spiv | sttng359: (i.e. the upgrade command can also downgrade) | 07:07 |
| sttng359 | ok | 07:07 |
| Peng | spiv: It can? | 07:07 |
| spiv | Yes. | 07:07 |
| Peng | Hey, it can. | 07:07 |
| sttng359 | I'd have to get fellow devs to share work with me, so I prefer the server installed version of tools | 07:07 |
| sttng359 | but I could probably get them to use my custom installed version. | 07:08 |
| lifeless | 1.6 is not going to be reliable on rich root | 07:08 |
| lifeless | _really_ don't use it with the bzr-svn import | 07:08 |
| sttng359 | does --1.9-rich-root represent the format used by newer Bazaar? That option doesn't exist in 1.6.1. | 07:09 |
| lifeless | no | 07:09 |
| Peng | "bzr init --2a foo && cd foo && bzr upgrade --1.6.1-rich-root" seems to go into an infinite loop. :D | 07:09 |
| vila | hi all ! | 07:09 |
| lifeless | the 1.9 formats are about a 15 months old, maybe more. | 07:09 |
| lifeless | Peng: the branch objects don't have a downgrader written for them. | 07:10 |
| lifeless | Peng: there is a bug open. | 07:10 |
| Peng | lifeless: Ah, fun. | 07:10 |
| lifeless | sttng359: you can use sftp:// rather than bzr+ssh://, then the version of bzr on the server won't matter. | 07:10 |
| sttng359 | do I need rich-root support on clones if they won't be directly commiting to subversion? | 07:14 |
| lifeless | yes | 07:14 |
| lifeless | 2.0 has rich root by default | 07:14 |
| lifeless | is much faster and uses less memory ;) | 07:14 |
| sttng359 | maybe I can convince my sysadmin to install a newer package, but even my home computer with 9.04 only has 1.13.1. | 07:16 |
| Peng | You can use the PPA on your home computer too. :> | 07:17 |
| sttng359 | Are http transports for Bazaar repository agnostic? | 07:20 |
| lifeless | I don't know what you mean by that question. | 07:21 |
| sttng359 | I'm just curious how much trouble open source developers have since it seems like the Bazaar repository format keeps changing. | 07:23 |
| Peng | It hasn't changed so far this year! | 07:23 |
| * Peng ducks | 07:23 | |
| Peng | People use older formats, or upgrade bzr. | 07:24 |
| poolie | vila, thanks for all the reviews | 07:25 |
| spiv | sttng359: as Peng says, people stick with the older formats if they can't upgrade bzr | 07:25 |
| sttng359 | If I can't clone an open source projects repository because it's the new 2.0 format for example. | 07:25 |
| poolie | and for replying to the meta patch pilot thing, that saved me feeling i was totally wasting my time | 07:25 |
| spiv | sttng359: the main problem we had was that bzr-svn required a non-default format until 2.0 | 07:25 |
| poolie | sttng359: are you having trouble yourself or is it just a general comment? | 07:25 |
| vila | poolie: hehe, you're welcome, there are still some left but the queue size is already more reasonable | 07:26 |
| poolie | fwiw i probably would have finished henninge's branch rather than pushing it back | 07:27 |
| poolie | bu, obviously, i can still actually do that myself | 07:27 |
| sttng359 | no, I am just an assumption that Bazaar 2.0 would create a 2.0 rep by defaultd on my difficulkty using repositories created with bzr-svn (yes, using pre-2.0 bazaar. | 07:27 |
| sttng359 | I have had enough issues with subversion automatically updating the format of working copies the moment a newer client even does a status on an older format. I was very glad to at least find out that Bazaar does not automatically upgrade. | 07:28 |
| sttng359 | But I assumed Bazaar would use the newest format available for new repos. | 07:29 |
| sttng359 | so standard 1.x Bazaar does not use rich-root for standard (non svn-based) repos? | 07:30 |
| Peng | Usually they wait a couple releases before making a new format the default. The 2.0 format has been supported since 1.18 or so. | 07:30 |
| Peng | sttng359: Bazaar only started defaulting to a rich-root format in 2.0. | 07:30 |
| vila | poolie: well, for henninge's branch, I left the door open, had he say: "Sorry I won't", I would have finished it, but I'd like to make some progress on the conflict stuff too... | 07:31 |
| _habnabit | Can you have a subdirectory in a branch be linked to some other branch, like you can in svn? | 07:31 |
| Peng | sttng359: There's nothing bzr-svn-specific about rich-root formats, it's just that bzr-svn is pretty much the only thing that requires rich-roots. | 07:33 |
| sttng359 | On a seperate note, I am having issues with Bazaar 1.13.1 and bzr-svn checking out a secured HTTPS subversion repository with unexpect 401 response (expect 200 or 404). | 07:34 |
| Peng | Oh god, _that_ bug. | 07:34 |
| sttng359 | so I *really* need to upgrade? | 07:34 |
| Peng | Wait. Maybe not _that_ bug. | 07:35 |
| Peng | Still auth makes my head hurt, and I meant to go AFK like an hour ago. Bye! | 07:35 |
| Peng | s/auth/HTTP auth/ | 07:35 |
| sttng359 | k | 07:35 |
| sttng359 | thkx for your help | 07:35 |
| nil1 | Hi | 08:33 |
| nil1 | Is there a known memory leak in "bzr svn-import"? | 08:34 |
| nil1 | If not, how can I obtain additional information for the bug report? | 08:34 |
| * igc dinner | 08:34 | |
| parthm | vila: i am going through your review comments https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691 | 08:44 |
| parthm | vila: for the comment on "def parent_dir(path):" are your suggesting i move the code into copy_ownership? | 08:45 |
| vila | parthm: copy_ownership says: "If own_src is None, the containing directory is used as source" but this refers to the *usage* of the function instead of implementing it, | 08:47 |
| vila | and even there ISTM that you *don't* call chown() if ownership_src is None in higer levels | 08:48 |
| vila | So I would rather special case None and '' in copy_ownership and get rid of parent_dir | 08:48 |
| vila | but I as said in the end, I'm not sure the whole approach is really sound... | 08:49 |
| parthm | vila: sounds fine. i think the change might have got lost in one of my edits. | 08:49 |
| parthm | vila: the approach is discussed a bit on bug #376388 | 08:49 |
| ubottu | Launchpad bug 376388 in bzr "~/.bazaar created owned by root (when run under sudo)" [Medium,In progress] https://launchpad.net/bugs/376388 | 08:49 |
| vila | parent_dir is weird in itself and doesn't realy match the way we work in bzrlib | 08:50 |
| vila | parthm: yeah, I've read that, I don't agree with everything said there :) | 08:50 |
| parthm | vila: ok. | 08:50 |
| parthm | so should we just keep the behavior as is for now? | 08:51 |
| vila | but if you address my other concerns, I'll nudge poolie for a review and we'll discuss on a clean patch | 08:51 |
| parthm | vila: sounds fine. | 08:51 |
| parthm | regarding the test. | 08:51 |
| vila | parthm: that's what I'm unsure about, ISTM that etckeeper already addressed the bug and that we may leave that as is. On the other hand, if we can address the sudo problem for the root user case, maybe we should | 08:52 |
| parthm | i use _dummy_chown to set instance variables and see if these are changed. does that seem inadequate to you. | 08:52 |
| vila | parthm: partly yes, because you then execute code that doesn't do what it's supposed to do and that's... weird | 08:53 |
| parthm | vila: the assumption is that os.chown works correctly. | 08:53 |
| parthm | i couldn't think of another way. | 08:53 |
| vila | i.e. this is cheating a bit too much and will be brittle in the long run (say if someone make a change, you may still have tests passing without detecting a potential bug) | 08:54 |
| parthm | vila: thats the lowest level. so unless the os.chown behavior changes it should catch things. the only other way istm is to actually copy ownership from/to another user. | 08:55 |
| vila | What I'd do there is making sure chown *change* uid gid | 08:56 |
| vila | yes, that would be better | 08:56 |
| parthm | but i am not sure how portable/reliable that is. | 08:56 |
| vila | as long as chown is available and the user running the test owns the containing directory, I'm pretty sure you're allowed to change uid/gid and still be able to delete the file | 08:57 |
| vila | or dir | 08:57 |
| parthm | vila: but do we have access to another user for a test system? we could assign root, but how does that play out with the test infra. | 08:57 |
| vila | I'll avoid root but using anything else should be fine | 08:57 |
| parthm | vila: ok. i was concerned about the delete part. i can try that out. | 08:57 |
| vila | making the test explicitly delete the chowned file is a good way to ensure that it fails if something goes wrong | 08:58 |
| parthm | vila: what other user do you suggest? | 08:58 |
| vila | uid+1, gid+1 | 08:58 |
| vila | anything that isn't the current user nor root | 08:58 |
| parthm | vila: +1 may not always work. for e.g. on my laptop i am the only user. | 08:59 |
| vila | ro | 08:59 |
| vila | I'm pretty sure you may use uids and gids that don't exist | 08:59 |
| vila | s/may/can/ | 08:59 |
| parthm | vila: oh. ok. so just change the uid/gid. sounds reasonable as long as we can delete it. i will give that a try. | 09:00 |
| vila | parthm: also recording the calls to chown allows to use a single assertEquals(('path', 12, 12), call_args) | 09:01 |
| vila | instead of 3 | 09:01 |
| parthm | vila: or maybe we can go with some user like 'backup' but i am not sure if that exists on osx. | 09:01 |
| parthm | vila: i am not sure i understand the part about recording the calls. | 09:02 |
| vila | you need to use uids anyway so no need to translate that from usernames, and I don't know of any username guaranteed to exist anyway | 09:02 |
| vila | let me find an example in the code base | 09:02 |
| parthm | vila: sounds ok. i can pick some reasonably large uid/gid | 09:02 |
| vila | parthm: arbitrary large is not guaranteed to be different of the current one, that's the key | 09:03 |
| parthm | vila: yes. +1 should be ok i suppose. if +1 has too many rights we are in trouble anyway :-) | 09:04 |
| fullermd | Probabilistic tests are more fun anyway :p | 09:04 |
| parthm | fillermd: :) | 09:04 |
| vila | fullermd: yeah and funny hostnames too :) | 09:04 |
| * fullermd slinks back into his corner [case] :p | 09:05 | |
| vila | parthm: bzrlib/tests/test_selftest.py search for SkippedTest | 09:05 |
| vila | parthm: the methods record the calls *and* call the real methods | 09:06 |
| vila | overrideAttr returns the original value (the real chown) that you'll need to use | 09:07 |
| parthm | vila: sounds good. | 09:08 |
| parthm | a somewhat related question. is there a shortcut to see work-in-progress mps. right now i go through my branch list for this but its difficult to remember. | 09:09 |
| Peng | https://code.edge.launchpad.net/$project/+activereviews | 09:10 |
| parthm | vila: so assertEquals actually makes the call? | 09:10 |
| parthm | Peng: it seems work-in-progress doesn't show up there. | 09:10 |
| Peng | Oh. | 09:10 |
| parthm | Peng: i was just wondering if there was something like +wip | 09:11 |
| vila | parthm: wow, no, assertEqual just checks that things are equal :) | 09:11 |
| Peng | parthm: The branch's +activereviews page shows work-in-progress ones, e.g. https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/+activereviews | 09:11 |
| parthm | vila: :-) so i make the call myself. | 09:11 |
| vila | parthm: there is https://code.edge.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1 | 09:11 |
| vila | parthm: you want a recording_chown that append to self._calls and *then* you can check : | 09:12 |
| parthm | vila, Peng: thanks. loggerhead definitely has a nicer url :-) | 09:12 |
| dcoles | Good afternoon. I was wondering if anyone knew if bzr+svn can use authentication.conf (trying to work on a Google Code svn+https repository that asks for passwords every operation) | 09:12 |
| parthm | vila: yes. thanks for the help on the review. i think i am good to take another stab at it. | 09:13 |
| Peng | vila: What pages link to +merges? | 09:13 |
| vila | assertLength(1, self._calls) and assertEquals(('path', 12, 12), self._calls[0]) | 09:13 |
| parthm | vila: good idea. | 09:13 |
| vila | Peng: I don't know, I just have this one in my history so I type 'workinp' in firefox and select it :-P | 09:14 |
| Peng | vila: Heh, okay. | 09:14 |
| vila | Peng: sorry, I lied, I just type ''wor' :D | 09:15 |
| vila | oh my, I should go through that list as Patch Pilot... | 09:15 |
| parthm | vila: thats a long list :-) | 09:16 |
| vila | Peng: I lied again, see: http://wiki.bazaar.canonical.com/PatchPilot | 09:16 |
| vila | Peng: it's mentioned there from 'You can also keep an eye on work in progress merges ...' | 09:17 |
| Peng | Ah. | 09:20 |
| * parthm goes back to actually closing review comments and not talking about them. | 09:20 | |
| Kohlrabi | hello, I got a question regarding checkout of subfolders: I have a project where I have a main "root" folder and subfolders e.g. "A" and "B". Currently I have "root" setup as a branch. Is it possible to just checkout/branch one of the subfolders and at the same time get the full history of that subfolder (i.e. no exporting), and also push only this subfolder back? | 09:47 |
| Kohlrabi | Or would I have to setup each subdir as a branch? | 09:47 |
| Kohlrabi | Also, if I did that, is it possible to have changes to the subfolders propagated to the root? | 09:49 |
| Kohlrabi | So if some user just needs folder "A" he can checkout/checkin that, but if someone wants the whole project he can checkout "root", and both are synchronized? | 09:49 |
| Kohlrabi | I'm not afraid to do a bit of python hacking to make the sync work ;) | 09:50 |
| bialix | vila: lol (re-patch crew mail) | 09:59 |
| bialix | Kohlrabi: A and B should be 2 branches | 09:59 |
| bialix | then you can use bzr-externals plugin or scmproj plugin to work on root+A+B as the whole | 10:00 |
| vila | bialix: Always Happy to make you laugh (TM) :D | 10:01 |
| bialix | vila: many thanks! | 10:01 |
| bialix | vila: I'm writing plugin as universal hooks launcher | 10:04 |
| bialix | it's maybe interested for others | 10:04 |
| vila | bialix: mail the list ! | 10:05 |
| bialix | I think I've figured how to run either external script or python function | 10:05 |
| bialix | err, I need your mini-review | 10:05 |
| Kohlrabi | bialix: thank you | 10:05 |
| Kohlrabi | Will look into that | 10:05 |
| vila | bialix: hehe, don't be shy :) | 10:05 |
| fullermd | Do you get mini-reviews from mini-pilots? :p | 10:06 |
| bialix | vila: so I'm trying to build such scheme: universal hook look into .bzrmeta/hooks/config for the details | 10:06 |
| * vila is reminded that Gary is already waiting for some test review :-// | 10:06 | |
| vila | -o- <-- mini plane | 10:06 |
| bialix | say start_commit hook (of MutableTree) | 10:06 |
| bialix | fullermd: yeah | 10:07 |
| bialix | so my hook launcher will looking for the line in the config like: | 10:07 |
| fullermd | . . . <-- mini anti-aircraft artillery | 10:07 |
| bialix | MutableTreeHooks.start_commit = XXX | 10:07 |
| * vila 's goes boom | 10:07 | |
| * vila 's *plane* goes boom | 10:08 | |
| vila | argh typo/joke/runied | 10:08 |
| bialix | ^ parachute for vila | 10:08 |
| bialix | \^/ | 10:08 |
| fullermd | That's OK. We expect typos while you're being shot at 8-} | 10:08 |
| vila | LOL | 10:08 |
| fullermd | ... 'course, we expect typos from you when you're NOT being shot at too... | 10:08 |
| vila | what a pyto | 10:08 |
| vila | bialix: remind me: is .bzrmeta versioned ? | 10:09 |
| bialix | vila: if you wish | 10:09 |
| bialix | but in general -- yes | 10:09 |
| bialix | it was igc's idea | 10:09 |
| lifeless | bialix: so, jelmer has a plugin that runs external hooks | 10:10 |
| bialix | to put there meta info | 10:10 |
| lifeless | its totally insecure | 10:10 |
| lifeless | and it sounds like what you are proposing is as well | 10:10 |
| bialix | lifeless: where it is? | 10:10 |
| vila | bialix: with an additional twist about running the hook or not depending on some config setting right ? | 10:10 |
| lifeless | http://wiki.bazaar.canonical.com/BzrPlugins | 10:10 |
| lifeless | look for shell-hooks | 10:10 |
| bialix | rats, I'm reinventing the jelmer's wheel | 10:11 |
| lifeless | bialix: running code specified *by the branch* is a very dangerous thing to do | 10:11 |
| lifeless | bialix: running code *selected by* the branch, is much safer, and thats what we already do. | 10:11 |
| bialix | I don't understand | 10:11 |
| lifeless | ok, say you have something in .bzrmeta to run a shell script | 10:12 |
| lifeless | I can tell you to branch my code to do something | 10:12 |
| lifeless | and the shell script can email me your credit cards, and then rewrite itself as being innocent | 10:12 |
| bialix | yeah, that's cool | 10:12 |
| lifeless | the same applies if the thing specified is python code | 10:13 |
| bialix | lifeless: I'm ok with that | 10:13 |
| * vila notes to never ever branch any lifeless stuff anymore | 10:13 | |
| bialix | and I need exactly thing thing | 10:13 |
| bialix | this thing | 10:14 |
| lifeless | bialix: Are you sure you need it? | 10:14 |
| bialix | yes | 10:14 |
| lifeless | its come up many times here and there has always been another way. | 10:14 |
| bialix | lifeless: there is no another way to run hooks, one always need to write a plugin to implement the hook | 10:15 |
| lifeless | I'll note that neither git nor hg run untrusted code, for the same reason - stuff that you clone can't be allowed to just run code of its own | 10:15 |
| lifeless | bialix: thats orthogonal to whether the branch supplies the code | 10:15 |
| bialix | okay, I understand | 10:15 |
| lifeless | you can have shell scripts in ~/.bazaar/shell-hooks or something, and I won't object | 10:16 |
| fullermd | Well. Just because it's nutso in one context doesn't make it so in another. | 10:17 |
| lifeless | you could have them in .bzr/branch/xxx too, as long as they can never be propogated by the branch [or effectively never :P] | 10:17 |
| bialix | lifeless: approach with branch.conf does not scale with colo plugin | 10:17 |
| fullermd | Having it in-branch has significant advantages over that schema. And there are situations where its drawbacks aren't relevant. | 10:17 |
| lifeless | fullermd: troll or serious? if serious please enlarge | 10:17 |
| fullermd | In ~/.bazaar/ is totally unscalable because it means you have to do it for (every user * every change). | 10:18 |
| bialix | unless we will have exactly the same model as git and hg by default: one working tree for many branches and only one branch.conf for all of them | 10:18 |
| fullermd | Under .bzr/ somewhere that doesn't propogate solves one set of problems. Somewhere that does (be it under .bzr/ or in the WT) solves another set. | 10:18 |
| fullermd | And in the case *I* work with all day, of internal-ish code, trust is fundamental anyway. | 10:19 |
| vila | fullermd: sure, but here I think the question is *who* controls. And via the already existing configs you can already depends on the branch to decide what code is executed. The point is to have *that* code under control and not arbitrary coming from anyone. | 10:19 |
| fullermd | Obviously trusting code from $RANDOM_SOURCE_ON_THE_NET is a totally different question. | 10:19 |
| * vila nods | 10:19 | |
| fullermd | But the only way code could end up in these branches is if I put it there, or one of a very few people I work with puts it there. | 10:20 |
| fullermd | And I know where they all live. | 10:20 |
| fullermd | (besides, we all run the versioned code in the branches anyway; if an attack vector were wanted, it's right there waiting already) | 10:21 |
| vila | reflections on trusting trust... | 10:22 |
| * fullermd nods. | 10:22 | |
| vila | ..arbitrary code can hide itself from bzr diff... | 10:22 |
| vila | nightmare | 10:23 |
| fullermd | And also the same thing as that article... Eric's? about differences in mindset in the OS vs corp VCS worlds. Things can make good sense in one and be lunacy in the other easily. | 10:23 |
| lifeless | so | 10:25 |
| lifeless | there are two problems | 10:25 |
| lifeless | a) distributing the code | 10:25 |
| lifeless | b) making it run | 10:25 |
| lifeless | for a) plugins are great. So are shell scripts in ~/.bazaar if you lik that sort of thing. | 10:25 |
| lifeless | both of these can be totally automated for users * changes: make a branch with all your plugins, put 'bzr pull' in a cronscript. | 10:25 |
| lifeless | b) then, for both cases, is 'run the code always, in every branch, and have the code quit early if it doesn't want to do anything' | 10:26 |
| lifeless | bialix: I don't understand why the ^ won't work for you. (using shell scripts if needed, thats a different conversation). | 10:27 |
| lifeless | jelmers shell-hooks plugin may need some love, and I don't think anyone else from core has audited it; it may be insecure - I don't know. | 10:28 |
| bialix | lefeless: jelmer's code is pretty simple | 10:28 |
| bialix | but it does not work what I need: it has no support for start_commit | 10:28 |
| bialix | and in fact there is need some sort of templates instead of dumping all possible arguments to command line | 10:29 |
| lifeless | should be easy enough to extend | 10:29 |
| bialix | lifeless: I don't understand your question about "why the ^ won't work for you" | 10:29 |
| bialix | I need special hook in the specific branch | 10:29 |
| bialix | not in al branches | 10:29 |
| bialix | all | 10:30 |
| lifeless | bialix: so there is a conceptual 'if block' for that one branch, right ? | 10:30 |
| bialix | to be precise: I need to run scons befor starting commit so some auto-generated files will be refreshed | 10:30 |
| lifeless | so, in psuedo code: - in the hook, you say | 10:31 |
| bialix | lifeless: if specific_tree: yes | 10:31 |
| lifeless | 'if branch.config.run_scons: run_scons()' | 10:31 |
| lifeless | and that then will only run scons on the branch you want it to run scons | 10:31 |
| bialix | lifeless: in another branch I need to run something else | 10:31 |
| bialix | I don't want to write zillion plugins | 10:31 |
| lifeless | I'm not talking plugins | 10:31 |
| lifeless | if you're doing shell scripts you're writing shell scripts | 10:32 |
| bialix | if I want branch-specific python code? | 10:32 |
| lifeless | [note to self, running scons *is* running arbitrary code...] | 10:32 |
| vila | bialix: then you run the python code is the branch matches some config setting | 10:33 |
| bialix | I want to distribute my hooks as the part of my branch | 10:33 |
| vila | bialix: I don't want to give you my credit card number | 10:34 |
| bialix | I understand your security concerns, but I think for colo-case using branch.conf is the wrong idea | 10:34 |
| vila | bialix: how do you address that ? | 10:34 |
| bialix | put them into .bzrmeta/hooks | 10:34 |
| bialix | I understand lifeless idea to enable them explicitly | 10:34 |
| bialix | so it should be enabled via unversioned .bzrmeta/hooks/local config | 10:35 |
| vila | For the news_merge plugin we have a setting that should be set explicitly, what makes colo usage so specific that you can't add the relevant code there ? | 10:37 |
| bialix | colo usage means you have several branches | 10:37 |
| vila | and ? | 10:38 |
| bialix | you need to remember that every time you create new short-lived branch you have to go into .bzr/branches/foo/.bzr/branch/branch.conf and copy-paste your settings | 10:38 |
| bialix | it's not my way | 10:38 |
| vila | you can do that in locations.conf then | 10:38 |
| vila | [/home/vila/src/bzr] | 10:39 |
| bialix | I don't use it because of some reasons | 10:39 |
| vila | post_commit_to = bazaar-commits@lists.canonical.com | 10:39 |
| vila | news_merge_files = NEWS | 10:39 |
| vila | auto_update_copyright = True | 10:39 |
| bialix | I have many working trees around and I'm working with scmproj-based projects | 10:40 |
| bialix | it complicates things a lot | 10:40 |
| lifeless | so | 10:40 |
| lifeless | I think some settings should propogate in branch.conf | 10:40 |
| bialix | locations.conf is good only if you're working on mono-project and never move it around your filesystem | 10:40 |
| lifeless | and .bzrmeta/pluginname is equally good to do that | 10:40 |
| lifeless | the *key* thing for me is not to run arbitrary code | 10:41 |
| bialix | define "arbitrary code" | 10:41 |
| lifeless | I'm happy to advise on how to achieve that; we've managed so far, but we can be more userfriendly without losing that safety net. | 10:41 |
| lifeless | bialix: if I can make it mail me your credit card numbers, its arbitrary | 10:42 |
| bialix | it's too wide | 10:42 |
| bialix | I can write a plugin to do so | 10:42 |
| bialix | and advise my friends to install it | 10:42 |
| bialix | without putting anything in their branches | 10:42 |
| bialix | you get the loop | 10:43 |
| lifeless | the act of branching is the key thing | 10:43 |
| bialix | who will watch the twatchers? | 10:43 |
| lifeless | I realise you can have someone install a plugin - but they know that that means 'install new code' | 10:43 |
| lifeless | branching something should never equate to 'install new code' | 10:43 |
| bialix | lifeless: I have evidence when one man refused to run the code: python -c "import this" | 10:44 |
| lifeless | heh | 10:44 |
| vila | bialix: perl -t runs perl in a mode where it "taints" (marks) any unsecure code and all code depending on it, if you open a hole, you compromise the whole. We'd better enhance the whole than opening a hole | 10:46 |
| bialix | okay, I undertsand your points. Let's stop here. I know what I need, and I need it for my work. So it will be my private thing | 10:47 |
| bialix | thanks all for discussion | 10:47 |
| bialix | I think something similar to shell-hooks plugin should be in the core | 10:51 |
| sttng359 | I am using bzr 2.1.0 with bzr-svn 1.0.2 from PPA to checkout a SVN repo, but I keep getting a checksum mismatch about 10 revisions in. | 11:04 |
| sttng359 | I ran svnadmin verify across the whole repo which found no errors. | 11:04 |
| jelmer | sttng359: can you pastebin the error somewhere? | 11:06 |
| sttng359 | http://pastebin.com/k4jJuMFc | 11:08 |
| sttng359 | I had previously used bzr 1.13.1 with bzr-svn 0.5.3 successfully. | 11:11 |
| jelmer | sttng359: I have no idea what might be wrong there. Can you please file a bug against bzr-svn including the relevant backtrace from ~/.bzr.log ? | 11:19 |
| sttng359 | OK | 11:23 |
| sttng359 | as a workaround for now, is there any issues with using bzr 1.13.1 to do a checkout using the 1.9-rich-root repo from subversion, and perhaps later upgrading to 2a? | 11:34 |
| dcoles | Hi. Does anyone know how to make bazaar's svn+https scheme remember username and passwords? | 11:37 |
| bob2 | doesn't it use whatever svn uses? | 11:37 |
| dcoles | I've had no luck getting it to use authentication.conf. | 11:37 |
| dcoles | I'm... not really sure. | 11:38 |
| dcoles | bob2: There is a ~/.bazaar/subversion.conf, but I've not yet found it's config reference | 11:39 |
| jelmer | dcoles: Newer versions of bzr-svn can use ~/.bazaar/authentication.conf | 11:41 |
| jelmer | dcoles: bzr-svn will also use any passwords cached by svn | 11:42 |
| dcoles | jelmer: Thanks for the help. How new is "new"? I'm currently running the version in Lucid and haven't had any luck with authentication.conf (it doesn't even seem to note the configuration in the bazaar log) | 11:45 |
| jelmer | dcoles: 1.0.2 should be new enough (I think that's what's in lucid) | 11:46 |
| dcoles | jelmer: Yup. 1.0.2-2 | 11:47 |
| dcoles | I guess my question would then be should authentication.conf be set up the same as what you would for a normal bazaar remote repository? | 11:48 |
| jelmer | yeah | 11:48 |
| dcoles | I have a host, user and password set (and a commented out scheme of https) | 11:48 |
| jelmer | I think you need to have the scheme set to get it to work | 11:49 |
| dcoles | Ok, Ok, I've just tried a scheme of https, svn+https and https - still no luck | 11:53 |
| Kamping_Kaiser | can bzr-svn be told not to look in the root of an svn repo when branching over http? http://paste.debian.net/62396/ seems to be a result of trying to access svn/fsfla/ directly, which isn't viewable without a login | 11:56 |
| jelmer | Kamping_Kaiser: not at the moment, there's an open bug about that | 11:57 |
| Kamping_Kaiser | jelmer: ok, thanks for the info | 11:57 |
| jelmer | dcoles: so you get a password prompt ? | 11:57 |
| dcoles | jelmer: Yes - And a username prompt too | 11:58 |
| dcoles | "HTTPS username:" | 11:58 |
| === mrevell is now known as mrevell-lunch | ||
| dcoles | Ok, it looks like it's calling AuthenticationConfig.get_user(...) but that is just giving me my local username | 12:16 |
| jelmer | dcoles: are you including the username in the URL? | 12:17 |
| dcoles | No, I'm not | 12:18 |
| dcoles | Even with a username in the URL, it still asks for one | 12:20 |
| dcoles | auth.py calls get_user with what looks like an empty host... | 12:35 |
| jelmer | oh, hmm? | 12:41 |
| dcoles | I managed to find get_svn_simple which is also getting my local username passed to it before even calling get_user | 12:42 |
| dcoles | Though I'm not quite sure where get_svn_simple is called from - I couldn't find it by greping /usr/lib/pyshared | 12:43 |
| jelmer | dcoles: the svn libs call it | 12:43 |
| jelmer | when they need credentials | 12:44 |
| dcoles | Ah, so similar to pysvn's auth callbacks | 12:45 |
| ahorden | hey all, we have been converting over to Bazzar from git, its allot nicer, but we need to move servers can we just do a mv -vf on the root reporatory to the new system over nfs with no issues? the server will have the same host name, but the system path will be diffrent so I am guessing the only diffrence is the sftp path we use will have to reflect the change, but is there anything else I need to look out for? | 12:45 |
| jelmer | ahorden: nothing I can think of | 12:49 |
| dcoles | jelmer: OK. The prompts are coming from AuthenticationConfig.get_user, so I hacked get_svn_lookup so that it sets self.host to "clir.googlecode.com" and then I get no prompts and get_user and get_password return the correct values | 13:01 |
| jelmer | dcoles: could you perhaps file a bug against bzr-svn with this info ? | 13:04 |
| ahorden | thanks jelmer, I will give it a go | 13:05 |
| dcoles | jelmer: Sure thing. I'm about to head off to bed, so I'll make sure I report it in the morning. | 13:06 |
| jelmer | dcoles: thanks! | 13:06 |
| dcoles | Thanks for your help :) | 13:06 |
| rgrig | bzr almost kills my computer when I branch emacs. It uses >500MB of memory (I have 1GB in total) and the computer is almost unusable for >20 minutes. Should I file this as a bug? | 13:12 |
| persia | Good day. I have a branch and a need to have made a stable release branch from it about 10 months ago. I'd rather not record the results of "bzr revert -r327; bzr commit -m "Revert to r327" in the log. Is there an easy way to accomplish my goal? | 13:59 |
| james_w | bzr branch -r 327 stable-release-branch? | 14:00 |
| persia | My other option is reconstructing from a 16 month old branch, replaying each commit, but that's unappealing for other reasons. | 14:00 |
| * persia tries | 14:00 | |
| maxb | bzr branch -r 327 . ../stable-release-branch ? | 14:00 |
| james_w | yeah, that spelling :-) | 14:00 |
| persia | That works wonders. Thanks heaps for having already supported this, probably for ages :) | 14:01 |
| james_w | rather a fundamental operation :-) | 14:01 |
| james_w | available since long before my time :-) | 14:01 |
| * persia actually ran `bzr branch -r327 lucid jaunty` but it's the -r to branch that mattered | 14:01 | |
| rubbs | james_w: but not always obvious in this context | 14:02 |
| james_w | no | 14:02 |
| persia | It's very much not obvious, but incredibly useful and impossible to forget. | 14:02 |
| ramvi | I'm running bzr client on my server to get the newest code. When trying to branch I get Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later), but bzr --version returns Bazaar (bzr) 1.5 | 14:04 |
| ramvi | how do I fix this/ | 14:04 |
| ramvi | ? | 14:04 |
| beuno | ramvi, 1.16 is newer than 1.5 | 14:05 |
| james_w | hey beuno | 14:06 |
| beuno | so, upgrade bzr | 14:06 |
| beuno | hey hey james_w! | 14:06 |
| james_w | how's the new job treating you? | 14:06 |
| ramvi | I have to learn to count. You know if there's debian etch packages available? | 14:06 |
| ramvi | 1.5 seems to be the newest | 14:06 |
| james_w | ramvi: backports.org probably have something | 14:06 |
| ramvi | james_w: that's the one I'm using. 1.5 | 14:07 |
| james_w | ah | 14:07 |
| james_w | then I don't know, sorry | 14:07 |
| ramvi | thanks for point out that 1.16 is newer :) | 14:07 |
| beuno | james_w, I love it. Back to hacking on a daily basis, which I missed a lot. Also, busy busy busy :) how are you? | 14:08 |
| james_w | good thanks, pretty much the same :-) | 14:08 |
| james_w | it's been a while since I ran in to you | 14:08 |
| james_w | I guess you'll be at UDS this time? | 14:08 |
| beuno | james_w, not sure yet. Probably not, I'm trying to cut down on travel for a while, get back to a more normal day to day | 14:10 |
| james_w | yeah, I can imagine :-) | 14:10 |
| beuno | james_w, but I'm sure we'll bump into each other soon :) | 14:11 |
| james_w | yeah | 14:11 |
| james_w | let me know if you are over here | 14:11 |
| jam | morning all | 14:35 |
| james_w | morning jam | 14:35 |
| rubbs | morning | 14:35 |
| fullermd | Morning? Ah, no wonder it's gotten so bright... | 14:36 |
| bialix | anybody knows how missing -r should work? and is it work actually? | 14:59 |
| RobOakes | Is this a good place to ask for help with bzr and launchpad errors? | 15:04 |
| pwolanin | in bzr when I merge and have conflicts | 15:09 |
| pwolanin | is ther a way to specify that I want the version in the branch i'm merging into? | 15:09 |
| pwolanin | in svn I can use 'tf' | 15:09 |
| pwolanin | sorry I want the remote branch's version to replace local in case of conflict | 15:09 |
| rubbs | pwolanin: I don't know of any way with a bzr command, but *.THIS is from the branch being merged into. *.OTHER is from remote branch. *.BASE is what they both came from. Just rename *.OTHER to the file and delete all the others. Then mark the conflict as resolved | 15:11 |
| rubbs | that's how I do it at least | 15:11 |
| pwolanin | rubbs: ya, that's what I did before - but was hopiong bzr coudl do it in one swoop | 15:12 |
| rubbs | pwolanin: It might, but I don't know it. :( sorry | 15:13 |
| pwolanin | rubbs: np, thanks | 15:14 |
| vila | pwolanin: this is currently working on | 15:16 |
| vila | pwolanin: it will be be available as 'bzr resolve --take-this file' or '--take-other' | 15:17 |
| pwolanin | vila: hmm, ok - thanks for the update | 15:17 |
| pwolanin | find . -name "*.OTHER" | sed -E "s/(.+)\.OTHER/\1/" | xargs -n1 -I %j cp %j.OTHER %j | 15:17 |
| vila | pwolanin: you still need to call 'bzr resolve' before committing | 15:18 |
| pwolanin | might do the trick | 15:18 |
| pwolanin | vila: right | 15:18 |
| vila | 'bzr conflicts' may be a better start for scripts | 15:19 |
| vila | pwolanin: how many conflicts are you dealing with on average and of what kind ? | 15:19 |
| pwolanin | vila: these are trivial - I'm merging two builds of Drupal - some meta data files have different build info appended by build scripts | 15:20 |
| vila | pwolanin: so they are 'Text Conflicts', I won't adress them later too but probably with additional options available see http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution | 15:22 |
| pwolanin | vila: yes, text conflicts | 15:23 |
| === salgado is now known as salgado-lunch | ||
| chx | hey. i am getting a bzr: ERROR: [Errno 13] Permission denied and i cant understand why i pastebinned http://privatepaste.com/4dec19bef1 relevant information. | 15:54 |
| chx | i really have no idea what's going on, every file is owned by me :/ | 15:55 |
| vila | chx: check ~/.bzr.log and ~/.bazaar | 15:55 |
| vila | chx: did you run 'sudo bzr' sometimes ? | 15:55 |
| vila | chx: otherwise try running with -Derror and paste the traceback | 15:56 |
| chx | i doubt... | 15:56 |
| chx | vila: http://privatepaste.com/71c8ffd814 | 15:57 |
| chx | vila: find .bzr \! -uid `id -u` also comes back empty. | 15:58 |
| vila | I saw | 15:58 |
| vila | ha no, '.bzr' not '.' | 15:59 |
| chx | both . and .bzr | 15:59 |
| chx | i tried both | 15:59 |
| vila | BZR_PDB=1 bzr -Derror then | 15:59 |
| vila | and 'pp from_, to' when you got the pdb prompt | 16:00 |
| chx | (u'/ebs/home/kbridges/public_html/examiner-d7/.bzr/checkout/limbo/new-83', u'/ebs/home/kbridges/public_html/examiner-d7/sites/parc.dev.examiner.com/modules' | 16:03 |
| chx | oh shit | 16:03 |
| chx | thanks | 16:03 |
| vila | chx: Hey ! Tell me ! :) | 16:03 |
| chx | dr-xr-xr-x 4 kbridges kbridges 51 Feb 25 14:33 /ebs/home/kbridges/public_html/examiner-d7/sites/parc.dev.examiner.com | 16:04 |
| chx | so what would be the find command to find such ? | 16:04 |
| vila | chx: The error message is not nice, it would be good to make it clearer, care to file a bug ? | 16:04 |
| chx | vila: certainly, where? | 16:04 |
| vila | https://bugs.launchpad.net/bzr/+filebug | 16:05 |
| vila | chx: try explaining why you ended up with a read-only dir here, I smell a valid use case... | 16:06 |
| chx | well | 16:06 |
| chx | yeah | 16:06 |
| chx | i think that's a bzr error indeed | 16:06 |
| chx | no | 16:08 |
| chx | that's a pebkac | 16:08 |
| vila | I don't think bzr itself ever create a directory with dr-x but... I can imagine that he accepted to version it but failed to handle changes inside | 16:08 |
| chx | still we need a friendlier error message | 16:08 |
| vila | chx: certainly, mentioning the paths at least will help understand the problem (at least it worked for you :) | 16:09 |
| vila | did I just used at least twice ? Well, I realized it a t le^H^H^H^H^ | 16:10 |
| chx | vila: https://bugs.launchpad.net/bzr/+bug/531989 so far i filed this | 16:11 |
| ubottu | Launchpad bug 531989 in bzr "Permission denied error is not friendly" [Undecided,New] | 16:11 |
| bialix | hi, what is the correct way in bzr tests to say: I know this bug is broken, so just skip it | 16:58 |
| bialix | I have hit /msg NickServ identify | 16:58 |
| bialix | I have hit Bug #526221 | 16:58 |
| ubottu | Launchpad bug 526221 in bzr "tests involving stub_sftp are broken on win32" [Medium,Fix released] https://launchpad.net/bugs/526221 | 16:58 |
| SamB_XP | bialix: hehehe | 16:59 |
| * bialix shys | 16:59 | |
| SamB_XP | pasted the wrong thing or something? | 16:59 |
| bialix | pasted the wrong thing | 16:59 |
| SamB_XP | at least you didn't paste in your password! | 16:59 |
| bialix | yeah | 17:00 |
| bialix | that's chatzilla thing: it don't want to store my password | 17:00 |
| bialix | dumb chatzilla | 17:00 |
| SamB_XP | though usually my client manages to login without help from me ... | 17:00 |
| bialix | what is your client? | 17:01 |
| === salgado-lunch is now known as salgado | ||
| SamB_XP | an XChat that calls itself YChat for some reason ... | 17:01 |
| SamB_XP | (but, strangely, it does not have a Y icon!) | 17:02 |
| === deryck is now known as deryck[lunch] | ||
| === radoe_ is now known as radoe | ||
| === deryck[lunch] is now known as deryck | ||
| mathrick | hiya | 18:46 |
| mathrick | jelmer: what URL should I use to push to a github branch? | 18:46 |
| mathrick | the location git uses is git@github.com:mathrick/unix-options.git | 18:46 |
| mathrick | but bzr dislikes that | 18:47 |
| jelmer | mathrick: in fact, that's not a URL :-) | 18:54 |
| NfNitLoop | Are there any plans to add a 'bzr cp' command? | 18:54 |
| jelmer | mathrick: git+ssh://git@github.com/mathrick/unix-options.git | 18:54 |
| mathrick | ah | 18:54 |
| mathrick | I think I tried that | 18:55 |
| jelmer | NfNitLoop: vague plans, nothing concrete at this point | 18:55 |
| * mathrick checks | 18:55 | |
| jelmer | mathrick: what error did you get? | 18:55 |
| mathrick | nope, didn't try with +ssh | 18:55 |
| mathrick | ooh, but now it got wedged alright | 18:55 |
| NfNitLoop | jelmer: Yeah, I seem to recall that being the state of things a long while ago. I'm using bzr atop SVN so it feels dirty to do a fresh add in BZR when I could've done an svn cp. :p | 18:55 |
| mathrick | bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/mathrick/Dev/Lisp/lib/unix-options/.bzr/branches/.bzr/repository/') has no revision ('git-v1:ed0fdab09830e372d470089d77867a3ce7a79233',) | 18:55 |
| mathrick | jelmer: look like the same error again, did you look into it in any way? | 18:56 |
| jelmer | mathrick: what same error again? | 18:56 |
| mathrick | the one I reported some time ago, a week or so | 18:56 |
| mathrick | which everyone says should've been fixed in core | 18:56 |
| * mathrick checks for 2.2 betas | 18:57 | |
| jelmer | mathrick: sorry, can you refresh my memory | 18:58 |
| jelmer | ? | 18:58 |
| mathrick | NfNitLoop: but that's still how it works. Might be not ideal compared to svn cp, but at least we have sane branching and merges don't render our branches unusable :) | 18:58 |
| mathrick | jelmer: sure, I think I even filed a bug | 18:58 |
| jelmer | mathrick My memory is failing me and a quick check of the bzr-git bugs list also doesn't reveal anything | 18:58 |
| mathrick | jelmer: indeed, lemme check the history of the bugs I filed | 19:00 |
| mathrick | jelmer: https://bugs.launchpad.net/bzr/+bug/526792 | 19:00 |
| ubottu | Launchpad bug 526792 in bzr "Revision not present error in annotate" [Undecided,New] | 19:00 |
| mathrick | it got reassigned | 19:00 |
| mathrick | you did it even :) | 19:01 |
| jelmer | mathrick: that's a completely different bug | 19:01 |
| mathrick | oh | 19:01 |
| mathrick | jelmer: okay then, the above is what I got when trying git+ssh | 19:01 |
| jelmer | mathrick: what does bzr check output? | 19:03 |
| mathrick | jelmer: I might've messed something up, I've been cloning and rebasing things to work around git failing to fetch revisions in a way I seriously didn't feel like resolving | 19:03 |
| jelmer | what versions of bzr/bzr-git ? | 19:03 |
| mathrick | hang on | 19:03 |
| mathrick | 47 revisions | 19:03 |
| mathrick | 5 file-ids | 19:03 |
| mathrick | 8 inconsistent parents | 19:03 |
| mathrick | so again, like with that other repo cloned from git | 19:03 |
| jelmer | mathrick: what version of bzr-git are you running? | 19:04 |
| jelmer | cloning that repo I don't get any inconsistent parents | 19:04 |
| mathrick | I think it might be my shared repo | 19:05 |
| mathrick | jelmer: r721 | 19:05 |
| mathrick | jelmer: I just checked, cloning and reconciling a branch outside my shared repo works just fine | 19:05 |
| mathrick | but inside it, no cigar | 19:06 |
| mathrick | it was the same last time | 19:06 |
| jelmer | mathrick: but this repo was probably created with a much older version of bzr-git ? | 19:06 |
| mathrick | no, it's a shared bzr repo I've been using for two years or so | 19:06 |
| jelmer | mathrick: so some of the revisions in it were created with older versions of bzr-git at least? | 19:07 |
| mathrick | yes | 19:07 |
| jelmer | mathrick: Can you do a fresh clone of that git branch outside of the shared repo, then "bzr pull" in the other revisions from the shared repo branch and then dpush ? | 19:08 |
| mathrick | but none in this particular branch, I've created it 1h ago | 19:08 |
| mathrick | jelmer: I managed to dpush after just reconciling the branch cloned outside the shared repo | 19:08 |
| mathrick | I'm not quite sure what the best course of action is, this repo seems completely resistant to my attempts at reconciling it | 19:09 |
| jelmer | mathrick: I would create a new shared repo, clone all foreign branches into that and then pull whatever revisions you created yourself into that from the original shared repo | 19:10 |
| mathrick | urgh, that'd take forever, I keep all my branches in it | 19:11 |
| mathrick | jelmer: what if I just cloned that repo and attempted to reconcile the clone? | 19:11 |
| mathrick | would that change anything? | 19:11 |
| mathrick | I'm not sure it'd be safe to switch that out from under my branches | 19:12 |
| jelmer | mathrick: no, I doubt that would make a difference | 19:12 |
| mathrick | bummer | 19:13 |
| mwhudson | will i learn anything from reading the "Re: Fixing rebase rather than avoiding it" thread? | 19:49 |
| mwhudson | it's got a bit large... | 19:49 |
| james_w | mwhudson: not if you've read the other 5 threads on the subject | 20:01 |
| mwhudson | good | 20:01 |
| * mwhudson dumps it | 20:01 | |
| mathrick | humm | 20:14 |
| mathrick | mathrick@hatsumi:~/Dev/pettanko$ bzr info | 20:14 |
| mathrick | bzr: ERROR: Unknown repository format: 'Bazaar development format 0 with subtree support (needs bzr.dev from before 1.3)\n' | 20:14 |
| mathrick | what's the easiest way to fix that? | 20:15 |
| luks | you probably need an old bzr | 20:15 |
| luks | then upgrade to some non-developmenr format | 20:15 |
| mathrick | yeah, but what'd be the easiest way to do that in ubuntu? | 20:16 |
| luks | download the tarball | 20:16 |
| luks | you can run bzr directly from the unpacked directory | 20:16 |
| mathrick | aha, lemme try that | 20:18 |
| mathrick | is there a commandline option to disable plugins temporarily? | 20:19 |
| bialix | --no-plugins | 20:20 |
| mathrick | from gzip import U32, LOWU32, FEXTRA, FCOMMENT, FNAME, FHCRC | 20:20 |
| mathrick | ImportError: cannot import name U32 | 20:20 |
| mathrick | *grumble* | 20:20 |
| luks | hm, I think I've seen an error like this before | 20:21 |
| luks | python2.6? | 20:21 |
| mathrick | yes | 20:21 |
| luks | not as easy as I expected then :) | 20:21 |
| mathrick | will 2.5 help? | 20:21 |
| luks | yes | 20:22 |
| luks | otherwise you would have to patch bzr | 20:22 |
| mathrick | oh damn it | 20:26 |
| mathrick | now it won't upgrade because the old version doesn't understand 2a | 20:26 |
| mathrick | which is the format of the containing repo | 20:27 |
| luks | you can probably upgrade to some immediate format | 20:27 |
| luks | not sure which one | 20:27 |
| mathrick | yes, but it errors out when I try to do that | 20:27 |
| luks | oh | 20:27 |
| mathrick | I tried rich-root-pack, and it makes a backup, then goes "Dunno how to handle 2a" | 20:27 |
| luks | I don't understand the situatoin there | 20:27 |
| mathrick | I don't either | 20:27 |
| mathrick | somehow it managed to upgrade the repo without upgrading the branch | 20:27 |
| luks | ~/Dev/pettanko is in the old format, right? | 20:28 |
| mathrick | yes | 20:28 |
| mathrick | but it's under ~/Dev/, which is a shared repo | 20:28 |
| luks | hmm | 20:28 |
| luks | and ~/Dev/pettanko is using the repo? | 20:28 |
| * mathrick checks | 20:29 | |
| luks | it wouldn't complain about the old repo format if ~/Dev is 2a | 20:29 |
| mathrick | Standalone tree (format: development0-subtree) | 20:29 |
| mathrick | I guess not | 20:29 |
| mathrick | so I probably need to move it outside ~/Dev/ to upgrade | 20:29 |
| luks | yeah | 20:29 |
| luks | (just guessing) | 20:29 |
| mathrick | argh, it seems impossible to do | 20:44 |
| luks | not that I've ever done it, but I'd probably try to use bzr-fastexport/fastimport if everything failed | 20:45 |
| mathrick | yeah, if I can find them in versions compatible with 1.3 | 20:45 |
| luks | hm | 20:45 |
| bialix | mathrick: use pull or push | 20:46 |
| luks | oh right | 20:46 |
| luks | there is a bug in old bzr which allows that | 20:46 |
| mathrick | bialix: no can do, it errors out with bzr: ERROR: Repository KnitPackRepository('file:///tmp/clean-pettanko/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///tmp/pettanko/.bzr/repository/') | 20:46 |
| bialix | start bzr 1.3 as server | 20:46 |
| mathrick | hmm | 20:47 |
| lifeless | jam: 'sack' ? ! | 20:47 |
| lifeless | jam: btw did you read the bzr-search code for same? | 20:47 |
| jam | Self-contained Pack | 20:47 |
| bialix | and point it to your old branch | 20:47 |
| jam | You call it "Index" as near as I can tel | 20:47 |
| bialix | then try to branch from it | 20:47 |
| jam | but it has a lot of extra 'stuff' | 20:47 |
| bialix | heya jam | 20:47 |
| jam | hi bialix | 20:47 |
| jam | lifeless: I don't have a better name, but I'm certainly willing to change it | 20:48 |
| jam | I needed something to get started | 20:48 |
| lifeless | jam: its not perfectly isolated no; I was just meaning to make sure you had studied theprior art | 20:48 |
| jam | yeah | 20:48 |
| mathrick | bialix: interesting, it seems to hang when I try to connect | 20:49 |
| jam | also, I find your code a bit confusing to read, since you have "Index" meaning several things | 20:49 |
| jam | well, at least several different levels of meaning | 20:49 |
| lifeless | jam: ah | 20:49 |
| lifeless | jam: so "Index" == "Repository" | 20:49 |
| jam | storing indexes in a pack doesn't help | 20:49 |
| lifeless | ComponentIndex == Pack | 20:50 |
| lifeless | ComponentIndexBuilder == NewPack | 20:50 |
| lifeless | jam: what do you mean | 20:51 |
| jam | pack files have indexes to find the content in the pack file, which in your case the content is a btree index | 20:51 |
| jam | so you have the top-level 'collection of files' index, pointing to indexes which point to indexes | 20:51 |
| lifeless | tis a file system basically | 20:52 |
| jam | so 'doesn't help' *understanding* what level I'm looking at | 20:52 |
| lifeless | oh right, I see | 20:52 |
| lifeless | jam: well, it looks ok to me, though I'm not sure why you need a custom index for the directory | 20:53 |
| lifeless | I find Sack and Tie confusing | 20:54 |
| lifeless | it leaves me thinking of male strippers for some reason! | 20:54 |
| jam | lifeless: I'm a bit concerned about your associations :) | 20:54 |
| lifeless | so am I, so am I | 20:54 |
| jam | so the 'tie' is meant to make the file completely self-contained, at minimal expense | 20:55 |
| jam | you do it with just the meta-index, AFAICT | 20:55 |
| jam | 'index_value = '%d...' | 20:55 |
| jam | tells you how to find the various intermediate indexes | 20:55 |
| lifeless | right, I just put the directory listing for the indices as a directory listing | 20:56 |
| lifeless | 'these are the files in the pack' | 20:56 |
| lifeless | with their name | 20:57 |
| lifeless | it has the nice effect that I can add other things and not confuse older versions of bzr-search | 20:57 |
| lifeless | a new index added is just ignored | 20:57 |
| jam | so I plan on having a directory listing at the 'pack collection' level, but making it redundant with the tail of the actual '.pack' file | 20:57 |
| lifeless | jam: sure, I see that. I'm mainly asking 'why is the in-pack directory listing a special class' | 20:58 |
| lifeless | jam: rather than a regular btree index. | 20:58 |
| jam | readability | 20:58 |
| jam | atm | 20:58 |
| jam | I certainly could do just another btree | 20:58 |
| mathrick | man, finally | 20:58 |
| mathrick | the trick was to specify --pack-0.92-subtree, which wasn't listed in --help | 20:59 |
| jam | mathrick: well, it is generally considered a dev/experimental format, hence why it wasn't listed | 20:59 |
| mathrick | yeah, but --pack-0.92 was | 20:59 |
| jam | mathrick: sure, the '-subtree' is quite special | 21:00 |
| mathrick | and --development-subtree said "can convert to pack-0.92" | 21:00 |
| mathrick | which confused me | 21:00 |
| jam | I would assume just a bad doc for --development-subtree | 21:00 |
| lifeless | jam: so in terms of names; rather than tie, it looks like a Trailer to me, or a RootIndex | 21:00 |
| jam | reasonable | 21:01 |
| jam | oh, I also wanted to expose some of the values in the index to be combined into the overall directory listing | 21:01 |
| lifeless | or even, if we want to let our inner java dev out to plain, a TrailingRootIndex | 21:01 |
| jam | I'm not sure how you handle that | 21:01 |
| lifeless | jam: thats orthogonal | 21:01 |
| lifeless | by overall directory listing, you mean pack-names ? | 21:02 |
| jam | lifeless: somewhat, except it is easier to grab a named attribute than to parse a 'value' string back into its contents | 21:02 |
| jam | lifeless: right pack-names | 21:02 |
| lifeless | jam: mmm, mumble. Could easily subclass BTreeIndex to parse the values for you | 21:02 |
| * mathrick gets a lesson not to touch development formats without very good reasons | 21:03 | |
| lifeless | jam: bzr-search isn't wholly self contained; it's upload process returns the specific entry points. | 21:05 |
| lifeless | jam: I think its good to do what you're doing. | 21:05 |
| jam | I think you have a point to re-using the key-value of BTree versus Stanza | 21:05 |
| jam | so I'll poke at that a bit | 21:05 |
| jam | it does make testing a bit harder | 21:05 |
| en1gm4 | hi all | 21:05 |
| jam | since you can't just test the bytes on disk | 21:06 |
| jam | since they are compressed, etc | 21:06 |
| lifeless | jam: you might find you can offset that with a good Matcher | 21:06 |
| jam | en1gm4: hi | 21:06 |
| jam | lifeless: that decodes the Btree ? | 21:06 |
| lifeless | right; pass it a dict that you want the BTree to match | 21:06 |
| lifeless | it can unzip parse, check all the elements. | 21:06 |
| en1gm4 | simple question: bzr revert <file> restore <file> to the last commit, how can I restore a file from a particular revno? | 21:07 |
| jam | although BTreeIndex also assumes it has a Transport. Which we will ultimately do, but is a bit extra complex for this specific stuff | 21:07 |
| lifeless | BTreeMatches({}). .. | 21:07 |
| jam | en1gm4: bzr revert -r <revno> <file> | 21:07 |
| lifeless | jam: there is a transport adapter in bzr-search for this, rip it out wholesale | 21:07 |
| en1gm4 | thanks jam | 21:07 |
| lifeless | search.transport.FileView | 21:07 |
| lifeless | it even has tests | 21:09 |
| jam | lifeless: thx for the heads up | 21:11 |
| lifeless | it just maps a region of a file to be a transport | 21:11 |
| lifeless | actually its more general - you give it a dict of name:(start,length) | 21:11 |
| lifeless | and it acts a transport containing those names | 21:12 |
| lifeless | each of which can be readv'd. | 21:12 |
| lifeless | gotten | 21:12 |
| lifeless | and recommended_page_size queried. | 21:12 |
| lifeless | jam: I'd seriously consider calling this thing a pack still :- none of the higher level code needs to change at this point, except for index writing & setup-for-reading | 21:15 |
| jam | lifeless: well "SelfContainedPack" would be possible... | 21:19 |
| jam | ultimately I plan on bringing in the PackCollection code, etc. so that you have a self-managed thing you can just use | 21:19 |
| jam | or at least I'd like to | 21:19 |
| lifeless | jam: yay; I've wanted to do that for ages | 21:19 |
| jam | I didn't want to put it in 'pack_repo' though | 21:19 |
| lifeless | jam: indeed, at that point it should be pulled sideways | 21:20 |
| jam | so I needed somewhere to put it and 'pack.py' is really more about the Container streaming format | 21:20 |
| lifeless | pack_collection.py | 21:20 |
| lifeless | anyhow, I'm really glad you're doing this; I'm really just talking about the icing :) | 21:21 |
| jono_ | hey all | 21:27 |
| jono_ | getting a weird error | 21:27 |
| jono_ | bzr: ERROR: Could not acquire lock "/home/jono/source/bzr/python-snippets/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable | 21:28 |
| jono_ | what does that mean? | 21:28 |
| lifeless | you have it mounted on fuse | 21:28 |
| jono_ | lifeless, eh? | 21:29 |
| lifeless | or nfs/smb with file locks disabled | 21:29 |
| lifeless | thats generally the cause | 21:29 |
| jono_ | it is on my local disk | 21:29 |
| lifeless | we're trying to take an OS lock | 21:29 |
| jono_ | I don't understand what you mean lifeless | 21:29 |
| lifeless | we lock that file | 21:30 |
| lifeless | using OS locks | 21:30 |
| lifeless | (flock on unix I think) | 21:30 |
| jono_ | lifeless, what can I do to resolve this? | 21:31 |
| lifeless | the most common cause for the locking to fail is when its not on a local file system (which may not be obvious: early U1 stuff would fail, for instance) | 21:32 |
| lifeless | do you have a stale python/bzr process that might be messing with it ? | 21:32 |
| jono_ | hmm works now | 21:32 |
| jono_ | just pushed | 21:32 |
| lifeless | you can use fuser /home/jono/source/bzr/python-snippets/.bzr/checkout/dirstate | 21:35 |
| lifeless | to see if its inuse, in future | 21:35 |
| jono_ | cheers | 21:36 |
| jono_ | :) | 21:36 |
| === salgado is now known as salgado-afk | ||
| servilio | jelmer! | 22:13 |
| servilio | hi all! I am on my way to import a subversion repository with bzr-svn, any advise for things to watch-out? | 22:14 |
| jelmer | servilio: hi! | 22:19 |
| NfNitLoop | servilio: It's pretty simple these days. Just bzr branch <URL to your SVN branch> | 22:20 |
| NfNitLoop | if you have multiple related branches, I'd recommend branching into a shared repo. | 22:20 |
| jelmer | servilio: not really, it should "just work" :-) | 22:20 |
| NfNitLoop | jelmer: famous last words! | 22:20 |
| NfNitLoop | ;) | 22:20 |
| jelmer | :-) | 22:20 |
| jelmer | servilio: if you are going to import a set of branches in a svn repository, you might want to use the "bzr svn-import" command rather than "bzr branch" | 22:20 |
| NfNitLoop | eh. I just branch the branches I care about. No need to download and cache data from dead branches. | 22:21 |
| jelmer | NfNitLoop: it won't import any branches that have already been removed from svn unless you specify --all | 22:24 |
| servilio | jelmer: forgot that was the command I was looking at, from the homepage recommendation | 22:26 |
| servilio | jelmer: thanks! | 22:26 |
| servilio | NfNitLoop: thanks! | 22:27 |
| servilio | NfNitLoop, jelmer: I am migrating a subversion repository to bzr in this case, so I am using --all so far | 22:28 |
| servilio | already created a shared repo for them | 22:28 |
| servilio | jelmer: if my svn repo consists of different projects with independent {tags,branches,trunk} directories in each of them, should I import them separately into the bzr repo? or is there a way to import them all at once while keeping the branches, etc.? | 22:33 |
| mathrick | jelmer: btw, I managed to fix these repositories, more or less, by cloning again from the reconciled branches back into the repository | 22:48 |
| jelmer | re | 22:55 |
| jelmer | mathrick: More or less in what regard? | 22:55 |
| jelmer | re | 22:55 |
| jelmer | servilio: svn-import should be able to import them all at once | 22:56 |
| mathrick | more or less in the sense I can dpush from them, and they themselves don't have any inconsistent parents. I don't expect it has fixed the repo itself though | 22:56 |
| jelmer | mathrick: ah, right | 23:09 |
| igc | morning | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!