[00:00] <Peng> Wait, what about plugins?
[00:00]  * Peng wanders off.
[00:04] <slangasek> lifeless: there you are then
[00:06] <jelmer> spiv: Hmm, that's an interesting bug
[00:07] <jelmer> slangasek: I can't think of a reason a by-value joined tree wouldn't work
[00:07] <spiv> jelmer: something weird also happened when there were revisions
[00:07] <spiv> jelmer: it pushed ok, but the merge to trunk caused some sort of property conflict
[00:07] <jelmer> spiv: That's the bit I mean
[00:07] <jelmer> spiv: bzr svn-push can't use a clean "svn cp"
[00:09] <spiv> jelmer: hmm, why not?
[00:09] <jelmer> spiv: if there is a branch A with tip revision 42 and you're trying to push a branch B that also has tip 42 it has to do a copy of r41 -> /B that replays the changes in r42
[00:09] <jelmer> otherwise the two branches actually have a different revision history
[00:10] <jelmer> A has tip 42 and B has tip 42+1 where rev 1 is en empty commit that changes the branch nick from A to B
[00:11] <ubotu> New bug: #203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376
[00:12] <jelmer> slangasek: thanks
[00:12] <jelmer> spiv: ^
[00:12] <spiv> jelmer: hmm, because you can't easily figure out that the tip 42 in B happens to be the same as 42 elsewhere in the repo?
[00:13] <jelmer> spiv: I can figure that out, but the problem is that B has more revisions than A
[00:14] <jelmer> the commit that contains the "svn cp" will show up as well
[00:14] <spiv> Ah, the impedence mismatch, because making a branch in bzr doesn't make a revision.
[00:14] <spiv> But in svn it does.
[00:15] <spiv> I think I see.
[00:15] <jelmer> yep, that's a clearer way of explaining it
[00:15] <lifeless> so a cp that makes no alterations should not generate a revision in the mappings
[00:15] <lifeless> :)
[00:16] <jelmer> lifeless: yep, but there are performance considerations there
[00:21] <radix> hay guise
[00:21] <radix> sry for bzr-svn bgz
[00:31] <spiv> jelmer: I think I'll recommend people like the Twisted guys should just keep using "svn cp" for the initial branch in the repo.
[00:35] <ubotu> New bug: #203381 in bzr-svn "Error when pushing 0.4.8 to a branch that exists in svn." [Undecided,New] https://launchpad.net/bugs/203381
[00:38] <lifeless> jelmer: btw, your versionedfile thunks in bzr-svn will need updating soon :)
[00:40] <jelmer> spiv: Makes sense
[00:41] <jelmer> spiv: We could potentially add a create-svn-branch command
[00:41] <jelmer> lifeless: Which thunks? :-)
[00:41] <spiv> jelmer: yeah, I was thinking about that.  I'm not sure if I like the idea or not :)
[01:11] <lifeless> jelmer: do you not have an implementation of repo.text_store.get_weave ?
[01:16] <mxpxpod> I'm trying to convert a git repo to a bzr repo and I'm running into the same problems described here: https://bugs.launchpad.net/bzr-git/+bug/181811
[01:16] <ubotu> Launchpad bug 181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New]
[01:16] <mxpxpod> the problem is that when I do the last instruction, it tells me that my converted directory isn't a branch
[01:25] <lifeless> mxpxpod: I suggest you look into bzr fast-import
[01:28] <mxpxpod> lifeless: hrmmm... the git in gutsy doesn't provide git-fast-export :(
[01:29] <poolie> wow i had no idea of http://www.python.org/dev/peps/pep-0292/
[01:29] <poolie> least of all that it was in 2.4
[01:34] <jelmer> lifeless: nope, don't need it
[01:34] <jelmer> lifeless: the only place where versionedfile is used is in the fetch code
[01:39] <lifeless> jelmer: and annotate
[01:39] <lifeless> jelmer: and repository stacking
[01:39] <LeoNerd> Random thoughts.... a 'TODO counter' plugin... Keep a track of how many 'TODO' comments I still have in checked-in code
[01:39] <LeoNerd> Plus maybe a daily email of "Here's some things left to do:" with a few lines of context
[01:43] <jamesh> poolie: people never expect to find new functionality in the string module :)
[01:51] <jelmer> lifeless: repository stacking isn't supported yet
[01:51] <jelmer> lifeless: nor is annotate on remote svn files
[01:57] <lifeless> jelmer: so, to stack we'll need this
[01:58] <lifeless> yay internode, you go
[01:58] <lifeless> jelmer: so, to stack we'll need this
[01:59] <mxpxpod> lifeless: thanks for the tip... I just compiled git from hardy for gutsy and the fast-import worked flawlessly
[02:00] <jelmer> lifeless: the main reason I haven't bothered to look at it yet is because performance on directories will suck badly
[02:00] <lifeless> jelmer: I don't think that that is a good reason not to do it ;)
[02:01] <lifeless> hmm bzrtools complaining
[02:01] <jelmer> lifeless: well, in either case it's probably better to wait until the new vf api lands :-)
[02:01] <lifeless> time to edit off the version check again
[02:08] <jml> jelmer: should I be running released bzr-svn or trunk bzr-svn?
[02:09] <jml> LeoNerd: I've thought about that.
[02:10] <jml> LeoNerd: To do it right, that plugin would need to be language-aware.
[02:14] <jml> poolie: finally heading to yours.
[02:15] <jelmer> jml: Depends on what version of bzr you'r eusing :-)
[02:16] <jelmer> jml: 1.2 -> released bzr-svn, bzr.dev -> bzr-svn's bzr branch
[02:42] <lifeless> jelmer: btw, why would directories be slow ?
[02:50] <jelmer> lifeless: there's no way to get all the interesting revisions for a directory
[02:50] <jelmer> it is possible for a file
[02:50] <lifeless> dir copies are not explicit ?
[02:51] <jelmer> lifeless: they are, but there is no call in the svn smart server protocol to retrieve the interesting revisions for a particular dir
[02:55] <lifeless> garh
[02:56] <lifeless> about a page of deprecation warnings to go
[03:23] <jml> ugh. bzr shelve uses __methods
[03:47] <kgoetz> how can i unlock a repo? i had a commit message window open and my ssh link died
[03:47] <poolie> kgoetz: bzr break-lock URL
[03:48] <kgoetz> poolie: i get a reply of "bzr: ERROR: The lock for '/home/kgoetz/public_html/dansitev01' is in use and cannot be broken."
[03:52] <poolie> hm
[03:53] <poolie> is there still a bzr process running on that machine by any chance?
[03:53] <kgoetz> let me check
[03:54] <kgoetz> yes there is. theres a `bzr ci` running still
[03:56] <kgoetz> poolie: thanks for pointing that out - killed the process and the break-lock worked
[03:56] <poolie> you're welcome
[04:45] <igc> night all
[04:56] <lifeless> igc: night
[04:57] <lifeless> igc: you jetlagged ?
[05:45] <poolie> and i shold be here
[05:58] <poolie> lifeless: symbol_versioning patch sent
[05:59] <lifeless> thanks
[06:11] <lifeless> poolie: k, I'm done for the day; this is I think the hardest of the apis to adjust, because of the ghost implications, and its nearly done.
[06:11] <lifeless> poolie: couple of failing tests still
[06:52] <lifeless> jml: whats wuhi ?
[06:53] <jml> lifeless: We Haven't Used It
[06:53] <jml> I could *swear* I've read it in some agile manifesto before.
[06:59] <lifeless> ah
[07:02] <TFKyle> hmm, wouldn't that be whui?
[07:22] <jml> TFKyle: yes. there was a typo somewhere along the way.
[07:27] <lifeless> I object to that, I'm not a typo. I'm a hoomarn bean
[07:32] <i386> lifeless: have you seen this? http://code.google.com/p/python-safethread/
[07:37] <bob2> "base (single-threaded) throughput is only around 60-65% that of normal CPython"
[07:52] <lifeless> i386: no, I haven't
[11:56] <bob2> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ermurri/vc-bzr/emacs22.1/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[11:57] <luks> you can't push over http
[11:57] <bob2> that was a pull
[11:57] <luks> no idea then
[11:57] <james_w> bob2: are you running the latest version?
[11:58] <bob2> 3295
[12:02] <bob2> ah, it was a heavy weight checkout
[12:04] <james_w> ah, ok.
[12:56] <siretart> does anyone know if a new bzrtools release is scheduled to appear 'soon'?
[13:06] <james_w> hi siretart
[13:06] <james_w> I haven't heard.
[13:06] <james_w> Aaron is normally pretty prompt
[13:12] <siretart> hi james_w
[13:12] <siretart> I've now built a debian package for myself based on what's currently in bzrtools.dev
[13:13] <siretart> however the testsuite (not run during package build) fails
[13:13] <siretart> I've considered uploading it to debian to get bzrtools and bzr-builddeb installable again
[13:18] <dky> i heard as part of emacs discussions, some performance improvements have been proposed or checked in?
[13:19] <dky> I am interested in testing for performance, could someone give me extra information how to test bzr for performance
[13:28] <bob2> 'bzr --profile command whatever' might be of use
[14:35] <mbt> Is there some trick to being able to use bzr normally on an NFSv4 mounted home directory?
[14:40] <james_w> mbt: what do you mean normally?
[14:41] <mbt> Without errors... Nearly everything I do is accompanied by an "bzr: ERROR: [Errno 5] Input/output error" when using it on an NFSv4-mounted home, but when on the local filesystem, I do not get this error.
[14:41] <mbt> For example, I get that error when I bzr diff
[14:41] <mbt> or bzr status
[14:42] <james_w> mbt: the error traceback would be useful to see.
[14:42] <mbt> james_w: Is there a way to make it generate one?
[14:42] <mbt> It just shows the Errno 5 message.
[14:42] <james_w> mbt: bzr -Derror diff
[14:43] <mbt> james_w: http://pastebin.com/d1561bfcd
[14:46] <james_w> mbt: ok, so it's having some problems removing the lock.
[14:48] <mbt> Should I go ahead and file a bug, then?  I would presume that it is supposed to work on an NFS-mounted home, right, or is that outside of what bzr is expected to do?
[14:54] <james_w> mbt: is https://bugs.launchpad.net/bzr/+bug/137387 it?
[14:54] <ubotu> Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged]
[14:56] <igc> morning
[14:56] <james_w> hi igc
[14:56] <mbt> james_w: It might be, but I am not sure.
[14:57] <mbt> james_w: Let me see if I can coax bzr into giving me more details
[14:57] <igc> hi james_w
[14:59] <james_w> igc: fast-import broke for me. I haven't had time to debug it yet.
[14:59] <igc> james_w: just send me the traceback
[14:59] <igc> I added tag support last night
[15:00] <igc> well, lightweight tags at least
[15:00] <igc> might be that?
[15:00] <mbt> Is there a way to generate a log file as is shown in that bug report, james_w?  I can't seem to find it.
[15:00] <james_w> igc: no, it was before that.
[15:00] <james_w> mbt: ~/.bzr.log
[15:01] <james_w> igc: it's bzr-fast-export | bzr fast-import on bzr.dev
[15:01] <bratsche> Is it possible with bzr to work with multiple branches out of one directory and switch between them, similar to git?
[15:01] <igc> james_w: ok, I'll try that. How far though was it previously?
[15:02] <bratsche> Or actually, I should just state what my problem is first and see if there is any better way to do what I'm doing in bzr:
[15:02] <james_w> igc: it did all bzr-fast-export could export.
[15:02] <james_w> igc: let me upload the dump for you.
[15:03] <bratsche> We have a pretty large codebase in bzr at work now, and each time I make a branch it takes a long time to branch the remote mainline to a local directory because it's pulling down all the source.
[15:03] <igc> bratsche: are you using a shared repository locally?
[15:04] <igc> it's highly recommended to do that
[15:04] <bratsche> No, the shared repo is on the server.
[15:04] <bratsche> Let me search for how to do a shared repo locally.
[15:04] <igc> bratsche: you definitely want a shared repo locally as well
[15:04] <mbt> it looks like that might be the bug... though the workaround in it does not work, and I still get problems... sigh
[15:04] <james_w> bratsche: a shared repository is just a way of sharing data between branches so you can do it anywhere.
[15:04] <igc> it's covered in the User Guide
[15:05] <bratsche> igc: Right now I do: bzr branch <remote-mainline> <remote-branch-url> ; bzr checkout <remote-branch-url>
[15:05] <james_w> bratsche: ouch
[15:05] <bratsche> igc, james_w: Awesome, thanks very much!  I'll search for how to set that up.
[15:05] <james_w> are remote-mainline and remote-branch-url sharing a shared repo?
[15:05] <bratsche> james_w: Yes.
[15:06] <james_w> igc: http://jameswestby.net/scratch/bzr-export.txt
[15:06] <james_w> though it is about 20MB, so you may prefer to just generate it locally.
[15:06] <igc> james_w: I'll generate it locally
[15:07] <igc> It's just bzr-fast-export.py bzr.dev, right?
[15:07] <james_w> yep.
[15:08] <Odd_Bloke> Afternoon.
[15:09] <bratsche> So I want to do like: bzr init-repo my-local-repo ; cd my-local-repo ; bzr branch <remote-mainline> ; bzr checkout <remote-mainline>
[15:09] <bratsche> To setup my local shared repo?
[15:09] <mbt> http://pastebin.com/d2f120d12 -- james_w, should I add that info to bug 137387?
[15:09] <ubotu> Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] https://launchpad.net/bugs/137387
[15:09] <bratsche> And then when I create new branches, I would branch from the local repo?
[15:10] <james_w> hi Odd_Bloke
[15:11] <Odd_Bloke> bratsche: You only need to do one of branch or checkout there.
[15:11] <luks> bratsche: repositories are just an optimalization, you can ignore them and just use the workflow you had before
[15:11] <james_w> mbt: yeah probably
[15:11] <luks> but with a repo it won't download everything
[15:11] <james_w> mbt: if you could debug why these errors occur that would be great.
[15:11] <luks> because you already have the revisions
[15:12] <bratsche> So I create my repo, and just checkout <remote-mainline>?
[15:12] <Odd_Bloke> james_w: o/
[15:12] <Odd_Bloke> bratsche: Within the repo, yeah.
[15:13] <bratsche> Odd_Bloke: What about when someone else at work posts a branch on the server, and I want to switch over to view it?
[15:14] <luks> bratsche: switch the existing checkout?
[15:14] <luks> if so, 'bzr switch <other-remote-branch>'
[15:14] <bratsche> Okay, thanks.
[15:14] <Odd_Bloke> bratsche: Or you can checkout that branch into a different directory in the repository.
[15:14] <bratsche> I'd better go read some more about repos rather than ask all of this here.
[15:14] <bratsche> Sweet.
[15:15] <bratsche> Thanks everyone.
[15:16] <james_w> bratsche: there is also "bzr help repositories" that explains a little bit
[15:17] <mbt> james_w: I would love to help debug it, but I am not sure where I would even start on it.  I know next to nothing about file locking and filesystems.  All I really know at this point is that bzr on local reiserfs works perfectly, on nfsv4, it doesn't.
[15:20] <mb1> arrgh.
[15:21] <mbt> Was my last msg about reiserfs/nfs/etc received?
[15:21] <james_w> yeo
[15:22] <james_w> well I'm not sure if it's a locking problem in terms of flock() etc., or just the way that we are creating lockdirs
[15:22] <mbt> k wasn't sure if that actually got out before my client crashed lol
[15:22] <james_w> I don't know the lock code at all though I'm afriad.
[15:23] <mbt> Well, I can try to poke around it at some point this evening, but I have to finish setting up my network, because it's been restructured (which is actually how I found this issue lol).
[15:25] <spiv> jelmer: when is the 0.4.8 release? :)
[15:38] <awilkins> jelmer: Should be able to have another crack at building that binding on Friday
[15:38] <awilkins> jelmer: A bit busy until then.
[15:39] <jelmer> spiv: I'm trying to get it done before 1.3
[15:39] <jelmer> spiv: I hope to get the pyrex stuff in before then
[15:56] <ubotu> New bug: #203598 in bzr "Bzr should remember all locations and provide nicknames" [Undecided,New] https://launchpad.net/bugs/203598
[15:57] <spiv> jelmer: ah, ok.
[15:59] <spiv> jelmer: personally I'd probably release 0.4.8 without pyrex, and if you happen to make a 0.4.9 (or even 0.5.0...) with pyrex a week later, then that's fine.
[15:59] <spiv> jelmer: but I do sympathise with wanting to minimise churn
[16:08] <spiv> jelmer: would you like other people to test your pyrex branch, btw?
[16:14] <jelmer> spiv: well, there is one bug which still needs fixing
[16:14] <jelmer> spiv: do you have any pyrex experience?
[16:15] <spiv> jelmer: a little bit
[16:16] <jelmer> spiv: I'm trying to get pyrex to not return NULL from a cdef function when an exception is being raised
[16:16] <hsn_> can someone please tell me again command for changing branch into lightweight checkout?
[16:17] <james_w> hsn_: I think reconfigure can do it
[16:18] <jelmer> spiv: that's the main bit that's preventing the pyrex branch from working
[16:19] <hsn_> james_w: yes, thats right
[16:30] <ubotu> New bug: #203607 in bzr "bzr unable to upgrade pack-0.92 to rich-root-pack format" [Undecided,New] https://launchpad.net/bugs/203607
[16:34]  * lamont has a stupid-bzr question..
[16:34] <lamont> hrm..
[16:34] <lamont> nm
[16:36] <awilkins> The stupid-bzr plugin isn't compatible with the current bzr version I'm afraid
[17:30] <jam_> hmm.. that was a very long question
[17:30] <jam_> I seem to have missed it completely :)
[17:31] <dennda> Hey
[17:31] <dennda> I am just trying to branch a remote svn repository (over https)
[17:32] <dennda> bzr-svn is installed
[17:32] <dennda> this is the result: http://paste.pocoo.org/show/34207/
[17:35] <Odd_Bloke> jelmer: ^^^
[17:38] <james_w> dennda: can you try bzr branch svn+https://svn.example.com/myrepo
[17:49] <lifeless> moin
[17:49] <dennda> james_w: thanks, that works
[17:49] <dennda> james_w: but how to tell bzr how to push to that location?
[17:50] <dennda> nevermind
[17:50] <dennda> just figured it out
[17:50] <dennda> thanks
[18:03] <jelmer> dennda: see the FAQ
[18:04] <jelmer> dennda: never mind, I was reading backlog
[18:11] <ubotu> New bug: #203643 in bzr "'bzr status' crashes with MemoryError" [Undecided,New] https://launchpad.net/bugs/203643
[18:41] <lopio> hi
[18:42] <lopio> i'd like to propose bazaar instead of cvs but there are 2 question about it.Could you help me ?
[18:42] <james_w> sure
[18:44] <lopio> 1) it seems impossible to retag single files (example i need to create a package with old files labelled AAA and i want to add 2 files in HEAD)
[18:45] <james_w> lopio: sorry, I don't understand the question, could you explain it a little more please?
[18:45] <lopio> in CVS i'll extract old label AAA and i'll force a retag AAA on the 2 files
[18:45] <lopio> ok
[18:45] <luks> lopio: no, bzr doesn't have per-file tags
[18:46] <luks> (or per-file revisions, like cvs)
[18:47] <luks> in bzr you would normally branch of the tag AAA and then merge the changes to those 2 files from HEAD
[18:48] <lopio> i see luks but in this case i'll have a new branch forever
[18:49] <luks> is that a problem?
[18:50] <lopio> it is a problem when you have a schema with central repository....
[18:50] <james_w> lopio: if you want the old versions of two files then you can use revert to get them, and then commit to include them in your current HEAD
[18:50] <luks> well, tag in bzr applies to the whole tree
[18:51] <luks> so if you don't have such tree in your branch, you need to create it
[18:51] <lopio> ok
[18:51] <lopio> this is not a blocking problem -)
[18:51] <lopio> Now a real problem -(
[18:52] <luks> but generally you would have this problem with any VCS that isn't CVS
[18:52] <luks> I don't know of any other VCS that works on file basis
[18:52] <lopio> CVS is old but is able to manage CRLF
[18:53] <lopio> and this is a real problem for us
[18:53] <abentley> siretart: I'll try to have it out this evening.
[18:53] <lopio> we have a central CVS repository and we are able to co and commit in XP and HP both
[18:54] <lopio> this is because in CVS you have to specify -kb parameter when you add an exe file
[18:55] <lopio> in this way when you checkout under  XP a CR is added to files different from exe (and removed during commit)
[18:56] <james_w> lopio: we want to add support for line endings, but it is not done yet.
[18:57] <lopio> this is a strong limitation i think -((((((((((
[19:00] <lopio> It seems a marvellous versioning system so i hope some people could add this feature as soon as possible
[19:01] <lopio> keep up the good work!!! Thank you very much...see you later..bye
[19:05] <igc> james_w: fyi - fast-import is better now wrt renaming handling
[19:06] <igc> a bug still exists though
[19:06] <igc> it now gets a lot further on your bzr.dev export but not all the way through
[19:07] <igc> I'm moving onto some other stuff now so it might be a day or so before I get back to this
[20:01] <mamato_> anyone know of tool to completely remove files from my bzr history?
[20:02] <james_w> mamato_: no such tool exists yet I'm afraid.
[20:04] <mamato_> weird...
[20:07] <mwhudson> bzr strongly discourages rewriting history
[20:11] <mamato_> hmm... should have maybe sticked to rcs then :S
[20:12] <mwhudson> you might be able to use rebase, especially if the file hasn't changed much over history
[20:12]  * mamato_ strongly encourages cleaning up one's crap when needed
[20:13] <mwhudson> i guess we could have an argument about that
[20:13] <mwhudson> but i can't really be bothered
[20:17] <nevans> mamato_: the only compelling use-case I can see for changing history in a good VCS is when "sensitive" data has accidentally gotten into the repo
[20:17] <nevans> e.g. passwords
[20:23] <mamato_> i need versioning for personal code... i'm the only user... for the first project i used it, i realized that i had accidentally checked in tons of images which dont need versionning... couldn't back up my branch to the internet like i wanted... had to loose all my change history weeks after... if a 'good VCS' doesn't allow it, maybe that's not what i need...
[20:25] <mamato_> all i want is a 'useful vcs' that corresponds to my needs...
[20:25] <nDuff> mamato_, fastexport + edit + fastimport?
[20:25] <nDuff> mamato_, that's not entirely unlike the SVN methodology of dumping to XML to edit history.
[20:27] <james_w> nDuff: I expect there will be a tool to filter a fast-export stream at some point.
[20:27] <nevans> okay... wanting to trim disk usage in a personal-use only project... that's another compelling use-case.  ;-)
[20:28] <nevans> (I don't deal with personal-use projects much... except for /etc and ~/ )
[20:29]  * mamato_ can't find fastexport info on google :S
[20:30]  * mamato_ found fastimport!
[20:30] <nDuff> mamato_, https://lists.ubuntu.com/archives/bazaar/2008q1/038391.html
[20:31] <nDuff> mamato_, ...not saying that's the most current location.
[20:31] <nevans> it looks like git already has a tool for filtering fast-export streams: http://www.kernel.org/pub/software/scm/git-core/docs/git-filter-branch.html
[20:33] <nDuff> nevans, looks to me like you'd need to actually import the stream into a git repository to use that. Which, granted, wouldn't be the end of the world.
[20:35] <mamato_> nevans: thx for the info...
[20:38] <mamato_> i hear git is quite nice too... will look into it more closely... except for this, have had good experience with bzr though :(
[20:51] <mamato_> how do you .bzrignore some sub-directories?
[20:51] <spiv> mamato_: have you seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#ignoring-files ?
[20:52] <mamato_> yep
[20:52] <mamato_> but didn't find info
[20:55] <mamato_> spiv? it only deals with ignoring files... not directories... and specifying directory doesn't seem to work
[20:57] <spiv> mamato_: hmm, I'd expect ingoring a directory to work
[20:58] <spiv> mamato_: it seems to work as I'd expect for me: http://rafb.net/p/nyFWyY31.html
[21:01] <spiv> mamato_: perhaps you've already added the file?  "bzr ignore" won't ignore a file that's already versioned.
[21:01] <NfNitLoop> I regularly ignore directories.
[21:01] <spiv> mamato_: so you may need to use "bzr rm --keep" on those files.
[21:01] <mwhudson> damn, i wish i had a spare time machine so i could work on bzr's graph operations
[21:01]  * spiv -> afk
[21:04] <mamato_> weird... your test case works but doesnt work with my branch... and not already versioned... going back to figuring it out...
[21:05] <mamato_> ah... parent dir (whihc i want to ignore) IS versionned... makes sense...
[21:27] <spiv> jelmer: I think for the exceptions returning NULL issue you want "cdef int spam() except -1:" (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/basics.html#ExceptionValues)
[22:07] <ubotu> New bug: #198092 in bzr "Should tell the user to run bzr launchpad-login before push lp:" [High,Triaged] https://launchpad.net/bugs/198092
[22:07] <jelmer> spiv: that doesn't work, since an SVN error is a pointer
[22:08] <jelmer> spiv: pyrex only supports "except NULL" but NULL in this case actually is the only return value that means there's no error
[22:13] <AfC> jelmer: got a sec
[22:14] <AfC> ?
[22:17] <james_w> hi AfC
[22:20]  * AfC waves
[22:39] <lifeless> jelmer: don't try to use the same function for two different protocols then :)
[22:40] <lifeless> jelmer: the one directly exposed to python _must_ use the python conventions - return NULL -> there is an error set
[22:40] <lifeless> jelmer: you probably need to wrap the svn_ra functions with ones that invert the return code to do what you need
[22:41] <jelmer> AfC: hi
[22:41] <jelmer> lifeless: hi
[22:42] <jelmer> I already have one level of indirection - I register a pyrex callback that can calls a python function
[22:43] <AfC> jelmer: I know we almost talked about this the other day, but I was wondering if you have any [further] specific insight into whether or not two different people with different Subversion account names could use a bzr-svn branch once created?
[22:44] <AfC> jelmer: ie, it took me the better part of 9 days to create a bzr-svn branch of GTK. I'd like to share that with someone else to save that being (through no fault of bzr-svn's) someone's first impression of Bazaar
[22:44] <lifeless> AfC: you can share that just fine
[22:45] <lifeless> AfC: the svn account name is not part of the created bzr branch
[22:45] <AfC> but obviouly they have a different [ssh] account to talk to GNOME's Subversion repository, so if I either a) publish the resultant Bazaar branch, or b) tarball the branch + repository
[22:45] <AfC> and pass it to someone, whether or not it would work
[22:45] <jelmer> AfC: Yes, two people with the same name could share a bzr-svn branch
[22:45] <AfC> jelmer: different usernames
[22:46] <jelmer> AfC: yes, no problemo
[22:46] <AfC> jelmer: ah. AWESOME
[22:46] <AfC> Then I shall get us hosting a series of such branches as a community service.
[22:47] <poolie> good morning
[22:47] <AfC> jelmer: so I assume all that will have to happen is that when it comes time for them to commit and push back to the upstream Subversion repo is to do
[22:48] <AfC> jelmer: bzr push --remember svn+ssh://their_user_name@svn.gnome.org/svn/gtk+/trunk
[22:48] <AfC> jelmer: and they'll be all set
[22:48] <jelmer> AfC: yep
[22:48] <AfC> Beautiful
[22:48] <jelmer> AfC: Hopefully shallow branches can help avoid the long time it takes to get an initial branch
[22:48] <jelmer> lifeless: What's the status on shallow branches?
[22:48] <AfC> It was interesting to hear Carl report his experience that:
[22:49] <AfC> "The *moment* I see a Subversion URL from someone, even before I think I might want to hack on it, I just feed it to git-svn and let it run on a server, because I know it'll take forever, but eventually it'll be done and I'll have a branch to use from Git if I want to"
[22:50] <AfC> (And they do then share those around, which also gave me the idea of seeing if we could too. Awesome)
[22:50] <jelmer> AfC: 9 days seems like a lot of time, btw
[22:50] <hsn_> what kind of storage is more resistent to corruption? packs or knits and what kind of storage has better recovery tools?
[22:50] <jelmer> I also have a gtk+ trunk import here, and afaik it took less than a day
[22:51] <AfC> (well, I had intermittent network access and a not-svn-HEAD to deal with)
[22:51] <lifeless> hsn_: packs
[22:51] <lifeless> jelmer: they work but not with the smart server
[22:52] <lifeless> jelmer: I'm fixing the root issue preventing them working with the smart server at the moment
[22:52] <awilkins> Go-go shallow branches!
[22:53] <awilkins> Also go go pyrex bindings
[22:53] <jelmer> lifeless: ah, cool
[22:58] <lifeless> jelmer: which is the versionedfiles rework
[22:58] <lifeless> jelmer: because you need to be able to stack on historical data
[22:59] <lifeless> poolie: status for me -> versionedfiles at full steam
[23:00] <poolie> toot toot!
[23:00] <poolie> enjoy
[23:08] <jml> I just tried to branch a Subversion branch into a pack repo and got this: bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/Pimlico/jana/.bzr/repository/') is not compatible with repository SvnRepository('http://svn.o-hand.com/repos/jana')
[23:08] <jml> I'm using bzr-svn trunk and Bazaar 1.2
[23:09] <awilkins> jml: You need rich-root-pack
[23:10] <jml> awilkins: that in 1.2?
[23:10] <awilkins> jml: Was in .092 AFAIK
[23:10] <awilkins> 0.92
[23:11]  * jml tries
[23:12] <jml> OK. Now I'm getting SubversionException: ("PROPFIND request failed on '/repos/jana/branches/jana'", 175002). This is odd, because I can check it out just fine with the svn client
[23:13] <awilkins> jml: Is it a password protected repo?
[23:13] <jml> awilkins: no.
[23:13] <jml> awilkins: or, at least, it's not protected for reading.
[23:13] <awilkins> Are you using a release or the tip of a branch (of bzr-svn)
[23:14] <jml> awilkins: tip of http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/
[23:15] <awilkins> I've never used that..... try the 0.4.8 branch
[23:16] <awilkins> I presume you've installed patched bindings, etc?
[23:17] <jml> I'm fairly sure I have.
[23:18] <jml> maybe I'll try the packaged version.
[23:18] <jelmer> bzr-svn will give you a warning if you're not using the patched bindings
[23:38] <jml> jelmer: so, any ideas?
[23:38] <lifeless> jml: whats a jana?
[23:39] <jelmer> jml: have you tried the 0.4.8 branch?
[23:39] <jml> jelmer: no, I'll have a look at that.
[23:39] <jml> lifeless: it's apparently a japanese word. the project is the openedhand guys' new calendar thingummy
[23:40]  * awilkins thinks of Jana of the Jungle
[23:55] <lifeless> fingers crossed, step 1 may be done. whew.
[23:59] <poolie> lifeless: call me sometime today, at your convenience