[00:00] <davidstrauss> lifeless: record gives me an internal error
[00:01] <davidstrauss> lifeless: I'm using the 1.11 package for OS X
[00:06] <lifeless> davidstrauss: thats odd
[00:06] <lifeless> does 'bzr selftest loom' pass?
[00:06] <davidstrauss> lifeless: Also on very late code on CentOS 5
[00:06] <davidstrauss> lifeless: i'll try
[00:09] <davidstrauss> lifeless: All tests pass
[00:09] <lifeless> file a bug please
[00:19] <lifeless> jelmer: reviewed your patch - I don't think it works
[00:20] <jelmer> lifeless, it seems to work fine here - or do you mean it's not lazy?
[00:21] <lifeless> I don't think it achieves your goal
[00:21] <lifeless> because formats are probed
[00:21] <lifeless> it will be probed anytime a miss occurs on a .bzr dir
[00:21] <lifeless> I think that bzr-svn has to provide a lazier format object
[00:25] <lifeless> jelmer: do I make sense?
[00:26] <jelmer> lifeless: yeah, I see your point
[00:27] <jelmer> lifeless, The probe functions are pretty lightweight already though
[00:27] <sohail> lifeless, in the instructions you gave me for branching, do I always have to log on to the server to create a branch in that manner?
[00:27] <lifeless> then what would be gained by this?
[00:27] <lifeless> sohail: not at all, I wanted ot check the repo because of your size concerns
[00:27] <lifeless> sohail: just 'bzr branch url_to_master url_to_new_branch'
[00:28] <sohail> ah
[00:28] <sohail> and then remove-tree?
[00:28] <lifeless> won't be needed remotely
[00:28] <sohail> cool
[00:28] <sohail> thanks
[00:28] <lifeless> np
[00:30] <lifeless> jelmer: so, you said in your mail that this would let us not load all of subversion
[00:30] <lifeless> jelmer: do your probe functions check that svn is _possible_ before loading svn?
[00:30] <lifeless> e.g. t.has('.svn')
[00:31] <jelmer> lifeless, hmm
[00:31] <lifeless> irrelevant for http
[00:31] <lifeless> but for local..
[00:31] <jelmer> lifeless, yeah, my patch just saves an imports in some cases
[00:31] <jelmer> lifeless, they actually check for isinstance(transport, LocalTransport) and transport.has(".svn")
[00:31] <lifeless> jelmer: and the import that is saved, is it of svn itself, or bzrsvn ?
[00:32] <jelmer> lifeless: bzr-svn/subvertpy
[00:34] <lifeless> so you could move the probe pre-checks into __init__, avoiding that import always except when it may really be a svn tree
[00:35] <jelmer> not sure I follow
[00:35] <jelmer> what do you mean by pre-checks?
[00:36] <jelmer> ah, sorry
[00:36] <jelmer> the import that is saved is just the import of the file that the BzrDirFormat derivatives are in
[00:45] <lifeless> I've bb:rejected based on this conversation
[00:45] <lifeless> I think that if bzr-svn is importing to much still, the change at this point needs to be in bzr-svn
[00:45] <lifeless> or
[00:45] <lifeless> the change to the format code would need to be rather different
[00:47] <jelmer> hmmok
[00:48] <davidstrauss> lifeless: https://bugs.launchpad.net/bzr-loom/+bug/322557
[00:48] <davidstrauss> lifeless: enjoy :-)
[00:49] <lifeless> jelmer: basically the probe code has to be assumed to be executed; the bzr-svn probe is 'is it local, and is there a .svn, and does svn recognise it'
[00:49] <lifeless> jelmer: the first two checks do not need to import subvertpy or anything; only the last check does
[00:49] <jelmer> lifeless, Yeah, I see your point, I'm still just wondering whether the change isn't worth it
[00:50] <lifeless> I think the change adds complexity without gaining anything in general
[00:50] <lifeless> and its misleading to people because it will claim to be lazier than it really is
[00:51] <lifeless> davidstrauss: looking
[00:51] <jelmer> lifeless, it seems like my real beef is with bzr-hg anyway
[00:51] <jelmer> as 75% of the time of running "bzr ls" is in mercurial
[00:52] <lifeless> ouch!
[00:52] <lifeless> well, all-in-__init__ is maybe not such a good idea :P
[00:52] <lifeless> otoh is it import time
[00:52] <lifeless> or something else
[00:53] <jelmer> readconfig() is apparently 62%
[00:53] <jelmer> from mercurial.ui
[00:53] <lifeless> whee
[01:01] <jelmer> lifeless, other than that, I now seem to have a bzr-svn that loads just __init__ and format
[01:01] <lifeless> jelmer: excellent
[01:02] <jelmer> lifeless, is there any reason we're *disabling* mercurial's demandload thingie?
[01:02] <lifeless> jelmer: yeah, it broke
[01:03] <lifeless> jelmer: there is a bzr-git thread on the list
[01:03] <lifeless> from Timmie
[01:13] <lifeless> spiv: bug 322299 smells like server autopack to me
[01:17] <spiv> lifeless: yeah, it does seem like server-side autopack is failing, but the root cause still isn't obvious
[01:30] <davidstrauss> Is it possible to pull a set of branches at once?
[01:31] <lifeless> multipull I think
[01:37]  * jelmer pulls bzr-foreign into yet another bzr plugin
[01:45] <thumper> jelmer: what's the bzr-svn command to push back to svn?
[01:46] <jelmer> thumper, pushing into an existing branch: "bzr push"
[01:46] <jelmer> thumper, to a new branch: "bzr svn-push"
[01:46] <thumper> hmm..
[01:50] <thumper> jelmer: docs say that http is supported for svn writes using webdav
[01:51] <jelmer> thumper, yep
[01:51] <thumper> jelmer: does bzr-svn support https webdav writes?
[01:51] <jelmer> thumper, yep
[01:51] <thumper> ok
[01:51] <thumper> I'm trying to help someone on #nzpug
[01:51] <thumper> jelmer: could I get you to pop in perhaps?
[01:51] <jelmer> sure
[01:58] <spiv> igc: I just got hit by the same unrelated test failure on PQM (LockableFiles.__del__ in blackbox.test_shelve) as you.
[02:00] <jelmer> spiv, fwiw, I've seen that issue as well
[02:00] <jfroy|work> I have an existential question.
[02:01] <spiv> jfroy|work: There is no spoon.
[02:01] <jfroy|work> Why does bzr encode ~ as %7E?
[02:01] <jfroy|work> That is all.
[02:03] <spiv> jfroy|work: hmm, probably because urllib.quote does.
[02:03]  * jfroy|work wants prettier URLs.
[02:03] <jfroy|work> Time to write a patch.
[02:03] <spiv> jfroy|work: although bzrlib.urlutils explicitly tries to declare that ~ isn't to be escaped I guess there are some places that don't go through those code paths.
[02:05] <spiv> Hmm, actually, bzrlib.urlutils.escape will do that too, it doesn't take the _url_dont_escape_characters/_url_safe_characters sets into account.
[02:05] <spiv> It basically just relies on urllib.quote.
[02:05] <spiv> So I guess that's why.
[02:07] <spiv> igc, jelmer: I guess it's to do with the UserWarnings that I get from blackbox.test_shelve when I run the tests on my laptop
[02:07] <spiv> ("was gc'd while locked" warnings from test_shelf_order, test_shelve_no_message, test_shelve_one)
[02:07] <jfroy|work> spiv: I didn't expect you to dig that deep. Thanks for the info.
[02:09] <spiv> jfroy|work: not a problem
[02:23] <thumper> jelmer: thanks for your help
[02:27] <jelmer> thumper, np
[02:33] <spiv> igc, jelmer: I think I've figured out the cause of the intermittent pqm failure, patch sent.
[04:12] <igc> hi all
[04:14] <spiv> igc: I sent a patch that should fix that odd PQM failure.
[04:14] <spiv> igc: it happened to me too :)
[04:17] <igc> spiv: awesome. just approved the patch btw
[04:19] <spiv> Yay :)
[04:52] <sohail> lifeless, there?
[04:52] <lifeless> apparently
[04:52] <sohail> cool!
[04:53] <sohail> more branching questions
[04:53] <lifeless> shoot
[04:53] <sohail> so now I am on another machine and did bzr switch next
[04:53] <sohail> but I don't seem to have the latest changes...
[04:53] <lifeless> is the commit you want listed in 'bzr log' ?
[04:54] <sohail> yeah
[04:54] <sohail> ok... sorry for pinging you, pebkac
[04:54] <sohail> bug in the code
[04:54] <sohail> hee hee
[04:54] <spiv> Hooray for easy questions :)
[04:54] <sohail> :-)
[05:16] <lifeless> sohail: np
[05:40] <Peng_> jelmer: Do you still support running bzr-svn 0.4 with bzr.dev? If so, could you fix the SPEC_TYPES warning? (I think I'll switch to 0.5 anyway though.)
[06:58] <vila> hi all
[06:59] <lifeless> yo
[07:35] <vila> igc: did you see my ping about usertest ?
[07:41] <vila> spiv: Yeah for your fix regarding test_shelve, got bitten by it yesterday too
[07:43] <spiv> vila: that makes lots of us, then :)
[07:44] <vila> I re-submitted immediately in anger and it went through :-)
[07:44] <vila> So I knew it was transient but I had no time to go further...
[07:49] <igc> vila: I missed that ping sorry
[07:49] <vila> igc: ping, I have bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict failing since a couple of days/weeks and no idea on how to fix it (the test is 3 lines long but the failure output is 800 lines long giving me little hints :-/)
[07:50] <vila> igc: no problem, I have an history at my fingertips :)
[07:51] <igc> vila: I'll take a look soon
[07:53] <vila> igc: thanks in advance :)
[08:00] <igc> vila: thanks for the reviews btw
[08:00] <vila> np
[08:01] <vila> Since jam gave a tweak for faster log, I didn't review, but I agree with him globally
[08:01] <vila> igc: Especially the part where he said: "it seems like it would make sense to create a class
[08:01] <vila> definition, and turn them into 'self.XXX'." mwhahahahaha
[08:01] <vila> :)
[08:08] <Peng_> 2899 KB to download the latest ~25-30 revisions of bzr.dev. I wonder how much bandwidth btrees would save overall?
[08:15]  * igc dinner
[10:14] <Lo-lan-do> Um, why does bzr viz on a bound branch try to contact the server?
[10:14] <Lo-lan-do> Shouldn't it only use the local history?
[10:18] <luks> probably to check what's the latest revision of the branch
[10:22] <spiv> Lo-lan-do: someone else reported that bug recently, I think
[10:23] <spiv> It might also be something silly like looking up the branch nick.
[10:57] <bialix> LarstiQ: I was over optimistic yesterday. Morning is smarter than evening. I'd prefer to implement subprojects for scmproj on top of new format and new layout. That said subpprojects will be there in a couple of weeks. Sorry. I hope you can play with scmproj without subprojects some time.
[10:58] <fullermd> That's why I do all my work in the evenings; things are so much easier and get done faster  ;)
[10:59] <bialix> hehe
[10:59] <bialix> you never sleep, do you?
[10:59] <fullermd> Sleep is for wimps.
[10:59] <fullermd> Happy, healthy, well-rested wimps, but wimps nonetheless!
[11:00] <bialix> :-D
[11:17] <beniwtv> hi.. is bzr:// read-only? It complains it can't commit because of that :(
[11:17] <bialix> bzr server --allow-writes
[11:18] <fullermd> But it's ususally used pure read-only since there's no access control on it above the IP layer.
[11:19] <beniwtv> fullermd: Access control doesn't matter really, it's just a small office server, and you can only access it from the office
[11:23] <fullermd> Well, strictly speaking, it DOES matter; you've just got it taken care of   :)
[11:25] <beniwtv> bialix: Works, thanks :)
[12:45] <ollie> hello I have done a bzr push to a remote server. the  ssh'd in and done bzr st and get bzr: ERROR: No WorkingTree exists for
[12:45] <ollie> how do i turn this into a working tree
[12:46] <luks> bzr checkout .
[12:46] <ollie> i have done this before but can't remeber what i did
[12:46] <ollie> luks: perfect thanks
[12:47] <ollie> if i now do some changes on the server e.g. the config file then do a bzr push later from my laptop will my server changes be overwritten?
[12:48] <luks> no, the working tree won't be overwritten at all
[12:48] <luks> and bzr push will complain that it can't update the remote working tree
[12:48] <ollie> ok so then i could do bzr up right from the server
[12:48] <ollie> ah ic
[12:48] <ollie> so bzr push is really only for a one off
[12:48] <ollie> whats the best way to deploy to a live server then?
[12:48] <luks> bzr push is for pushing bzr data
[12:49] <luks> you can use the bzr-push-and-update plugin if you are using bzr+ssh and you want to automatically update the checkout
[12:49] <luks> and there is a bzr-upload plugin to just upload the actual files, not bzr data
[12:49] <ollie> yeah i remember seeing that before
[12:50] <ollie> i have the situation where i have a dev server and then a live server where clients add files via a cms.
[12:50] <ollie> developers work on dev clients works on live via cms
[12:50] <ollie> but i need to take developers changes to live
[12:51] <ollie> at the moment i have dev and live as checkouts of a repository but i am sure this is not the best way to do it
[12:52] <ollie> i can't find all that much info about web dev workflow using bzr via google
[12:52] <ollie> which is odd
[12:52] <santagada_web> ollie: there is some info on bazaar wiki
[12:58] <santagada_web> ollie: I think that your production server should be deployed with bzr-upload...
[13:25] <ollie> is there away to get rid of bzr push info e.g. bzr info shows related branches
[13:25] <ollie> which i no longer want
[13:26] <Lo-lan-do> I didn't find a proper way to do that, you'll need to edit the .bzr/branch/branch.conf file and remove the lines.
[13:57] <awilkins> Hey, anyone else notice that bzr ls --unknown is listing paths to STDERR or is that just me?
[14:43] <phinze> i heard that loggerhead has no way of displaying information about tags... is this true?
[14:52] <phinze> whoa; just realized that if i have a branch diverge while i'm running tests, and i'm forced to merge the commits that slipped in with myself (therefore making them subrevisions of my commit) that when I push I can actually *reduce* the overall branch revno
[14:54] <AmanicA> phinze: in the version of loggerhead I run, I don't see tags
[14:55] <bialix> phinze: you would be interested in using append-only branches
[14:55] <Lo-lan-do> phinze: Yeah, non-linear history can lead to interesting results :-)
[14:56] <Lo-lan-do> (And you don't want to trust the revno anyway)
[14:56] <bialix> grrr, why launchpad still cannot upgrade hosted branches?
[14:56] <bialix> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[14:56] <bialix> :-/
[14:57] <bialix> I should use sftp URL?
[14:57] <AmanicA> phinze: it seems tag support is still under development: https://bugs.launchpad.net/loggerhead/+bug/246739
[14:57] <Peng_> bialix: sftp should work. bzr+ssh might with a new enough bzr?
[14:58] <bialix> sftp does not work either
[14:58] <bialix> I'm running official bzr.exe 1.11
[14:58] <bialix> rats rats rats
[14:58] <Peng_> Ah. Sorry, then.
[14:59] <Lo-lan-do> Did you specify a format explicitly?
[14:59] <bialix> no
[14:59] <AmanicA> hi bialix, don't you ever work/sleep :)
[14:59] <bialix> bzr upgrade sftp://bialix@bazaar.launchpad.net/~bialix/bzr-x-bit/trunk
[14:59] <Lo-lan-do> I suggest you give it a try :-)
[14:59] <bialix> you know something?
[14:59] <Lo-lan-do> bzr upgrade --format=1.9-rich-root sftp://qjsdfq
[15:00] <Lo-lan-do> I know nothing, but I suspect that upgrade without an explicit format might try to upgrade to the most recent *default* format, and the newer ones haven't been made the default yet.
[15:00] <bialix> yep, my bad
[15:00] <bialix> this branch is already upgraded
[15:00] <bialix> but my local branch was not
[15:01] <bialix> hence my confusion
[15:01] <bialix> but error message is confusing
[15:02] <bialix> why it told me about meta-directory?
[15:02] <bialix> AmanicA: hi
[15:02] <bialix> AmanicA: here 17:01
[15:02] <AmanicA> hi
[15:02] <AmanicA> here too
[15:02] <bialix> why I should sleep?
[15:03] <AmanicA> because you didn't last night?
[15:03] <bialix> :-) no, I fall asleep after conversation with LarstiQ
[15:03] <AmanicA> :D
[15:03] <bialix> !summon LarstiQ
[15:03] <bialix> :-P
[15:03] <AmanicA> and I hear he also fell asleap after that conversation
[15:04] <bialix> hehe
[15:04] <bialix> scmproj is better soporific ever
[15:04] <AmanicA> sweet
[15:04] <bialix> what you think about my latest subproj idea?
[15:07] <AmanicA> sounds good
[15:07] <bialix> ok
[15:07] <AmanicA> I'm glad I could convince you :)
[15:07] <AmanicA> an I didn't even have to build a prototype
[15:08] <AmanicA> I'll really try to get some of those lp-bugs ticked off soon
[15:08] <AmanicA> (to get then new format out sooner)
[15:09] <bialix> I'm working on new format today, have some free time
[15:10] <bialix> the main problem is rewriting of docs
[15:19] <AmanicA> great thanks
[15:40] <sewmyheadon1> Hi Folks, anyone here use bzr with Dropbox?
[15:42] <sewmyheadon1> Or, can you think of any reason why bzr wouldn't work with Dropbox?
[15:45] <santagada_web> sewmyheadon1: you plan to use it for yourself or to share the data with other people?
[15:46] <sewmyheadon1> santagada_web: Myself, basically. I access my Dropbox from both a desktop and laptop and wonder if I'm using bzr on both, could I have my branch/repo setup in Dropbox?
[15:48] <rockstar> Can someone please get the bzrtools package for 1.11 into the PPA?
[15:48] <santagada_web> sewmyheadon1: I can't think of anything that might go wrong, if you are not in the middle of a commit while dropbox is copying stuff
[15:48] <santagada_web> I don't know how bzr does locking during commits
[15:48] <santagada_web> but I would guess dropbox would not copy them correctly
[15:49] <sewmyheadon1> Thanks santagada!  I think we'll give it a spin and see if/how it works.
[15:53] <santagada_web> sewmyheadon1: dropbox copying is manual right?
[15:53] <santagada_web> sewmyheadon1: it doesn't start the backup automatically right?
[15:56] <sewmyheadon1> santagada_web: It's strange.  Dropbox creates a folder in your home dir and, when you copy files into it, it uses WebDAV (I think) to copy these files into 'the cloud,' which is the storage they use on Amazon servers.  When you use another machine that's connected to the same DBox account, Dropbox checks periodically to make sure your files on the new machine are up to date, and will copy down any changes automatically.
[15:57] <sewmyheadon1> So you could use Dropbox on twenty machines all connected to your Dropbox account and each machine will poll your local and remote Dropbox folders periodically looking for changes and auto sync.  Make sense?
[15:57] <sewmyheadon1> You end up with local files on each machine connected to Dropbox.
[16:12] <kfogel> hunh.  Can't install bzr in home dir, using exactly the instructions in INSTALL:
[16:12] <kfogel> http://paste.lisp.org/display/74497
[16:14] <kfogel> And this grep finds no results in the tree:
[16:14] <kfogel> find . -type f -print | xargs grep "must supply either"
[16:20] <bialix> kfogel: "must supply" error from python distutils lib
[16:21] <kfogel> bialix: thanks
[16:21] <bialix> kfogel: though I don't have enough experience with linux home install
[16:21] <bialix> try to read: python setup.py install --help
[16:21] <kfogel> bialix: exactly what I'm doing now :-)
[16:22] <bialix> khm
[16:22]  * bialix shuts up
[16:22] <kfogel> bialix: what does "khm" stand for?
[16:23] <bialix> *cough*
[16:23] <bialix> never mind
[16:23] <kfogel> bialix: ?? :-)
[16:23] <kfogel> bialix: if it's offensive, I won't take offense.  I just like to keep my acronym collection up to date.
[16:23] <bialix> my native language is russian
[16:24] <bialix> sorry
[16:24] <bialix> I don't want to say something bad
[16:24] <kfogel> bialix: heh.  Okay.  Well, thanks for the clue about distutils lib.
[16:24] <bialix> it was translations from russian
[16:25] <kfogel> bialix: now you've made me *really* curious
[16:25] <bialix> I guess in English you using only hmm
[16:25] <kfogel> aaaah
[16:25] <kfogel> yes
[16:25] <bialix> "hmm"
[16:25] <kfogel> variable number of "m"s
[16:25] <kfogel> hmmmmmmmmmmmmmmmmm
[16:25] <kfogel> hmmmmmmmmm
[16:25] <bialix> khm it's hmm + cough
[16:25] <kfogel> hmmm
[16:25] <kfogel> got it
[16:25] <bialix> when you don't want to say something
[16:26] <kfogel> slightly more sarcastic, maybe, than "hmm"?
[16:26] <bialix> it depends on context I guess
[16:26] <bialix> in this case it was harmless, my hint about --help was too late
[16:27] <bialix> sorry
[16:29] <kfogel> oh, nothing to apologize for
[16:29] <kfogel> My debugging is not going very well.
[16:30] <kfogel> Argh, why is it that every time one tries to do X, one must first debug three prerequisites of X?
[16:30] <kfogel> (I'm just whining, you can ignore that.)
[16:30] <santagada_web> kfogel: yak shaving
[16:31] <kfogel> santagada_web: sigh, yeah
[16:31] <kfogel> So does 'python setup.py install --home ~' work for you?
[16:31] <james_w> kfogel: it might be that bzr's use of distutils breaks --home
[16:31] <james_w> you could perhaps use --prefix instead, but I imagine that leaves a less desirable structure
[16:31] <vila> kfogel: I think I use $HOME instead of ~ (but never tried for bzr though....)
[16:32] <vila> I used --prefix $HOME too
[16:32] <kfogel> james_w: --prefix errored too, though in a different way
[16:32] <james_w> oh
[16:32] <kfogel> vila: I tried with "/home/kfogel" already, which is what $HOME and ~ both expand to
[16:32] <bialix> kfogel: just to be sure, what say: `python -V`
[16:32] <kfogel> bialix: Python 2.5.2
[16:33] <bialix> good
[16:33] <bialix> IIRC bzr's C-extensions required explicit options
[16:33] <kfogel> vila: in theory, it should *never* make a difference whether you say ~ or $HOME or /home/yourdir -- the program can't tell the difference, since the shell expands it.
[16:33] <bialix> something like python setup.py build_ext ... install ...
[16:33] <bialix> I guess jam can say more
[16:34] <bialix> jam: ping
[16:34] <vila> kfogel: I agree with the principle :) I was trying a cheap shot... just in case
[16:34] <kfogel> vila: heh
[16:34] <bialix> kfogel: why you need to *install* bzr?
[16:35] <kfogel> vila: let me put it this way: if that made a difference, I'd have something much, much larger to debug.
[16:35] <vila> kfogel: just for perspective, why do you want to install in your $HOME ?
[16:35] <kfogel> bialix: so I can use it from anywhere
[16:35] <kfogel> vila: because it's a shared system and we'd prefer not to install dev code system-wide
[16:35] <bialix> you can just make symlink for bzr script
[16:35] <kfogel> bialix: I think I'm about to back down to that.  But will it load the right libs?
[16:36] <vila> kfogel: I was just about to say the same than bialix :)
[16:36] <vila> kfogel: it should
[16:36] <bialix> "the same than bialix" -- English is hard language
[16:36] <kfogel> I.e., if /home/kfogel/bin/bzr is a symlink -> /home/kfogel/src/bzr/bzr.dev-trunk/bzr, when I run it will it load the right libs from the latter dir, instead of from the system dir (which will be bzr 1.11)?
[16:36] <vila> I have 4 or 5 such symlinks in my ~/bin
[16:36] <vila> bialix: I wanted to recommend symlink, just like you :)
[16:37] <vila> kfogel: yes
[16:37] <bialix> vila: yes, I understand
[16:37] <kfogel> vila: it seems to yes (once I did 'hash -r')
[16:37] <kfogel> I guess I'll just do that.
[16:37] <vila> hash.... I hate it
[16:37] <bialix> kfogel: what say: python -c "import sys; print sys.path"
[16:39] <kfogel> http://paste.lisp.org/display/74499
[16:39] <kfogel> bialix: ^^
[16:40] <bialix> first entry '' -- IIRC it means current script dir
[16:40]  * bialix mutters: kfogel can try to install bzr at home with easy_install
[16:43] <kfogel> bialix: oh, I've got a working solution now, so I've timed out :-(.  This was all on the way to doing another more important thing.
[16:43] <kfogel> It's a pity bzr's homedir install recipe is (apparently) broken, but if I stop to fix that, then something else doesn't get done.  You know how it is.
[16:43] <bialix> it's ok
[16:45] <fullermd> kfogel: Err?  Shells don't always expand ~.  Only when it's at the start of a word.
[16:46] <fullermd> % echo --prefix=~/foo
[16:46] <fullermd> --prefix=~/foo
[16:47] <kfogel> fullermd: yes, but barring that
[16:47] <kfogel> fullermd: there are ways to suppress ~ and $ expansion.  But assuming they *are* expanded, the program cannot tell.
[16:47] <maxb_> kfogel: oh dear, have I coaxed you into venturing into problematic territory?
[16:47] <kfogel> maxb_: heh!  Hi there.
[16:47] <kfogel> Yes, but you were still right.
[16:47] <kfogel> (didn't know you hung out here, maxb_)
[16:49] <maxb_> Only recently. Ubuntu's incredibly keen on bzr, I figured I'd see what all the fuss was about :-)
[16:54] <kfogel> maxb_: it's good.  I'm not an expert yet, but starting to grok it.
[16:59] <jelmer> rockstar, nice work on the graphstats command :)
[16:59] <rockstar> jelmer, Thanks! http://media.theironlion.net/etc/graphstats-bzr.dev.png
[16:59] <bialix> AmanicA: finished rewrite of the project.cfg doc
[16:59] <rockstar> That's bzr.dev  It's a godo demonstration of the obvious shortcomings of the prototype.
[16:59] <jelmer> rockstar, It would be nice if it could not print labels for people who have contributed less than 0.5 % or something
[17:00] <rockstar> jelmer, yea, I plan on doing something like that.
[17:00] <jelmer> rockstar, since I get a lot of text that overlaps for some projects
[17:00] <bialix> AmanicA: format-change branch revno.180. If you will want to look
[17:00] <james_w> that pqm chap looks pretty useful prolific
[17:00] <rockstar> jelmer, I think what I'd like to do is create a new project and use the same concepts from bzr-stats, but implement them differently.
[17:00] <rockstar> james_w, :)
[17:01] <jelmer> rockstar: I don't think this would be bad to have in bzr-stats actually
[17:01] <rockstar> jelmer, I'm more interested in an API for generating statistics and less of a plugin.
[17:01] <rockstar> I assume I'd make some sort of plugin ui for it, but that's not something I much care about.
[17:02] <rockstar> jelmer, so unless you (and jam) aren't opposed to be going to town on bzr-stats itself, it might be better to start a new project.
[17:02] <rockstar> s/be/me
[17:03] <jelmer> rockstar: I'm certainly not opposed to that
[17:03] <rockstar> jelmer, I also noticed that the API needs some updating.  It's got a lot of code that broke in 1.6  :)
[17:04] <rockstar> I guess it's a plugin that not many people use.
[17:04] <jelmer> rockstar, which branch of the plugin are you using?
[17:04] <jelmer> I'm not seeing any problems and I use it regularly with bzr.devc
[17:04] <rockstar> jelmer, trunk.
[17:05] <rockstar> jelmer, try `bzr ancestor-growth`
[17:05] <jelmer> ah, yeah
[17:05] <jelmer> that breaks here as well
[17:05] <jelmer> the only commands I use are stats and credits
[17:06]  * fullermd thinks he filed bugs around there...
[17:06] <rockstar> jelmer, I have breakage on credits as well
[17:06] <rockstar> jelmer, nevermind, I thought I did.
[17:07] <fullermd> Oh, not on a-g.  Just on credits and committer-stats.
[17:08] <jelmer> lp:bzr-stats is what I package for Debian/Ubuntu
[17:14] <pdragon> i just did an update from launchpad to my local repository and it found a conflict in a binary file. Which of the files (BASE, OTHER, THIS) is the new file from launchpad and which is the original I had locally before?
[17:15] <Lo-lan-do> I think OTHER is the one from the repo, THIS is yours, and BASE is probably their latest common ancestor.
[17:16] <pdragon> ok. i was leaning towards OTHER as the new one since it has the largest file size. wasn't sure on the original though
[17:17] <Lo-lan-do> But don't trust me, I try to avoid binaries and conflicts when I can.
[17:17] <pdragon> yeah, i'm really not sure why there is a conflict
[17:18] <fullermd> Very complex geopolitical forces were at work.
[18:16] <dwt> jelmer: Hey, are you there?
[18:16] <jelmer> dwt, yes
[18:16] <dwt> Great. :)
[18:16] <dwt> I am trying to check out a directory from my svn server at https://ipx11390.ipxserver.de/svn/mhaecker/open-source/nsNet/trunk/ with the newest version of bzr and bzr-svn (just branched from http://people.samba.org/bzr/jelmer/bzr-svn/stable/
[18:17] <dwt> It works fine, but when I run bzr check afterwards in the checkout it dies with an exception
[18:17] <Peng_> Oh, wow. I was just thinking about pinging jelmer too. :P
[18:17] <dwt> :)
[18:17] <dwt> Do you want to take a look at it directly or should I just file it as a bug?
[18:18] <dwt> (It seems pretty reproducibly as I just created a new user, installed a new bzr and gave my repo a try after somebody complained to me that he was unable to work with the repo he had after pulling from my svn)
[18:19] <dwt> Oh, and I did a checkout of this repo with an older version of bzr (1.09 I think) and that one works fine, so this looks like a regression
[18:20] <jelmer> dwt, seems to work fine here
[18:20] <jelmer> with bzr-svn 0.5
[18:20] <dwt> I just branched from http://people.samba.org/bzr/jelmer/bzr-svn/stable/
[18:20] <dwt> maybe that is the wrong location?
[18:22] <jelmer> dwt, that's the 0.4 branch
[18:22] <dwt> I see
[18:22] <dwt> Let me check for the new url on the website, then I can retry with the new branch
[18:24] <Peng_> dwt: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/ for 0.5 (and you need subvertpy)
[18:24] <Peng_> dwt: http://people.samba.org/bzr/jelmer/subvertpy/trunk/
[18:24] <jelmer> Peng_, what were you about to ping me about?
[18:24] <dwt> Oh, that is no longer included?
[18:25] <Peng_> jelmer: Well, for one thing, I was gonna file a bug about the svn-v4 revision IDs being used in tags on that svn-v3 branch.
[18:25] <dwt> thanks Peng_
[18:25] <Peng_> jelmer: Also, one one branch (lighttpd-1.4.x, as always), bzr-svn 0.4 gives the latest revision an svn-v3 ID, but 0.5 gives it an svn-v4 ID. Is that supposed to happen?
[18:26] <jelmer> Peng_, yes
[18:26] <Peng_> jelmer: ...Why? :P
[18:26] <jelmer> Peng_, What would you suggest would happen?
[18:27] <Peng_> jelmer: About what? The tags or the second thing?
[18:28] <jelmer> Peng_, the second thing
[18:29] <Peng_> jelmer: Well, I wouldn't expect it to create 1129 svn-v3 revisions and then one svn-v4, when past versions created all svn-v3.
[18:30] <jelmer> Peng_, it created svn-v3 revisions because those were revisions pushed from bzr-svn
[18:31] <Peng_> jelmer: So 0.5 will create svn-v4 IDs, except for revisions created by bzr-svn 0.4? And it just so happens that 99.9% of this branch falls under that?
[18:31] <jelmer> Peng_: Yes
[18:32] <Peng_> OK.
[18:32] <jelmer> Peng_, revisions created by bzr-svn 0.5 and their ancestors
[18:32] <jelmer> *0.4
[18:32] <Peng_> Right.
[18:35] <AmanicA> bialix: thanx, I'll look a little later (I was away a while)
[18:35] <bialix> AmanicA: ok, it's already there
[18:36] <bialix> I'm starting working on everything is optional part
[18:41] <Peng_> jelmer: Well, I filed bug 322856. I hope it's coherent, and you don't mind. :P
[18:43] <Peng_> Nice, ubottu.
[18:55] <dwt> jelmer: I have some trouble getting the bzr-svn 0.5 branch to work here... Maybe you could help?
[18:55] <dwt> I installed subvertpy via easy_install
[18:55] <dwt> (after I failed with the direct checkout and install)
[18:55] <dwt> but it seems it is not recognized by the svn plugin
[18:55] <jelmer> what doesn
[18:55] <jelmer> t work
[18:56] <jelmer> ?
[18:56] <dwt> bzr selftest svn
[18:56] <dwt> fails with this line
[18:56] <dwt> cannot import name revspec_registry
[18:56] <jelmer> dwt, you need bzr.dev
[18:56] <dwt> which I am pretty sure belongs to subvertpy
[18:56] <dwt> uh..
[18:56] <dwt> ok
[18:57] <dwt> Is there a version of bzr-svn 0.5 that I can use against bzr 1.11?
[18:57] <dwt> It's no real problem for me to go to bzr.dev
[18:57] <jelmer> dwt, not at the moment
[18:57] <dwt> but my collegue is not very versed in shell. :/
[18:57] <jelmer> I guess I could make that bit optional
[18:58] <dwt> that would be super awesome. :)
[18:58] <dwt> (I'm going to fetch something to eat, and will be back in about half an hour)
[19:02] <Lo-lan-do> dwt: I use r2420, seems to work
[19:02] <Lo-lan-do> (Last commit before 1.12 became mandatory :-)
[19:14] <dwt> back
[19:14] <dwt> Lo-lan-do: :) Well, that's an option
[19:16] <jelmer> 1.11 should work again now as well
[19:19] <dwt> Thanks a lot jelmer!
[19:20] <dwt> is this http://people.samba.org/bzr/jelmer/bzr-svn/0.5
[19:20] <dwt> the right location to pull to get 1.11 compatibility?
[19:20] <dwt> (because I only get "no revisions to pull." when I try to)
[19:34] <jelmer> dwt, sorry, my link went down
[19:34] <jelmer> pushing again now
[19:35] <dwt> Thanks  a lot
[19:39] <davidstrauss> Is there a way to clean up storage of revisions from deleted branches from shared storage?
[19:40] <Lo-lan-do> Hmm.  I don't know if it's the lazy loading or whatever else, but I am now able to get bzr info results in 0.6 seconds.  Nice speed improvement :-)
[19:41] <Lo-lan-do> And bzr status in 1.1 seconds in a large-ish tree.  Congrats!
[19:43] <jelmer> Lo-lan-do: bzr-svn will also do complete lazy loading if you have bzr.dev
[19:44] <Lo-lan-do> Not yet, but I'll be expecting 1.12 with great enthusiasm :-)
[19:47] <Lo-lan-do> "using experimental bzr-svn mappings; may break existing branches in the most horrible ways"
[19:48] <Lo-lan-do> Should I rollback to r2420?
[19:49] <jelmer> Lo-lan-do, it should've always printed that
[19:49] <Lo-lan-do> I never saw it.
[19:49] <jelmer> Lo-lan-do, perhaps the new lazy importing fixes have just fixed the warning printing
[19:49] <jelmer> but nothing has fundamentally changed
[19:50] <Lo-lan-do> Okay.
[19:50] <Peng_> Yeah, I don't think it's been printing the warning for a while now.
[19:50] <Peng_> (And it is now.)
[20:02] <orev_> hi, trying to get my head around the bzr concept.. if I make a bunch of changes in a branch, and commit each one along the way, then push those changes to a central server, will the central server see all of the commits individually, or does it only see the push as one commit?
[20:03] <orev_> not sure if my terminology is right, I'm mostly familiar with svn
[20:03] <jpds> orev_: The former.
[20:03] <jpds> You can make as many commits as you like, it'll appear on the server exactly as 'bzr log' shows it.
[20:04] <orev_> ah, cool.  so if I were to have a job that committed every hour, for example, then push to the central once a day, from the central I will be able to see commits from each hour?  just wanted to clarify with an example
[20:05] <jelmer> orev_: Yep
[20:05] <orev_> cool
[20:05] <orev_> thanks
[20:06] <LarstiQ> bialix: I'm home
[20:07] <bialix> LarstiQ: good evening
[20:07] <bialix> I wrote you in the morning, I can repeat if you don't have log
[20:09] <bialix> in short: subprojects will wait some time
[20:11] <LarstiQ> bialix: I'll check my backlog. Ok, I'll write out the components then.
[20:11] <bialix> in the irclogs it's around 10:57
[20:11] <bialix> sorry for inconvenience, but I think I should finish new format stuff first
[20:12] <LarstiQ> that's ok
[20:12] <bialix> so I don't to rewrite subprojects support twice
[20:12] <LarstiQ> bialix: I have aline from you around 11:57 in my away log, was that it?
[20:12]  * LarstiQ nods
[20:12] <LarstiQ> bialix: that makes sense, and I can wait.
[20:12] <LarstiQ> I just wasn't sure if they were supposed to work or not, before we talked yesterday.
[20:13] <bialix> subprojects should help to make very big hierarchical projects
[20:13] <bialix> LarstiQ: they planned, but not implemented yet
[20:14]  * LarstiQ goes make some dinner
[20:15] <bialix> bon appetite
[20:15] <bialix> and perhaps bye
[20:22] <jam> vila: ping
[20:22] <jam> I want to chat quickly about your fix for bug #277537
[20:22] <vila> jam: pong
[20:25] <davidstrauss> This gives me an error: bzr branch bzr://vcs.fourkitchens.com/drupal/7-fic 7-fic-cvs-patch
[20:25] <davidstrauss> bzr: ERROR: No such file: ('trigger.info-20081206090157-hohh42o0mhstvdpe-503', 'bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py')
[20:28] <vadi2> Is there a way with bzr-gtk to browse the revisions of one file?
[20:34] <jelmer> vadi2, not at the moment
[20:35] <vadi2> alright
[20:35] <luks> time to install qbzr :)
[20:35] <luks> me hides
[20:36] <vadi2> what is the command there?
[20:36] <luks> bzr qlog path/to/file
[20:36] <luks> or bzr qblame path/to/file
[20:38] <lifeless> hi
[20:39] <vadi2> luks: thanks for the tip, but it doesn't display the file at that revision, only the commit notes and affected files
[20:39] <vadi2> but, I did find out what revisions was it changed at, so that helps.
[20:40] <luks> oh, maybe I misunderstood the original question then
[20:40] <vadi2> yes, I'd like to browse the file as the different snapshots
[20:41] <luks> there is qbrowse for browsing the whole tree at any revision
[20:41] <vadi2> yes, but I want a specific file only
[20:41] <luks> and it can launch a window that shows the file in that revision
[20:42] <davidstrauss> lifeless or jelmer: can you help me with the error I posted above?
[20:42] <james_w> hi lifeless
[20:43] <davidstrauss> It is making our Drupal developers not so happy.
[20:51] <kfogel> whoa.  On my brand-new ubuntu box, 'cd bzr.dev-trunk; sudo python setup.py install' fails, ending in:
[20:51] <kfogel> bzrlib/_patiencediff_c.c:1239: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘init_patiencediff_c’
[20:51] <kfogel>   Failed to build "bzrlib._patiencediff_c".
[20:51] <kfogel>   Use --allow-python-fallback to use slower python implementations instead.
[20:51] <kfogel> error: command 'gcc' failed with exit status 1
[20:52] <kfogel> I can use the suggested flag, but... I wonder why it won't build on this box, yet builds fine on my debian box.
[21:03] <ronny> jelmer: when will subvertpy hit the ubuntu pkg repos and can it use replay?
[21:03] <jelmer> ronny, it can use replay
[21:03] <jelmer> ronny, It's in Debian's NEW queue at the moment, I hope to get it into jaunty
[21:03] <ronny> any chance to get it into intrepid?
[21:04] <jelmer> ronny, intrepid is already out, it's hard to change now :-)
[21:04] <jelmer> there is a PPA with the latest subvertpy though if you want to install it on intrepid
[21:04] <ronny> ok
[21:05] <ronny> jelmer: is there a win32 port somewhere around?
[21:05] <jelmer> ronny, there isn't one published, but it should build on win32
[21:05] <jelmer> it built on Windows when it was still part of bzr-svn
[21:06] <ronny> im considering porting anyvc's svn support to it
[21:07] <jelmer> cool
[21:07] <mwhudson> vila: you still here?
[21:08] <vila> mwhudson: yup
[21:10] <jelmer> dwt, any luck?
[21:10] <dwt> yes!
[21:10] <dwt> It worked great
[21:10] <jelmer> cool
[21:10] <dwt> Now I need to convert my collegue to the current version and the trunk of the plugin
[21:10] <dwt> and we should be able to run with it. :)
[21:11] <jelmer> dwt, bzr-svn should work with bzr 1.11 again now fwiw
[21:12]  * awilkins just changed the version requirements and it worked
[21:14] <awilkins> jelmer: Who's built subvertpy on win32 so far?
[21:14] <jelmer> awilkins, not sure if anybody has tried since I split it out of bzr-svn
[21:14] <awilkins> jelmer: The win32/python installers still don't have the extensions built, I have to delete the svn plugin after it runs or my users will moan :-)
[21:15] <LarstiQ> davidstrauss: does that happen for everyone branching it?
[21:15] <davidstrauss> LarstiQ: yes
[21:15] <davidstrauss> LarstiQ: Revision 521 introduced the corruption
[21:15] <davidstrauss> LarstiQ: He's using the Windows client
[21:18] <LarstiQ> davidstrauss: ok, it happens here too.
[21:19] <LarstiQ> davidstrauss: it seems to happen in the working tree creation stage.
[21:20]  * LarstiQ runs reconcile
[21:20] <davidstrauss> LarstiQ: reconcile runs fine
[21:20] <davidstrauss> LarstiQ: even on the server branch
[21:23] <LarstiQ> davidstrauss: indeed. Next up, check.
[21:23] <dwt> jelmer: Yes I was very happy to be able to upgrade to head again
[21:23] <davidstrauss> LarstiQ: That fails.
[21:23] <dwt> :) Thanks for that
[21:24] <jelmer> awilkins: Is anybody aware those extensions aren't built?
[21:24] <jelmer> dwt, you're welcome
[21:25] <LarstiQ> davidstrauss: I'm not well versed enough in inventory to debug this.
[21:25] <awilkins> jelmer: I would imagine that anyone who ever installs the win32/python build is aware, because it bugs you for every command regardless
[21:25] <awilkins> jelmer: But in terms of build team, probably not.
[21:26] <awilkins> jelmer: 'cause it's been like that since it started to be included in the win32 package
[21:26] <davidstrauss> LarstiQ: Is there someone else who could look at it?
[21:26] <awilkins> Maybe I'm the only person who uses the python build?
[21:27] <awilkins> I like it because I can hack my live Bazaar, which is naughty but functional
[21:27]  * awilkins sumbits a bug
[21:27] <LarstiQ> davidstrauss: I agree lifeless would be a very good candidate. It's around his wakeup time now.
[21:30] <LarstiQ> davidstrauss: there are some extra revision after 521, how did people manage that?
[21:30]  * LarstiQ tries a lightweight checkout
[21:31] <davidstrauss> LarstiQ: I'm going to move my repaired branch to 7-fic and move the broken one to 7-fic-broken
[21:31] <LarstiQ> davidstrauss: repaired?
[21:32] <davidstrauss> LarstiQ: I took a good branch, merged changes to 520 and patched in changes 521-525
[21:32] <davidstrauss> LarstiQ: Merging anything 521 or later corrupted the branch
[21:33] <LarstiQ> aha
[21:33] <davidstrauss> LarstiQ: I've moved the branches now
[21:57] <davidstrauss> The corrupted one is at bzr://vcs.fourkitchens.com/drupal/7-fic-broken
[22:11] <lifeless> hi davidstrauss
[22:11] <davidstrauss> lifeless: hi
[22:11] <lifeless> davidstrauss: I have a little analyser I may get you to run
[22:11] <davidstrauss> lifeless: great
[22:11] <lifeless> but first, I need some food - will you be on in 15 ?
[22:11] <davidstrauss> lifeless: yes
[22:12] <lifeless> cool
[22:27] <davidstrauss> lifeless: I PMed you with my email address so I can get the utility.
[22:36] <jelmer> lifeless, when you're back
[22:36] <jelmer> lifeless, any idea what fs encoding pqm has?
[22:36] <lifeless> yes
[22:36] <lifeless> C
[22:36] <lifeless> I think
[22:36] <lifeless> or utf8
[22:36] <lifeless> it runs in cron
[22:36] <jelmer> hmm
[22:37] <jelmer> So I guess I can't test os.readlink() with non-ascii characters there then..
[22:37] <lifeless> davidstrauss: http://paste.ubuntu.com/111461/plain/
[22:37] <jelmer> (it's definitely not utf8)
[22:37] <lifeless> change the path at the top appropriately
[22:38] <jelmer> lifeless, thanks
[22:38] <lifeless> jelmer: well the test should be guarded for windows etc too :P
[22:38] <lifeless> jelmer: see other non-ascii tests
[22:41] <davidstrauss> lifeless: do i run this from the branch root?
[22:43] <lifeless> edit the 'ccan' string to the path to the branch
[22:51] <davidstrauss> lifeless: ok
[22:54] <davidstrauss> lifeless: I get ": No such file or directory", even after configuring ccan
[22:54] <lifeless> can I see the full error please
[22:55] <davidstrauss> [straussd@web3 ~]$ ./check_repo.sh
[22:55] <davidstrauss> : No such file or directory
[22:55] <davidstrauss> That is the full error
[22:55] <lifeless> its a python script :P
[22:55] <lifeless> try 'python check_repo.sh'
[22:55] <davidstrauss> ah, ok
[22:55] <davidstrauss> there we go
[22:56] <davidstrauss> [straussd@web3 ~]$ python check_repo.sh
[22:56] <davidstrauss> Checking 645 revs of 648
[22:56] <davidstrauss> ghost revisions: set([])
[22:56] <davidstrauss> missing texts(altered by) total: 3186 set([])
[22:56] <davidstrauss> related file details for missing keys:
[22:56] <davidstrauss> scanning for all references to missing keys
[22:56] <davidstrauss> lifeless: that's it
[22:56] <lifeless> it finished?
[22:56] <davidstrauss> lifeless: yes
[22:56] <lifeless> ok
[22:57] <lifeless> and this was the problem branch ?
[22:57] <davidstrauss> lifeless: yes
[22:57] <davidstrauss> lifeless: would you like a tarball of the branch?
[22:57] <lifeless> no thanks :)
[22:57] <lifeless> does 'bzr check' pass in the branch?
[22:57] <davidstrauss> lifeless: no
[22:57] <davidstrauss> if (self.text_sha1 != tree._repository.texts.get_sha1s([key])[key]):
[22:57] <davidstrauss> KeyError: ('trigger.info-20081206090157-hohh42o0mhstvdpe-503', 'bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py')
[22:57] <davidstrauss> that's what i get from check
[22:58] <lifeless> ok
[22:58] <davidstrauss> you can download the branch from http://straussd.fourkitchens.com/7-fic-broken.tgz
[22:58] <lifeless> what that discrepancy means is that there is a revision in the repository, *not* referenced from the branch, which for some reason does not have that file delta
[22:59] <lifeless> what format is the branch?
[22:59] <davidstrauss> lifeless: [straussd@web3 7-fic-repaired]$ bzr upgrade
[22:59] <davidstrauss> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[23:00] <lifeless> davidstrauss: 'bzr info'
[23:00] <davidstrauss> Standalone branch (format: pack-0.92)
[23:07] <lifeless> davidstrauss: in what way is it broken
[23:07] <lifeless> [I know check fails, but what user operation fails/goes wrong]
[23:08] <davidstrauss> lifeless: Try branching from bzr://vcs.fourkitchens.com/drupal/7-fic-broken
[23:08] <lifeless> interesting, thats in tree building
[23:08] <lifeless> I think I can tell you what has gone wrong in the past
[23:09] <edgimar> If I branch a trunk repository, make some changes to it, and then pull new changes from the trunk (merging), then it looks like the new-changes get merged into my changes, and not the other way around (from the revision numbers in the log command).  Is that right?
[23:09] <lifeless> edgimar: thats because you merged from the trunk
[23:10] <lifeless> edgimar: so of course they should show as merged into your branch
[23:10] <edgimar> How do I make it so that I am merging into the trunk, instead of the other way around?
[23:10] <lifeless> hang on
[23:10] <lifeless> you said trunk -> your branch
[23:10] <lifeless> do you mean your branch -> trunk ?
[23:11] <edgimar> I guess I mean that it's my branch of the trunk -- but..
[23:11] <edgimar> I thought you could have multiple branches in the same directory with bzr.
[23:11] <edgimar> Or not?
[23:12] <davidstrauss> lifeless: ping me when you're ready to talk again
[23:12] <edgimar> So, in principle, I could switch from one branch to another, which would just update the working-directory contents.
[23:12] <lifeless> you can certainly have one working dir and use it to edit different branches, using the switch commands to switch between them, or using pull --overwrite to turn one branch into a mirror of any other
[23:12] <davidstrauss> lifeless: I have to get back to Drupal.org upgrading stuff
[23:12] <lifeless> davidstrauss: yeah sorry, back with you asap
[23:13] <lifeless> edgimar: yes - 'bzr help switch'
[23:13] <lifeless> edgimar: 'push' and 'pull' make mirrors
[23:13] <lifeless> edgimar: so if you 'push' somewhere, it will end up an exact mirror of what you had in front of you
[23:14] <edgimar> lifeless: ok, so let's say I have 'my branch', which shares the same history as the trunk up until rev. 100, where I have made a change.  I want to merge that change into the trunk, and push it to the trunk.  So, what are the logical steps I need to follow to do that?
[23:14] <lifeless> edgimar: imagine that I own trunk
[23:15] <lifeless> edgimar: I would 'bzr merge your_branch; bzr commit -m"merged edgimar"; bzr push <public_mirror>'
[23:15] <ronny> anyone aware if bzr can run on ironpython/jython/pypy?
[23:15] <dash> ronny: quite unlikely
[23:16] <LarstiQ> ronny: jelmer though there was some ironpython going on with monodevelop iirc
[23:16] <dash> ronny: very few python programs run unmodified on them.
[23:16] <lifeless> edgimar: so, if you are owning trunk as well, you would do the same thing - cd $trunk, mege, commit, push-to-public
[23:17] <lifeless> edgimar: the complication is you want to have only one working copy at a time; this is easy, and there are two ways to do it: I'll describe the fully manual way so you can see the bits, then the shortcut
[23:17] <edgimar> lifeless: ok, but if I don't have 'the trunk' repo on my machine, does it make more sense to branch it into a new directory, or is there a nice way to use my existing branch and just create a new 'trunk' branch within that directory?
[23:17] <dash> edgimar: bzr keeps each branch in a separate directory
[23:18] <dash> but branches and working copies aren't the same, as lifeless appears to be about to explain :)
[23:18] <lifeless> edgimar: so if you do push your current branch somewhere (could be in the same repo, or $wherever), you can do the following sequence, starting from 'I'm done and I want to get this in trunk'
[23:18] <edgimar> lifeless: quite honestly, I say this because it is painful sometimes having to wait so long to branch something from launchpad, and if I can share the common history in my existing branch, it'd be fabulous...
[23:19] <edgimar> lifeless: ok, go ahead with what you were planning to say.
[23:19] <lifeless> edgimar: bzr push $my-branch; bzr pull --overwrite $trunk; bzr merge $my-branch; bzr commit -m 'merge my-branch'; bzr push $trunk
[23:20] <edgimar> lifeless: ok, got it.  So, the trick is to first duplicate my branch locally, then overwrite it with the trunk.
[23:20] <lifeless> right
[23:20] <lifeless> now, like I say there is a shortcut
[23:20] <lifeless> what it needs is that local duplicate to start with
[23:21] <lifeless> (doesn't even have to be local)
[23:21] <lifeless> so starting from the same point you are at today, with trunk on lp, and your local diverged copy
[23:21] <lifeless> bzr push ../$my-branch
[23:21] <lifeless> bzr bind $trunk
[23:21] <lifeless> bzr update
[23:22] <lifeless> (this will do a merge). resolve conflicts if needed
[23:22] <lifeless> bzr commit -m "Merged my-branch"
[23:22] <lifeless> then, to go back to your local copy, bzr switch ../$my-branch; bzr pull $trunk
[23:23] <lifeless> this converts your current local branch into a 'checkout' which can act like cvs/svn with a master location changes are pushed to on commit, and knows about mainline commits etc
[23:24] <edgimar> Why do you need to go back to your local copy in this case?  Can't you always just use bind?
[23:24] <lifeless> sure
[23:24] <lifeless> you can bind and unbind
[23:26] <edgimar> ok, I'll look more into it for the details.   Thanks for the help.
[23:26] <lifeless> np
[23:28] <ronny> hmm, the reexecute setup wont work on jython - no os.execvp (bzr line 45)
[23:30] <lifeless> davidstrauss: so
[23:30] <davidstrauss> lifeless: back
[23:30] <lifeless> davidstrauss: that revision isn't in your repository
[23:30] <spiv> ronny: and it'd try to execute a non-jython python anyway...
[23:30] <lifeless> davidstrauss: but there is a text compressed against one of the versions of it
[23:31] <davidstrauss> lifeless: ok
[23:31] <lifeless> do you have other branches?
[23:31] <lifeless> ones you might have been editing on 2008/12/06
[23:33] <lifeless> if we can find the branch with rev bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py
[23:33] <lifeless> we can fix this trivially
[23:37] <lifeless> you can use 'bzr cat-revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py' as a quick test for whether a branch has that revision in its repo
[23:40] <lifeless> while you look I'm going to peek a little more deeply
[23:41] <_Andrew> I've checked out a copy of my project and I have modified it for a completely new project, how do I make sure this different project is no associated with the old project?
[23:42] <lifeless> _Andrew: what do you mean?
[23:43] <_Andrew> Well I modified the old project for a new project however when I make a commit on this new project it's asking me for my password I use to upload to launchpad.
[23:44] <lifeless> if you did 'bzr checkout FOO' then when you commit it will commit to 'FOO'
[23:44] <lifeless> you should use 'bzr branch' if you want to make a new branch of something
[23:44] <_Andrew> is there a command I and use to "branch" it now?
[23:44] <_Andrew> I can use**
[23:44] <lifeless> you can convert the checkout to a normal branch by running 'bzr unbind'
[23:45] <_Andrew> ah thanks, that's what I am looking for. Is there a command to use which can check this information?
[23:45] <lifeless> bzr info
[23:46] <_Andrew> ok, it says stand alone tree, is this correct?
[23:47] <lifeless> thats our default, yes
[23:47] <_Andrew> ok, thanks a lot
[23:48] <lifeless> np
[23:52] <davidstrauss> lifeless: I get this from catting the rev: "bzr: ERROR: The repository file:///srv/bzr/repo/drupal/7-fic-broken/.bzr/repository/ contains no revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py."
[23:55] <jelmer> abentley: Hi
[23:55] <abentley> jelmer: hi
[23:56] <jelmer> abentley: All my submissions to merge@code.launchpad.net seem to be causing trouble for launchpad
[23:56] <jelmer> Am I doing something wrong?
[23:56] <abentley> Do  you have an oops id?
[23:56] <awilkins> davidstrauss: Suddenly missing repository?
[23:56] <jelmer> abentley, e.g. OOPS-1125CEMAIL2
[23:56] <davidstrauss> awilkins: pardon? it seems mostly just like some corruption
[23:57] <awilkins> davidstrauss: Ok, I had a problem recently where the entire repository vanished - might have been a stray shell command but I never pinned it down
[23:57] <abentley> jelmer: Do you have an older one?
[23:57] <davidstrauss> awilkins: I have not encountered that issue.
[23:57] <jelmer> abentley, yes, OOPS-1118CEMAIL9
[23:58] <abentley> jelmer: It looks like your merge directives have no source branch.
[23:59] <abentley> jelmer: LP currently can't use the bundle from a merge directive.
[23:59] <abentley> So you should use --no-bundle.
[23:59] <jelmer> abentley: Ah, ok
[23:59] <jelmer> abentley: Thanks!
[23:59] <abentley> jelmer: Fixing that is my current task.