[00:00] <igc> lifeless: well done!
[00:01] <igc> lifeless: I'll review that other patch this morning
[00:01] <igc> morning all
[00:01] <jml> good morning.
[00:03] <faceprint> I've got what is probably a dumb question, but I haven't been able to find an answer in any online docs or mailing list archives.  Is there a way to put a setting into branch.conf, commit it (or something to that effect) so it is shared?
[00:04] <james_w> thanks for releasing 1.17 jml
[00:05] <lifeless> faceprint: not currently
[00:10] <garyvdm> faceprint: you can push it some where that is shared though. What do you want to do exactly?
[00:12] <faceprint> i've written a plugin, and I want to put some settings for it into branch.conf so the entire team doesn't have to manually keep settings in sync
[00:13] <garyvdm> Ok - Now I understand. Sorry - can
[00:13] <garyvdm> 't help
[00:14] <lifeless> faceprint: you could have your plugin read from the tree
[00:21] <jml> james_w, my pleasure.
[00:31] <poolie> hi igc
[00:31] <igc> hi poolie
[00:31] <jml> can I set a submit branch without editing locations.conf?
[00:32] <poolie> jml, i don't think so
[00:32] <poolie> sending mail for a new rm
[00:33] <jml> thanks.
[00:34] <poolie> thanks jml, it's been good
[00:34] <Raim> jml: bzr send --remember? but probably not what you were looking for...
[00:35] <jml> Raim, it's pretty close actually, if I tack on a --no-bundle and -o-
[00:36] <jml> hmm. I get a warning about masked values.
[00:37]  * jml sets this problem aside
[00:40] <poolie> jml, our 4w schedule would have 2.0rc1 on 6 August and the final on the 13th
[00:41] <poolie> any comments on how that fits with lp rollout?
[00:42]  * jml checks out the calendar
[00:42] <mwhudson> launchpad isn't going to rollout in august most likely
[00:43] <jml> Next roll-out after 2.2.7 is 2.2.9 on Sept 23rd. Someone's going to announce this properly on the blog soon.
[00:43] <poolie> mm i saw that
[00:43] <poolie> well, let's say not 'rollout' in particular, but lp's development cycle in general
[00:44] <jml> poolie, a bzr upgrade is going to have to be special-cased no matter when it is.
[00:44] <jml> poolie, so, those dates are just fine.
[00:44] <poolie> k thanks
[00:45] <poolie> you know some people at canonical would not have said the second sentence and would have just left me wondering :)
[00:46] <jml> poolie, well, in this case I was figuring it out as I went along. the idiosyncrasies of a synchronous medium, don't you know?
[01:24] <lifeless> http://paste.ubuntu.com/223141/
[01:24] <lifeless> poolie: ^
[01:24] <lifeless> I'm about to ring to double check this
[01:24] <lifeless> and talk about the other stuff you msged me
[01:24] <poolie> to ring me
[01:24]  * poolie braces
[01:24] <poolie> ok then
[02:53] <mwhudson> more things that aren't thread safe in bzrlib!
[02:54] <mwhudson> progress bars
[02:55]  * mwhudson attempts to phrase this more usefully
[02:55] <poolie> hm
[02:56] <mwhudson> basically i think one wants a ui factory per thread
[02:57] <mwhudson> i also don't know if the consequences of the unsafety are at all important
[03:04]  * igc lunch
[03:05] <mwhudson> seems likely it's pretty harmless
[03:21] <poolie> mwhudson: it's not clear to me what kind of threadsafety it ought to work
[03:22] <mwhudson> poolie: the
[03:22] <mwhudson>             warnings.warn("%r is not the active task %r"
[03:22] <mwhudson>                 % (task, self._task_stack[-1]))
[03:22] <mwhudson> warning trips occasionally
[03:23] <poolie> yeah
[03:23] <poolie> this uifactory assumes the code is singlethreaded
[03:23] <poolie> so the warning is saying, you need something else
[03:23] <SamB> GTK isn't threadsafe either
[03:23] <poolie> the text mode progress bars will be unhappy if you run multiple threads there
[03:23] <SamB> it freaks out if you call the it from more than one thread
[03:23] <poolie> if this happens even when you have them off, as it probably does, it's a bug
[03:23] <poolie> that i may fix sometime
[03:24] <poolie> but more seriously, lots of code in bzr has state that's unsafe to run concurrently
[03:24] <lifeless> thats ok, python can't do it anyway
[03:24] <poolie> there's not really any contract that you're allowed to do it
[03:24] <poolie> or to do it under particular conditions
[03:25] <SamB> poolie: just stop mutating stuff
[03:25] <SamB> then you're fine!
[03:28] <mwhudson> poolie: this happens with SilentUIFactory too
[03:29] <poolie> ok i agree that's a bug; probably not worth filing as i'll probably fix it next time i refactor there...
[03:29] <mwhudson> cool
[03:29] <mwhudson> i got a bit worried that it was screwing things up, but that was something else
[03:29] <mwhudson> if it just produces a warning now and then (which i think is what it does) i don't really care
[03:30] <poolie> if you're keen you can change silentuifactory not to have that code
[03:31] <mwhudson> i still owe you a patch to make TextProgressView more parameterizable i think
[03:35] <mwhudson> hm, is merge --preview broken?
[03:46] <lifeless> mwhudson: details
[03:47] <mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/402022
[04:00] <jfroy> $ bzr log -r -1 lp:rivenx/trunk/0.8
[04:00] <jfroy> bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked
[04:00] <jfroy> :sad:
[04:01] <fullermd> Objects just wanna be free.
[04:14] <poolie> mwhudson: looks like a qbzr problem, try updating that first?
[04:15] <poolie> hi jfroy, look for an existing bug, it sounds familiar and may be fixed
[04:15] <jfroy> well not in 1.17 :|
[04:15] <jfroy> not a huge deal
[04:16] <mwhudson> poolie: seems you are right
[04:16] <mwhudson> sorry for the noise
[04:17] <poolie> maybe apport should automatically google for the exception :)
[04:17] <poolie> jfroy: https://bugs.edge.launchpad.net/bzr/+bug/389413
[04:18] <jfroy> Similar, though my command was log
[04:19] <jfroy> Added a comment to say so.
[04:29] <spiv> jfroy: I think jml or mwhudson filed one about log recently
[04:30] <jml> I did.
[04:30] <spiv> Possibly the same bug, possibly not.
[04:30] <jml> It's probably a dupe.
[04:32] <jml> missing doesn't take a -d parameter. woe. :(
[04:45] <SamB> grr ... latest bzr nightly seems to make the bzr-fastimport tests fail
[04:59] <SamB> igc: did you notice that bzr-fastimport breaks w/ the latest nightly PPA bzr?
[05:00] <igc> samB: no, but I half expected it
[05:00] <lifeless> bad deltas?
[05:01] <igc> samB: please raise a bug and I'll look at it soon
[05:01] <igc> lifeless: I'd expect so
[05:01] <fullermd> Is the expected half the fast or the import?   O:-)
[05:01] <igc> fullermd: the import
[05:02] <igc> fullermd: it will be *real* fast I expect
[05:02] <fullermd> Shucks.  Oh well, at least it's still fast.
[05:02] <lifeless> igc: I'd hope not
[05:02] <igc> fullermd: it will exit quickly I suspect :-)
[05:03] <igc> fullermd: it just won't work as such
[05:03] <SamB> igc: I also discovered that bug #401249 is worse than I thought
[05:03] <SamB> well, that might also be better, though
[05:04] <SamB> since it means I definately don't have to untangle anything from the head-tracking code ;-)
[05:05] <SamB> igc: what format would you like the test results pasted in?
[05:05] <igc> samB: not sure I understand the question
[05:06] <SamB> just regular, or subunit, or?
[05:06] <igc> SamB: regular is fine
[05:07] <lifeless> :P
[05:16] <SamB> https://bugs.launchpad.net/bzr-fastimport/+bug/402041
[05:17] <SamB> ubottu: that's not an ubuntu bug!
[05:17] <SamB> I sure don't!
[05:34] <lifeless> SamB: wheee, fun
[05:34] <SamB> lifeless: the selftest errors?
[05:34] <lifeless> yah
[06:39] <lifeless> EOD For me
[06:39] <lifeless> see youall tomorrow
[06:39] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928 still needs review
[06:48] <lifeless> jml: any chance you'll review my subunit branch this avo?
[06:48] <jml> lifeless, a reasonably strong one actually.
[06:48] <lifeless> woo
[06:48] <lifeless> thanks
[06:49] <lifeless> I'm going to do another patch tonight to output time:
[06:49] <lifeless> would you enjoy a subunit talk @ slug?
[06:50] <jml> I haven't been to slug since 2007
[06:50] <jml> :)
[06:50] <jml> lifeless, but it sounds like a good idea.
[07:49] <poolie> lifeless, all the cool kids go to fp-syd now :)
[07:49] <poolie> it's just about functional too :)
[07:50] <lifeless> poolie: sadly, fp-syd is on thursdays
[07:56] <poolie> wow
[07:57] <lifeless> poolie: ?
[07:57] <poolie> the release
[07:57] <poolie> that's great
[08:00] <jml> which release?
[08:00] <jml> :D
[08:01] <bob2> 57408   .bzr/repository
[08:01] <bob2> 174084  backup.bzr/repository
[08:01] <bob2> ^ good work
[08:01] <lifeless> welcome to bzr 2
[08:17] <bialix> igc: helllo
[08:18] <igc> hi bialix! How are you?
[08:18] <bialix> I'm still trying to enter work-mode
[08:18] <bialix> sorry for delay with tarballs
[08:19] <bialix> I'll upload them now
[08:19] <igc> bialix: yes, it took me several days last week to get going again - well after the 900 emails in my inbox were triaged :-)
[08:19] <bialix> the same here
[08:19] <igc> bialix: the tarball is done, the Windows installer is not
[08:20] <bialix> ok
[08:20] <bialix> will do
[08:21] <bialix> last night I've realized there is hidden bug in my check of bzr version
[08:23] <bialix> igc: so what revno I should package to installer? rev 191 tagged as release-0.5, but there is also rev 192
[08:23] <igc> bialix: 192
[08:24] <bialix> I'll update the tag
[08:24] <igc> I tried to move the tag using qtag but it may not have pushed correctly
[08:25] <bialix> push --overwrite should do. I've pushed updated tag. please, check it
[08:28] <bialix> igc: there is two test package now?
[08:28] <bialix> one in the root and other in lib
[08:31] <garyvdm> Hi bialix/igc
[08:32] <bialix> hi garyvdm
[08:35] <bialix> igc: installer has been uploaded
[08:35] <igc> bialix: thanks
[08:35] <igc> hi garyvdm!
[08:49] <bialix> garyvdm: I'd like to have buttons Refresh and Diff swapped in qcommit
[08:50] <poolie> hi bialix, garyvdm
[08:50] <bialix> hi poolie
[08:53] <bialix> garyvdm: btw, your error dialog is very nice, but I wonder if we should suggest to users file bugs against qbzr and not bzr itself?
[09:06] <LarstiQ> bialix: can you detect which part the bug lies?
[09:07] <bialix> well, I mean errors in GUI very often occurs because of internal qbzr error
[09:07] <bialix> anyway we can reassign bug later
[09:08]  * LarstiQ nods
[09:08] <LarstiQ> bialix: it sounds good to me.
[09:08] <LarstiQ> bialix: but detecting where the problem lies would be cool. Even better if you can detect why, next step is automatically fixing it! ;)
[09:08] <bialix> by recompiling python bytecode!
[09:09] <bialix> like in Chrome browser
[09:09] <LarstiQ> changing running programs I sometimes really miss
[09:22]  * igc dinner
[09:24]  * bialix bbl
[12:01] <LarstiQ> lifeless: can you upload bzr 1.17 to Debian, or should someone else do that?
[12:01] <lifeless> LarstiQ: someone  else should :)
[12:01] <LarstiQ> ok
[12:01] <lifeless> little busy atm
[12:01]  * LarstiQ will see if he can prepare that
[12:03] <jelmer> LarstiQ: I've got it prepared here, just need to find my gpg key
[12:03] <LarstiQ> jelmer: sweet!
[12:04] <jelmer> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/c0ae45a26df55c3bfbb79c0523c4de78.pack is redirected to https://launchpad.net
[12:04] <LarstiQ> jelmer: does anyone over there know anything about openpgp cards with non-sha1 yet?
[12:05] <LarstiQ> jelmer: could you try again? some admin fiddling was going on
[12:06]  * jelmer tries again
[12:09] <lifeless> jelmer: we had a server issue
[12:10] <lifeless> jelmer: its resolved-for-now, but the root cause requires code changes. mwhudson is working on those.
[12:10] <jelmer> lifeless: ah, thanks
[12:42] <gnomefreak> is there another way to push to a branch other than lp:~? its stalling at 43%
[13:07] <TheJosh> Hi all
[13:09] <TheJosh> does a bzr+ssh server require regular ssh accounts on the server (i.e. user accounts)
[13:13] <bob2> yes
[13:13] <bob2> it is over ssh, after all ;)
[13:15] <TheJosh> so is there a way to tell sshd to only accept bzr connections, but not shell connections? I would prefer if my various users were not able to have shell access to my server
[13:18] <awilkins> TheJosh: Make the default shell for their user /bin/false
[13:18] <TheJosh> thanks
[13:28] <garyvdm> gnomefreak: I think you can push to lp using sftp.
[13:28] <LarstiQ> bob2, TheJosh: you can also use a custom ssh server
[13:29] <garyvdm> gnomefreak: try changing the the bzr+ssh://bazaar.lau... address to sftp://bazaar.lau...
[13:29] <garyvdm> gnomefreak: It will probably be much slower.
[13:31] <gnomefreak> garyvdm: as long as it doesnt stall im happy. ill try now
[13:32] <TheJosh> Now I'm getting "bzr: ERROR: Connection closed: please check connectivity and permissions" when I try to checkout. I thought I read something about that somewhere, but I cannot remember where
[13:32] <gnomefreak> garyvdm: this command? bzr push sftp://bazaar.launchpad.netgnomefreak/firefox/firefox.dev
[13:33] <garyvdm> yes
[13:33] <gnomefreak> garyvdm: thanks
[13:34] <gnomefreak> im getting permission denied and i know my ssh key passphrase is right
[13:35] <LarstiQ> gnomefreak: you're missing a slash there
[13:35] <LarstiQ> and a ~
[13:35] <gnomefreak> bzr: ERROR: Permission denied: "/gnomefreak/firefox/firefox.dev": [Errno 13] mkdir failed
[13:35] <LarstiQ> gnomefreak: ~gnomefreak/
[13:35] <gnomefreak> LarstiQ: i fixed the slash
[13:35] <gnomefreak> ah thanks LarstiQ
[13:35] <LarstiQ> TheJosh: does it mention a public key?
[13:36] <TheJosh> Nope. What I pasted is the entire error message
[13:36] <gnomefreak> LarstiQ: thats working ill let you know if it stalls too
[13:36] <garyvdm> gnomefreak: I suspect that launchpad may be slow today due to a rush to download the launchpad code.
[13:36]  * garyvdm checks if it's on slashdot yet.
[13:37] <garyvdm> Nope not on slashdot yet.
[13:37] <LarstiQ> garyvdm: this would be an opportune moment to make use of the decentralized nature of bzr
[13:38] <LarstiQ> TheJosh: could you pastebin the complete transcript from the point where you enter the command used?
[13:38] <TheJosh> sure
[13:39] <garyvdm> larstiq: But of course people will want to get it from the _canonical_ location...
[13:39] <TheJosh> http://pastebin.com/d67cd919
[13:39] <garyvdm> lame...
[13:39]  * awilkins beats garyvdm with the punstick
[13:39] <LarstiQ> fwiw I have a copy I could seed
[13:40] <awilkins> I've already decided to grab the LP sources _later_
[13:40] <awilkins> Not least because the dependancies are huge and my ISP will throttle my connection unless I download them after 2100
[13:40] <LarstiQ> TheJosh: k, you could try and see if adding -Derror enlightens more, but at this point I would try and see if `ssh TheJosh@chaoticrage.com` works
[13:41] <awilkins> From #launchpad : < wgrant> Currently downloading Launchpad at 0KB/s
[13:41] <TheJosh> It connects, and then dies instantly - because I set the shell to /bin/false
[13:41] <awilkins> Methinks LP is doomed to be rather slow for quite a few hours
[13:42] <garyvdm> Hi bialix
[13:42] <bialix> hi Gary
[13:44] <garyvdm> bialix: Can't reproduce bug 402103, and I have no idea what it could be.
[13:45] <garyvdm> Can you try a minimal test case:
[13:45] <garyvdm> cb = QtGui.QCheckbox()
[13:46] <garyvdm> cb.setCheckState(0)
[13:46] <bialix> you want me to check it in python shell?
[13:46] <garyvdm> yes please
[13:46] <bialix> it will be not fair experiment
[13:46] <bialix> because I'm running bzr.exe
[13:48] <LarstiQ> TheJosh: can you ssh in?
[13:48] <TheJosh> I can SSH in
[13:48] <TheJosh> LarstiQ, I can SSH in, but the shell exits straight away because I set the shell to be /bin/false
[13:49] <bialix> garyvdm: QWidget: Must construct a QApplication before a QPaintDevice
[13:49] <bialix> I have segfault
[13:49] <LarstiQ> TheJosh: ah, that may be it.
[13:50] <LarstiQ> TheJosh: have a look at contrib/bzr_access instead
[13:50] <bialix> (Pdb) cb.setCheckState(0) *** TypeError: argument 1 of QCheckBox.setCheckState() has an invalid type
[13:52] <garyvdm> bialix:  Please can you try:
[13:52] <TheJosh> LarstiQ, How does that help my problem?
[13:52] <garyvdm> cb.setCheckState(QtCore.Qt.Unchecked)
[13:52] <LarstiQ> TheJosh: instead of setting to /bin/false, which I'm rather sure is what is denying you to login
[13:52] <LarstiQ> or well
[13:53] <LarstiQ> run bzr over ssh
[13:53] <garyvdm> bialix: I suspect that if you upgrade to PyQt4.4 it will be fixed.
[13:53] <bialix> garyvdm: I'm already running PyQt 4.4.3
[13:53] <TheJosh> LarstiQ, isn't that what i'm trying to do, run bzr over ssh (i.e. bzr+ssh://)
[13:53] <garyvdm> Oh
[13:53] <LarstiQ> TheJosh: yes, but you can't, because your shell is /bin/false
[13:54] <LarstiQ> TheJosh: I might be wrong, but that is how I analyze the situation
[13:54] <bialix> garyvdm: as discussed we stopped to support 4.3, and I've switched to latest available
[13:54] <awilkins> LarstiQ: That might be my fault... I was of the opinion that it would prevent shell logins.. .but not running bzr
[13:54] <TheJosh> or I just run through sftp://
[13:55] <bialix> awilkins: hi, can you explain what's wrong with qconflicts so you don;t use it?
[13:55] <awilkins> bialix: Didn't know it was there!
[13:55] <awilkins> bialix: Ooh, shiny
[13:55] <awilkins> bialix: IT was absent when I first started using qbzr
[13:55] <bialix> garyvdm: cb.setCheckState(QtCore.Qt.Unchecked) is worked
[13:56] <bialix> awilkins: it was added many months agop
[13:56] <gnomefreak> using sftp im getting Connection to bazaar.launchpad.net closed by remote host.d 1211/1295
[13:56] <LarstiQ> TheJosh: sure, that is an option, though slower
[13:57]  * garyvdm wonders how many other cool qbzr feature there are that people are not aware of.
[13:57] <bialix> btw vila broke qpush
[13:57] <gnomefreak> list them in bzr --help?
[13:57]  * awilkins awilkins runs `bzr help commands | grep q`
[13:57] <TheJosh> So why does bzr not have any decent access controls, thus preventing me from using the bzr:// smart-server directly. Argh so annoying!
[13:58] <bialix> and vila away on vacation, rats, I have no person to poke
[13:58] <garyvdm> awilkins: Not just commands.
[13:59] <gnomefreak> i dont get it sunbird pushed fine but firefox branch wont push
[13:59] <awilkins> TheJosh: The only access you can control in a DVCS is to transports, so it doesn't make sense for bzr to implement access controls when there are so many nice implementations on existing transports
[13:59] <luks> awilkins: the first version of qconflicts was actually written for you exclusively, because you were complaining how that's the only thing you use bzr-gtk for :P
[13:59] <bialix> hi luks
[13:59] <luks> hey
[14:00]  * awilkins blsuhes
[14:00] <garyvdm> gnomefreak: I suspect that this is a hosting issue. Maybe they will be able to help you at #launchpad
[14:00] <garyvdm> Hi luks
[14:00] <gnomefreak> garyvdm: thanks ill ask
[14:01] <garyvdm> bialix: How is qpush broken?
[14:01] <awilkins> qbzr and external merge apps ; does it permit selection on patterns?
[14:02] <awilkins> And does the definition permit formats?
[14:02] <bialix> garyvdm: push complains when wt is not clean, me working with lightweight checkout, but qpush is started in the root of the master branch that has out-of-date tree
[14:02] <bialix> so now we have to "fix" qpush, thanks to vila
[14:03] <LarstiQ> bialix: --no-strict?
[14:03] <bialix> maybe, but anyway it's not there right now
[14:04] <luks> awilkins: I'm not sure I understand the question, but it uses the same format as extmerge
[14:05] <awilkins> luks: I patched bzr-gtk for my own use to accept a python format-string because the way it built args didn't work too well on windows
[14:06] <awilkins> luks: Looking at the implementation in qbzr it looks similar only it uses replace instead of format
[14:11] <garyvdm> luks: I also use a patched version of extmerge. And I could not get conflicts to do what I wanted - I should just fix it my self but I've not had time.
[14:12] <garyvdm> I want it to run meld bar.py.THIS bar.py bar.py.OTHER
[14:14] <luks> "meld %t %r %o" doesn't work?
[14:18] <bialix> btw, qconflicts does not support winmerge
[14:18] <TheJosh> awilkins, surely a 'smart' server, which provides its own transport, should be able to proved basic authentication
[14:20] <LarstiQ> TheJosh: very little people run bzr://
[14:20] <LarstiQ> hmm, that came out wrong
[14:21] <TheJosh> LarstiQ, perhaps because it doesn't have authentication
[14:21] <LarstiQ> TheJosh: rather, because we alread have ssh I think
[14:21] <TheJosh> yeah, but then I am opening up everyone to my entire VPS.
[14:22] <LarstiQ> TheJosh: but have a look at http://pypi.python.org/pypi/ClueBzrServer/0.2
[14:23] <TheJosh> thanks
[14:25] <garyvdm> bialix: please will you see if lp:~garyvdm/qbzr/bug402103 works
[14:29] <bialix> garyvdm: it works, but strange
[14:29] <garyvdm> bialix: Your PyQt is more fussy than mine.
[14:30] <bialix> if I have tree w/o changes and then change file and refresh there appears additional columns: date/size etc
[14:30] <garyvdm> bialix: TreeWidget never shows the size.
[14:31] <garyvdm> Is this is qcommit?
[14:31] <garyvdm> *in
[14:31] <bialix> garyvdm: it seems like PyQt4.4.x Windows build is much worse than 4.3.1
[14:31] <bialix> in qcommit, yes
[14:32] <garyvdm> bialix: That's surprising. Please will you imagebin a screenshot.
[14:33] <bialix> may be I need file a bug?
[14:34] <garyvdm> bialix: ok
[14:34] <bialix> garyvdm: http://imagebin.ca/view/5nu7sR.html
[14:35] <garyvdm> bialix: it should be easy to change qpush to change subprocess starting dir, instead of using -d
[14:36] <garyvdm> bialix: that is a bug.
[14:36] <bialix> I'll file it
[14:37] <luks> speaking of qci, would somebody object if I get rid of the help text in the Branch group (when committing to a checkout)?
[14:37] <bialix> garyvdm: any ideas about bug 402100?
[14:37] <luks> I don't think it belongs there and it takes space
[14:37] <garyvdm> bialix: looking at that screen shot, I realized that Bug 402100
[14:37] <garyvdm> is due to your pyqt version
[14:38] <garyvdm> I'll boot into windows just now to fix it.
[14:38] <bialix> luks: it was idea of Mark Hammond, I never was big fan of big texts there
[14:38] <awilkins> What do you dudes use to make the UI? QtCreator?
[14:38] <bialix> QtDesigner
[14:38] <luks> I'd rather write a manual than have that text in UI
[14:38] <garyvdm> aqilkins: some times
[14:39] <bialix> some dialogs hand written
[14:39] <garyvdm> ^^^ most of the time.
[14:39] <bialix> :-)
[14:39] <bialix> Designer is very good to mock UI
[14:41] <bialix> garyvdm: btw about your cool idea to show revision message in qdiff: may be we need to do it all the time when qdiff running as qdiff -cN ?
[14:42] <garyvdm> Yes
[14:42] <luks> yeah, I'd like that too
[14:43] <garyvdm> I personally don't use that very often. I normally go into qlog - then dbl click on a rev.
[14:44] <bialix> IIRC gitk shows diff right in the log window when user selects revision
[14:44] <garyvdm> and vis shows it in a tab
[14:45] <bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/402218
[14:45] <garyvdm> bialix: thanks
[14:45] <luks> gitk can do that, because git is fast enough :)
[14:46] <luks> even getting the revision delta is slow in bzr
[14:46] <CaMason> hi guys. I took a branch, and I've made a number of commits to it. I've now made a change to a single file, and I'd like to merge that single change into the parent branch. Is this possible?
[14:47] <awilkins> CaMason: Yes, for given values of yes
[14:47] <garyvdm> luks: meld %t %r %o - gives me "Error while running merge tool (code 0)"
[14:47] <luks> hm
[14:47] <CaMason> would you mind explaining the process at all?
[14:47] <awilkins> CaMason: You can i) Cherrypick that revision into parent, ii) start a new branch off parent, make the change there and merge it into both branches
[14:47] <CaMason> brilliant, thanks I'll look that up
[14:50] <CaMason> with option2, should I uncommit from my branch before merging it in from the new new branch?
[15:05] <garyvdm> bialix: I can't reproduce  bug 402218.
[15:05] <garyvdm> I tried in a lw checkout
[15:06] <garyvdm> Where the wt tip is older than the master branch tip
[15:07] <bialix> bug 402218 is not related to lt checkout I guess
[15:07] <garyvdm> Ah - bialix: If you scroll to the right, do you see the status column
[15:07] <garyvdm> I think that all columns are visible
[15:08] <garyvdm> I originally thought that it was because it had a RevisionTree, and not a WorkingTree.
[15:08] <bialix> garyvdm: yes, the status column here
[15:09] <bialix> I've used small window size to reduce screenshot
[15:10] <bialix> garyvdm: additional columns appears only if you start qci in clean tree (without any changes)
[15:52]  * GaryvdM reading the comments in http://news.slashdot.org/story/09/07/21/1224259/Canonical-Fully-Open-Sources-the-Launchpad-Code while I wait for bzr to pull lp:qbzr very slowly...
[15:59] <Tak> heh
[16:35] <bialix> GaryvdM: another problem with qci: when I have pending merge and many many renamed files in subfolder then scrolling wt view does not repaint it until I click mouse on some item
[16:36] <GaryvdM> bialix: Ok - please will you try get a screenshot
[16:36] <bialix> screenshot?
[16:37] <bialix> I'm not sure
[16:37] <bialix> it's need to see in action
[16:38] <GaryvdM> bialix: ok - Please log a bug.
[16:39] <GaryvdM> I just managed to fix one of the column bugs. - Looking up the bug number.
[16:44] <GaryvdM> bialix: Bug 402218 fixed :-)
[16:44] <ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
[16:45] <ubott2> Ubuntu bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released]
[16:45] <ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
[16:45] <bialix> lol
[16:45] <bialix> ubottu fight with ubott2
[16:45] <GaryvdM> These bots need to chill!
[16:49] <beuno> I don't have op access to remove him  :/
[16:53] <GaryvdM> Hi beuno
[16:53] <beuno> hi GaryvdM!
[16:54] <GaryvdM> Must be an exciting day for everyone at Canonical!
[16:56] <beuno> it is  :)
[16:56] <beuno> we're very happy about the release
[16:56] <beuno> you don't drop a few million lines of code into the world every day
[16:57] <bialix> amazing
[17:01] <bialix> interesting, why codehosting is open sourced in the end?
[17:02] <beuno> bialix, Mark decided to release everything. That's about as much as any of us know  :)
[17:02] <bialix> hm
[17:03] <luks> marketing is usually the reason for such decisions :)
[17:03] <beuno> luks, not in Canonical  ;)
[17:04] <luks> I don't believe that
[17:04] <beuno> you should work for us for a while then
[17:09] <GaryvdM> bialix: bug 402100 seems to be a qt bug with using ResizeToContents and having check boxes.
[17:10] <ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
[17:10] <ubott2> Ubuntu bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed]
[17:10] <ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
[17:10] <bialix> any chance on workaround?
[17:11] <GaryvdM> One solution would be to Stretch the filename and ResizeToContents of the status.
[17:11] <GaryvdM> That did not work to well with qbrowse - cause the status is then to far away from the filename
[17:13] <bialix> GaryvdM: maybe just to not use ResizeToContents in qci?
[17:14] <GaryvdM> ok
[17:16] <bialix> GaryvdM: btw, many thanks to qlog branch1 branch2 --> it's fantastic for doing complex repeated merge of 2 diverged branches!
[17:16] <bialix> I mean refresh
[17:16] <GaryvdM> :-)
[17:24] <igc> night all
[17:30]  * bialix waves
[18:03] <KhaZ> Hrmm, weird problem I'm having.  I'm running bzr under cygwin.  I've got a ~/.bazaar/bazaar.conf with an alias set up for bzr st.  If I use the bzr that ships with cygwin, the alias gets triggered on bzr st.  If I use the win32 native bzr, the alias doesn't trigger.
[18:03] <KhaZ> Does the native and the cygwin binaries have different locations for $HOME?
[18:03] <KhaZ> Oh, just read online about %APPDATA%... Damn.
[18:04] <luks> you can put your config to %APPDATA% and make a symlink to that from cygwin's home
[18:04] <KhaZ> I thought symlinks don't work properly in cygwin - aren't they just copies?
[18:04] <luks> I don't know actually
[18:04] <luks> I just expected them to work
[18:04] <KhaZ> Yeah; me too. :(
[18:05] <KhaZ> That said, it would work.  The only irritation is that I version control my home directory, so now I have to install something outside of my home directory to make this work.
[18:05] <KhaZ> I wonder why the difference between Windows an Unix versions?  It would be so convenient to always have it in $HOME, at least in (my) theory. ;)
[18:06] <luks> native applications on windows don't put their data directly in the home directory
[18:06] <luks> while native applications on unix do that
[18:06] <KhaZ> Right.  So is it just a matter of following the default policy on the platform you're on?
[18:06] <luks> I guess so
[18:06] <KhaZ> As in, bzr has no requirement to use $APPDATA except for conforming to the OS it's on?
[18:07] <KhaZ> (Just curious here.)
[18:07] <luks> you can set $BZR_HOME if you want
[18:07] <luks> yes
[18:07] <KhaZ> Oh.  That sounbds awesomer.
[18:09] <KhaZ> Huh.  Setting BZR_HOME yields a No handlers could be found for logger "bzr" error.
[18:10] <KhaZ> "bzr: ERROR: [Error 3] The system cannot find the path specified: '/cygdrive/c/Documents and Settings/eparker/bazaar'"
[18:10] <KhaZ> export BZR_HOME="$HOME" should work, no?
[18:10] <luks> you can't access that path from native windows
[18:11] <KhaZ> Oh.  Duh
[18:11] <KhaZ> Right
[18:11] <KhaZ> It's using the native binary but it doesn't know WTH /cygdrive is.
[18:11] <KhaZ> My bad.
[18:17] <KhaZ> Ack.  $BZR_HOME doesn't set the root of where the config files.  I still need to duplicate my configs.  I'm reading the ConfiguringBzr page and there doesn't seem to be an env-var for 'this is the root of bazaar\'s configs variable'.  Any chance you know of one, luks?
[18:17] <KhaZ> (Right now I've got ~/.bazaar/[my config files] and ~/.bazaar/bazaar/2.0/[my config files], which is rather uggo.
[18:18] <luks> can't you just set BZR_HOME differently on windows and cygwin?
[18:19] <luks> make it point to %APPDATA%/bazaar/2.0 on windows
[18:19] <luks> and ~/.bazaar on cygwin
[18:19] <KhaZ> I can, but it looks like on windows/cygwin they append the directory bazaar/2.0/ to whatever BZR_HOME is.  On Linux they just append .bazaar to it.
[18:19] <luks> oh, hm
[18:19] <KhaZ> Hence my problem.  I need two directories to version my config files.
[18:20] <KhaZ> I suppose I could read the source to figure it out if need be.
[18:20] <KhaZ> It seems like a strange behaviour to have an env var for a partial path.
[18:21] <luks> that sucks, there doesn't seem to be a way around it
[18:22] <KhaZ> That does suck.  Maybe I'll write a ticket about it; see if the devs think it's a good idea.  Definitely would help me.
[18:22] <luks> changing the behavior of BZR_HOME is most likely not an option
[18:22] <luks> but a new variable could be added
[18:23] <KhaZ> That's what I'm thinking.  I hate to suggest yet another env var, but that would probably hurt the least people.
[18:24] <KhaZ> Ah; looks like there's already a bug for it.
[18:24] <KhaZ> https://bugs.launchpad.net/bzr/+bug/348640
[18:24] <ubott2> Ubuntu bug 348640 in bzr "Want a variable to override location of ~/.bazaar etc" [Low,Confirmed]
[18:26] <luks> this is trivial to fix
[18:27] <luks> but there is no way I'm sending a patch to bzr again :)
[18:28] <KhaZ> Hah; why's that luks ? :)
[18:30] <luks> let's not discuss that :)
[18:30] <luks> http://paste.pocoo.org/show/129942/
[18:30] <luks> if you want you can take this, add a test and submit it
[18:31] <KhaZ> Oh, hot.  Easiest fix I never had to write. ;)
[18:31] <KhaZ> I'll monkey with that and see.  I wonder if my last patch ever got taken... I never did follow up on it.
[18:37] <nickoe> How do I update to a specific revision?
[18:42] <luks> nickoe: you can't update a checkout to a specific revision
[18:42] <luks> nickoe: what exactly do you want to do?
[18:42] <nickoe> revert a file
[18:43] <luks> then "bzr revert -rX FILE"
[18:46] <nickoe> luks: $  bzr revert -rX main.c
[18:46] <nickoe> bzr: ERROR: No namespace registered for string: u'X'
[18:47] <luks> replace X is the revision you want
[18:47] <luks> or use "bzr revert main.c" if you want the last committed revision
[18:47] <luks> er, s/is/with/
[18:49] <nickoe> $  bzr revert -r1 main.c
[18:49] <nickoe> bzr: ERROR: Not a branch: "/some/silly path to my file/main.c/".
[18:49] <nickoe> i am exec in /some/silly path to my file/
[18:50] <nickoe> luks, what is wrong?
[18:50] <luks> /some/silly path to my file/ is probably not a branch
[18:50] <nickoe> luks, does it have to be?
[18:51] <luks> you normally want to rever a versioned file
[18:51] <luks> *revert
[18:51] <luks> and such a file must be in a branch
[18:52] <nickoe> ohh, ofc, I am in the woring project, :P
[18:54] <Kinnison> Anyone know how harmful messages like this are: inconsistent details in skipped record: ('michael.hudson@canonical.com-20070704120851-qih0ajr8ie2csj6m',) ('97295 243 0 276', ((('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',),),)) ('781826 243 0 276', ([('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',)],))
[19:00] <nickoe> luks, thank you, bye
[20:25] <j^> why does  bzr branch lp:launchpad need like 500mb ram?
[20:27] <j^> looks like its even still growing
[20:28] <j^> this is with Bazaar (bzr) 1.16.1
[20:29] <j^> 912m 708m 1592 S   44 36.3   3:07.53 bzr
[20:33] <LarstiQ> j^: is that over http or ssh?
[20:34] <j^> LarstiQ, i think http, i have an account on lp though and it usually uses ssh if i do bzr lp:something
[20:34] <j^> upgrading now to 1.17 and will try again
[20:35] <LarstiQ> j^: I think the relevant bug might be https://bugs.edge.launchpad.net/bzr/+bug/402657
[20:36] <LarstiQ> j^: hmm, or maybe a related one
[20:37] <j^> [#########/          ]   3792KB    46KB/s | Fetching revisions:Inserting stream
[20:37] <LarstiQ> j^: does ~/.bzr.log illuminate?
[20:38] <j^> that looks like http
[20:38] <j^> 159.916  25 bytes left on the HTTP socket
[20:38] <LarstiQ> j^: right
[20:38] <LarstiQ> j^: what does `bzr launchpad-login` report?
[20:38] <j^> j
[20:39] <LarstiQ> hmm, why doesn't it pick ssh then
[20:40] <j^> 1.17 still uses all my ram
[20:40]  * LarstiQ nods
[20:40] <LarstiQ> j^: you can do it in bits and pieces
[20:41] <LarstiQ> j^: were you using a shared repository to branch into?
[20:41] <j^> bzr branch lp:launchpad/edge  launchpad uses ssh
[20:42] <LarstiQ> ok
[20:42] <j^> LarstiQ, i was not using a shared repository was just trying bzr branch lp:launchpad
[20:42] <LarstiQ> j^: right
[20:42] <LarstiQ> then it is slightly trickier to do it in batches
[20:43] <LarstiQ> j^: bzr branch -r 1 lp:launchpad launchpad; cd launchpad; bzr pull -r 1000; bzr pull -r 2000; etc
[20:43] <j^> i am happy to get it in a shared repos if that helps
[20:44] <j^> how would i use a shared repos?
[20:44] <LarstiQ> j^: if you plan to do development on launchpad that would be the recommendation
[20:44] <j^> for now i wanted to read the code
[20:44] <j^> since the webinterface does not list the files
[20:44] <j^> it lists them but does not show the contents
[20:44] <LarstiQ> j^: `bzr init-repo --2a ~/src/launchpad; bzr branch lp:launchpad ~/src/launchpad/trunk` for instance
[20:45] <LarstiQ> j^: or you could use the trick I just showed you
[20:46] <j^> will try the shared repos first, i might start hacking on it
[20:46] <LarstiQ> j^: there, https://bugs.edge.launchpad.net/bzr/+bug/402139 might be the bug I was looking for
[20:52] <Kinnison> Anyone have any idea why bar is giving me annoying messages like 'SHA1KnitCorrupt' when I try and pull the dulwich repo?
[20:53] <LarstiQ> Kinnison: I do not, jelmer might
[20:54] <Kinnison> Are there any bzr people at debconf this year?
[20:55] <LarstiQ> Kinnison: Jelmer is
[20:55]  * LarstiQ sadly is not :(
[20:56] <LarstiQ> Kinnison: are you there?
[21:12] <Kinnison> I am, sorry, was re-reading bits of soyuz and reminiscing
[21:12] <Kinnison> jelmer: I should prod you about this dulwich problem, but perhaps tomorrow?
[21:21] <jelmer> Kinnison: yeah, I should be around tomorrow
[21:21] <Kinnison> coolbeans
[21:21]  * Kinnison decides to head to the lobby with some cards
[21:22] <LarstiQ> ooh
[21:22]  * LarstiQ really needs to find some Debian people geographically close soon
[21:32] <|malibu|> Help!
[21:32] <|malibu|> I had a commit hang on me.  I broke out of it and now I have a remote lock
[21:32] <|malibu|> Anyone know how I clear this out and redo the commit?
[21:33] <beuno> |malibu|, and bzr break-lock REMOTE_URL doesn't work?
[21:36] <|malibu|> didn't know about that one
[21:37] <|malibu|> ok seems to have worked..
[21:37] <LarstiQ> |malibu|: break-lock should be suggested to you if you try any operation on a locked branch?
[21:37] <|malibu|> commit again should catch everything?
[21:37] <LarstiQ> |malibu|: yeah
[21:38] <|malibu|> ok cool, thanks
[21:38] <|malibu|> I did bzr -h but didn't see break-lock in there
[21:38] <LarstiQ> |malibu|: `bzr help commands` lists it
[21:38] <|malibu|> ah
[21:53] <Hillshum> How do I clone a cvs repo?
[21:59] <Hillshum> anyone?
[22:19] <Leonidas> Hillshum: CVS repos don't get cloned, they get checked out
[22:20] <Leonidas> uhm, bzr 1.17 depends on zlib for building, why is that so?
[22:22] <Hillshum> Leonidas, Yeah, I think I have it now, so "bzr checkout http://some.box.com/trunk" ?
[22:22] <sender> Can anyone help me get started to contribute translations for bzr plugins?
[22:22] <Leonidas> Hillshum: CVS does not use HTTP
[22:23] <Hillshum> Leonidas, what protocol then?
[22:23] <Leonidas> Hillshum: most of the time it is 'pserver'
[22:24] <Leonidas> Hillshum: what do you want to do in the first place?
[22:24] <sender> E.g. how do I add a new translation to bzr-explorer (https://translations.launchpad.net/bzr-explorer/trunk) ?
[22:24] <Hillshum> Start woking on a antiquated cvs repos
[22:25] <Hillshum> hillshum@ibook:~$ bzr checkout pserver://parliament.cvs.sourceforge.net/cvsroot/parliament
[22:25] <Hillshum> bzr: ERROR: Unsupported protocol for url "pserver://parliament.cvs.sourceforge.net/cvsroot/parliament"
[22:30] <Leonidas> bzr does not support cvs directly
[22:30] <amanica> sender, I think you may need to join the team
[22:30] <Leonidas> Hillshum: let launchpad import the project, then clone it.
[22:30] <amanica> also it may automatically show your language if launchpad knows it
[22:30] <amanica> sender: i.e if you added your language to your launchpad preferences
[22:31] <sender> amanica: thanks, you are right. I notified LP of my language and now I can select it.. :)
[22:31] <amanica> sender: I'm just guessing
[22:31] <amanica> cool
[22:31] <sender> amanica: do you know if I can use a local app to translate instead of the LP interface?
[22:31] <amanica> yes you can
[22:31] <sender> amanica: and how can I test bzr-explorer with the translation?
[22:32] <amanica> I have not used it yet though
[22:32] <sender> amanica: I've got poedit here, but do not have a clue how to start off
[22:32] <amanica> sender: mmm.. maybe bialix or ianc can help you there
[22:33] <LarstiQ> Leonidas: because bzr uses zlib and the C extension needs to include headers/build against it
[22:33] <amanica> sender: maybe ask this on the mailinglist
[22:33] <amanica> I'm sure you'd get a responce
[22:34] <sender> amanica: will do, thanx :)
[22:34] <amanica> cool
[22:35] <Leonidas> LarstiQ: this seems to be a new feature, right?
[22:38] <LarstiQ> Leonidas: yes. I can look up which exact bzr version introduced it if you want.
[22:47] <lifeless> moin
[22:49] <DaffyDuck_> Let's say we are two working on a project. A shared repository is located on a dedicated server. My friend makes changes, and "bzr push":es changes. Then I make changes and push changes. This causes a conflict. How is this handled? Do I merge from the server, and then push the merged changes?
[22:50] <amanica> goodnight
[22:52] <Leonidas> LarstiQ: thanks, don't bother. I just saw it today because the usual easy_install -U bzr failed and somewhere inside of the _terribly helpful_ messages of GCC was a missing header error.
[22:55] <awilkins> DaffyDuck_: are you working in a branch, or a checkout?
[22:56] <awilkins> DaffyDuck_: But yes, you can merge, and push the changes. Then your friend will have to pull your changes (or merge later after he commits some more)
[22:59] <lifeless> DaffyDuck_: if youre pushing to the same branch, I suggest using a checkout
[23:03] <DaffyDuck_> awilkins: Um.. What's the difference between a branch and a checkout? I always do "bzr branch ...", but I assume I can do a "bzr checkout ..."?
[23:05] <DaffyDuck_> Ah, so a checkout is simply set of working files?
[23:06] <awilkins> DaffyDuck_: Checkout is "bound" to the master branch so all commits are also comitted there
[23:06] <awilkins> Unless they changed it already so that checkouts are all lightweight ones (no local repository branch)
[23:07] <awilkins> If you've used SVN, a lightweight checkout is like an SVN working copy
[23:07] <lifeless> DaffyDuck_: a checkout provides the cvs/svn style centralised workflow
[23:07] <DaffyDuck_> Ah, ok. That makes sense.
[23:07] <lifeless> where commits to a common object are serialised and the left hand history is preserved
[23:07] <lifeless> at an implementation level the default checkout is a 'bound branch'
[23:08] <lifeless> but you can also create one with no history attached, if you pass --lightweight. This is not a good idea from a performance angle if you're working over anythin other than a LAN
[23:08] <DaffyDuck_> checkout = centralized, branch = decentralized (but push/pull can make it semi-centralized).
[23:08] <awilkins> Or if you ever use your laptop on the train :-)
[23:09] <DaffyDuck_> awilkins: I use my laptop on the train almost every day. :)
[23:09] <lifeless> DaffyDuck_: a normal checkout will work fine on the train, you just can't commit
[23:10] <lifeless> DaffyDuck_: the way I do this is I have a couple of branches for projects with shared mainlines
[23:10] <DaffyDuck_> lifeless: Yeah, but it's commit I want. :)
[23:10] <lifeless> one that is a checkout
[23:10] <lifeless> and one that is a normal branch
[23:10] <lifeless> when I'm offline, or doing speculative stuff, I use the normal branch
[23:10] <lifeless> once its reviewed and ready to land, I merge it to the checkout and commit
[23:10] <lifeless> which simultaneously pushes it and enforces the mainline
[23:10] <awilkins> You can commit to Â"heavy" checkouts, there are just extra steps (nd parameters)
[23:11] <DaffyDuck_> lifeless: Thanks for the tip. That feels like a very natural way to work, so I just may adopt it.
[23:11] <awilkins> I tend to have a local no-trees repository and take lightweight checkouts from it, branch as I wish locally, and merge and push my changes when required
[23:12] <lifeless> awilkins: oh, I have these branches in a shared repo; but the key thing is checkout+regular branches ;)
[23:12] <awilkins> I'll commit my patches, switch my working tree back to the mainline, merge from the local branch, and then push
[23:12] <DaffyDuck_> So both of you have something like proxy checkouts. Hmm..
[23:13] <awilkins> We do the same thing we just use different infrastructure
[23:13] <|malibu|> Does bazaar have commit hooks on the server side?
[23:13] <lifeless> yes
[23:13] <|malibu|> awesome, tks
[23:13] <awilkins> I'm really still interested in seeing a version of pipeline that supports parallel pipes
[23:14] <awilkins> Or just a straight port of Mercurial pbranches
[23:14] <awilkins> (which I was tempted to do after I saw it was just one source file)
[23:14] <|malibu|> BTW.. bzr with light checkout makes an awesome dropbox-type thing
[23:16] <|malibu|> I'd really like to get it to do a commit every time I write a file.. but even with a batched up commit it works great
[23:20] <DaffyDuck_> Is "init-repo" (shared repository) merely a way of collecting several branches of a project in a single entity on a server?
[23:20] <fullermd> No, it doesn't make a single entity of anything.  It's a way of sharing storage among branches with common history.
[23:21] <DaffyDuck_> fullermd: So, if I have a dev, and a stable. I merge dev to stable, then stable actuallty uses the storage of dev (if I do no changes)?
[23:22] <fullermd> Well...    yes, I guess, but that's a confusing way of looking at it.
[23:22] <fullermd> Better is "if I have a dev and a stable, they both store their history in one common place"
[23:23] <fullermd> (and thus any common history, which is probably most of it, is only stored once rather than twice)
[23:24] <fullermd> Every branch always has a repository, because that's where revisions are stored.  init-repo is used to create shared repos, so that multiple branches can use the same repository.
[23:25] <DaffyDuck_> fullermd: Ah, ok. From the init-repo example, it looked like they smiply created two different branches inside a "init-repo" directory, and I was wondering if the branches can simply be moved out of that init-repo directory and be used individually, but I guess there's more to it than that.
[23:26] <DaffyDuck_> Hmm... It seems like init-repo is what I want to do. I need to experiment with it a little.
[23:26] <fullermd> Yes, if you move them out of the shared repo, they can't find it anymore.  That would be Bad(tm).
[23:27] <fullermd> You can move them around all you want underneath it though.
[23:27] <DaffyDuck_> Oh. Hmm... I find that cool, yet confusing.
[23:27] <fullermd> (of course, if you 'bzr init' two branches inside a repo, they don't have any shared history, so there's no real win)
[23:28] <DaffyDuck_> fullermd: Yeah, I figured. You init one "branch", and then "branch" the others to get full usage?
[23:29] <fullermd> Well, most of the time, you'd "branch" an existing branch of the project, then "branch" from that (or from other existing branches)
[23:30] <fullermd> But 'init' creates a branch ab ovo.  There's no history [yet], and any future history is thus divorced from the history of any existing branch, or any separately init'd branch.
[23:32] <DaffyDuck_> fullermd: Ah. So - technically - bzr will check if it is inside a?shared repo when a "branch" is created?
[23:32] <lifeless> DaffyDuck_: if you're starting new stuff in bzr, I encourage you to pass --2a to your init-repo command
[23:32] <lifeless> DaffyDuck_: this is the format that will be default in 2.0
[23:33] <fullermd> DaffyDuck_: Yes, an existing repo will be used if it's found, otherwise we'll create a new (unshared) one specifically for that branch.
[23:33] <lifeless> jam: around?
[23:33] <DaffyDuck_> lifeless: Ok. The description doesn't tell me anything, but I'll take you advise.
[23:34] <DaffyDuck_> fullermd: Excellent. The puzzle is coming together.
[23:34] <fullermd> DaffyDuck_: So, if you have a repo at /repo, and you go to /repo and run "bzr branch http://some/project/ a", the branch 'a' will use the repo.
[23:34] <fullermd> DaffyDuck_: And if you run "bzr branch http://some/project/ b" after that, b will also use the repo, so it will finish very quickly since it already has all the revisions in the repo from when it branch'd into 'a'.
[23:34] <lifeless> DaffyDuck_: we're hopinh to make it the default in about a month
[23:35] <DaffyDuck_> I'll start experimenting (best way of learning) with shared repos tomorrow. Thanks for the information, all of you.
[23:35] <DaffyDuck_> I can't believe we stuck with subversion this long. :(
[23:35] <DaffyDuck_> Expect more questions tomorrow. :)
[23:35] <lifeless> DaffyDuck_: the only caveat is you need bzr 1.16.1 or newer
[23:36] <lifeless> DaffyDuck_: but you want that anyway :)
[23:36] <DaffyDuck_> lifeless: It appears I have 1.16.1.