=== spiv_ is now known as spiv [00:02] lifeless: I am just a user. So when you say unpolished do you mean it is not really supported yet or do you mean it just is a little more pain than it will eventually be? [00:04] eric_programmer: I mean lots of rough edges; possible bugs. I wouldn't use it unless you plan on helping finish it off :( [00:04] eric_programmer: sorry :( [00:06] lifeless: No problem. Is there any alternatives. I looked at the config-manager but didn't quite understand how it fit into things. I am coming from SVN + Piston so am looking for somewhat of an equivalent. [00:08] I don't know what piston does [00:10] lifeless: Basically is a add-on for SVN. Works a little like svn:externals but actually puts the source of the vendor code in your own tree. This way you can make changes and track those changes. But then later do a piston update vendor/some_lib and it will pull in the latest from that project merged in with your changes. This way you can make local changes and control when updates come in from vendors. [00:12] eric_programmer: config-manager can do that' basically you record all your externals in a flat text file [00:13] lifeless: OK, I'll have to check that out more carefully then. Sounds like it may be what I am looking for until Bazaar get's full support. Thanks! [00:13] eric_programmer: you want the python codebase [00:25] Is it possible to have more than one (non-nested) tree in a branch? [00:25] I'm still trying to wrap my brain around this. [00:26] awmcclain: no; a branch is a pointer to a revision-tree [00:27] when you commit the pointer is changed [00:28] I see. So when you you run bzr branch inside a shared repo, what happens in terms of "branches" and "trees" [00:28] ? [00:28] is "working-tree" the same as "tree"? [00:28] no, right? [00:28] working tree is a tree that can be edited; when referring to whats on disk they are often used interchangably [00:29] bzr branch creates a new branch using the revision pointer from another branch; then creates a working tree at the same location with the contents of that revision [00:30] unless invoked in a shared repo with --no-working-trees [00:30] right; in that case the second step is skipped [00:30] ah ha! I learned something! [00:31] are you new to bzr? [00:31] Yes. [00:31] you may find it easier to completely ignore repositories for a while [00:31] they are nothing more than a space optimisation [00:34] Well, I'm doing enough nitty-gritty work (between stripping out SVN revisions and writing a plugin to interface with bzr-eclipse deal with our eclipse workflow) that it doesn't really bother me. I just want to make sure I'm understanding the concepts. [00:35] My primary goal is to make branching fast and easy easy easy. [00:35] awmcclain: ok :). [00:35] And along the way I need to deal with some architectural issues with the way our VCS was set up. === NichardRixon[clo is now known as NichardRixon [00:48] moin [00:48] If you have a nested branch structure (like in http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch), and you branch the mainline, do you get revisionn histories from everyone's feature branches? [00:50] outside the repository? no. [00:53] bob2: So if you do bzr branch mainline, you just get the mainline change history, not bob/feature-foo as well [00:53] right, branches are separate [00:54] this is why I said ignore repositories:) they don't change any semantic behaviour [00:55] lifeless: Ahhhh. Of course. Ok, now it makes sense what you were saying. I was thinking of them in an SVN sense. [00:56] Hierarchy in the filesystem (branch B is in a folder of branch A) is separate than the tree hierarchy [00:56] s/than/from [00:56] Ok. Last question, I swear: [01:03] In http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style, under "backing up" it mentions "You may even wish to bind local task branches to remote ones established on a backup server just for this purpose.". How would that work? bzr branch local-mirror local-feature-branch. bzr remote-branch. bzr bind local-feature-branch remote-branch? [01:06] awmcclain: what it means is 'work like you do with svn' - so that the remote server that is backed up has every branch [01:06] awmcclain: and when you commit those branches get the commits [01:06] awmcclain: I don't think backing up is a reason do to this; workflow and team coherence is a much better reason to do this. [01:07] lifeless: Very good point. The only thing I want to mitigate is the remote possibility that someone's machine goes down with their local feature on it. [01:08] awmcclain: then have them make sure its published in some fashion somewhere :) [01:11] lifeless: Is the main reason to have nested branches (or just developer branches published) on the mainline server to facilitate corroboration on feature branches? Because it's easier to just both pull from the central location vs push pulling between devs? [01:12] awmcclain: uhm, nested branches is not what you mean I think [01:12] I mean a shared repository structure like: http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch [01:13] or even http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar [01:13] awmcclain: anyhow, if you have two developers working on a single feature, it can be advantageous to have a single branch they both commit too [01:15] I have to go catch a train [01:16] awmcclain: man that wiki page is confusing [01:16] Tell em about it. :) [01:17] did you try the user guide? it may have something better [01:19] it's the same thing verbatim [01:19] :) [01:38] So, anyone here intending to be at FOSDEM? === rolly is now known as kumi [01:52] igc: ^ see comments re shared repo stuff [01:52] Odd_Bloke: yep, I will [01:53] shall do [01:54] Odd_Bloke: I'll be wandering around and hopefully be on IRC (if they managed to get the WiFi working this year) [01:54] Odd_Bloke: are you speaking / manning a booth? [01:54] jelmer: how is wouter? [01:55] lifeless: ok but busy with uni last time I spoke to him [01:56] awmcclain: wrt the 'using a backup server', what I meant was something like this ... [01:57] bzr push sftp://our-backup-server/me/work-for-X [01:57] then use bind to bind to it while in the office [01:57] as lifeless said, commits will implicitly go there as well [01:57] igc: our-back-server being different than our-mainline-server? [01:57] when out of the office, unbind and work locally [01:58] it can be - it's up to you [01:58] he was actually on the channel a couple of days ago [01:58] if the motivation is "let's not lose work when a laptop disk crashes", then ... [01:58] Exactly [01:58] it doesn't need to be the main repo - it can be anywhere central that's backed up [01:58] also the motivation being "let's make this whole thing as easy as possible" [01:58] =) [01:59] igc: I strongly suggest not using 'bind' for 'backup'. Its a) confusing and b) will /conflict/ with folk that use checkouts for workflow. [01:59] well it's one option [01:59] another is being in the habit of doing a regular push to a cental server as well [02:00] igc: its an abuse of a workflow feature; as seen above it just confuses people. [02:00] lifeless: yes and no [02:00] igc: another is to run a backup tool. Or do push-multi before signing off. [02:00] clearly you need multi-bind, so you commit to your 17 redundant data centres [02:00] Also, is there any to use http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch over http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar? To me the only real difference is that your mainline trunk is either a parent or sibling... and nested branches don't work in trac-bzr. Is there a performance increase? [02:00] bob2: exactly. [02:01] awmcclain: I would never arrange branch A under branch B, because when we get real nestd branches working that will cause all sorts of errors. [02:01] hm, I was being fascetious, but it would be neat to commit to local and remote repository [02:01] lifeless: 'Nuff said. [02:01] keep in mind that some teams are sticking with central VCS solely for the 'we like central backups' all the time side effect [02:01] awmcclain: *unless* you know you won't be using tested trees. [02:02] igc: in which case, they should just use 'bzr checkout' all the time, which will do the same thing. When offline they use bzr commit --local. [02:02] igc: what I'm getting at here is the following: [02:02] new users see repository layout as something to get right, because they assume a high cost to change (because svn is bad, mmkay). [02:03] and to understand that page they need to know all about repositories, bind, namespaces, difference between branches with trees and without trees. [02:03] which is a huge learning curve that new users should not need to know. [02:03] !!!" new users see repository layout as something to get right" [02:03] agreed, but I didn't write that page :-) [02:03] (and because svn offers some advantages to some layouts (e.g. checkout trunk to get trunk/{project1,project2})) [02:04] i just uttered that not more than 5 minutes ago [02:04] bob2: our nested trees will do that correctly when polished. [02:04] my point is that in a central system, commit = checkpoint + publish + backup [02:04] awmcclain: you're not the first I've seen having this problem [02:04] igc: I'm not blaming you for the page; but you are defending some of the content at least. [02:05] hmm.. i think even monotone made it easier to understand, as they avoid the trees vs no tree repositories.. since trees are always stored in sqlite, and only working copies make files [02:05] in Bazaar, you have the flexibility to make it mean any one, or two, of those [02:05] lifeless: I did write the bit about pushing to a backup server [02:05] igc: I posted to the list a while back that we're making the curve harder than it has to be. [02:06] I'd agree with that ... [02:06] I'm far from finished with the docs fwiw [02:06] igc: I think that that page needs to let new users be much more agile; there are multiple answers but we don't have to provide a concordance in the introductory information. [02:06] If I may, as a new user, chime in.... the whole page on distributed workflow is really really great.... except for that one paragraph on backing up the server. (Since that was exactly my worry coming from a central VCS). It just wasn't informative enough. [02:06] (sorry igc) [02:07] feedback is great - thanks [02:07] is it clearer now? [02:07] igc: anyhow, I would rather we provide a flowchart 'if you want to achieve X' system for this, rather than a huge list of choices [02:08] On the whole, though, the docs on bazaar have been really great for me to wrap my mind around the big problems... 1 How is DVCS better? 2. How can I adjust our existing workflow to best suite that? [02:08] igc: with the first option being 'are you a single user with a small tree' -> no repository, kthxbye [02:08] bbiab [02:08] let me see [02:08] igc: I'm heading to Martins now. [02:09] igc: looking at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style. Did you change it? [02:09] lifeless: np - thanks for the ping [02:09] awmcclaim: I wrote it if that's what you mean [02:10] ohhh... is it clearer now, yes, after irc? yes [02:10] i thought you meant that you changed the docs [02:11] No, what I meant was I didn't write the section on NestedTreeLayout [02:11] I wrote a large amount of the rest though [02:11] (and after irc) [02:13] Ah yes. Is "NestedTreeSupport" different than 8.2.2 Nested Style repository layout? === jelmer_ is now known as jelmer [02:13] Overall, i just want to say that the docs were the main reason I chose bzr over hg. [02:14] awmcclain: cool [02:14] awmcclain: and yes it is different [02:14] Ok, good. [02:15] I don't want to think about it then. :) [02:17] jelmer: Nope, will be a spectator again this year. [02:17] awmcclain: ah yes, I meant Nested Style repo layout (or whatever the really long section like that is called) [02:18] hehh [02:18] awmcclain: and I'm wrapper you like the docs - that's great news [02:18] s/wrapper/wrapped/ [02:20] jelmer: Are you manning/speaking? [02:22] Odd_Bloke: nope, not this year [02:23] Odd_Bloke: Interested in meeting up during FOSDEM? We could get some people involved in Bazaar development together [02:23] I know at least LarstiQ is going to be there as well as some users [02:24] jelmer: Yeah, I'd be up for that. [02:25] Odd_Bloke: are you going to be on IRC during the weekend? [02:26] Hopefully the network is going to be working correctly again this year [02:28] anyhow, sleep first [02:29] Night! [02:29] * Odd_Bloke intends to stay up so he doesn't miss his train and then nap liberally. === NichardRixon[clo is now known as NichardRixon [02:34] * igc food [02:37] Anyone here familiar with bzr-svn? [02:56] awmcclain: A number of people are. If you have a question, just asking it is the best way to get a response. :) [03:07] Odd_Bloke, are you coming to London to see us? [03:25] poolie: Yeah, I'd like to. [03:34] Here's a strange thing: I'm getting an error in trac svn: PermissionDenied: Permission denied: "/repos/pandasite/.bzr/branch-format": [Errno 13] Permission denied: u'/repos/pandasite/.bzr/branch-format' [03:35] Even though my /repos/pandasite is world readable [03:35] does it need to be writable as well? [03:35] s/trac svn/trac+bzr/ [03:42] awmcclain: I don't know why trac+bzr would try to write [03:43] looking at the python it's just trying to "get" using a local bzr transport at file:///repos/pandasite/ [03:44] ls -al /repos/pandasite [03:44] total 16 [03:44] drwxr-sr-x 4 clownfish dev 4096 Feb 22 02:41 . [03:44] drwxrws--- 6 root dev 4096 Feb 22 01:37 .. [03:44] drwxr-sr-x 6 clownfish dev 4096 Feb 22 01:36 .bzr [03:44] drwxr-sr-x 9 clownfish dev 4096 Feb 22 02:44 panda [03:44] then for whatever reason its failing to read; are the directory above rx for this user ? [03:45] drwxrws--- 6 root dev 4096 Feb 22 01:37 .. [03:45] ahhh! [03:45] the sticky bit! [03:45] sigh [03:45] * awmcclain shudders off into corner [03:45] a good way to test these things is to su to the user doing the access [03:46] and explore in shell [03:46] jml: when are thou arriving? [03:46] spiv: ottid [03:46] lifeless: I've pinged poolie confirming if it's ok to leave now. no response yet. [03:47] Can't su as ww-data because i've removed the shell. :) [03:47] www-data that is [03:47] jml: I'mm here :) [03:47] So, the instructions on http://bazaar-vcs.org/SharedRepositoryTutorial (set the perms of your repo directory to 02770) don't work for trac+bzr. [03:47] jml: he says its ok to come now [03:47] ok. [03:48] * jml tidies up some stuff [03:48] awmcclain: su -s /usr/bin/bash www-data [03:49] awmcclain: as root; so sudo su -s ... [03:54] lifeless: "ottid" [03:54] ? [03:54] ditto :) [03:54] Oh, right [03:54] I forget to use the xrandr option to flip my screen :P [03:54] Odd_Bloke: did you tell Claire so? i don't remember seeing a response from you? [03:55] that wouldn't work either :) [03:55] poolie: I haven't responded yet, because I completely forgot to do so. [03:55] do now :) [03:56] Oh, so close... now: "No node at revision current%3A" [03:57] lifeless, poolie: I'll probably head off in about an hour [03:58] rightyo [03:58] poolie: Who is Claire and how do I tell her so? :p [04:00] see my mail [04:02] poolie: The only mail I can find (and recall getting) doesn't mention a Claire (http://paste.pocoo.org/show/29283/). [04:02] do you see my private msg? [04:05] poolie: I don't. [04:05] You would appear not to be identified with NickServ... [04:07] now? [04:48] hmm... if I have a path with hundreds of files and folders, and I want to ignore _all but a few_ files, how would I do that in .bzrignore? [04:49] kumi: probably easiest to ignore everything, then add the ones you want to keep [04:49] you can add ignored files [04:49] this is assuming there's no easy expression that will match [04:49] Oh, that's surprisingly simple [04:49] let's see [04:51] we try to be pleasantly simple [04:52] Worked like a charm, thanks [05:07] Ug. I can't figure this out. I've branched a directory from SVN into a shared repo, but when I point bzr+trac to the repo, I get "no node at current:", and if i point it one level in (to the branch) i get "can't compare datetime.datetime to float" [05:11] New bug: #194251 in bzr-dbus "bzr-dbus should not require a separate daemon to broadcast notifications" [Undecided,New] https://launchpad.net/bugs/194251 [05:16] lifeless: ^^^ the above bug contains my thoughts about how to improve bzr-dbus [05:21] jamesh: ok; we should talk about this daemon presence/absence thing; I'm really not sure that we can do without it, and I don't understand why doing without it is a feature [05:21] jamesh: specifically getting the mappings right seems to require state to me [05:22] lifeless: I don't think that is a problem provided that the servers providing the mappings are able to readvertise themselves on demand [05:22] (which I cover in that bug) [05:23] jamesh: ah; won't that require event driven servers though? [05:24] lifeless: for bzr-avahi, I just run an event loop in a daemon thread [05:24] works great [05:25] jamesh: ok, I shall read the bug. [05:25] jamesh: I still don't get the objection :) [05:25] lifeless: other than the daemon being unnecessary and the cause of pretty much all the other bzr-dbus bugs? :) [05:28] well, its not being fully utilised today; but besides that - it is the cause of bugs ? [05:29] the big improvement is changing things to use signals instead of method calls [05:30] with current bzr-dbus, "bzr commit" will needs to send a DBus message to the daemon and wait for a response [05:31] by instead sending it as a signal, it need not block on a response [05:31] and if you're sending a signal, you may as well send it to everyone who has expressed interest [05:37] current bzr-dbus does send a signal [05:37] the service is the one that waits [05:39] the set_rh hook calls Activity.advertise_branch() That in turn performs a DBus method call to the broadcast daemon [05:39] a method call is two messages (one in each direction) [05:40] oh hmmm [05:40] so youre right. [05:40] lifeless: I don't expect "nested-style" layout to interact poorly with nested trees. [05:41] abentley: when the user has a tree in the repo I expect it too [05:41] abentley: tree-less repos - sure. [05:41] a signal is basically a "one way" method call that can optionally be broadcast (as opposed to being sent to a single DBus name) [05:41] jamesh: ok; in principle I'm for this, but I want to think around the mapping implications. [05:41] jamesh: also, are you volunteering ;) [05:42] lifeless: sure, although I may not be timely in sending patches :) [05:42] lifeless: The plan for nested trees was to allow arbitrary locations to be used. [05:42] jamesh: (I do know the difference between signals and calls on dbus :)) [05:43] lifeless: one of my ulterior motives for running an event loop on "bzr serve" is that I need one for bzr-avahi anyway [05:44] lifeless: if bzr-dbus requires effectively no setup and has low overhead with no listeners, I may as well make bzr-avahi depend on it [06:00] jamesh: ok; I'm keen to reduce overhead. [06:26] tree = bzrlib.workingtree.WorkingTree.open('.') [06:26] state = tree.branch.get_loom_state() [06:27] tree.branch.remove_thread('string_here') [06:27] tree.branch.nick = 'rf' [07:13] Anyone up? Trying to upgrade bazaar on ubuntu... but I can't figure out how to add the entry to my sources.list. It keeps telling me the 1.0.0 i have installed is current [07:15] https://launchpad.net/~bzr/+archive has the correct sources.list lines [07:15] maybe you forgot to "sudo apt-get update" or similar? [07:15] oh, man. i'm too tired. I totally misse dthat [07:16] thank you [07:16] np [07:17] hrm [07:18] it's removing bzr-svn... was that merged into bzrtools? [07:18] no [07:18] bzr-svn (maybe) isn't updated to work the latest version of bzr [07:19] :( [07:19] well [07:19] this stinks [07:25] good night all [07:25] New bug: #194274 in bzr-loom "Removing the bottom thread should be possible." [Medium,Triaged] https://launchpad.net/bugs/194274 [07:26] awmcclain: i'll check about bzr-svn, but i have to go now [07:26] for now i suggest you stay on 1.1 [07:26] okee doke [07:28] awmcclain: i think that bug is the indirect cause of your problem [07:29] 194274? [07:46] New bug: #194277 in trac-bzr "Trying to view diffs between revisions on a single file shows revision on ALL files" [Undecided,New] https://launchpad.net/bugs/194277 === doko_ is now known as doko [07:57] night all [08:01] New bug: #194282 in trac-bzr "Pointing trac to a shared repository with a single branch yields an error" [Undecided,New] https://launchpad.net/bugs/194282 [08:01] later all [08:01] night [08:01] well [08:01] this has been a long day. I'm signing off as well. Too bad I couldn't get the trac stuff to wrok. :-\ [08:02] thanks lifeless, for all your help === kiko-afk is now known as kiko [10:33] hm something is odd here: bzr check says "429 revisions", yet bzr up says "Tree is up to date at revision 390.". No I haven't merged anything from anyone, nor branched it. [10:34] any idea? would bzr uncommit cause it? I used it a few times [10:35] yes [10:36] ah [10:36] dato, how do I get rid of those "orphand" revisions? [10:36] at the moment, you only can by branching your current branch to a new branch, and use that one from now on [10:37] b get foo foo.new [10:37] mv foo foo.old [10:37] mv foo.new foo [10:37] :) [10:37] dato, hm I store it in a shared repo (in case I later want to branch), so a bit more complex [10:37] but I see [10:37] oh, it indeed is a bit more hairy in a shared repo [10:38] dato, hariy? hm? [10:38] how would one do in a shared repo then [10:38] but only a bit [10:38] cd .. [10:38] ah right [10:38] b init repo.new [10:38] er [10:38] init-repo [10:38] and then branch each over to new repo right [10:38] b get repo/foo repo.new/foo [10:38] yes [10:38] etc [10:38] hrrm [10:39] dato, would be nice with a command to get rid of such orphand revisions [10:39] unless you committed some really big (or confidential) revisions by mistake [10:39] you normally don't care [10:39] dato, really big indeed [10:39] AnMaster: yes, there's been talk about it for ages [10:39] and saw a typo in commit message. uncommited, recommited [10:39] * AnMaster wonders if bzr uncommit works after bzr sign-my-commits [10:40] I've sometimes wondered about accidental committing of privileged data [10:40] never done it, thank god. [10:40] but it is an interesting issue. [10:40] I guess if the privileged data is in revision N and you do a bzr branch on (N-1) that gives you a clean copy? [10:41] yes [10:41] barring the shared repo issue mentioned above [10:41] I assume it doesn't push orphand revisions [10:41] on bzr push [10:41] * quicksilver nods [10:41] so the data would just be locally [10:42] btw anything interesting new in bzr 1.2? [10:50] there is the bzr remove-revisions plugin [10:50] which will removed orphaned revisions [10:50] but it's slow as hell, because it can optionally rewrite the whole history of the repository [12:02] jelmer: it seems that pushing to svn from bzr shell leaves the database locked === jrydberg__ is now known as jrydberg [12:21] Can anyone tell me about Visual [12:21] Studio integration? [12:22] I find the SOC-project, but nothing about it actually being successful or not. As in production quality. [12:24] dato: I'm not doing anything fancy to the database [12:26] jelmer: well, all I know is that if I `bzr shell`, and push to svn from there, and leave the shell open, I can't push from another terminal. [12:26] not that is something critical, but just I thought you'd like to know. [12:26] (btw the "db is locked" error spits a traceback) === mrevell is now known as mrevell-lunch [12:44] Nobody knows about Visual Studio support for bzr? === mrevell-lunch is now known as mrevell [16:02] is there a known bug about the bzrtools 1.2.0-1ubuntu2 package being broken? [16:02] the postinst is failing for me because none of the .py files that it's looking for are there [16:06] Hi. Getting the following when committing: bzr: ERROR: exceptions.AttributeError: children [16:07] Full traceback: http://dpaste.com/36405/ [16:49] WhAlBeRg [16:49] NeRdEsInNnN [17:00] asf [17:14] Hi there [17:14] Can I update a lightweight checkout of a branch to an older revision? [17:14] Lo-lan-do, you mean revert it to an older revision? [17:15] Yes [17:15] Lo-lan-do, bzr revert -r revision_number [17:15] will revert the tree to the state it was at a specific revision [17:15] you can also create a new branch from that revision [17:16] Hm. But I'll have locally modified files then :-/ [17:18] Lo-lan-do, I don't understand what you want very well than. Can you explain a bit more? [17:18] you have a remote branch, and a local lightweight checkout, right? [17:19] Right. [17:19] And I'd like to change the contents of the files I have locally. So bzr revert -r foo works. [17:20] But when I do that, bzr status tells me the files are added/modified/deleted/whatever [17:20] Lo-lan-do, yeap. Then you'll have to commit them, fo course [17:20] I don't want to commit, I just want to navigate the past. [17:21] Lo-lan-do, then just re-branch at that revision [17:21] it it's just to look through [17:22] then just delete ir when you're done [17:22] That sounds a big suboptimal, especially if I want to poke at several past revisions. [17:22] s/big/bit/ [17:23] ah, well, I'm not sure what tool let's you navigate revisions better, but I do think it would be a plugin [17:24] Basically, I've tried the bisect plugin, and I'm trying to go a bit past that. [17:24] See what happens if I poke files around. [17:25] Lo-lan-do, maybe the list will be more helpful [18:36] Did I get this message - `bzr: ERROR: Cannot lock: transport is read only: ´ - because I used `bzr checkout´ instead of `bzr branch´? [18:37] exarkun: yes, are you doing a commit? [18:37] No, it happened during checkout [18:37] exarkun: ah, that's a bug. [18:38] exarkun: you can probably branch and the "bzr bind", or checkout using "bzr+ssh://" [18:38] maybe [18:39] actually it happened as part of an automated process which is difficult to alter :/ [18:40] exarkun: :/ [18:40] james_w / exarkun : just yesterday I did a light checkout over http and it worked [18:40] of course not for committing but the checkotu didn't error [18:40] hm [18:41] lemmie make sure I actually completely understand what's going on... [18:41] jdong: yeah, it only seems to be some branches that cause it. [18:41] exarkun: are you using checkout --lightweight? [18:41] doesn't look like it. this is the full command - '/usr/bin/bzr checkout http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk build' [18:42] there's a comment in this code about how --lightweight causes a cannot-lock error ;p [18:42] yeah, that's a heavyweight one. [18:42] oh dear. [18:44] lol [18:44] oh hm [18:44] why would you do an entire heavyweight checkout for a build though? [18:44] maybe this is using an old version of bzr [18:45] (my tests were with bzr 1.1 or 1.2, forgot which) [18:45] this host seems to have bzr 0.8.2 [18:45] maybe I will upgrade it [18:45] Holy crap. [18:45] a tiny bit outdated [18:51] ah, cool, that fixed it [18:52] * james_w cheers for progress [18:52] we finally know that we have improved on 0.8.2 [18:52] :P [18:52] True. I haven't even considered the question since, like, 0.9 :p [18:54] Hey folks, when I try to add a directory with bzr add, it says "Ignored 27 file(s) if you wish to add some of these files, please add them by name" is there any way to override that so I don't have to manually go through and find those files? [18:54] not that I'm even sure where this listing of 27 files would be. [18:54] 'bzr ignored' [18:55]