[00:13] <Noldorin> do bzr branches maintain soft links?
[00:35] <jelmer> Noldorin, bzr can version sym links
[00:50] <Noldorin> jelmer, symbolic links = soft links no?
[00:51] <jelmer> Noldorin, yes
[00:51] <Noldorin> ok
[00:51] <Noldorin> cool
[00:52] <Noldorin> jelmer, btw how is bzr-svn these days? does it work with codeplex servers yet?
[00:52] <Noldorin> or bzr-tfs even
[00:53] <jelmer> Noldorin, bzr-svn doesn't work with codeplex servers; codeplex servers aren't real svn servers, and they provide inconsistent data
[00:53] <Noldorin> so it seems yeah
[00:53] <Noldorin> jelmer, how about tfS?
[00:53] <jelmer> Noldorin, it seems unlikely bzr-svn will ever work with codeplex servers until the server side is fixed
[00:53] <Noldorin> they probably hacked SVN to work with TFS over there
[00:54] <Noldorin> so maybe never :-(
[00:54] <jelmer> bzr-tfs would be a better candidate, but I haven't seen much movement on it recently
[00:54] <Noldorin> yeah, nor have i it seems
[00:54] <Noldorin> oh well
[00:54] <Noldorin> cheers for the update.
[00:54] <jelmer> sorry I can't give you better news
[00:54] <jelmer> it'd be interesting to see a bzr-tfs happen
[01:38] <Noldorin_> jelmer, no worries. yeah, i check bzr-tfs regularly and will probably continue. nothing exciting there yet though
[02:39] <BlindWolf8> Hey spiv
[02:58] <bignose> I need to “cherry-pick” the removal of a specific change a while ago on a branch.
[02:58] <bignose> (temporarily, to demonstrate a failure for a regression test)
[02:58] <lifeless> merge . -r x..x-1
[02:58] <bignose> would that involve some funky ‘--revision’ spec?
[02:59] <bignose> ah yes
[03:00] <bignose> hmm. the revision I'm interested in targeting is from a merge.
[03:00] <bignose> can I say ‘1658.1.1575..before:1658.1.1575’?
[03:00] <bignose> would that be equivalent?
[03:03] <lifeless> bignose: it will take the left hand side of that
[03:03] <lifeless> but yes, should do what you want
[09:39] <Lo-lan-do> Hi all :-)
[09:40] <Lo-lan-do> I'd like to gently poke jelmer (or anyone) about #628973…
[09:40] <jelmer> bug 628973 ?
[09:40] <Lo-lan-do> Nah, the other 628973, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628973
[09:40] <jelmer> :)
[09:42] <jelmer> Lo-lan-do, there is a weird bug in subvertpy/libapr that's preventing uploads of bzr-svn at the moment
[09:42] <jelmer> launchpad bug 803353
[09:43] <Lo-lan-do> Ah.  Okay.  I'll mark the packages as on hold in my aptitude, then.
[09:43] <Lo-lan-do> Thanks for the info.
[09:44]  * jelmer comments o nthe debian bug
[09:44] <maxb> 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] <jelmer> maxb: sure, happy to
[09:46] <maxb> Just checking I wasn't going to duplicate work :-)
[09:46] <maxb> Ok, I'll have something pushed by tomorrow
[09:54] <jelmer> maxb: thanks for checking. I should probably do that more too
[09:54] <jelmer> 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] <jelmer> __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] <jelmer> __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] <jelmer> __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] <jelmer> are you specifying any arguments to revert?
[10:17] <__yhvh__> no
[10:19] <jelmer> __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] <jelmer> oh, interesting - is this on a vfat fs perhaps?
[10:20] <poolie> hi all
[10:20] <jelmer> 'morning poolie
[10:20] <__yhvh__> fuseblk
[10:22] <jelmer> __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] <poolie> hi all
[13:23] <brad_> does bazaar have anything like hg update null?
[13:26] <LeoNerd> 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] <brad_> 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] <LeoNerd> Oh.. Hmm..
[13:28] <LeoNerd> Well, you can blow away the checkout, and leave only the branch. Is that what you're after/
[13:28] <brad_> sort of
[13:28] <brad_> but I want an easy way to get it to the state from any other state
[13:28] <brad_> so in mercurial, it is just hg update null
[13:29] <LeoNerd> I believe it's  bzr zap
[13:29] <LeoNerd> To remove the checkout
[13:29] <brad_> let me try that
[13:29] <fullermd> remove-tree
[13:30] <brad_> that worked
[13:30] <brad_> remove-tree
[13:30] <brad_> what do I do to get the tree back, since update doesn't seem to be working
[13:30] <LeoNerd> bzr checkout
[13:30] <fullermd> checkout
[13:30] <brad_> thanks
[13:30] <brad_> I see the help mentions that
[13:30] <brad_> my bad
[13:30] <brad_> very nice
[13:31] <brad_> ok, that seems to be essentially what I was looking for
[13:31] <brad_> does bzr have plugins out of the box for doing a clone of a subversion repository?
[13:31] <maxb> Most definitely
[13:31] <LeoNerd> Depends what "box" you mean :)
[13:31] <brad_> hehehe
[13:31] <brad_> well, from the official release on the website
[13:32] <LeoNerd> There's bzr-svn which is available in Debian/Ubuntu/.. probably others.. I don't think it's corecore though...
[13:32] <brad_> mercurial at least has a convert plugin included that does a convert, but it isn't exactly a clone
[13:32] <LeoNerd> 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] <LeoNerd> Depends what you're wanting
[13:32] <brad_> yeah, I want to clone it, and be able to pull down changes, push changes back up
[13:33] <brad_> basically, have bzr act like a svn client
[13:33] <brad_> I was able to do that in mercurial with hgsubversion
[13:33] <brad_> but it seems a bit buggy
[13:33] <brad_> 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] <LeoNerd> So, your question still seems a bit mixed. These are two different use-cases...
[13:35] <LeoNerd> 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] <brad_> well, 1 I think it what I want primarily
[13:36] <brad_> I don't need bzr to work from an svn checkout
[13:37] <LeoNerd> Ahrighty. Yes; that's the common use-case.. but I just wanted to clear up the question to be sure :)
[13:37] <brad_> 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] <brad_> so I just need the bzr-svn plugin?
[13:45] <LeoNerd> Should do, yup
[13:45] <LeoNerd> Admittedly a year since I last used it, but that's how it worked when I did
[13:45] <LeoNerd> maxb: How is that going, by the way? Are your bzr-related evangelisms getting anywhere?
[13:46] <maxb> Hah, at MX you mean?
[13:46] <maxb> Mainly stalled on lack of a true need for a DVCS given current development practices
[13:49] <poolie> hi maxb, lenerd
[13:49] <poolie> *leonerd
[13:51] <LeoNerd> Ahyes..
[14:04] <thumper> poolie: if I use set_append_revisions_only(true) on a remote branch (i.e. LP) will it do the right thing?
[14:05] <poolie> it should
[14:05] <thumper> cool
[14:46] <Red15> How does one remove all traces of a branch inside a shared repo ?
[14:46] <Red15> i'm having difficulty (those who were here yesterday might recall)
[14:46] <Red15> commiting, because the commit is quite large and bzr is souping up all the memory available in the server
[14:47] <Red15> finally the kernel kicks in and kills the process
[14:48] <jelmer> Red15, the easiest way is to create a new repository and clone all branches you do not want to remove into that
[14:48] <Red15> ouch ...
[14:48] <Red15> sounds like quite the hassle
[14:49] <Red15> do shared-repositories complain when you move then around or do they not care for their parent directory ?
[15:01] <briandealwis> 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] <Red15> ok, that's what i figured thanks for confirming briandealwis
[15:01] <Red15> am noticing shared-repos are quite bad for bzr memory usage
[15:03] <briandealwis> Red15: how so?  A standalone branch has a repo too — it's just not shared (bar lightweight checkouts)
[15:03] <Red15> i was maintaining a big-shared-repo for our company
[15:03] <Red15> but the hosted server has ~1gb of ram
[15:04] <Red15> the total dirsize of the shared repo is ~1gb
[15:04] <Red15> when committing the bzr smart server process uses all the memory in the server causing kernel-oom-measures to fire
[15:05] <briandealwis> Red15: I wonder if you're hitting a repacking threshold.
[15:05] <Red15> briandealwis, how can i tell?
[15:05] <briandealwis> I've just hit one myself with one branch, and it's painful
[15:05] <briandealwis> Red15: look at the logs
[15:06] <Red15> this was on server side : http://paste.ubuntu.com/635054/
[15:07] <briandealwis> You'll need to look before that.  Mine has sometime like "648.407  Auto-packing repository GCRepositoryPackCollection(CHKInventoryReposito
[15:07] <briandealwis> ry('file:///Users/bsd/Manumitting/Projects/e4/.bzr/repository/')), which has 28
[15:07] <briandealwis> pack files, containing 28102 revisions. Packing 21 files into 1 affecting 21102"
[15:07] <briandealwis> Red15: but it sounds like you could really benefit from adding some more RAM to your server
[15:07] <Red15> this one is today : http://paste.ubuntu.com/635806/
[15:08] <briandealwis> But that didn't fail, right?
[15:08] <Red15> actually nvm that one
[15:09] <Red15> http://paste.ubuntu.com/635807/ that one failed
[15:10] <briandealwis> 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] <Red15> https://bugs.launchpad.net/bzr/+bug/184237
[15:11] <Red15> or this one : https://bugs.launchpad.net/bzr/+bug/736001
[15:29] <briandealwis> 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] <Red15> 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] <mgz> ah, jml just proposed his bug 660852 branch
[16:34] <jml> yes what?
[16:34] <jml> mgz: please play with it. Am interested in feedback.
[16:35] <jml> (also, interested in better ways to code it)
[16:36] <mgz> 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] <mgz> the general plan looked good.
[16:37] <mgz> okay, so, you have u"" literals in tests, python 3 gets sad at them.
[16:40] <jml> mgz: oops. sorry.
[16:41]  * jml really needs to tweak 'make check' to run with all local Pythons
[16:41] <mgz> also, using doctestmatches with unicode is asking for pain.
[16:41] <jml> yeah, there's a bug about that isn't there
[16:41] <mgz> there's a bug against testtools I've got a branch for, but also,
[16:41] <mgz> doctest screws us majorly on that front
[16:42] <mgz> because inside an innocently named `_indent` function, they encode to whatever the sys.stdout encoding is
[16:42] <jml> mgz: ok. I'll stick with Equals.
[16:42] <mgz> which... clearly is no good for testtools/subunit passing things cross process
[16:42] <jml> mgz: once this patch is ok, I want to resurrect your tb stack frame patch
[16:43] <jml> but I guess a bunch of other bugs ought to get fixed first.
[16:43] <mgz> yup, we need to find a near(ish) way of doing that.
[16:43] <mgz> *neat
[16:43] <jml> 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] <mgz> sticking __unittest = True at the top of all modules is ugly, but adding our own _is_relevant_tb_level would work too
[16:47] <mgz> the changes to _details_to_str look sensible to me.
[16:49] <mgz> 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.
[16:52] <jml> mgz: hmm. interesting thought re details_to_str becoming public.
[16:53] <jml> mgz: I've pushed up changes to make tests pass with Python 3
[16:56] <mgz> that all looks good. removing the underscore can probably wait till I find whether I need to delve into privates for bzr.
[17:00] <jml> 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] <jml> (I don't really know much about bzrlib.tests any more0
[17:00] <mgz> yeah, that's the traceback-1 stuff probably
[17:01] <poolie> jml, i put an example failure on the bug
[17:01] <mgz> remember spiv hacking around a test duplication issue where each test grew a new traceback every time an instance of it failed?
[17:01] <poolie> o/ mgz
[17:01] <jml> mgz: ? it says 'traceback', not 'traceback-1'
[17:01] <mgz> hm. wrong guess then.
[17:02] <spiv> mgz: yeah, I'm pretty sure I fixed that issue
[17:06] <mgz> jml: _details_to_exc_info needs changing to mkae bzrlib work
[17:07] <jml> mgz: ah, I see.
[17:08] <jml> 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] <mgz> I'm a little worried about 'reason' vs 'traceback' too, I don't quite see where that'll be handled
[17:08] <mgz> as in, skip vs error
[17:08] <jml>             except TypeError:
[17:08] <jml>                 # have to convert
[17:09] <mgz> ^it's confusing, basically, it's the compat with the unittest api
[17:09] <mgz> which deals in exc_info not details dicts
[17:11] <jml> so it catches the decorated thing not understanding the details kwarg?
[17:11] <mgz> yup.
[17:12] <jml> and what about this bit:
[17:12] <jml>                 # extract the reason if it's available
[17:12] <jml>                 try:
[17:12] <jml>                     reason = ''.join(details['reason'].iter_text())
[17:12] <jml>                 except KeyError:
[17:12] <jml>                     reason = _details_to_str(details)
[17:12] <jml> I mean, I don't see how that squares with your reason vs traceback worries.
[17:12] <mgz> ah, that's me answering my own question
[17:12] <jml> :)
[17:13] <mgz> hey, spiv and poolie were both awake... aus has migrated to the northern hemisphere?
[17:15] <jml> mgz: Canonical hack-a-thon in Dublin.
[17:16] <mgz> aha.
[17:54] <poolie> thanks for looking at the subunit unicode bug
[18:00] <jamdahl> Hi, I'm having a problem with directories when using bzr through the command line
[18:01] <jamdahl> I run the command \
[18:01] <jamdahl> bzr init "C:\Users\jamdahl\Documents\New folder (2)\"
[18:02] <jamdahl> and it says the directory does not exist
[18:03] <mgz> jamdahl: what does `mkdir "C:\Users\jamdahl\Documents\New folder (2)\"` say?
[18:04] <jamdahl> it says it already exits
[18:05] <jamdahl> Ah, I found the problem, it's the \ at the end
[18:06] <mgz> okay, then try removing th...
[18:06] <mgz> you got there first :)
[18:06] <mgz> file a bug.
[18:08] <mgz> your command line was wrong, and bzr does tell you how, but could be clearer
[18:14] <jml> mgz: can you please take a look at https://code.launchpad.net/~jml/testtools/doctest-unicode-safety-672056/+merge/66500
[18:19] <mgz> jml: that's not enough unfortunately.
[18:19] <jml> mgz: oh?
[18:19] <MadGirl> well, oh is that all?
[18:20] <mgz> is DocTestMatches designed to take arbitrary objects and stringify them though?
[18:20] <jml> mgz: it does make the test pass :)
[18:20] <mgz> jml: printing the output also gets messed up
[18:20] <mgz> 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] <jml> mgz: ok, thanks.
[18:27] <mgz> jml: see lp:~gz/testtools/unicode_doctestmatches_764170
[18:27] <jml> mgz: thanks.
[18:28] <mgz> there are... all kinds of annoying interactions here with different python versions
[18:28] <jml> mgz: yeah.
[18:28] <mgz> I'm not sure the bug you duped against was the same thing either, will look at when I get back.
[18:29] <jml> mgz: I'm wondering whether it's acceptable to just mangle output
[18:29] <jml> mgz: as the least of all evils.
[18:29] <mgz> yeah, that sometimes happens currently, and it's better than breaking entirely (which that branch does currently on 2.6)
[18:30] <mgz> okay, I'm gone.
[18:37] <Noldorin_> jelmer, hello, you around?
[18:38] <jelmer> Noldorin_, hey
[18:38] <Noldorin_> jelmer, yesterday you told me bzr supports symlinks...does it support them on windows though?
[18:38] <jelmer> Noldorin_, no, it doesn't support them on Windows (how would it?)
[18:38] <Noldorin_> well Windows does have symlinks...
[18:38] <Noldorin_> they just require admin rights to create :-S
[18:42] <Noldorin_> jelmer, guess it still doesn't support them though
[18:43] <jelmer> 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] <Noldorin_> jelmer, yes that would probably be a good idea.
[19:00] <Noldorin_> what's the easiest way to get the tag of a certain revision?
[19:14] <LarstiQ> mgz: here by chance?
[19:17] <LarstiQ> the behaviour on 803796 seems to be weird, or I'm doing something rather wrong
[20:40] <mgz> 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] <LarstiQ> mgz: "Tree is up to date at revision 0 of branch /tmp/bzr"
[20:41] <mgz> hm, that's not as useful as I thought it'd be.
[20:41] <LarstiQ> mgz: I filed bug 804037 about the weirdness I ran into
[20:42]  * LarstiQ didn't dig very deep 
[20:42] <LarstiQ> so could be wildly off, but I'm suspecting a null: vs None conversion problem
[20:42] <mgz> blast, riddell's branch isn't linked from bug 242175
[20:43] <mgz> https://code.launchpad.net/~jr/bzr/242175-empty-branch-merge/+merge/61152
[20:44] <mgz> okay, so somehow we're not hitting that error message codepath, but also not getting the old traceback
[20:47] <mgz> or do you get it when you run `bzr update` in your -r 0 branch?
[20:50] <LarstiQ> mgz: that message is `bzr update` in my -r0 branch
[20:50]  * LarstiQ doesn't get a traceback
[20:51] <mgz> okay, so that part is okay then, it's just the transfer that I agree is suprising.
[20:52] <Noldorin_> how cna i find out which revisions in a branch have tags and what they are?
[20:53] <mgz> `bzr tags`?
[20:54] <Noldorin_> mgz, oh dear, how did i miss that! thank you
[23:43] <timrc> 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] <jelmer> timrc, your branch is in a bzr format with more capabilities than the format the default development branch is in
[23:44] <timrc> jelmer, it throws an exception in Python, but is it actually problematic?
[23:44] <jelmer> 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] <jelmer> timrc: IIRC it doesn't actually push any data if it gives this error
[23:53] <timrc> jelmer, thanks for the assistance :)