[00:10] <dhon_> hi all, I've got files in d:\project\subdir under version control and I'd like to add files in d:\project. I'd say I need to change the root bzr directory to d:\project - how do I do that & preserve the history in subdir?
[00:12] <dhon_> I guess I could just move the .bzr directory and then "bzr move --after" all the original files into subdir?
[00:12] <dhon_> thoughts?
[00:15] <Peng> You could probably do this with rich roots.
[00:17] <dhon_> what are rich roots?
[00:19] <Peng> The / directory entry of the branch is versioned. I'm pretty sure it's possible to move it.
[00:22] <dhon_> Peng: so I could convert the repo to rich roots format and then move the root somehow?
[00:23] <Peng> dhon_: Maybe.
[00:24] <Peng> I dunno.
[00:24] <Peng> I just tried it and it tracebacked.
[00:30] <dhon_> Peng: what commands did you use?
[00:31] <Peng> dhon_: "bzr mv . foo". Traceback. :)
[00:32] <Peng> I'm pretty sure rich root formats should be able to support that; perhaps bzr doesn't yet though.
[00:39] <jelmer> Peng: I doubt that will ever work - it doesn't even work for a regular mv
[00:39] <Peng> Ok.
[00:39] <Peng> Shucks.
[00:40] <jelmer> Peng: Although the error message should obviously be more sensible
[00:40] <jelmer> Peng: what exactly are you trying to do?
[00:41] <Peng> I was seeing if it was possible to move the root.
[00:42] <jelmer> Peng: it is certainly possible to change the root - see the split command
[00:50] <dhon_> jelmer: I was trying to move the root from d:\project\subdir to d:\project
[00:50] <dhon_> so I could add files at that level
[00:51] <dhon_> I want the files in subdir to stay there (and to keep their history)
[00:54] <dhon_> on another note: is it possible to "branch" or "copy" a single file in a repo into two separate files?
[00:54] <dhon_> eg 1.txt to 1a.txt & 1b.txt?
[01:07] <jelmer> dhon_: "bzr join" should be able to do that
[01:08] <jelmer> dhon_: (moving the root from d:\project\subdir to d:\project)
[01:08] <jelmer> dhon_: There's no way to split a file at the moment
[01:38] <dhon_> jelmer: thanks - help shows join as still experimental as of 1.2 so I think I'll stay clear for the moment
[07:24] <Peng> jelmer: Is it just me, or did you define CachingParentsProvider twice?
[08:22] <Odd_Bloke> jelmer: Congrats on the release!
[09:56] <aantn> hello
[09:56] <aantn> does bzr uncommit actually revert your files
[09:57] <bob2> no
[09:57] <aantn> I'm trying to change the revision log and bzr uncommit seems to be the only way to do so
[09:57] <bob2> (the point of uncommit is to not revert the files)
[09:57] <aantn> bob2: what does the --dry-run flag do?
[10:03] <bob2> just show you what it would do (which is not all that useful for 'uncommit')
[13:36] <fbond> Hi, I'm seeing "authorization failed" trying to push to an svn repository.  svn has already cached my credentials.  What am I missing?
[13:37] <jelmer> fbond: have you prefixed the URL with svn+ ?
[13:37] <fbond> Oh, hmm...
[13:37] <fbond> Yes.
[13:37] <fbond> Pushing to svn+http://...
[13:37] <jelmer> what os are you on? The caching trick doesn't work on Windows or Mac OS X
[13:37] <fbond> Oh, maybe...
[13:37] <fbond> I'm on LInux
[13:38] <fbond> But I'm pushing to the trunk URL, should I instead be pushing to the repository root?
[13:38] <jelmer> no, you should indeed be pushing to the trunk URL
[13:38] <fbond> Oh, okay.
[13:38] <jelmer> committing to this repository using SVN works ok, without any passwords being prompted?
[13:38] <fbond> Yep, that's right.
[13:38] <fbond> bzr: ERROR: Permission denied: ".": CHECKOUT of '/logistix/!svn/ver/183/trunk/pkg-src': authorization failed (http://svn.local.network)
[13:39] <fbond> The error is on CHECKOUT, which is interesting...
[13:41] <fbond> I'm using bzr-svn 0.4.8, bzr 1.2
[13:42] <fbond> jelmer: I'm using a bzr branch, not an svn wc.  That's normal, right?
[13:42] <fbond> jelmer: i.e. I made the branch with `bzr branch ...'; is this even relevant?
[13:43] <jelmer> fbond: yeah, that all sounds fine
[13:44] <jelmer> fbond: what version of svn are you using?
[13:44] <fbond> On my workstation: version 1.4.4 (r25188)
[13:45] <fbond> On the server: version 1.3.2 (r19776)
[13:45] <fbond> jelmer: Do you need mod_svn version info?
[13:45] <jelmer> Odd_Bloke: thanks :-)
[13:46] <jelmer> Peng: Whoops, fixing..
[13:48] <jelmer> fbond: Sorry, no idea
[13:49] <jelmer> fbond: and you were able to create a bzr branch of the svn branch earlier without problems, or does that not require authorization?
[13:55] <fbond> jelmer: only write access requires auth.
[13:56] <fbond> jelmer: I'll try making the branch again, I think I made it with an earlier version of bzr/bzr-svn...
[13:56] <jelmer> fbond: that shouldn't be relevant
[13:56] <fbond> jelmer: Hmm.  Is there any way to turn on debug logging so I can see what's going on?
[13:57] <jelmer> fbond: running bzr with -Dtransport will print to ~/.bzr.log what it is trying to do
[13:59] <fbond> jelmer: thanks!
[13:59] <jelmer> fbond: there is no way to debug the authentication step though - that all happens deep down inside the subversion libraries
[14:05] <rexbron> andrea-bs: bzr builddeb does not use LP as it's bugtracker, do you have a link to the upstream one?
[14:07] <andrea-bs> rexbron: the exception was raised by bzr itself, so you should file a bug against bzr
[14:07] <rexbron> andrea-bs: kk
[14:07] <jelmer> andrea-bs: afiak it just uses the debian bugtracker
[14:08] <andrea-bs> jelmer: thanks
[14:14] <rexbron> andrea-bs: https://bugs.edge.launchpad.net/bzr/+bug/206013
[14:14] <ubotu> Launchpad bug 206013 in bzr "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New]
[14:14] <andrea-bs> thanks rexbron
[14:15] <rexbron> I would still like to file a bug against bzr-builddeb for the uncommited changes problem
[14:15] <rexbron> does anyone have a link to their tracker?
[14:16] <james_w> rexbron: bugs.launchpad.net/bzr-builddeb
[14:16] <rexbron> james_w: I was intending to file it against the upstream code base
[14:17] <james_w> rexbron: I'll move the existing bug over, thanks.
[14:17] <rexbron> ok will post a link soon
[14:19] <james_w> rexbron: ah, I never enabled launchpad bugs for it, I'll move it to the Ubuntu package for now.
[14:20] <james_w> rexbron: please don't use pastebin for tracebacks on bug reports, as they expire.
[14:20] <rexbron> I will not in future, I just looked at the scroll back from an earlier conversation
[14:22] <andrea-bs> rexbron: mh... strange... I'm not able to reproduce the situation
[14:23] <rexbron> andrea-bs: Could be a pecurilarity of the branch
[14:23] <andrea-bs> rexbron: could you give me the exact command you used, please?
[14:24] <rexbron> andrea-bs: just to remind you, this is from a script not from the commandline
[14:24] <andrea-bs> rexbron: oh, right
[14:24] <rexbron> I am making this call:
[14:24] <rexbron> builddeb.run(branch=self.debianLocalLocation, result='./build-area', orig_dir='./', builder='dpkg-buildpackage ' + self.debuildOptions, merge = True)
[14:24] <fbond> jelmer: got my issue resolved; svn was acting *very* oddly...
[14:25] <fbond> jelmer: it seems that it cached auth info that worked for me, but wasn't my user, or something similar.
[14:25] <fbond> I minimized the server-side config to allow just me, and it asked for a new password.
[14:25] <fbond> Dunno
[14:25] <fbond> Fixed now, anyway.
[14:27] <rexbron> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/206021
[14:27] <ubotu> Launchpad bug 206021 in bzr-builddeb "builddeb should raise a python exception when the .run() method is called and there are uncommited changes to the working tree" [Undecided,New]
[14:29] <rexbron> andrea-bs: as for the first bug I reported, it could have something to do with the watch file not existing
[14:30] <andrea-bs> rexbron: does "debian.bleedingedge/.bzr" exist?
[14:30] <ubotu> New bug: #206013 in bzr-builddeb "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New] https://launchpad.net/bugs/206013
[14:31] <rexbron> andrea-bs: yes, otherwise bd would not work if the orig-dir is set correctly
[14:32] <fbond> jelmer: I probably would have seen the issue right away in ~/.subversion/auth/svn.simple; everything is in plain text in a file whose name looks like a hash.
[14:32] <fbond> jelmer: may want to suggest that if anyone else asks.
[14:33] <fbond> jelmer: also, this is an interesting passage from the svn book:
[14:33] <fbond> http://svnbook.red-bean.com/en/1.4/svn.serverconfig.pathbasedauthz.html; Partial Readability and Checkouts
[14:33] <fbond> jelmer: thanks again
[14:40] <andrea-bs> rexbron: sorry, I can't reproduce it: I get every time a IOError (No such file or directory)  :(
[14:42] <rexbron> andrea-bs: try and pull this branch https://code.edge.launchpad.net/~ubuntu-bleedingedge/blender/debian.bleedingedge
[14:43] <andrea-bs> rexbron: done
[14:43] <rexbron> still the same error?
[14:43] <andrea-bs> rexbron: there's no "blender-svn.py" file
[14:44] <rexbron> andrea-bs: copy the bzr-bd.run() method I posted (replacing the varriable where nessicary) and try it out
[14:47] <andrea-bs> rexbron: Could not find the upstream tarball after uscan
[14:47] <rexbron> it won't as I am creating it at run time
[14:52] <andrea-bs> rexbron: I've tried with all possible orig-dirs, they all raise a good exception to me
[14:53] <rexbron> andrea-bs: Could it be version specific?
[14:53] <andrea-bs> rexbron: probably, which version of bzr and builddeb are you using?
[14:54] <rexbron> I am running bzr 1.0 and bd 0.90
[14:54] <rexbron> Ubuntu Gutsy with backports
[14:54] <andrea-bs> oh, now I understand
[14:54] <rexbron> :)
[14:54] <andrea-bs> I'm using bzr 1.2.0.candidate.1 and builddeb 0.92.0dev0
[14:55]  * rexbron appolgises not not mentioning this sooner
[14:55] <andrea-bs> you told me you were using the 1.0 so I was thinking you were on hardy
[14:55] <andrea-bs> I mark the bug as "Fix released" so
[14:55] <rexbron> andrea-bs: wait
[14:55] <rexbron> I will try to reproduce it on hardy and if not, we can mark it as released
[14:55] <andrea-bs> rexbron: sure
[14:56] <andrea-bs> rexbron: ok, great idea
[14:58] <andrea-bs> rexbron: generally I prefer to close bugs and reopen them because sometimes the reporters forget to tell if the bug still occur, so I'm going to mark it "Incomplete": it will expire after 60 days
[14:58] <rexbron> ok
[15:09] <james_w> rexbron: the raising an exception thing is completely different in newer releases.
[15:09] <james_w> rexbron: it doesn't complain at all and just builds the working tree.
[15:12] <rexbron> james_w: ok
[16:08] <c0le> hello people..
[16:08] <c0le> I have a doubt with bzr-svn ..
[16:09] <james_w> hi c0le
[16:10] <c0le> james_w: I noticed that bzr-svn is adding an entry to the bzr:revision-id:v3-trunk property of svn every time I do a commit..
[16:10] <c0le> Does this list of entries in the property keep increasing ?
[16:11] <c0le> or does it get recycled after reaching a max number of entrieS?
[16:12] <james_w> I don't know, I think it keeps increasing.
[16:12] <c0le> james_w: Ouch :-S that would look bad after a 1000 such commits..
[16:12] <dato> I think that entry contains the full revision history
[16:13] <dato> so yes, it'll increase afaik
[16:13] <james_w> c0le: are you using trac?
[16:13] <c0le> james_w: Yes, and I can see the list increasing over each commit..
[16:14] <c0le> james_w: i.e., trac shows it in the changeset..
[16:14] <james_w> c0le: I think there's a way to turn of the display of them.
[16:15] <c0le> james_w: Aw.. something like 'ignore property'?
[16:16] <james_w> c0le: I've no idea what the option is, I just think I remember someone mentioning such a thing before.
[16:16] <c0le> Hmm.. I wonder how git-svn does this tracking..
[16:16] <c0le> james_w: ok.. i'll google on that..
[16:16] <james_w> it doesn't
[16:17] <c0le> james_w: ah, ok..
[17:08]  * lamont tries again to understand how to break from bzr's belief that he wants a directory-per-branch and create a single working tree with multiple branches in it that he can switch between
[17:10] <luks> lamont: bzr init-repo --no-trees foo; bzr init foo/branchA; bzr co --lighweight foo/branchA workingtree
[17:10] <luks> then you can have as many treeless branches under foo as you want
[17:10] <luks> and switch the working tree with bzr switch
[17:11] <jelmer> c0le: git-svn doesn't do tracking as far as I know
[17:11] <jelmer> c0le: bzr-svn 0.5 will hopefully support storing that sort of metadata in revision properties rather than file properties
[17:13]  * lamont wonders "what sort of tracking"?
[17:15] <jelmer> lamont: All bzr-specific metadata
[17:15] <lamont> ah, ok
[17:15] <jelmer> lamont: so it is possible to push a bzr branch into svn and then create that exact same branch again from the data pushed into svn
[17:20] <james_w> jelmer: isn't it that git doesn't need to, as its model doesn't create a parallel imports problem?
[17:20] <james_w> lamont: cbranch from bzrtools may also help with that workflow.
[17:20] <luks> james_w: it still stores more metadata than svn can
[17:21] <dato> like full author name
[17:21] <luks> author name, author date, etc.
[17:21] <dato> or timezone
[17:21] <jelmer> james_w: it reduces the need for full round-tripping support
[17:22] <james_w> ah, ok.
[17:57] <MikeJJ> hi, i'm trying to install Bazaar on windows following the quick install guide (the python one), but i get stumped here . . .
[17:58] <MikeJJ> "Bzr Tools and Bazaar GUI needs to be compiled. Use same procedure as for compiling Paramiko."  i fail at finding how to compile Paramiko :P
[17:58] <MikeJJ> any advice ? :)
[17:58] <luks> python setup.py install?
[17:59] <MikeJJ> lol, that simple ?  thanks :D
[17:59] <luks> I don't really know, just guessing
[18:00] <MikeJJ> well, looks like that did it.  thanks again :)
[18:52] <thekorn> hi, I've got another bzrlib question: what is the easiest way of getting the 'kind' of an unknown file in a workingtree?
[18:53] <james_w> thekorn: osutils.file_kind is what you want I think
[18:53] <arnetheduck> jelmer, another question for you - should this be reported as a bug?: "Using saved location: https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk
[18:53] <arnetheduck> bzr-svn is not up to date with installed bzr version 1.3.
[18:53] <arnetheduck> There should be a newer version of bzr-svn available.
[18:53] <arnetheduck> bzr: ERROR: Transport operation not possible: http does not support mkdir()
[18:53] <arnetheduck> "
[18:54] <james_w> arnetheduck: are you doing push?
[18:54] <arnetheduck> jelmer, when pushing a new directory to svn...
[18:54] <arnetheduck> james_w, yes
[18:54] <james_w> can you try "bzr push svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
[18:57] <arnetheduck> james_w, I think it may be working since the command is taking a lot longer now =)
[18:58] <arnetheduck> (it's a big commit and sf isn't the fastest site on the net
[18:58] <james_w> arnetheduck: if it works do "bzr push --remember svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
[18:58] <thekorn> james_w, oh, i'm too much focused on bzrlib that I don't see the obvious
[18:59] <james_w> thekorn: no problem
[18:59] <arnetheduck> james_w, that's what I did actually =)
[19:00] <james_w> arnetheduck: great, your faster than me :-)
[19:01] <abentley> james_w: I would use Tree.kind, unless trying to get the kind of unversioned files.
[19:02] <jelmer> arnetheduck: to push new branches, use "bzr svn-push"
[19:02] <arnetheduck> jelmer, it wasn't a new branch, just a new dir in an existing branch...
[19:03] <james_w> thekorn: you said "unknown" you meant "unversioned" rather than "arbitrary" didn't you?
[19:03] <arnetheduck> jelmer, btw, should I worry about the 1.3 warning?
[19:03] <jelmer> arnetheduck: how do you mean?
[19:03] <arnetheduck> "bzr-svn is not up to date with installed bzr version 1.3"
[19:04] <jelmer> arnetheduck: 0.4.9 is out and supports bzr 1.3
[19:05] <thekorn> thekorn, well, I think i'm a bit confused: I would like to get all files which are in the 'unknown' section when I run 'bzr status'
[19:05] <thekorn> james_w, i meant
[19:05] <arnetheduck> jelmer, bugger, I checked yesterday I think and it wasn't =)
[19:05] <jelmer> arnetheduck: the warning itself isn't really worrysome but you'll find that one or two things give tracebacks
[19:05] <thekorn> james_w, and I thought I could get these files with tree.unknowns()
[19:06] <thekorn> but this does not work as expected
[19:07] <james_w> thekorn: yes, I think that's right, and in that case osutils.file_kind is the correct function to use to get the kind.
[19:07] <james_w> what do you get that you don't expect?
[19:10] <thekorn> james_w, damn I'm always mixing workingtree and revisiontree, sorry, my problem is that list(revtree.unknowns()) always returns an empty list
[19:10] <thekorn> when revtree is an revisiontree object
[19:10] <arnetheduck> jelmer, the one I reported the other day? something about some revision number being wrong?
[19:11] <james_w> thekorn: I think that's right isn't it?
[19:13] <thekorn> james_w, I don't know, have not read any documentations on this, can't revision trees have unknown files?
[19:14] <thekorn> and if so, why is there a unknowns()-method for RevisionTree-objects?
[19:15] <Peng> Hmm, one project moved its svn repo to Google Code. Does svn consider the repos different and does bzr-svn?
[19:17] <Peng> Hmmm, I think it might have changed significantly.
[19:17] <Peng> There are fewer revisions in G Code.
[19:19] <james_w> thekorn: a revisiontree is a committed state, so I think it makes sense for it to have 0 unknowns
[19:19] <james_w> as to whether the method should be implemented on it I am not too sure.
[19:20] <thekorn> james_w, yes this makes sense, thank you
[19:21] <arnetheduck> james_w, here's what I got now: bzr: ERROR: libsvn._core.SubversionException: ("MKCOL of '/svnroot/dcplusplus/!svn/wrk/0dd13b40-b1d2-4fab-9b0e-5fb8b3a13bb3/dcplusplus/trunk': 405 Method Not Allowed (https://dcplusplus.svn.sourceforge.net)", 175002)
[19:23] <james_w> arnetheduck: I have no idea about that I'm afraid.
[19:25] <abentley> It's implemented on Tree so that we don't have to special-case other functions depending on their Tree type.
[19:34] <arnetheduck> jelmer, how about http://www.pastebin.ca/955617?
[20:08] <jelmer> arnetheduck: one sec
[20:09] <jelmer> arnetheduck: doesn't make much sense to me. I don't understand why bzr would be trying to create a directory there
[20:18] <arnetheduck> jelmer, it does make sense - svn by default first creates a working folder for the transaction, commits everything there and then moves the transaction to a new revision file...
[20:19] <arnetheduck> jelmer, could it be that the digest auth is not being sent (when using pure svn, my credentials are fetched automagically)?
[20:25] <jelmer> arnetheduck: that all happens under the hood though - the protocol doesn't include commands like that
[20:27] <jelmer> arnetheduck: does "bzr branch <repos-url>" list the branch you're trying to push to?
[20:46] <ubotu> New bug: #127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged] https://launchpad.net/bugs/127734
[20:57] <lifeless> moin
[20:58] <abentley> lifeless: moin
[20:58] <jelmer> hey lifeless, abentley
[21:04] <arnetheduck> jelmer, I've successfully committed to the svn branch before, but never with a new directory
[21:05] <jelmer> arnetheduck: you added a new directory in your bzr branch and you're now trying to push the revision that added that directory?
[21:14] <arnetheduck> jelmer, correct
[21:14] <arnetheduck> jelmer, now that I think about it, I first removed a directory and then added one with the same name
[21:15] <arnetheduck> jelmer, hm, that makes it two revisions to commit - one that removes a directory (and contents), then another that adds a directory (and contents) with the same name as the one removed
[21:16] <jelmer> arnetheduck: that shouldn't be relevant here though
[21:16] <jelmer> the mkdir call you're seeing is about creating a new branch, not about a directory in a branch
[21:17] <arnetheduck> jelmer, I'll try again, maybe it was some temporary error
[21:18] <jelmer> arnetheduck: I doubt that
[21:18] <jelmer> arnetheduck: does "bzr branch <repos-url>" list the branch you're trying to push to?
[21:18] <jelmer> arnetheduck: sorry, I mean "bzr branches <repos-url>"
[21:23] <arnetheduck> jelmer, running...
[21:31]  * Peng wonders what bzr-svn is doing.
[21:32] <Peng> Augh!
[21:33] <Peng> It took like 2 minutes to pull 1 revision!
[21:33] <jelmer> Peng: are you using 0.4.9 ?
[21:34] <Peng> jelmer: I'm using yesterday's 0.4 branch.
[21:34] <jelmer> Peng: the development branch can have major performance regressions while in flux
[21:34] <Peng> Apparently so.
[21:37] <mathrick> hiya
[21:37] <Peng> Hello.
[21:38] <mathrick> what would be the easiest / best way of serving a writeable public repo with authentication?
[21:39] <Peng> mathrick: bzr+ssh?
[21:40] <mathrick> Peng: and without ssh?
[21:40] <james_w> webdav?
[21:40] <mathrick> okay, I guess ssh is the easier way then
[21:41] <Peng> Yeah.
[21:41] <Peng> If it's a FOSS project, you could use Launchpad.
[21:41] <mathrick> it's not, not yet anyway
[21:45] <arnetheduck> jelmer, it's still stuck...
[21:46] <jelmer> arnetheduck: in the "bzr branches.." run?
[21:46] <jelmer> it took only a minute or so here..
[21:46] <arnetheduck> jelmer, here's what I tried: "bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
[21:47] <jelmer> arnetheduck: please try the repository url
[21:47] <jelmer> bzr branches
[21:47] <jelmer> svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/
[21:57] <spiv> Good morning.
[21:59] <lifeless> hi
[22:24] <mathrick> bzrserve@sei.meidokon.net's password:
[22:24] <mathrick> Server is too old for fast get_parent_map, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
[22:24] <mathrick> bzrserve@sei.meidokon.net's password:
[22:24] <mathrick> why does it have to reconnect?
[22:25] <mathrick> it makes me input the password twice
[22:25] <james_w> mathrick: because the server is too old.
[22:26] <mathrick> yeah, but why does it have to reconnect to use the older protocol?
[22:28] <spiv> mathrick: because the older protocol wasn't designed to allow graceful degradation in the case where a client sends a request with a body but the server doesn't recognise the request
[22:28] <lifeless> mathrick: because the old protocol let the server get confused about edge of messages
[22:29] <mathrick> aha, not nice of it
[22:29] <lifeless> mathrick: so there was no way to be sure when it was actually ready for new input
[22:38] <arnetheduck> jelmer,  bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/ returned nothing
[22:41] <jelmer> arnetheduck: what do you have the branching scheme set to?
[22:45] <arnetheduck> auto I think, didn't specify anything, and when importing it got my branches right so...
[22:45] <arnetheduck> jelmer, sorry, gotta go, I'll check back tomorrow...
[22:45] <jelmer> the fact "bzr branches" returns nothing suggests something may be wrong there
[22:45] <jelmer> arnetheduck: what does "bzr svn-branching-scheme <repos-url>" print?
[22:46] <ubotu> New bug: #206242 in bzr-svn "Add append-revisions-only setting for Subversion repositories" [Wishlist,Triaged] https://launchpad.net/bugs/206242
[22:58] <lifeless> spiv: looks like only us around; point 2 point call ?
[22:59] <spiv> lifeless: sure.
[23:04] <igc> morning
[23:22] <evarlast> is it possible to branch or export a subdirectory of a repository? maybe this is called NestedTreeSupport ?
[23:23] <Peng> evarlast: To turn a subdirectory of a branch into its own branch, see bzr split.
[23:24] <lifeless> evarlast: we discussed this in london
[23:24] <lifeless> you can also split as Peng says
[23:24] <lifeless> igc: hi, spiv and I just did a p2p call as we couldn't see any others :>
[23:26] <igc> hi lifeless
[23:26] <spiv> igc: FWIW, my plan for the day is email + smart impl of set_last_revision_info
[23:27] <igc> spiv: thanks
[23:27] <evarlast> thank you so much. I searched as searched and could not find split.
[23:28] <igc> spiv,lifeless: my plan for the day is ... email + reviews + package the new hook we worked on at PyCon
[23:33] <lifeless> igc: I'm working on versionedfiles
[23:37] <ubotu> New bug: #206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,New] https://launchpad.net/bugs/206258
[23:53] <sabdfl> hi folks
[23:53] <sabdfl> are 1.3 packages available in the usual ppa? i haven't seen them for hardy yet
[23:54] <sabdfl> and is there an agreement with the distro team to put 1.3 into hardy itself (not the ppa)?
[23:56] <Peng> sabdfl: The PPA takes a few days to update.
[23:56] <Peng> Hey, hg 1.0 is out. :)
[23:57] <sabdfl> thanks peng, and congrats on the 1.0
[23:58] <Peng> Not congrats to me.
[23:58] <Peng> I mean, I'm not one of their developers.
[23:58] <sabdfl> ah, thought you were
[23:58] <Peng> I'd *like* to be, if I was smart enough. :P
[23:59] <Peng> (I'd like to do more than typo fixes on bzr too. I'm not a traitor!)