[00:06] moin [00:38] morning [01:17] Peng_, jusy sasw your reviews [01:17] thanks [01:18] Oh, you're welcome. [01:21] I wonder what that TooManyConcurrentRequests thing is about [01:28] Soo. Anyone got IPv6 access? Run an IPv6 bzr server? [01:30] too crazy for me :) [01:30] I missed my medication and wound up setting up an IPv6 tunnel on my server. :D === arjenAU2 is now known as arjenAU [01:33] beuno: TMC is a masking error [01:34] beuno: it means that some code is trying to make smart RPC calls a after an error left the smart connection in a bad state [01:34] beuno: e.g. attempting to unlock a lock after the server bailed [01:34] beuno: -Dhpss can be a useful way to get some info on it [01:34] lifeless, ah [01:34] hrm [01:35] lifeless: Oh, thanks. [01:35] fixing it requires finding the fault,and correcting it so that when this failure occurs it leaves the connection in a good state [01:36] bb is down :( [01:37] I wonder how to get loggerhead to do that for me [01:37] beuno: try:except; :P [01:37] beuno: there is another possible cause [01:37] beuno: which is using a single connection from threads [01:38] beuno: smart connections do not overlap requests, you need separate connections if you want to make a second request before the first is finished [01:38] or finally, if you have a generator response, you need to exhaust the generator before making new requests [01:41] lifeless: You mean a multithreaded server or a multithreaded client? [01:42] Peng_: user of a connection [01:42] Wait, where does TMCR happen? Client or server? [01:42] * Peng_ 's brain isn't fully engaged today. [01:42] Peng_: could happen on either, but in practice clients have a much larger surface area to get wrong [01:47] FWIW, the subject of this is https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821#comment17559 [01:47] I just realized that there might be two smart servers in play which...is totally confusing. [01:50] there are two in play [01:50] where is the exception coming from [01:50] the bzr client, or loggerheads client ? [01:51] lifeless: bzr client. [01:52] I think. [01:52] do this [01:52] start loggerhead in one terminal [01:52] run bzr log in another [01:55] Yeah, that's what I did. The bzr client is the one that displayed the traceback, but it's possible it got it somewhere else. Or something. [01:56] so that means that the client is leaving a hpss connection in a bad state [01:56] run with -Dhpss [01:56] its likely getting an error from loggerhead [01:56] though I didn't know that loggerhead provided hpss calls over its http connection [01:57] lifeless: It doesn't, yet. Though there's a branch up about it. [01:57] Like I said, my brain is pretty fried right now. [01:58] Peng_: does this branch do that? [02:00] soliciting for reviews of [02:00] https://code.launchpad.net/~lifeless/bzr/Commands.hooks/+merge/6936 [02:00] lifeless: No. [02:01] Peng_: in any event, if the exception is in the client, debug the client [02:02] you'll find a bug there for sure; once fixed we can see whats wrong with loggerhead [02:02] and as I said before -Dhpss is a good starting point [02:02] that said, if you're fried. Go sleep. [02:04] igc: ^ if you have a few that branch would love a review [02:05] shall do lifeless - consider it done [02:05] igc: thanks [02:05] i.e. I'm about to spent today reviewing all I can [03:17] bbiab [04:24] * igc lunch === timchen1` is now known as nasloc__ [05:30] I have a little question that I should know, but since I've heard bzr now uses git's packs.... bzr tracks files? or content? I mean if it tracks content with solid renaming [05:31] tc-rucho: bzr does not use git's packs. [05:31] tc-rucho: bzr tracks file names and content separately; it has excellent renaming support. [05:34] lifeless: http://bazaar-vcs.org/BzrVsHg#Mercurial%27s%20Earlier%20Advantages then what's that? [05:34] a wiki page? [05:34] .... [05:34] :) seriouslly, give me a sec to refresh my memory [05:34] I mean that about "Git's format - packs" [05:34] the page is accurate, as it says 'similar to' [05:35] git's packs are a different format to bzr's packs [05:35] they are conceptually similar [05:36] ok, the question of the million. If I take a file with history, split it in two, then save in 2 different files; will bzr track that it's just a reallocated content or treat this as new coded being entered into the repository? [05:36] (git would track the content and this would keep history of every single line in the two resulting files) [05:39] currently bzr considers it new content [05:39] we have a plan to address this [06:12] igc: thanks; I hadn't seen your reply [06:13] lifeless: np [06:13] I think of New Features as things for developers-using-bzr, not plugin authors so much [06:14] and that plugin authors should be reading 'Internals' [06:40] igc: replied - thanks for catching all the little noise in that patch [06:41] lifeless: cool. I'll take a look. As I said, it looked pretty promising so I'm keen to get it through review [06:42] I'm fading right now [06:42] but if you have any questions feel free to chat here for faster turnaround === abentley1 is now known as abentley [08:50] does it only for me http://doc.bazaar-vcs.org is not available? [08:50] main site works ok [08:51] wfm [08:51] me too [08:53] Question : (sorry, I know I could read the source), are all commit times stored UTC and presented local-time? [08:55] Hm. [08:55] awilkins: Well, by default they're presented in their original time zone [08:56] So, if I commit at 0800 on a server in PDT, when I pull that revision to UTC the time will still say 0800 and not 0000 ? [08:56] Oops, 1600 (confusing!) [08:56] ISTM that on disk, a UTC timestamp and the offset from UTC are stored. [08:56] * awilkins has the opportunity to test this [08:56] awilkins: Look at $ bzr cat-revision -r 123 [08:57] awilkins: What do you mean, "pull that revision to UTC"? [08:57] Peng_: Pull the revision into a branch hosted on a box running in the UTC timezone (or rather, GMT. Which is BST at present anyway) [08:57] Although I think UTC should be a valid locale..... [08:58] awilkins: The local time zone won't change the revision's data. [08:59] awilkins: Like I said, ISTM that the UTC timestamp + time zone offset are stored on disk. With that information, bzr can display it using the orignal time zone, local time, or (theoretically) anything else; it's all the same time, so it doesn't matter. [08:59] Peng_: No, but does it change the presentation of the commit time ; - will 0800 PDT display as 1600 in the BST zone (because that's when it happened) [08:59] I'm checking this now [08:59] Ok, the logs have zone into [08:59] info [09:00] Yeah. [09:01] Right, so logs jsut display the time + zoneinfo [09:01] awilkins: From "bzr help log": " --timezone=ARG Display timezone as local, original, or utc." [09:01] I think my questions are probably more about qlog now then [09:01] I definitely don't know anything about that. [09:01] And qlog seems to do it right by me - it uses local [09:01] You could compare with "bzr log" to see what qlog doe -- yeah. [09:02] Ok, I'm glad that's all in order :-) [09:06] lifeless: ? [09:06] Who else is a loom-person? [10:48] Does anyone know off-hand if there is a newer version of push_and_update than 0.2dev around? [11:58] lifeless: ? === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === gdmfsob is now known as mishok13 [14:06] hi, a friend and I are working on a project together and we decided to go with a decentralized with a shared mainline workflow, however, I want to work on more than one machine, I can do that right? I'm coming from svn and the only way to do that there is to make a lot of commits, but with bzr I can just treat my working copy both ways, peer-to-peer for me and team colaboration for us, right? [14:14] cdecarlo, yeap [14:16] beuno: thanks [14:17] beuno: and that's b/c bzr isn't tied to a repos in the way svn is right? each working copy I have is a repos in itself? [14:17] cdecarlo, exactly [14:18] as long as you use "bzr branch" and not "bzr checkout" to get the branches [14:18] beuno: sweet === fta_ is now known as fta [15:10] hey, can anyone recommend a bzr hosting service that isn't launchpad or savannah? :) [15:10] What's a "hosting service"..? [15:10] bzr doesn't need anything special on a server.. Anything you can HTTP from, or FTP/SFTP to will suffice.. [15:11] right, but i'm thinking of something which also provides trac and backs things up, etc. [15:12] hmm.. personalyl I've never had much luck with trac against bzr.. It doesn't quite understand it [15:12] And for backup I just use rsync. Though probably I should use bzr push [15:20] Wait for July and Launchpad goes OSS.... [15:21] (apart from the bestest bits, alas) [15:21] what will that solve? [15:21] Not much [15:21] Well, it might give me some more options [15:21] twas directed at mattl [15:22] awilkins: code hosting part won't be free software. [15:22] which is why i'm looking at non-launchpad options. [15:22] I know, but "wait for LP to go OSS" doesn't seem as a very useful answer to "recommend a hosting service" [15:23] heh [15:23] i might be waiting a while [15:24] what's wrong with a regular web hosting, though? [15:24] i want a bug tracker too. ideally one that can actually work with bzr. [15:25] sourceforge? if you don't mind a crappy bug tracker :) [15:25] heh. [15:25] BugsEverywhere, but I have my reservations about how useful the in-tree-tracker model is [15:25] same problem as launchpad. [15:26] I'd still just setup my own trac [15:26] Sourceforge has an OSS version [15:26] doesn't need to be bugs in bzr... just something that can see that, for example, a commit message that closes a bug. [15:27] You could write a hook that pokes at Trac's XMLRPC [15:27] Last time I tried something with that I was pleased at how easy it was [15:28] you could also just add a link to the trac comment when you close a bug [15:28] well, i am wondering what tracbzr does... [15:28] and from the other side you have many local bzr tools [15:28] qbzr has a "fixes" entry in it's commit dialog - which trackers does that work with? [15:29] awilkins: bzr commit --fixes just stores metadata about the bug urls, nothing else [15:29] Aha, it goes with te fixes arg for commit [15:29] luks: Is there a hook that has access to that data? [15:29] it's in the revision object [15:29] so any hook can access that [15:30] hey, I wanted to try bzr-svn, but I got an error about the module 'tdb' not supporting the attribute 'open'. I couldn't find anything on the gmane mailinglist search. Anyone got an idea? [15:30] Needs a newer tdb version? What OS are you on? [15:31] And how did you install bzr-svn? [15:31] dvheumen, you need a new version of tdb or to deinstall tdb? [15:31] jelmer: hey, I think it was your package I used, from the archlinux AUR repository [15:32] dvheumen, I don't do archlinux packaging, I'm upstream [15:32] jelmer: ow okay, than I'm confusing you with someone else ... no matter :P [15:32] jelmer: I'll try finding a new tdb package, tnx for the info [15:33] luks, awilkins... thanks for your help :) [15:34] jelmer: what version should I minimally have? [15:34] dvheumen, Git snapshot from after december I think [15:35] okay [15:59] Can someone tell me if there's a way to have a file in VCS, but I ignore updates unless explicitly asked to update it? [16:00] I know it's a weird request, but there's files generated by the IDE that really should never need to update. They also contain window positions and recently used lists. Obviously, we don't care about those. [16:05] rotund, I don't think there's anything like that at the moment [16:06] can't the new wt views do something like that? [16:06] e.g. svn (or at least tortoisesvn) has a ignore-on-commit changelist [16:07] which is not processed by status/diff/commit unless you explicitly ask it to [16:07] jelmer: Thanks. That's what I thought. [16:07] what's a wt views? [16:11] morning [16:11] i'm trying to reacquaint myself with the use of loom [16:12] i've got a codebase in an svn repo that's been copied from the original project's repo [16:12] i.e., one revision was copied, no history is shared between them [16:14] i'm using bzr-svn and I want to develop a set of patches that can be applied to my current branch, and then adapted for application 'upstream' [16:15] do I understand correctly that to produce a series of patches like that, i'd do 'up-thread' for each, commit my changes, then do 'down-thread' and use the diff result as the patch? [16:30] does anyone here use bzr on windows? i'd like to know how ssh works with (using the windows installer package) [16:32] adaran: you'd use putty, much the same way it's setup for subversion [16:32] sidnei, i don't have putty installed - and yet it seems to work "out of the box" [16:32] adaran: oh, it might be using paramiko then [16:32] which is a python library for ssh [16:32] sidnei, i simply installed it and i can do bzr ls bzr+ssh://foo.bar just fine - which, of course, bothers me =) [16:33] adaran: bzr has support for multiple ssh providers [16:33] does the windows install use paramiko? [16:33] LarstiQ, that's fine. i just need to find out which one it uses at the moment and see if it's secure enough [16:33] adaran: openssh and putty at least, but what might be going on is the bundled pycrypto+paramiko in this case [16:34] adaran: try to supply -Dtransport and look at .bzr.log? [16:34] dash: the all in one installer? I'd certainly think so [16:34] im pretty sure the installer bundles paramiko (im working on setting up a nightly build for the installer and it's a requirement) [16:34] sidnei: cool [16:36] LarstiQ, where'd that .bzr.log end up? [16:36] bzr version should tell you [16:37] in "My Documents" [16:37] oh boy.. [16:37] is --no-trees implied when running bzr init-repo? I haven't used it on an old repo but I don't see the files in its directory [16:38] adaran: bzr --version will say, it differs over windows versions afaik [16:38] LarstiQ, it's using paramiko, it seems [16:38] vxnick: it does. Long time ago it didn't. [16:39] LarstiQ: thanks [16:39] vxnick: see `bzr reconfigure` if you want to change that. [16:39] don't want to change it, just wanted some clarification :) [16:39] ok :) === herb__ is now known as herb === beuno_ is now known as beuno [16:44] hmm, where am i supposed to put my keys btw? [16:44] on windows, that is [16:44] I don't know with bare paramiko [16:45] paramiko uses the putty key agent [16:45] adaran: it's not mentioned in the userguide? [16:45] LarstiQ, i'll go have a look [16:45] Pageant [16:45] luks: pageant, or is that something else? [16:45] ah [17:03] anyone know if there is a new qbzr version? [17:03] I thought that 0.10 or 0.9.10 was due "real soon now" [17:03] but I don't think it has been released yet [17:04] btw, jelmer didn't mark subvertpy 0.6.6 as a release on https://edge.launchpad.net/subvertpy, but I see it as a tarball in http://samba.org/~jelmer/subvertpy/ [17:04] Anyone know why? [17:04] I suppose he didn't put 0.5.4 in https://edge.launchpad.net/bzr-svn [17:05] And I *know* that exists... [17:16] Crud [17:17] is there no way to rename threads in a loom? [17:21] jam: 0.6.1 is the last bzr-svn release I'm aware of [17:21] LarstiQ: which brings up a good point, are we supposed to be switching from the 0.5.x series to 0.6.x? [17:21] I'm pretty sure I packaged 0.5.4 for bzr-1.14 [17:21] (since that was the state of the release script.) [17:23] jam: I've uploaded 0.6.1 [17:23] jam: johnf has been doing the ppa for bzr and bzrtools, I've been doing bzr-svn [17:24] jam: I have no clue about windows installers [17:24] jam: but yeah, I'd go with 0.6.x [17:24] hmm... it seems we still only have qbzr-0.9.8 in the ppa [17:24] bzr-gtk is also old [17:24] LarstiQ: what about subvertpy 0.6.6 ? [17:25] I saw a release on jelmer's web page [17:25] but it doesn't seem to be tagged in whatever trunk I have [17:25] hmm.. and we only have 0.6.1 in the ppa [17:25] jam: I'm not taking care of that (yet) [17:25] jelmer might be at pinkpop right now [17:27] * LarstiQ looks at the subvertpy changelog [17:27] jam: there was no bzr-svn 0.6.1 release either I could find btw [17:28] jam: I'm willing to take responsibility for subvertpy too. I'll ask jelmer about 0.6.6, and clearer announcing in general [17:29] sure [17:29] As for 'clearer announcing' I don't often remember from email [17:29] so just having things tagged in the appropriate overview page works best for me [17:30] jelmer pinging me on irc works best for me :) [17:30] well, I have to package about 4 different ones for the bzr release... [17:30] * LarstiQ nods [17:30] jam: I notice https://edge.launchpad.net/~subvertpy/+archive/ppa has 0.6.1 only too [17:31] oh, and do you know if he has a "0.6-mirrored" like 0.5? [17:31] The windows build host has messed up dns [17:31] so I have to manually register every domain name I want to access [17:31] subvertpy or bzr-svn? [17:31] so having everything on LP helps me a lot [17:31] bzr-svn [17:31] trunk is atm, but that's not stable [17:32] (stable, as in pointing to 0.6 always) [17:32] right, I just saw that [17:32] I don't care specifically about 0.6 [17:32] just 'trunk' [17:32] in the past he had switched to having everything hosted at people.samba.org rather than lp [17:32] he seems to have switched back [17:33] jam: no, hosting is at samba, lp mirrors [17:33] LarstiQ: at one point, jelmer had it to [17:33] * LarstiQ nods [17:33] "bzr branch lp:bzr-svn" would actually download from samba [17:34] I don't know *how* he made that work, but it did [17:34] jam: remote branches [17:34] jam: oh, https://code.edge.launchpad.net/~jelmer/bzr-svn/0.6 does exist [17:34] jam, which is different from mirrorred branches [17:34] sure [17:34] anyway, /me => lunch for now [17:35] jelmer: we just discussed subvertpy 0.6.6 not being clearly tagged/if it should be packaged (windows installer/ppa) [17:35] jelmer: do you want me to take care of subvertpy for the bzr ppa too? [17:37] LarstiQ: I've fixed the tag for 0.6.6 [17:37] LarstiQ: If you can, that would be awesome [17:37] jelmer: sure. [17:38] jelmer: should I start on 0.6.6 now, or are there reasons to stay away from it? [17:39] LarstiQ, no, 0.6.6 should be fine [17:39] k [17:39] LarstiQ, actually, it seems there's enough changes to do a 0.6.7 [17:40] ok :) [17:40] jelmer: should I also care about https://edge.launchpad.net/~subvertpy/+archive/ppa ? [17:43] jelmer: so I should use 0.6.6 for bzr-1.15? [17:44] jam: Ideally 0.6.7, which I've just pushed [17:44] and tagged [17:45] seems to be going === brainsik_ is now known as brainsik [18:23] jelmer: do you use something for release automation? [18:25] you can't ignore changes on a tracked file, right? eg, never commit that file anyway (so you don't have to deselect it each time) [18:26] Kissaki: correct. You could unversion it. [18:27] I've often wanted a "bzr freeze PATH" command [18:27] Kissaki: or perhaps an appropriate idiom is to version a template, copy, edit and ignore for local use. [18:27] LeoNerd: what would that do? [18:27] Yup. exactly for that use case... that a repo contains a template config file for general use. Each checkout on a machine edits it for local use [18:27] A "bzr freeze"ed file is never looked at, presumed to always be pristine [18:27] ah [18:27] k, thx [18:27] "bzr stat" will not show changes, "bzr commit" will not submit it [18:28] you might be able to pull that off with a plugin [18:28] Offhand I can't quite think on the behaviour what might happen if upstream has a patch for it.. Do we attempt to merge locally anyway, or just ignore it? [18:28] It suggests the commands 'freeze PATH', 'unfreeze PATH' and 'frozen' (to list them) [18:28] the file not being selected for commit would be enough really... [18:28] Kissaki: -x [18:29] hm? [18:29] Kissaki: bzr commit -x filetoexclude [18:29] ah, hmm [18:29] Kissaki: if aliases work per branch, you could alias commit to that [18:29] not sure, and seems a bit risky to me [18:30] well, -x doesn't even work for qci [18:30] the requirements keep mounting! :) [18:31] Kissaki: file a bug on qbzr [18:31] personally, as I said, I'd reevaluate wether the file needs to be versioned in the first place [18:32] yes, it has to... But I think that setting I changed doesn't even change the proj file itself... :P [18:33] -h doesn't list -x for qci, so it's probably supposed to be that way [18:34] Kissaki: hmm, I'd think it's an oversight for qci [18:34] yes, it's just a missing feature [18:34] Kissaki: oh boy, a (VS) project file? [18:34] yeah, those things are irritating [18:34] yep [19:05] LarstiQ, I hope to use moap at some point [19:06] jelmer: ah [19:08] jelmer: I had http://liw.iki.fi/liw/unperish/ in mind, hand't heard of moap before [19:09] jelmer: liw coincidentally (and some other .fi Debian people) I'm meeting up with this week in Amsterdam. If you want to join us you're welcome. [19:11] LarstiQ, I hadn't seen unperish before :-) I like the idea behind moap but it doesn't work well enough in practice, I'll give it a try [19:12] jelmer: sorry it took so long, finally updated https://bugs.launchpad.net/bzr-svn/+bug/342065 [19:12] Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,Incomplete] [19:12] LarstiQ, sounds like fun [19:13] bleh, somebody should make up a word for gezellig in English [19:13] jfroy, thanks [19:14] jelmer: kodikas, viihtyisä, seurallinen; according to my dictionary ;) [19:21] i've been trying to branch or checkout a remote repository on windows xp. however, after downloading all the data, the tree is built (according to the status message), after which only a ton of gibberish is put out in my console. can anyone tell me why? [19:22] never seen that before [19:23] trying with torquoise bzr now, see if it makes any difference. i've had RAM problems before (apparently, 1,25 GB page file were needed, which is an awful lot to download and extract ~ 50 MB of data to 500 MB), but i've had no more warnings about that when making the last attempt [19:27] same error with the GUI [19:29] adaran: could you pastebin that? [19:29] LarstiQ, no, it's too large [19:29] LarstiQ, I need to find a way to capture the head of it first. it seems to dump a lot of binary data [19:30] LarstiQ, i get python repr()'s of some binary stuff [19:30] adaran: that certainly sounds wrong [19:31] LarstiQ, shouldn't bzr produce a log? [19:31] adaran: yup. `bzr --version` tells you where it's stored [19:32] aw, shit. it's grown to 200 MB and notepad can't open it :P [19:36] LarstiQ, http://pastebin.com/m18f9561 -- there [19:37] LarstiQ, bzr check on server runs fine [19:50] Hopefully, this the appropriate place to rant about hg. [19:50] I'm trying it on a new project [19:50] and boy, is their "log" feature broken. [19:51] I understand why they spend so much time destroying their history with queues and rebase kind of gross stuff. [19:51] The reason is that log just displays everything flat, in order in which it got into the repository, no merge hierarchy. [19:51] * ddaa feels better [19:52] Pfft. You're missing the point, man. It's FAST. [19:53] * ddaa hits fullermd with a plank studded in spiky and rusty nails [19:54] fullermd: thanks for helping my catharsis :) [19:54] I've sometimes thought the rabid joy of gitk springs from the same well, actually... [19:54] * Kinnison grins [19:55] Kinnison: hello you cuddly red-haired man. [19:57] hgk does help, but then this "flat log" attitude then engenders the "fast forward pull on no divergence" idea, which just completely screws away the notion of a mainline. [19:58] Well, they dovetail. [19:58] The log breakage engender a whole view of how to do dvcs, which is just WEAK. [19:59] If your tool doesn't do anything useful with the first parent path, it won't aim at workflows which preserve it, which makes it useless, which makes it not preserved, which... [19:59] ddaa: salut [19:59] 's why trying to explain across that divide just ends up with both sides looking puzzled. [19:59] It produces a tool that makes people think "let's do the svn dogpile branch thing, except distributed". [20:00] fullermd: actually, you can prove this is a bad idea by pointing that some implications are absurd. [20:01] Only to people who care about and pay attention to theory :p [20:01] Specifically, the idea that people should not do small frequent commits because it pollutes the logs. [20:01] Oh, they can do small frequent commits. You just use rebase to squish them together logically later. See how easy it is? [20:02] You do not need to pay attention to theory to find value in "oops, I have done shit in the last 30 min, let's do revert" [20:02] fullermd: that precludes early sharing of work. [20:03] Nah, you just tell all your peers to rebase on your new rebase. That's what distributed means, isn't it? [20:03] No it isn't. [20:04] I need to finish this presentation about "Why Bazaar is better" [20:04] Or "Advanced Bzr" [20:05] To explain all the non-obvious stuff that people new to do DVCS just don't see. [20:05] yes, the ability to get a clean trunk log is the #1 reason I decided to sue bzr over hg [20:05] s/sue/use/ [20:05] I might not be looking in the right places, but where are good docs on bzr-svn workflows? [20:05] is there a way to do a bzr ignore that is only local? [20:05] to my working copy? [20:06] rbriggsatuiowa: no, there isn't. [20:06] alright - thanks [20:06] sevenseeker, whatever workflow works for bzr itself should work for bzr-svn generally [20:07] rbriggsatuiowa: You can add per-user ignores, but they affect any of your branches. [20:07] that's fine [20:07] ok, I am doing this wrong then. I did 'bzr checkout foo' and then I can't branch from foo with 'bzr branch foo foo_branch' [20:08] Actually, my distaste for hg just crossed the line where I'm willing to discard history instead of waiting for someone to fix bzr-hg. [20:08] I have one config file I don't want checked in when I'm on our production machine [20:08] sevenseeker, what about it doesn't work [20:08] sevenseeker, ? [20:08] where do I add the per user ignore? [20:08] rbriggsatuiowa: That's in ~/.bazaar/ignore I believe. [20:08] ddaa, rbriggsatuiowa: .bzrignore doesn't have to be versioned. So if *none* of the ignores need to apply to others, you can do that. [20:08] thanks [20:08] the other nice thing about bzr is that you can do almost everything without having to change your thinking from svn :) [20:09] jelmer: let me clean this out and try again... troubleshooting I did silly things I think [20:11] Anyway, let's try this thing. Maybe I'm going to realize that I do not actually care about clean mainlines. [20:12] quelle horreur [20:12] Actually, I can't help it... I do care. [20:13] (wow, it took me all of one minute of pondering) [20:13] jelmer: no .svn or .bzr in any workingcopy dir [20:14] jelmer: this was via 'bzr co http://foo.bar/svn/foo' [20:14] sevenseeker, that should create a .bzr directory in the checkout [20:15]