[00:13] do bzr branches maintain soft links? [00:35] Noldorin, bzr can version sym links [00:50] jelmer, symbolic links = soft links no? [00:51] Noldorin, yes [00:51] ok [00:51] cool [00:52] jelmer, btw how is bzr-svn these days? does it work with codeplex servers yet? [00:52] or bzr-tfs even [00:53] Noldorin, bzr-svn doesn't work with codeplex servers; codeplex servers aren't real svn servers, and they provide inconsistent data [00:53] so it seems yeah [00:53] jelmer, how about tfS? [00:53] Noldorin, it seems unlikely bzr-svn will ever work with codeplex servers until the server side is fixed [00:53] they probably hacked SVN to work with TFS over there [00:54] so maybe never :-( [00:54] bzr-tfs would be a better candidate, but I haven't seen much movement on it recently [00:54] yeah, nor have i it seems [00:54] oh well [00:54] cheers for the update. [00:54] sorry I can't give you better news [00:54] it'd be interesting to see a bzr-tfs happen [01:38] jelmer, no worries. yeah, i check bzr-tfs regularly and will probably continue. nothing exciting there yet though [02:39] Hey spiv [02:58] I need to “cherry-pick” the removal of a specific change a while ago on a branch. [02:58] (temporarily, to demonstrate a failure for a regression test) [02:58] merge . -r x..x-1 [02:58] would that involve some funky ‘--revision’ spec? [02:59] ah yes [03:00] hmm. the revision I'm interested in targeting is from a merge. [03:00] can I say ‘1658.1.1575..before:1658.1.1575’? [03:00] would that be equivalent? [03:03] bignose: it will take the left hand side of that [03:03] but yes, should do what you want === BasicPRO is now known as BasicOSX === hunger_ is now known as hunger === hunger is now known as hunger__ === hunger__ is now known as hunger === BasicPRO is now known as BasicOSX [09:39] Hi all :-) [09:40] I'd like to gently poke jelmer (or anyone) about #628973… [09:40] bug 628973 ? [09:40] Launchpad bug 628973 in Nikki and the Robots "FEATURE: move camera in terminal OEM" [High,Fix released] https://launchpad.net/bugs/628973 [09:40] Nah, the other 628973, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628973 [09:40] Debian bug 628973 in bzr-svn "bzr-svn uninstallable in unstable" [Grave,Open] [09:40] :) [09:42] Lo-lan-do, there is a weird bug in subvertpy/libapr that's preventing uploads of bzr-svn at the moment [09:42] launchpad bug 803353 [09:42] Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353 [09:43] Ah. Okay. I'll mark the packages as on hold in my aptitude, then. [09:43] Thanks for the info. [09:44] * jelmer comments o nthe debian bug [09:44] jelmer: Oh, also, bzr-pipeline needs an update too, though there's no bug about that. I was thinking of doing a snapshot merge into the alioth branch and asking you to sponsor, if that's ok? [09:45] maxb: sure, happy to [09:46] Just checking I wasn't going to duplicate work :-) [09:46] Ok, I'll have something pushed by tomorrow [09:54] maxb: thanks for checking. I should probably do that more too [09:54] I think we should get the commit email notifications back up for alioth [09:58] <__yhvh__> hey so is there a way to revert files modified like (properties changed: -x to +x) ? [10:01] <__yhvh__> I even tried feeding the list through xargs chmod but not happening [10:01] __yhvh__, revert should also revert property changes [10:02] <__yhvh__> yeah I imagine it should but it doesn't seem to work, the files end with * is that significant? [10:03] <__yhvh__> to be clear the list of modified files all get appended * [10:03] __yhvh__, that * indicates they have changed properties [10:09] <__yhvh__> yeah I really don't know what's happening here, bzr revert lists all the files with changed permissions, does the resolution passes, no effect [10:09] <__yhvh__> it did revert an actual edit I made [10:16] __yhvh__: what platform are you on? Does "bzr st" still list the reverted files as modified? [10:17] <__yhvh__> fedora 15, and yes it does [10:17] <__yhvh__> bzr 2.3.3 [10:17] are you specifying any arguments to revert? [10:17] <__yhvh__> no [10:19] __yhvh__: that definitely sounds like a bug (but a quite unusual one) [10:19] <__yhvh__> might just be me being dumb, chmod -x file fails silently [10:19] oh, interesting - is this on a vfat fs perhaps? [10:20] hi all [10:20] 'morning poolie [10:20] <__yhvh__> fuseblk [10:22] __yhvh__, it sounds like a file system bug if it's silently ignoring requests to change the mode; it should set some sort of error (ENOSYS?) [10:25] <__yhvh__> jelmer: yup touched a new file and it's created a+x [10:25] <__yhvh__> sorry for noise and thanks [12:56] hi all [13:23] does bazaar have anything like hg update null? [13:26] Maybe? But since most of us in here probably don't use hg we're unlikely to know what that is. Could you describe it generally? [13:27] it basically is a state of the working directory that precedes the first revision, so the working directory has no files checked out [13:28] Oh.. Hmm.. [13:28] Well, you can blow away the checkout, and leave only the branch. Is that what you're after/ [13:28] sort of [13:28] but I want an easy way to get it to the state from any other state [13:28] so in mercurial, it is just hg update null [13:29] I believe it's bzr zap [13:29] To remove the checkout [13:29] let me try that [13:29] remove-tree [13:30] that worked [13:30] remove-tree [13:30] what do I do to get the tree back, since update doesn't seem to be working [13:30] bzr checkout [13:30] checkout [13:30] thanks [13:30] I see the help mentions that [13:30] my bad [13:30] very nice [13:31] ok, that seems to be essentially what I was looking for [13:31] does bzr have plugins out of the box for doing a clone of a subversion repository? [13:31] Most definitely [13:31] Depends what "box" you mean :) [13:31] hehehe [13:31] well, from the official release on the website [13:32] There's bzr-svn which is available in Debian/Ubuntu/.. probably others.. I don't think it's corecore though... [13:32] mercurial at least has a convert plugin included that does a convert, but it isn't exactly a clone [13:32] bzr-svn lets you branch from svn, or just use the bzr tool as an svn client; so your workdir can either be a bzr branch/checkout or svn [13:32] Depends what you're wanting [13:32] yeah, I want to clone it, and be able to pull down changes, push changes back up [13:33] basically, have bzr act like a svn client [13:33] I was able to do that in mercurial with hgsubversion [13:33] but it seems a bit buggy [13:33] so trying to find the version control I feel most comfortable with, and which one makes the process as effortless as possible to setup. [13:35] So, your question still seems a bit mixed. These are two different use-cases... [13:35] 1. Branching a native bzr branch off a svn repo, working on it natively in bzr, then pushing it back. 2. Using the bzr commandline tool as a client for your svn checkout workdir. [13:36] well, 1 I think it what I want primarily [13:36] I don't need bzr to work from an svn checkout [13:37] Ahrighty. Yes; that's the common use-case.. but I just wanted to clear up the question to be sure :) [13:37] I just want to be sure that I can pull down changes from svn as other people commit stuff, and be sure that I could push stuff back to svn if I have something I'd want/need to commit [13:38] so I just need the bzr-svn plugin? [13:45] Should do, yup [13:45] Admittedly a year since I last used it, but that's how it worked when I did [13:45] maxb: How is that going, by the way? Are your bzr-related evangelisms getting anywhere? [13:46] Hah, at MX you mean? [13:46] Mainly stalled on lack of a true need for a DVCS given current development practices [13:49] hi maxb, lenerd [13:49] *leonerd [13:51] Ahyes.. [14:04] poolie: if I use set_append_revisions_only(true) on a remote branch (i.e. LP) will it do the right thing? [14:05] it should [14:05] cool [14:46] How does one remove all traces of a branch inside a shared repo ? [14:46] i'm having difficulty (those who were here yesterday might recall) [14:46] commiting, because the commit is quite large and bzr is souping up all the memory available in the server [14:47] finally the kernel kicks in and kills the process [14:48] Red15, the easiest way is to create a new repository and clone all branches you do not want to remove into that [14:48] ouch ... [14:48] sounds like quite the hassle [14:49] do shared-repositories complain when you move then around or do they not care for their parent directory ? [15:01] Red15: as I understand it, shared repos are self contained — it's the branches that are contained under the repo that are position sensitive. So as long as you move the shared repo further up (towards the root), you'll be ok — providing there isn't a shared repo there already [15:01] ok, that's what i figured thanks for confirming briandealwis [15:01] am noticing shared-repos are quite bad for bzr memory usage [15:03] Red15: how so? A standalone branch has a repo too — it's just not shared (bar lightweight checkouts) [15:03] i was maintaining a big-shared-repo for our company [15:03] but the hosted server has ~1gb of ram [15:04] the total dirsize of the shared repo is ~1gb [15:04] when committing the bzr smart server process uses all the memory in the server causing kernel-oom-measures to fire [15:05] Red15: I wonder if you're hitting a repacking threshold. [15:05] briandealwis, how can i tell? [15:05] I've just hit one myself with one branch, and it's painful [15:05] Red15: look at the logs [15:06] this was on server side : http://paste.ubuntu.com/635054/ [15:07] You'll need to look before that. Mine has sometime like "648.407 Auto-packing repository GCRepositoryPackCollection(CHKInventoryReposito [15:07] ry('file:///Users/bsd/Manumitting/Projects/e4/.bzr/repository/')), which has 28 [15:07] pack files, containing 28102 revisions. Packing 21 files into 1 affecting 21102" [15:07] Red15: but it sounds like you could really benefit from adding some more RAM to your server [15:07] this one is today : http://paste.ubuntu.com/635806/ [15:08] But that didn't fail, right? [15:08] actually nvm that one [15:09] http://paste.ubuntu.com/635807/ that one failed [15:10] Red15: that one is definitely repacking. I wonder if there's a way to avoid repacking — it's an optimization, not a requirement, as I understand it. [15:11] https://bugs.launchpad.net/bzr/+bug/184237 [15:11] Ubuntu bug 184237 in Bazaar "autopacking should be optional" [Undecided,Invalid] [15:11] or this one : https://bugs.launchpad.net/bzr/+bug/736001 [15:11] Ubuntu bug 736001 in Bazaar "Re-packing happens at inconvenient times and blocks further operations" [Medium,Confirmed] [15:29] Red15: I've installed John's bzr-prompt-repack plugin; you could adapt it for your server to always skip repacks on your server, and schedule a repack for the evenings (once you've added more memory) [15:29] for now i've decided to not use shared repo's anymore and i think that should steer clear of the problem for now [16:34] ah, jml just proposed his bug 660852 branch [16:34] Launchpad bug 660852 in testtools "text failure report is too gassy" [Wishlist,In progress] https://launchpad.net/bugs/660852 [16:34] yes what? [16:34] mgz: please play with it. Am interested in feedback. [16:35] (also, interested in better ways to code it) [16:36] I saw a few nits looking at an earlier iteration, will review and see if there's anything still needing sorting if you like [16:36] the general plan looked good. [16:37] okay, so, you have u"" literals in tests, python 3 gets sad at them. [16:40] mgz: oops. sorry. [16:41] * jml really needs to tweak 'make check' to run with all local Pythons [16:41] also, using doctestmatches with unicode is asking for pain. [16:41] yeah, there's a bug about that isn't there [16:41] there's a bug against testtools I've got a branch for, but also, [16:41] doctest screws us majorly on that front [16:42] because inside an innocently named `_indent` function, they encode to whatever the sys.stdout encoding is [16:42] mgz: ok. I'll stick with Equals. [16:42] which... clearly is no good for testtools/subunit passing things cross process [16:42] mgz: once this patch is ok, I want to resurrect your tb stack frame patch [16:43] but I guess a bunch of other bugs ought to get fixed first. [16:43] yup, we need to find a near(ish) way of doing that. [16:43] *neat [16:43] mgz: as far as I'm concerned, we can use __unittest and make sure that testtools' own runner re-sets __unittest to False. [16:44] sticking __unittest = True at the top of all modules is ugly, but adding our own _is_relevant_tb_level would work too [16:47] the changes to _details_to_str look sensible to me. [16:49] I wonder if it shouldn't become a public api, or some part of it. bzrlib doesn't want to stay doing str(_StringException) forever and needs to have some means to show the test information during the run. === beuno is now known as beuno-lunch [16:52] mgz: hmm. interesting thought re details_to_str becoming public. [16:53] mgz: I've pushed up changes to make tests pass with Python 3 [16:56] that all looks good. removing the underscore can probably wait till I find whether I need to delve into privates for bzr. [17:00] mgz: poolie was just trying my branch w/ bzr. The traceback still comes up in curly braces. I'm not sure why that's the case. [17:00] (I don't really know much about bzrlib.tests any more0 [17:00] yeah, that's the traceback-1 stuff probably [17:01] jml, i put an example failure on the bug [17:01] remember spiv hacking around a test duplication issue where each test grew a new traceback every time an instance of it failed? [17:01] o/ mgz [17:01] mgz: ? it says 'traceback', not 'traceback-1' [17:01] hm. wrong guess then. [17:02] mgz: yeah, I'm pretty sure I fixed that issue [17:06] jml: _details_to_exc_info needs changing to mkae bzrlib work [17:07] mgz: ah, I see. [17:08] mgz: I have to say, I don't really understand what the purpose of the code path is, why things would go down it [17:08] I'm a little worried about 'reason' vs 'traceback' too, I don't quite see where that'll be handled [17:08] as in, skip vs error [17:08] except TypeError: [17:08] # have to convert [17:09] ^it's confusing, basically, it's the compat with the unittest api [17:09] which deals in exc_info not details dicts [17:11] so it catches the decorated thing not understanding the details kwarg? [17:11] yup. [17:12] and what about this bit: [17:12] # extract the reason if it's available [17:12] try: [17:12] reason = ''.join(details['reason'].iter_text()) [17:12] except KeyError: [17:12] reason = _details_to_str(details) [17:12] I mean, I don't see how that squares with your reason vs traceback worries. [17:12] ah, that's me answering my own question [17:12] :) [17:13] hey, spiv and poolie were both awake... aus has migrated to the northern hemisphere? [17:15] mgz: Canonical hack-a-thon in Dublin. [17:16] aha. === beuno-lunch is now known as beuno [17:54] thanks for looking at the subunit unicode bug [18:00] Hi, I'm having a problem with directories when using bzr through the command line [18:01] I run the command \ [18:01] bzr init "C:\Users\jamdahl\Documents\New folder (2)\" [18:02] and it says the directory does not exist [18:03] jamdahl: what does `mkdir "C:\Users\jamdahl\Documents\New folder (2)\"` say? [18:04] it says it already exits [18:05] Ah, I found the problem, it's the \ at the end [18:06] okay, then try removing th... [18:06] you got there first :) [18:06] file a bug. [18:08] your command line was wrong, and bzr does tell you how, but could be clearer [18:14] mgz: can you please take a look at https://code.launchpad.net/~jml/testtools/doctest-unicode-safety-672056/+merge/66500 [18:19] jml: that's not enough unfortunately. [18:19] mgz: oh? [18:19] well, oh is that all? [18:20] is DocTestMatches designed to take arbitrary objects and stringify them though? [18:20] mgz: it does make the test pass :) [18:20] jml: printing the output also gets messed up [18:20] I need to leave in a sec but I'll see if I can throw my branch up somewhere for you to look at [18:20] mgz: ok, thanks. [18:27] jml: see lp:~gz/testtools/unicode_doctestmatches_764170 [18:27] mgz: thanks. [18:28] there are... all kinds of annoying interactions here with different python versions [18:28] mgz: yeah. [18:28] I'm not sure the bug you duped against was the same thing either, will look at when I get back. [18:29] mgz: I'm wondering whether it's acceptable to just mangle output [18:29] mgz: as the least of all evils. [18:29] yeah, that sometimes happens currently, and it's better than breaking entirely (which that branch does currently on 2.6) [18:30] okay, I'm gone. [18:37] jelmer, hello, you around? [18:38] Noldorin_, hey [18:38] jelmer, yesterday you told me bzr supports symlinks...does it support them on windows though? [18:38] Noldorin_, no, it doesn't support them on Windows (how would it?) [18:38] well Windows does have symlinks... [18:38] they just require admin rights to create :-S [18:42] jelmer, guess it still doesn't support them though [18:43] Noldorin_: yeah, bzr doesn't create them - we should probably just not be creating any files in disk but remembering the existing symlinks that are already in the tree [18:44] jelmer, yes that would probably be a good idea. [19:00] what's the easiest way to get the tag of a certain revision? [19:14] mgz: here by chance? [19:17] the behaviour on 803796 seems to be weird, or I'm doing something rather wrong [20:40] LarstiQ: it is weird, but with the latest bzr you should get a neat error message rather than a traceback, if you could confirm that [20:40] mgz: "Tree is up to date at revision 0 of branch /tmp/bzr" [20:41] hm, that's not as useful as I thought it'd be. [20:41] mgz: I filed bug 804037 about the weirdness I ran into [20:41] Launchpad bug 804037 in Bazaar "bzr branch -r 0 downloads more than expected" [Medium,Confirmed] https://launchpad.net/bugs/804037 [20:42] * LarstiQ didn't dig very deep [20:42] so could be wildly off, but I'm suspecting a null: vs None conversion problem [20:42] blast, riddell's branch isn't linked from bug 242175 [20:42] Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175 [20:43] https://code.launchpad.net/~jr/bzr/242175-empty-branch-merge/+merge/61152 [20:44] okay, so somehow we're not hitting that error message codepath, but also not getting the old traceback [20:47] or do you get it when you run `bzr update` in your -r 0 branch? [20:50] mgz: that message is `bzr update` in my -r0 branch [20:50] * LarstiQ doesn't get a traceback [20:51] okay, so that part is okay then, it's just the transfer that I agree is suprising. [20:52] how cna i find out which revisions in a branch have tags and what they are? [20:53] `bzr tags`? [20:54] mgz, oh dear, how did i miss that! thank you === yofel_ is now known as yofel [23:43] I'm getting http://pastebin.ubuntu.com/636053/ when I create (bzr init) a new tree and then push it to an existing project... any idea how I can rectify this? Appears to be some sort of compatibility issue... [23:43] timrc, your branch is in a bzr format with more capabilities than the format the default development branch is in [23:44] jelmer, it throws an exception in Python, but is it actually problematic? [23:44] timrc: the development branch appears to be in an old format, so you might want to upgrade it to the current format unless it needs to be accessible by hardy bzr [23:45] timrc: IIRC it doesn't actually push any data if it gives this error === medberry is now known as med_out [23:53] jelmer, thanks for the assistance :)