[00:00] <`mousey> Does anyone know where I can obtain the Windows standalone installer for bzr 1.10?
[00:00] <Peng_> `mousey: The build machine has been having issues; there isn't one yet.
[00:00] <`mousey> ahh rightio
[00:01] <`mousey> can I just grab the zip and overwrite my existing bzr folder with it to get 1.10?
[00:01] <`mousey> *install folder
[00:13] <jelmer> wb enigma
[00:13] <jelmer> enigma, there are only a few bzr svn-* commands
[00:14] <jelmer> bzr svn-import / bzr svn-upgrade (not relevant right now) / bzr svn-branching-scheme (only for bzr-svn == 0.4) / bzr svn-set-revprops / bzr svn-layout
[00:15] <enigma> jelmer: Thanks.
[00:16] <enigma> jelmer: Suppose I branch http://remoterepo/trunk/foobar and then I tag rev 33. How do I get that tag back into SVN? (This is with 0.5)
[00:17] <enigma> I should clarify: http://remoterepo/svn/trunk/foobar
[00:20] <jelmer> enigma, there is no way to do that at the moment, in the future it will be possible to set a configuration variable with the path in which tags should be created
[00:20] <jelmer> you can hardcode that path for now, at layout/standard.py:230
[00:20] <enigma> What happens to tags right now?
[00:21] <enigma> Is the "custom" layout stuff relevant for 0.5 still?
[00:21] <jelmer> enigma, yes, the custom layout stuff is still relevant for 0.5
[00:21] <jelmer> enigma, You'll see what happens if you try the latest revision from the 0.5 branch :-)
[00:21] <enigma> Are there doc on the layout stuff (beyond the help page for layouts)?
[00:22] <enigma> jelmer: OK. Let me try...pulling...
[00:23] <jelmer> enigma, no, the svn-layout helppage is all there is
[00:23] <enigma> OK. Thanks.
[00:25] <jelmer> enigma: sorry, that should be layout/standard.py:310
[00:25] <enigma> OK.
[00:26] <enigma> So, if I check out a branch directly, I end up with a "wild card" layout?
[00:27] <enigma> So, I should check out at the "trunk" level?
[00:27] <jelmer> enigma: Ah, sorry
[00:27] <jelmer> enigma, You will end up with a WildcardLayout() if you have "branches = " configured in the bazaar configuration file
[00:27] <jelmer> enigma, you will end up with TrunkLayout() if you branch "/trunk" or "/branches/X"
[00:28] <jelmer> you will end up with CustomLayout() if you branch /trunk/foo/bar
[00:28] <jelmer> you will end up with RootLayout() if you branch "/"
[00:28] <enigma> So branching "/trunk/foo" will give me CustomLayout?
[00:28] <jelmer> only TrunkLayout() supports tags at the moment (as the path to the tags isn't known in all the other cases)
[00:28] <jelmer> enigma, correct
[00:29] <enigma> Oh, OK. I see. It's making a lot more sense now.
[00:37] <enigma> Am I the only one who gets a little mislead by the "No new revisions to push" message when pushing tags?
[00:37] <enigma> It seems like bzr should say "Push new metadata, but no new revisions"
[00:37] <enigma> Or something like that.
[00:37] <spiv> enigma: I think there's already a bug report about that
[00:37] <spiv> (not 100% sure)
[00:38] <spiv> It certainly is confusing.
[00:52] <enigma> By mandate of "central IT", we are required to stuff all our code in one subversion repository. Since we have several different project all in one repo, it seems as if the appropriate structure in svn should be: /project/(trunk|tags|branches). Does that sound right?
[00:52] <enigma> Currently we have /trunk/project, so that isn't going to play nice with bzr-svn if we want branching and tagging, right?
[00:53] <jelmer> enigma, branching is going to work ok (since you specify the branch URL each time), tagging isn't (since it has to find the tags URL on its own in that case)
[00:54] <jelmer> you can set the "tags" and "branches" configuration variables in the config to force it to find your branches and tags
[00:54] <jelmer> except that won't allow you to create new tags (yet), since I haven't hooked that up yet
[00:54] <enigma> OK.
[00:56] <enigma> jelmer: If I felt so inclined to add more detail to documentation, what would be a good way to give that back?
[00:57] <jelmer> enigma, yeah, definitely
[00:57] <enigma> How do I send the changes back?
[00:58] <jelmer> just "bzr send" should sent back your local commits to me :-)
[00:58] <enigma> OK. :-)
[01:16] <jelmer> Peng, interesting bug you hit there :-) Seems to be caused by svk replacing a directory by a copy of itself (without changes)
[01:47] <enigma> jelmer: Suppose I have "trunk/foobar" in svn and I want to make a branch "branches/foobar-2.0", should I just use "svn copy" to make the branch?
[01:47] <enigma> Or is there a way to make that branch with bzr-svn?
[01:47] <jelmer> enigma, you can just "bzr svn-push" to the new location
[01:47] <jelmer> enigma, but "svn cp" will also work
[01:48] <enigma> OK. Let me try the svn-push.
[01:48] <jelmer> Peng_, still there?
[01:50] <jelmer> lifeless, ping
[01:50] <enigma> jelmer: Wow! bzr-push worked beautifully!
[01:50] <RyanPrior> Can anybody point me to a document explaining bzr's advantages as compared to git, mercurial, perforce, and similar software?
[01:50] <jelmer> :-)
[01:51] <enigma> RyanPrior: This chat room is one of the advantages! ;-)
[01:51] <jelmer> RyanPrior, there are various BzrVsX pages on the wiki
[01:51] <jelmer> RyanPrior, http://bazaar-vcs.org/BzrVsGit / http://bazaar-vcs.org/BzrVsHg / ...
[01:51] <enigma> RyanPrior: Try to get a hold of the authors of Perforce on irc. ;-)
[02:11] <RyanPrior> Thanks for those links, they are informative.
[02:26] <AfC> Hm. Maybe someone in Canonical's marketing department should give http://bazaar-vcs.org/Benchmarks some love, seeing as how the most recent thing cited there is bzr version 1.1dev
[02:29]  * mwhudson needs his "bzr oh-crap-ive-been-editing-in-trunk" plugin again
[02:30] <mwhudson> extra bonus points if it can somehow convince emacs to reload all its buffers from the branch it should create...
[02:33] <thumper> mw:)
[02:33] <thumper> mwhudson: :)
[02:51] <Peng_> jelmer: pingpong
[02:54] <Peng_> jelmer: (that was really just a pong, not a ping)
[02:58] <jelmer> Peng_, Any chance you can unsubscribe from lp:~bzr-svn/bzr-svn/trunk ?
[02:58] <jelmer> lp won't let me remove it otherwise
[03:00] <spiv> jelmer: rename it from "trunk" to "please-unsubscribe-kthxbye"? ;)
[03:00] <jelmer> spiv, well, peng is the only subscriber, this seemed easier :-)
[03:13] <Peng_> Heh.
[03:14] <Peng_> jelmer: lp:~jelmer/bzr-svn/trunk? Done.
[03:14] <Peng_> You're deleting it? Poor branch.
[03:15] <jelmer> Peng_, thanks
[03:15] <jelmer> yeah, people seem to end up using it while it is not actively developed
[03:15] <jelmer> I'll just readd it when I work on it again
[03:16] <Peng_> Ah.
[03:17] <Peng_> It had a bunch of associated bugs, and a merge proposal.
[03:27] <igc> hi all
[03:29] <Peng_> Good morning.
[03:31] <lifeless> jelmer: having something called trunk not be the active branch is ... weird.
[03:32] <jelmer> lifeless, perhaps; that's why it's gone now
[05:48] <spiv> poolie: I just sent you some insert_record_stream RPC perf numbers.  Fairly basic at this stage, but it should be easier to get more numbers as the code gets less quirky.
[05:53] <poolie> thanks
[06:20] <poolie> spiv, can you please measure something for an incremental push too?
[06:22] <spiv> poolie: sure, just a moment.
[06:25] <spiv> poolie: pushing bzr.dev onto bzr.dev -r-100: 74 hpss calls (bzr.dev), 39 (streaming-push)
[06:27] <spiv> poolie: (and 20.9s/6.5s wall/user time vs. 24.4s/5.2s)
[06:32] <spiv> poolie: pushing one rev onto bzr.dev: 47 hpss calls vs. 24.
[06:33] <spiv> (And there's 3 easy to remove calls in that 24, I think)
[06:37] <poolie> so the wall time got worse?
[06:43] <spiv> poolie: yes, although the need for topological sorting is a likely culprit there.  There's possibly also some extra time due to the server doing more thinking now.
[06:44] <lifeless> shouldn't need topo sorting
[06:44] <spiv> poolie: oh, and tee'ing the stream in case a fallback is needed hurts a fair bit too.
[06:44] <lifeless> bah, I'm on leave.  Honest.  But dig up the mail I wrote about this some months back; topo sort is /one/ parameter in the api
[06:44] <spiv> lifeless: it's not needed in principle, it is with the current implementation :)
[06:45] <spiv> lifeless: which calls down to insert_record_stream([one_record]) many times on the server.
[06:45] <spiv> lifeless: that's certainly fixable, but getting things working comes before making them fast :)
[06:50] <spiv> lifeless: also, enjoy your leave!
[06:54] <poolie> is it just me or does the bzr-gtk test suite require the user to click the right buttons to make things pass?
[06:54] <poolie> spiv, anyhow, thankyou, that's helpful
[06:55] <spiv> poolie: great.
[07:07] <vila> hi all
[07:08] <vila> poolie: what bzr-gtk version are you using ? A bug was fixed long ago about that
[07:08] <vila> poolie: could be a new one though..
[07:10] <poolie> hello vila
[07:10] <poolie> it might be quite old...
[07:11] <vila> poolie: Just checked: I'm up to date and 'bzr selftest -s bp.gtk' runs flawlessly
[07:12] <spiv> I see that our test suite seems to import plugins even with --no-plugins atm.
[07:16]  * spiv sends off a quick patch about that.
[07:16] <spiv> Ok, that's me done for the day.
[07:23] <poolie> night spivvo
[08:19] <rkistner> is it at all possible to do something like single-file branching in bzr?
[08:20] <bob2> not really
[08:20] <bob2> you could branch and delete all but one file
[08:20] <rkistner> i'm developing a CMS website and want to use bzr for version control of the content
[08:21] <rkistner> so now if a user wants to edit content, i want to branch that content
[08:21] <rkistner> and merge it back in when the user is done editing
[08:21] <rkistner> but if i have a lot of users and content, it will get impractical to branch all the content for every user
[08:23] <rkistner> so actually, i just want to do a lightweight checkout of a single file
[08:23] <rkistner> might it be possible with "manual" api calls?
[08:24] <poolie> rkistner: yes, have a look at a MemoryTree or PreviewTree
[08:26] <rkistner> poolie: thanks, will have a look
[08:45] <rkistner> are there any documentation on MemoryTree and PreviewTree, apart from the API?
[09:34] <poolie> rkistner: maybe in doc/developer?
[09:36] <rkistner> actually, i couldn't even find the api documentation for previewtree so far
[09:39] <poolie> http://starship.python.net/crew/mwh/bzrlibapi/
[09:40] <poolie> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.memorytree.MemoryTree.html
[09:40] <poolie> is probably what you want
[09:40] <rkistner> ok
[09:41] <poolie> but what you're going to do will be a bit atypical
[09:41] <poolie> so it might be better to write about wherever you get up to to the mailing list
[09:42] <rkistner> ok
[13:34] <rocky> jelmer: i really think you should undeprecate "svn+http(s)" ;)
[13:34] <jelmer> rocky, why/
[13:34] <jelmer> ?
[13:36] <BUGabundo_work> hi
[13:36] <BUGabundo_work> what does "No handlers could be found for logger "bzr" " mean?
[13:38] <\sh> guys, what is the right way of updating bzr imported svn branches from svn repo?
[13:38] <\sh> forget the question.../me needs to clean glasses
[13:39] <Peng_> BUGabundo_work: Are you using bzrlib or running "bzr"?
[13:40] <BUGabundo_work> bzr Peng_
[13:40] <BUGabundo_work> brz commit .
[13:40] <BUGabundo_work> local repo of files
[13:40] <BUGabundo_work> stand alone
[13:40] <jelmer> \sh, :-)
[13:40] <Peng_> BUGabundo_work: 1.) It's not really a big deal; it's just a warning, 2.) It means the debug log isn't working for some reason.
[13:41] <\sh> jelmer: svn-upgrade is too obvious ;)
[13:41] <Peng_> BUGabundo_work: Run "bzr version" to see where it's located. Maybe you don't have write permissions?
[13:41] <BUGabundo_work> but really nasty when used with autocomplete TAB TAB
[13:41] <jelmer> \sh: not sure I follow, svn-upgrade should only be necessary if you used to use bzr-svn 0.3.x which is over a year old by now
[13:42] <BUGabundo_work> I see a few exceptions there
[13:42] <\sh> jelmer: then I'm lost ;) /me wants to do something like "svn update" on bzr imported svn branches :)
[13:42] <jelmer> \sh, Just do whatever you would do on a regular bzr branch :-)
[13:42] <jelmer> \sh, just "bzr pull <svn-location>" should work
[13:43] <jelmer> or "bzr update" if it's a checkout
[13:43] <\sh> jelmer: bzr pull? oh xmas is near :)
[13:43] <BUGabundo_work> Peng_ can you take a look please
[13:43] <BUGabundo_work> http://paste.ubuntu.com/86261
[13:45] <Peng_> BUGabundo_work: Haha. That issue was fixed in 1.10.
[13:45] <BUGabundo_work> I'm on jaunty
[13:45] <BUGabundo_work> I have 1.9-1
[13:45] <BUGabundo_work> should I test a PPA?
[13:45] <Peng_> You could.
[13:45] <BUGabundo_work> is there a bug I can track=?
[13:46] <Peng_> BUGabundo_work: For what?
[13:46] <BUGabundo_work> for this version error?
[13:46] <Peng_> BUGabundo_work: No, a bug was never filed about it.
[13:46] <BUGabundo_work> I'll file it when I come back
[13:46] <Peng_> Jaunty runs an alpha version of Python?
[13:46] <BUGabundo_work> I have no idea!
[13:46] <Peng_> BUGabundo_work: Like I said, the "bzr version" bug was fixed in 1.10.
[13:47] <BUGabundo_work> http://paste.ubuntu.com/86263/
[13:47] <BUGabundo_work> and http://paste.ubuntu.com/86264/
[13:47] <BUGabundo_work> brb
[13:49] <Peng_> BUGabundo_work: You can use the PPA to upgrade to bzr 1.10 if you want to, but it's not necessary. https://launchpad.net/~bzr/+archive
[13:49] <Peng_> BUGabundo_work: I only wanted you to run "bzr version" to find out the location of .bzr.log, but it's probably ~/.bzr.log.
[13:50] <Peng_> Wait, Jaunty? It doesn't look like there is a PPA build for Jaunty in the first place.
[13:50] <Peng_> Eh.
[14:10] <\sh> jelmer: any clue how to resolve this? or what would be a trigger for this? bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/')
[14:10] <jelmer> \sh, that's actually masking any real errors
[14:11] <jelmer> can you pastebin the full backtrace?
[14:11] <\sh> jelmer: there is no one
[14:11] <jelmer> \sh, when does this happen?
[14:12] <knighthawk> can anyone point me to docs on how to use nautilus-bzr?
[14:12] <knighthawk> I have it installed but don't see how to use it.
[14:12] <\sh> jelmer: after svn-import --all --incremental <zend-framework svn repo>
[14:12] <jelmer> knighthawk, it should just start showing small icons for your bzr managed files in nautilus
[14:12] <\sh> jelmer: he was in the stage of creating the revisions (I could do that again ;))
[14:12] <BUGabundo_work1> Peng_: back
[14:13] <jelmer> \sh, are you running 0.4.16?
[14:13] <\sh> jelmer: 0.4.13 from intrepid
[14:14] <knighthawk> jelmer yeah that's what I figured but it doesn't seem to be doing that.
[14:14] <jelmer> knighthawk, do you have python-nautilus installed?
[14:14] <rocky> jelmer: you have any idea about http://cluebin.appspot.com/pasted/4002 and http://cluebin.appspot.com/pasted/3611 ? that's with bzr 1.10 and bzr-svn-0.5 branch as of a few days ago (and just updated and confirmed it's still happening)
[14:15] <jelmer> \sh, It may be fixed in a newer version, or at least give a better error.
[14:16] <jelmer> rocky, the first is a bzr-svn bug that's been fixed in the 0.5 branch
[14:16] <\sh> jelmer: trying 0.4.16
[14:16] <knighthawk> jelmer, rpm -q python-nautilus
[14:16] <knighthawk> package python-nautilus is not installed
[14:16] <knighthawk> I'll see about that.
[14:16] <knighthawk> jelmer, doesn't seem to be a package name.
[14:17] <jelmer> knighthawk, I don't know what it's named on RPM-based systems, and whether it's packaged at all there, sorry.
[14:18] <knighthawk> jelmer, well that gives me a place to start thanks.
[14:21] <Peng_> Oops, now I was awya.
[14:21] <Peng_> away*
[14:21] <rocky> jelmer: both those msgs come from the same error, and i am running the latest code and get the same error (even if those pastes are a couple days old)
[14:21] <jelmer> rocky, you're running r2270 ?
[14:22] <rocky> jelmer: yep
[14:23] <rocky> jelmer: a more recent paste (definitely from r2270) is cluebin.appspot.com/pasted/4006
[14:23] <rocky> jelmer: and you can try it as well as the svn repo is publically available i believe
[14:25]  * jelmer gives it a try
[14:26] <rocky> jelmer: if that url doesn't work for you, just try the non-https version, i definitely know it's available to anonymous users
[14:26] <jelmer> it works without svn+ even :-)
[14:26] <rocky> jelmer: it never works properly for me without svn+ because pycurl barfs
[14:26] <rocky> jelmer: but regardless... did the branch/checkout work for you?
[14:27] <jelmer> still running
[14:27] <rocky> kk
[14:27] <rocky> for me it gets really far before it bails
[14:27] <Peng_> jelmer: If you changed bzr-svn's version_info from (0, 5, 0, 'rc', 1) to (0, 5, 0, 'candidate', 1), bzrlib._format_version_tuple() wouldn't barf on it anymore.
[14:27] <Peng_> Hmm.
[14:28] <BUGabundo_work1> Peng_: bug #308578
[14:28] <BUGabundo_work1> I filled it
[14:29] <Peng_> BUGabundo_work1: Yeah, it was definitely fixed in 1.10.
[14:30] <BUGabundo_work1> humm can you mark it in progress? or fix available?
[14:30] <BUGabundo_work1> where can I get the patch?
[14:30] <BUGabundo_work1> bzr repo?
[14:31] <Peng_> BUGabundo_work1: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3849
[14:33] <BUGabundo_work1> so bzr branch lp:bzr should do it for me?
[14:33] <Peng_> BUGabundo_work1: Well, yes.
[14:33]  * BUGabundo_work1 admits to be very new to this
[14:34] <Peng_> BUGabundo_work1: You could also get 1.10 off the website. Or you could just patch your 1.9 installation.
[14:34]  * BUGabundo_work1 wants to learn
[14:36] <BUGabundo> Peng_: $ cd /tmp/;bzr branch lp:bzr;
[14:36] <BUGabundo> Disconnecting: Corrupted MAC on input. bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[14:36] <rocky> jelmer: i have to take off for some errands but feel rest assured that i will ping you on the issue a little later :)
[14:38] <BUGabundo> Peng_: https://launchpad.net/~bzr/+archive already has 1.10, but no version for Jaunty... kinda strange..
[14:38] <Peng_> BUGabundo: Now _that_ I don't know. Is it really worth all this effort for the "bzr version" bug? :P
[14:39] <BUGabundo_work1> its just to fix that stupid warning ...  LOL
[14:39] <BUGabundo_work1> but I can wait.
[14:39] <Peng_> BUGabundo_work1: The logging thing isn't related to hte "bzr version" thing.
[14:40] <BUGabundo> I'll test deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu jaunty main  and see if both are fixed
[14:42] <Peng_> Hmm, why *does* "bzr version" traceback when plugins have a bad version_info anyway? The plugin code works around that (e.g., "bzr plugins" works).
[14:44] <BUGabundo_work1> no idea!
[14:44] <BUGabundo_work1> I'm just a simple user
[14:44] <BUGabundo_work1> who gets anoyed every day, when doing regular commits
[14:45] <Peng_> BUGabundo_work1: Does ~/.bzr.log exist?
[14:45]  * BUGabundo_work1 checking
[14:45] <BUGabundo_work1> yes
[14:45] <BUGabundo_work1> and is owned by root
[14:46] <BUGabundo_work1> can it be the origen of the prob?
[14:46] <Peng_> BUGabundo_work1: Probably.
[14:46] <BUGabundo_work1> maybe I did a commit with the wrong user?
[14:46] <Peng_> BUGabundo_work1: Try renaming/deleting/chowning it.
[14:46] <BUGabundo_work1> I have several repos
[14:46] <BUGabundo_work1> one for /etc
[14:46] <BUGabundo_work1> that is done with sudo
[14:47] <BUGabundo> sudo chown bugabundo:bugabundo .bzr -R
[14:47] <BUGabundo> ahhhhhhhhhh
[14:47] <BUGabundo> that works...
[14:47] <Peng_> Ohnoes, clones.
[14:47] <BUGabundo> no more warning
[14:47] <BUGabundo> eheh
[14:47] <BUGabundo> laptop with ubuntu
[14:48] <BUGabundo_work1> Office PC here
[14:48] <BUGabundo> but I still get the brz version trace
[14:48] <BUGabundo> upgrading bzr now
[14:49] <BUGabundo> it now works fine too
[14:49] <Peng_> :D
[14:49] <BUGabundo> Bazaar (bzr) 1.10rc1
[14:49] <Peng_> If you install bzr from source, you should compile the C extensions.
[14:49] <BUGabundo_work1> humm?
[14:50] <BUGabundo_work1> too complicated for me LOL
[14:50] <BUGabundo_work1> brb
[14:50] <BUGabundo_work1> thanks Peng_
[14:50] <Peng_> BUGabundo: 1.10 final is out too.
[14:50] <BUGabundo_work1> its what the PPA sent me
[14:53] <Peng_> Ah.
[15:47] <Stavros> hello
[15:47] <Stavros> i am trying to checkout a repo that has a symlink, but i'm on windows so it fails
[15:47] <Stavros> what can i do, apart from get a normal OS?
[15:51] <Stavros> symlinks? anyone?
[15:53] <Peng_> Stavros: There's a symlink plugin.
[15:56] <Stavros> Peng: ah, thanks
[16:25] <pthulin> if I've made a commit to a local branch that I havn't yet pushed anywhere, is there some way to change the commit message after hand? Thanks =)
[16:26] <LeoNerd> Only by uncommit/recommit
[16:27] <pthulin> aha, thanks LeoNerd
[16:29] <rocky> jelmer: any progress on the issue i mentioned earlier? :)  did you at least reproduce it ?
[16:30] <nDuff> I know there's been discussion in the past of support for plugins adding content-aware merge algorithms; has anyone implemented such a thing as of yet?
[16:31] <jelmer> rocky, Yes, I can confirm it's still there
[16:31] <jelmer> haven't found out what's causing it yet; hopefully later tonight
[16:31] <jelmer> nDuff, Not that I've seen
[16:32] <jelmer> nDuff, I think Odd_Bloke was working on it
[16:32] <Odd_Bloke> Nominally, yes.
[16:32] <Odd_Bloke> In reality, I haven't started.
[16:32] <Odd_Bloke> But I think you can already plug your own merge algorithms in.
[16:33] <Odd_Bloke> And so you could do some content-checking in there.
[16:33] <Odd_Bloke> But I don't really know any more than that.
[16:41] <garyvdm> If I've got a bound branch, (a checkout), is there a way to get it to use the parent/push locations?
[16:41] <garyvdm> parent/push locations of the branch it is bound to?
[16:49] <\sh> jelmer: I'm trying latest bzr + latest bzr-svn...same error no traceback...but when restarting the same import, he has less revisions to copy...
[16:49] <jelmer> \sh, that's correct, some revisions have already been copied in that case
[16:49] <jelmer> Odd_Bloke, ah, thanks
[16:49] <jelmer> \sh, can you comment out that exception and see what exception it is masking?
[16:49] <enigma1> I'm cloning an SVN repo...it gets to about version 4000 of 8500 and then I get the following error: bzr: ERROR: parent_id {3842@daff2dd8-1c3d-0410-9cd2-f6297dd8f964::trunk%2Fjetty-master%2Fsrc%2Fhtml} not in inventory
[16:49] <enigma1> (This is with bzr-svn 0.5)
[16:50] <enigma1> (trunk)
[16:50] <\sh> jelmer: how do I do this?
[16:52] <jelmer> \sh, bzrlib/repository.py:1142
[16:52] <jelmer> just replace the raise with a "pass"
[16:54] <\sh> jelmer: which method? in my source there is line 1142 in repository.py a "return result"
[16:55] <jelmer> \sh, unlock
[16:55] <jelmer> enigma42, hi
[16:56] <\sh> jelmer: thx...now it takes some more time
[16:58] <jelmer> AmanicA, hi
[16:58] <AmanicA> hi
[16:58] <jelmer> AmanicA, I always forget - do you have PQM access?
[16:58] <AmanicA> no
[17:00] <jelmer> AmanicA, Ok; I've submitted your tags-range patch
[17:01] <AmanicA> thanks!
[17:01] <AmanicA> *goes for dinner
[17:13] <enigma42> jelmer: Hi
[17:14] <enigma42> jelmer: I had just stepped out for a bit to take all the garbage cans out to the curb. ;-)
[17:17] <jelmer> enigma42, hi
[17:18] <jelmer> enigma42, are you on r2270?
[17:20] <enigma42> jelmer: Let me check
[17:21] <enigma42> jelmer: No....I'm on 2266
[17:21] <enigma42> Let me update.
[17:23] <enigma42> OK...I'm trying again. Should I clear the svn cache?
[17:24] <jelmer> no, that shouldn't be necessary
[17:24] <enigma42> OK
[17:26] <LarstiQ> jelmer: bzr-svn 0.5 deals well with a previously branch-scheme breaking mv, thanks!
[17:27] <LarstiQ> jelmer: unfortunately copies still seem to stop it dead in its tracks.
[17:27] <jelmer> LarstiQ, not sure I follow?
[17:27] <jelmer> LarstiQ, Copies of files you mean?
[17:27] <LarstiQ> jelmer: no, svn cp trunk branch
[17:28] <LarstiQ> now branch and trunk don't share history
[17:28] <LarstiQ> afaiui
[17:28] <jelmer> LarstiQ, they should, if you did a "bzr branch" of "branch"
[17:28] <jelmer> LarstiQ, or did you already push to both using older versions of bzr-svn?
[17:30] <jelmer> LarstiQ, oh, and "branch" would have one extra (pointless) commit after a "svn cp"
[17:30] <LarstiQ> jelmer: no bzr has been used on that branch afaik
[17:30] <LarstiQ> but maybe it wasn't an svn cp, but manually, hmm
[17:32] <LarstiQ> jelmer: would the svn log -v -r svnrev; where svnrev is the svn revno of the branch bzr first revision be helpful?
[17:32] <jelmer> LarstiQ, yes
[17:32] <LarstiQ> it's a bunch of adds :/
[17:32] <jelmer> not a copy?
[17:32] <LarstiQ> it mentions (from: /..)
[17:33] <jelmer> that's a copy
[17:33] <LarstiQ> ok
[17:42] <LarstiQ> jelmer: the README refers to BzrForeignBranches/Subversion/mapping , http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping doesn't seem to exist though?
[17:43] <enigma42> jelmer: Wow! bzr-svn 0.5 is *much* faster for pulling lots of revisions!
[17:44] <jelmer> enigma42, cool, that's good to hear :-)
[17:44] <enigma42> I'm able to pull down a 1000 revisions from a remote repo in about 1 minute.
[17:45] <jelmer> LarstiQ, ah, yeah, it's part of the bzr branch these days
[17:45] <enigma42> So this is the strange thing, if I just do a "pull", then it takes a really long time during "phase 0 of 2"
[17:45] <enigma42> But if I do "pull -v -r 2000" it goes much faster.
[17:45] <jelmer> enigma42, that's the "copying revisions" step or "fetching revision info" ?
[17:46] <enigma42> The "Pull phase 0/2"
[17:47] <enigma42> There's approx 8500 revisions in the svn repo.
[17:48] <enigma42> So what I'm doing right now is pulling down the revisions 1000 at a time.
[17:50] <enigma42> OK...I'm just around revision 4000 again and it's being slow.
[17:50] <enigma42> Let me investigate a bit.
[17:54] <LarstiQ> evening jam
[17:57] <enigma42> What is "Pull phase 0" anyway?
[17:57] <enigma42> Versus "1" and "2"?
[17:58] <jam> hi LarstiQ
[18:10] <jelmer> enigma42, is it working any better this time?
[18:12] <enigma42> Well...it's still slow, but I think I've narrowed it down to the problem revisions.
[18:13] <enigma42> I think it's getting stuck on an SVN branch we made a while back.
[18:21] <\sh> jelmer: I don't get any backtrace :(
[18:21] <jelmer> \sh, so it just works ? Or does something else fail?
[18:21] <\sh> no it failes after some time again..but no backtrace
[18:22] <jelmer> how does it fail?
[18:22] <\sh> same error message: bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/')
[18:24] <jelmer> \sh, ah, looks like there's another place where that exception is raised..
[18:24] <jelmer> bzrlib/repofmt/pack_repo.py
[18:24] <jelmer> any chance you can comment it out there as well and try again?
[18:24] <jelmer> sorry :-/
[18:24] <\sh> jepp
[18:28] <\sh> jelmer: I've to catch my train now...I'll leave it running, so I can see tomorrow morning what happened
[18:29] <\sh> ah ... now bzr: ERROR: Lock not held: LockableFiles(lock, file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/)                  but no backtrace ;)
[18:29] <\sh> anyways..I'm on the run :) cu tomorrow
[18:30] <jelmer> k
[18:30] <jelmer> bye!
[18:33] <enigma42> jelmer: I think I found the svn rev the pull is getting stuck on.
[18:33] <enigma42> jelmer: What sort of information should I dump out to see what's going on?
[18:33] <enigma42> Is just sits and sit here: | [                                                            ] Pull phase 0/2
[18:33] <jelmer> svn log -v for the particular revision would probably be useful
[18:34] <jelmer> but it's actually doing something ?
[18:34] <enigma42> top shows that it's using CPU
[18:34] <enigma42> But the progress bar is not ever moving.
[18:34] <enigma42> And it just sits there for minutes and minutes.
[18:35] <jelmer> if you run it with -Dtransport it will write the svn operations to ~/.bzr.log
[18:35] <enigma42> Oh, OK. Let me try that.
[18:35] <jelmer> you can also interrupt it with SIGQUIT (Ctrl-\), that will put you into a Python debugger
[18:35] <jelmer> you should then be able to see what's going on
[18:36] <enigma42> Ah...I see this log message: creating branch for POC of svn branching
[18:36] <enigma42>    A /branches/RELEASE_0_6_0 (from /trunk:4114)
[18:39] <bialix> hello
[18:39] <bialix> is there possible to create bzrdir without branch and checkout?
[18:40] <bialix> I'd like to have it in such state to prevent adding directory to toplevel branch and in the same to prevent creating checkout in this directory
[18:40] <enigma42> jelmer: It all gets very slow after the following:
[18:40] <enigma42> 25.838  svn update -r4115
[18:40] <enigma42> 26.259  'branches/RELEASE_0_6_0' copied from 'trunk':svn-v3-none:daff2dd8-1c3d-0410-9cd2-f6297dd8f964::4114
[18:41] <enigma42> jelmer: Maybe some kind of deep recursion following the copy?
[18:41] <knighthawk> still learning how to do remote checkouts bzr branch bzr+ssh://serverName/file/path works
[18:41] <enigma42> jelmer: I pulled the top of the repo, so I should have a "root" layout.
[18:42] <knighthawk> but bzr branch userName@bzr+ssh://serverName/file/path doesn't
[18:42] <jelmer> enigma42, yes, that will be slow indeed
[18:42] <knighthawk> how so I add the user name to the URL?
[18:42] <jelmer> enigma42, There's not usually a reason to pull the top of the repository
[18:42] <jelmer> enigma42, in fact, it should warn you if you do so
[18:42] <Peng_> knighthawk: bzr+ssh://username@host/path
[18:42] <Peng_> knighthawk: Just like HTTP.
[18:43] <enigma42> jelmer: What I'm trying to do is clone the whole SVN repo.
[18:43] <jelmer> enigma42, in that case, you'd want "bzr svn-import"
[18:43] <knighthawk> thanks Peng
[18:43] <jelmer> enigma42: that will import all of the branches in the repository
[18:43] <jelmer> enigma42: Right now you're cloning a repository as if it were a branch
[18:44] <enigma42> I'm trying to clone the repo so that I can push it to a new server.
[18:44] <enigma42> if I use svn-import, will that let me push it all to a new server?
[18:45] <jelmer> enigma42, yes, though you would have to run "bzr svn-push" for each branch that it imports
[18:46] <enigma42> Oh, OK. Let me try svn-import. Thanks.
[18:46] <jelmer> enigma42, You didn't get the warning from "bzr branch" ?
[18:47] <enigma42> I can't recall. Let me try again.
[18:47] <jelmer> E.g. if I do:
[18:47] <jelmer> ganieda:/data/tmp% bzr branch svn://svn.gnome.org/svn/gnome-specimen trpoq
[18:47] <jelmer> Cloning Subversion repository as branch. To import the individual branches in the repository, use "bzr svn-import".
[18:48] <enigma42> Oh yes, I did get that. I guess I just ignored it since I've cloned the repo as a branch before.
[18:49] <enigma42> It was probably faster to clone last time because I was using 0.4 and it didn't follow the copies.
[18:49] <knighthawk> Peng that worked for me from linux. How do I do that from Windows?
[18:51] <enigma42> jelmer: So that's definitely going to be strange to clone the repo as a branch if there are copies inside the repo.
[18:51] <jelmer> enigma42: I think that warning probably should be an error
[18:52] <jelmer> enigma42, bzr doesn't support copies so bzr-svn has to fetch the whole branch all over again
[18:52] <enigma42> jelmer: Yeah, because it makes sense to treat the repo as a branch up until it discovers the first copy, then it just gets strange.
[18:53] <jelmer> enigma42: I don't think it makes sense to treat the repository as a branch if there are "trunk" and "branches/*" directories
[18:53] <enigma42> jelmer: True.
[18:54] <enigma42> I still have to wonder why the SVN developers thought it was a good idea to flatten branches and tags into the tree. ack!
[18:54] <knighthawk> can anyone help me figure out bzr+ssh on windows? I have putty installed but I'm getting unsupport protocal for url
[18:54] <enigma42> jelmer: Now I get a different error: SubversionException: ("REPORT request failed on '/svn/sequoia/!svn/vcc/default'", 160005)
[18:55] <enigma42> knighthawk: bzr uses python parimiko for SSH, doesn't it?
[18:55]  * jelmer sighs
[18:55] <enigma42> ahem...that should be "paramiko"
[18:55] <jelmer> enigma42, can you pastebin the backtrace?
[18:55] <enigma42> Sure. One sec.
[18:56] <knighthawk> enigma42, sorry no clue Not really that up2date on ssh on windows. or python for that matter.
[18:56] <Peng_> knighthawk: Install paramiko (and its dependency pycrypto)
[18:57] <Peng_> Although the batteries-included installer probably comes with them...
[18:57] <enigma42> jelmer: http://pastebin.ubuntu.com/86460/
[19:17] <enigma42> jelmer: Another quick question for you, I always have to have "svn+https://" in order to get bzr to use the SVN plugin, but the plugin keeps complaining about "svn+" as being deprecated. Is there a way to get bzr-svn to work with just using "https" without the "svn+"?
[19:18] <enigma42> jelmer: In my case, the https connection is all certificate based, so that might be what's going on.
[19:19] <enigma42> Since subversion knows about the cert, but I have no idea how to tell python about it.
[19:19] <jelmer> enigma42: I think it works without svn+ if you don't have pycurl installed
[19:21] <jelmer> enigma42, it's basically a bug in pycurl, which doesn't allow client certificates
[19:21] <jelmer> s/client certificates/unchecked certificates/
[19:21] <enigma42> Oh, OK.
[19:21] <enigma42> Without pycurl, is there a way to tell python about the cert?
[19:22] <jelmer> yeah, the other http backend in bzr works better I think
[19:22] <jelmer> svn+https:// just makes bzr skip pycurl and only try bzr-svn
[19:23] <enigma42> OK. That make sense why it works then and not just "https"
[19:23] <enigma42> jelmer: I just hit another assert error.
[19:23] <enigma42>   File "/home/neumann/.bazaar/plugins/svn/revmeta.py", line 310, in get_direct_lhs_parent_revmeta
[19:23] <enigma42>     assert self == firstrevmeta
[19:23] <jelmer> keep 'em coming :-) Please pastebin
[19:24] <jelmer> what's the full backtrace? What function is calling get_direct_lhs_parent_revmeta?
[19:25] <enigma42> http://pastebin.ubuntu.com/86471/
[19:25] <enigma42> Hold on...let me make sure this machine is at the latest rev.
[19:27] <jelmer> I did fix a bug related to this recently..
[19:28] <enigma42> I'm re-running the branch with r2270, it was at r2264.
[19:28] <enigma42> It's still "determining changes", so it will be a little bit.
[19:35] <enigma42> jelmer: Yeah, I get the same error with slightly different line numbers
[19:35] <enigma42> line 313 instead of 310, etc.
[19:35] <enigma42> jelmer: You want me to pastbin that?
[19:36] <jelmer> enigma42, have you cleared the svn-cache on that machine recently?
[19:36] <enigma42> No.
[19:36] <enigma42> You want me to do that and try again?
[19:36] <jelmer> enigma42, please do
[19:36] <enigma42> OK. here goes....
[19:37] <enigma42> oooh...v2271 is out. ;-) I'll use that.
[19:38] <enigma42> jelmer: Is there any point in deleting 'subversion.conf' in addition to "rm -Rf svn-cache"?
[19:38] <jelmer> enigma42, no, that shouldn't be necessary
[19:38] <enigma42> OK
[19:39] <enigma42> OK...I'm trying again with v2271
[19:39] <enigma42> (and a clean cache)
[19:48] <enigma42> jelmer: OK. I just got the same error.
[19:49] <enigma42> jelmer: Let me know if there's more info I can send you.
[19:51] <jelmer> enigma42, can you pastebin the last backtrace? it would be useful to have the correct line numbers
[19:52] <enigma42> OK
[19:53] <enigma42> http://pastebin.ubuntu.com/86485/
[19:56] <jelmer> thanks!
[19:58] <enigma42> jelmer: You're welcome. I'm going to be away for a bit...back later.
[20:17] <thumper> jelmer: hi
[20:17] <thumper> jelmer: how goes the svn-serve work?
[20:17] <thumper> jelmer: is there a road map document anywhere?
[20:17] <jelmer> thumper: Hi!
[20:17] <jelmer> thumper, It's going pretty well, but for now I'm focussing on getting 0.5 out the door
[20:18] <thumper> jelmer: what needs to be done for 0.5?
[20:18] <jelmer> thumper, bug fixing :-)
[20:18] <thumper> jelmer: heh
[20:19] <jelmer> thumper, Basically, bzr svn-serve only supports a mainline at the moment (not merged revisions yet), not commit support, no "svn diff" support
[20:19] <jelmer> and it can't update from an older revision yet
[20:19] <thumper> ok
[20:20] <jelmer> basically, it can do "svn checkout", "svn log", "svn ls", "svn stat", "svn proplist --revision"
[20:20] <jelmer> the others shouldn't be hard too implement, since all of the logic of mapping bzr revisions to svn revisions is already present in bzr-svn
[20:20] <jelmer> it's just a matter of doing it
[21:00] <jelmer> abentley, hi
[21:00] <abentley> jelmer: Hi.
[21:00] <jelmer> abentley, I'm trying to fix bug 307541, but I'm at a bit of a loss as to what's going on
[21:00] <jelmer> Do you have an idea perhaps?
[21:02] <abentley> jelmer: Not off the top of my head.  I think someone else had this recently, but that was with a private branch, so I couldn't reproduce it.
[21:07] <kfogel> In https://bugs.edge.launchpad.net/bzr/+bug/306394, I have added a note that it appears to be fixed now.  What does "nominate for release" mean, and should I click that too? :-)  If the bug is fixed in the mainline, then does that mean the fix will automatically be in the next release?
[21:10] <jelmer> abentley, n/p, thanks for have a look
[21:10] <jelmer> kfogel, Usually the fix gets submitted to the bazaar mailing list, reviewed and then merged into bzr.dev
[21:11] <jelmer> When that's happened, the bug gets marked as "fix released"
[21:11] <kfogel> jelmer: well, the fix somehow already made it into mainline (because that's my parent branch, and I didn't fix the bug locally).  But somehow the bug was never updated.
[21:11] <kfogel> jelmer: so: it's already in bzr.dev.
[21:12] <jelmer> kfogel, thanks - I've marked it as "fix released" now
[21:12] <kfogel> jelmer: thanks
[21:12] <epsy> what was the last bzr-launchpad version that broke lp: links compatibility?
[21:12] <epsy> (or just added them)
[21:12] <jelmer> epsy, that was a very long time ago, I think
[21:13] <epsy> yeah, but some people still seem to be using such outdated versions
[21:14] <epsy> [22:10] <K-Yo>: bzr: ERROR: Not a branch: /home/xx/armagetron/lp:armagetronad/0.2.8/
[21:14] <jelmer> epsy: oh, that's a different issue I think
[21:14] <jelmer> epsy, At one point not all bzr commands expanded lp:
[21:14] <epsy> yeah
[21:15] <jelmer> 1.4rc1 fixed it for "bzr pull"
[21:16] <epsy> so basicaly 1.4 ?
[21:16] <epsy> gah
[21:16] <epsy> typoday :<
[21:16] <jelmer> epsy, yeah, 1.4
[21:17] <epsy> right, thanks
[21:25] <K-Yo> hello, I can't find the package file from the download page... it seems aptitude gives me an outdated version of bzr :< how can I solve that? (I just want to install it on my Debian machine!)
[21:29] <NfNitLoop> K-Yo: click on the "instructions" link for Debian on the download page.
[21:29] <NfNitLoop> It will tell you how to add the bzr package repository so that aptitude will grab the latest version.
[21:30] <NfNitLoop> Oh, wait, those instructions are a little vague. :)
[21:30] <K-Yo> NfNitLoop, so I can follow the "ubuntu" stuff?
[21:30] <NfNitLoop> I'm not sure...
[21:30] <NfNitLoop> there's backports.org for Debian backports.
[21:31] <NfNitLoop> but it looks like 1.5 is the latest there.
[21:31] <NfNitLoop> What I do on my debian box is just:  apt-get remove bzr;  download tar.gz from bazaar-vcs.org, unpack and run 'sudo python setup.py install'
[21:31] <K-Yo> okay
[21:32] <K-Yo> i'll try that :)
[21:32] <NfNitLoop> K-Yo: good luck. :)
[21:32] <K-Yo> ty
[21:32] <NfNitLoop> My server is still Debian, but it's notoriously slow for getting new software added.
[21:32] <NfNitLoop> Next time I have to rebuild it, I think it'll be Ubuntu. :p
[21:33] <jelmer> experimental has bzr 1.10
[21:33] <duckx> Martin around ?
[21:33] <duckx> Hy hy ;)
[21:33] <K-Yo> well, I just need over 1
[21:35] <poolie> hello all
[21:36] <jelmer> 'morning poolie
[21:37] <jelmer> jam, 1.10 isn't tagged :-(
[21:38] <jam> jelmer: nothing is tagged in bzr.dev, or were you hoping to get it from jam-integration?
[21:40] <jam> I just tagged it, I remember I actually had to delete the tag because I had to do a NEWS update
[21:40] <jam> but it should be good now
[21:41] <jelmer> jam, in bzr/1.10
[21:41] <jelmer> jam, since rc1 was tagged there
[21:42] <jelmer> jam, thanks!
[21:43] <jam> PQM doesn't seem to copy tags for some reason
[21:43] <jam> I haven't ever understood why
[21:43] <jam> I've always just kept them in jam-integration, and let them propagate to whoever wants them
[22:32] <duckx> jelmer: got one question from martin ...
[22:32] <duckx> I can't answer rightly now
[22:33] <duckx> The question is if I can return a boolean value from the config files ...
[22:34] <duckx> As far as I can get the thing, (Looked at the config.py file) there is no easy way to return a boolean value from the config files
[22:49] <enigma> jelmer: Did you need me to send you any more info on that assert error I posted earlier?
[22:49] <jelmer> enigma, sorry, haven't had any time to look at it further
[22:50] <enigma> No problem. Just let me know if you want more info.
[22:50] <jelmer> duckx, I think there is a as_bool() function
[22:51] <duckx> Yes indeed
[22:51] <duckx> But the way I would like to lookup my subject_with_hostname is the way the get_user_option does ...
[22:52] <duckx> And indeed the get_user_option does a get_value
[22:53] <duckx> as_bool only works this way config.get_parser()[section].as_bool('parameter_lookup')
[22:53]  * duckx still no get how the policy thing works in the config
[22:54] <jelmer> It may not be possible
[22:54] <jelmer> IIRC only one of the underlying objects has as_bool() and not the top-level Config object
[22:55] <duckx> Indeed
[22:55] <duckx> So my conclusion currently is that it is not possible to retrieve a boolean value from the config file ...
[22:56] <duckx> Is it possible to extend the get_user_option with a boolean=False parameter ?
[22:56] <duckx> I know it would break the API ...
[22:56] <duckx> But looks like it is the cleanest solution ....
[22:57] <jelmer> duckx: It's probably a better idea to raise this on the mailing list
[22:58] <jelmer> personally I would rather see a as_bool() function on the top-level config object
[22:58] <duckx> My concern is the following
[22:59] <duckx> I would like to set the subject_with_hostname in a specific location or globally
[22:59] <duckx> for example:
[22:59] <duckx> [/etc]
[22:59] <duckx> subject_with_hostname = true
[23:00] <duckx> For this to work I think I should use something like the get_user_option function to get this functionnality
[23:01] <duckx> That is the way I understand the config.py file so far ;)
[23:07] <jelmer> duckx, yeah, it seems to me like it would make sense to do that by implementing as_bool() on the top-level config object
[23:11] <duckx> jelmer: if i get the thing right it would make a call like config.as_bool(config.get_user_option('subject_with_hostname')) right ?
[23:12] <jelmer> duckx, Either that (although I don't see why as_bool() would need a config instance?) or having as_bool() call get_user_option for you
[23:14] <markh> igc: ?
[23:16] <duckx> jelmer: as_bool sadly could only be used linked extending a dictionnary ...
[23:16] <duckx> as it takes a key as parameter ...
[23:16] <duckx> And look for the key inside the self object ...
[23:17]  * duckx always love the perfid but clever martin questions ... ;)
[23:18] <duckx> Ok jelmer I will try to explain my concern on the mailing list ...
[23:18] <jelmer> duckx, the logic inside of the current as_bool() can be factored out though as a function that takes a string and returns a bool
[23:23] <jml> do you think bzr push --overwrite should imply --use-existing-dir?
[23:27] <kfogel> There's no particular convention for bugfix branch nicks, right?  I'm using "bug-NNNNN-short-desc-of-bug".
[23:28] <kfogel> Some existing nicks are like that, others are different.
[23:39] <Peng_> kfogel: I don't know of a convention. Yours sounds nice.
[23:40] <kfogel> Peng_: thanks.
[23:40] <Odd_Bloke> kfogel: I normally just use 'NNNNNN'. :)
[23:40] <kfogel> Peng_: can you sanity-check my bzr process for me?  It's the first time I'm fixing a bug, I want to make sure I'm going about things right.
[23:41] <kfogel> (say "yes" and I'll summarize what I'm doing)
[23:41] <kfogel> (say "no" and I'll silently choke back my tears :-) )
[23:41] <Peng_> "Maybe"? :D
[23:41] <kfogel> :-)
[23:41] <Odd_Bloke> kfogel: Just blurt it out and someone'll say something. :)
[23:42] <kfogel> In summary: I have a local "bzr.dev" tree, bzr info says: parent branch: http://bazaar-vcs.org/bzr/bzr.dev/
[23:42] <kfogel> In the parent dir, I did:
[23:42] <kfogel>    bzr branch bzr.dev bug-306394-status-continue-after-nonexistent-file
[23:42] <kfogel> Then I cd'd into the bug-... branch.
[23:42] <kfogel> Then I made the first of several changes to fix the bug, and committed my change.
[23:43] <Peng_> Sounds good so far.
[23:43] <duckx> jelmer: thx for your help mail sent ... hope it is clear enough ;)
[23:43] <kfogel> I plan to commit more changes, including a new regression test in bzrlib/tests/test_status.py.
[23:43] <kfogel> Peng_: EOT
[23:44] <Peng_> kfogel: Still sounds good. :)
[23:44] <kfogel> (When these are all ready, I'll figure out how to make my branch available for review -- can see that there's documentation on that, but haven't read it yet.)
[23:44] <kfogel> Peng_: okay, thanks!
[23:46] <poolie> hello duckx, kfogel, jelmer
[23:46] <poolie> jelmer, thanks for your update on bzr-git
[23:47] <kfogel> poolie: helloz
[23:50] <kfogel> hmmm:
[23:50] <kfogel>  WARNING  Plugin "Bzrtools" is not up to date with installed Bazaar version 1.11dev.
[23:50] <kfogel> There should be a newer version of Bzrtools available, e.g. 1.11.
[23:50] <Peng_> kfogel: You can push to a server you own, or Launchpad, or just use "bzr send" to send a bundle. Which would be covered by the docs, I guess. :P
[23:50] <kfogel> 'bzr shelve' seems to be failing
[23:50] <kfogel> Peng_: heh, you read my mind
[23:50] <kfogel> (was just reading abuot how to push to lp for review)
[23:51] <Peng_> kfogel: You're using bzr.dev? I guess you should use bzrtools's dev branch too, if you're not already.
[23:52] <kfogel> Peng_: I didn't even know I had or didn't have something called "bzrtools" until this moment.
[23:52] <Peng_> kfogel: ...Oh.
[23:52] <kfogel> bzr branch http://bazaar-vcs.org/bzr/bzr.dev/ bzr.dev
[23:53] <kfogel> that's the command I ran, from http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html
[23:53] <kfogel> Was I supposed to grab something else too?
[23:53] <Peng_> Not really. bzrtools is a popular plugin, but you don't have to use it.
[23:53] <kfogel> the string "bzrtools" does not appear in HACKING.html AFAICT
[23:53] <kfogel> Peng_: apparently if I want to use "shelve" I have to use it :-).  Or if I want to run the test suite...
[23:54] <kfogel> (the main bzr test suite, that is)
[23:54] <bob2> your OS's bzr package might have suggested it
[23:54] <Peng_> kfogel: bzrtools used to provide the shelve command, but it was recently merged into bzr.dev.
[23:54] <bob2> you can use bzr --no-plugins
[23:54] <kfogel> Peng_: hmmm.  So, I have a bzr installed on my system, but when I run the test suite, I expect the bzr in my local branch to be used.  Is that a wrong expectation?
[23:55] <Peng_> kfogel: Well, which "bzr" did you run? The system one or the local one? :P
[23:55] <Peng_> kfogel: Use "./bzr" or whatever if it's not in your PATH.
[23:55] <kfogel> Peng_: I'm in my branch (the bug-NNNNN branch branched from my bzr.dev, which is in turn a branch of mainline), and I run 'make check'.
[23:56] <Peng_> Oh.
[23:56] <kfogel> Peng_: ...t_shelve.TestShelveList.test_no_shelved_changes FAIL                  47ms
[23:56] <kfogel> test #594 I guess
[23:57] <kfogel> Peng_: the larger picture here is: I'm running the test suite to make sure it currently doesn't fail.  Then I will add a new test to make sure that my fix for 306394 does what I think it does.
[23:57] <kfogel> But I got stopped on step 1 (run the test suite) :-).
[23:57] <Peng_> Erm.
[23:58] <Peng_> Well, you can run "./bzr --no-plugins selftest". (make just runs "./bzr selftest" with some options.)
[23:58] <kfogel> I could just take my latest bzr.dev and run 'make install'.  That would probably solve the problem.  But it might mask this bug we're encountering now -- the one where the installed bzr is used when running the test suite, or so it seems.
[23:58] <Peng_> kfogel: You could also run "./bzr plugins -v" to see where bzrtools is coming from.
[23:58] <kfogel> Peng_: thx, trying that...
[23:58] <Peng_> kfogel: The Makefile explicitly runs "./bzr", so it's not using the installed one.
[23:58] <Peng_> Unless something really weird is happening, I guess..