[03:24] <lifeless> poolie: ping
[03:28] <poolie> hi
[03:28] <lifeless> can I ring?
[03:28] <poolie> apparently yes :)
[04:25] <grettke> Hi guys. Newbie question: When I create a mirror branch, I must first run init-repo. Doing so tells it to store new revisions in the src repo, not the branch. When I create a task branch, though, how does it know to keep revisions in the branch. I am confused about the role of init-repo...
[04:28] <Verterok> grettke: the init-repo creates a shared repository, where you 'll create/branch your feature branches
[04:29] <Verterok> grettke: maybe 'll help if you just see the shared repository as a revision storage
[04:29] <lifeless> grettke: init-repo creates a database for the bulk content to be stored in; all other commands operate on branches - pull works branch to branch
[04:30] <lifeless> grettke: runnning 'init-repo' is *entirely optional*. If you just want to mirror one branch of a project, don't bother with init-repo.
[04:31] <Verterok> lifeless: hi
[04:31] <lifeless> Verterok: hi :>
[04:31] <Verterok> thanks for the detailed explanation of shared repos :)
[04:32] <grettke> Verterok: Ok. So this is something like an optimization, don't check out the entire history for every single branch I want to create, since I should just do it once for the mirror and levergae that for branches of the mirror?
[04:33] <grettke> lifeless: I see. I'm looking at mirroring and then branching multiple projects.
[04:35] <grettke> Thanks guys.
[04:36] <lifeless> grettke: yes, shared repos are precisely an optimisation
[04:39] <grettke> Verterok and lifeless: What repo structure do you recommend for the "Team collaboration, distributed style" of development?
[04:44] <lifeless> grettke: any
[04:44] <lifeless> repo structure is orthogonal to workflow
[04:44] <grettke> lifeless: I see. We are all "used to" the svn style.
[04:47] <lifeless> grettke: svn conflates repository and branches
[04:47] <lifeless> grettke: workflow in bzr is focused purely on branches
[04:48] <lifeless> grettke: commonly every developer will have one or more repositories whereever they have branches
[04:52] <grettke> lifeless: So if there are two centralized projects, proj1 and proj2, then a developers run init-repo twice (creating separate directories) , one for each project?
[04:53] <grettke> lifeless: Why are centralized repos initialized with the --no-trees option?
[04:55] <lifeless> grettke: a developer could have one repo for both, or two repos, or one repo per branch - whatever suites their needs (multiple machines, etc etc)
[04:56] <lifeless> grettke: the --no-trees option is useful for wherever you won't be editing the source code
[04:57] <lifeless> grettke: central servers don't generally have people editing code on them :P
[04:57] <grettke> lifeless: Understood. Thank you. I just finished reading the user-guide, so I was dying to ask some questions.
[04:58] <grettke> lifeless: One good thing about SVN is that it will get people off of CVS and onto a Distributed VCS quickly ;)
[04:58] <lifeless> :P
[05:00] <grettke> lifeless: Here is what I mean: It is not radically different from CVS, and it "fixes" some things. If you dig into SVN more than superficially, and you learn how it works, the SECOND thing you will start asking for (the first is merge tracking) is "disconnected-commits".
[05:00] <grettke> lifeless: So I wasn't teasing, SVN lowers the barrier for CVS users!
[05:10] <grettke> Thanks lifeless, Verterok, goodbye.
[06:55]  * vila not really here, yet, but soon
[06:56] <lifeless> vila: thanks for your email
[06:56] <lifeless> vila: a bundle would have been better
[06:58] <lifeless> ok, night all
[07:26] <vila> hi all
[07:27] <vila> lifeless: sry, I keep forgetting that (my editor provides shelf-like features for bundles as well as any bzr command output)
[07:28] <vila> poolie: ping
[07:28] <beuno> mornin' vila
[07:28] <vila> hi beuno !
[07:29] <beuno> how's it going?
[07:32] <vila> better and better, mouth can open by 2cm in the morning, reaching 3 or 4cm in the evening, eating has become a possible alternative again :-)
[07:32] <poolie> hi vila
[07:33] <vila> hi poolie
[07:40] <vila> lifeless: If you pass around and have some minutes to spare, I'd like to chat a bit (not more than some minutes, I swear :)
[07:46] <gour> hi, do you recommend 'dive into python' book for learning the lang?
[07:46] <gour> (so we can help hacking bzr one day)
[07:51] <spiv> gour: its pretty good, IIRC.
[07:51] <spiv> gour: it might be slightly dated w.r.t. to current versions of Python, but probably not enough to matter.
[07:53] <gour> spiv: thanks. i was reading 'learning python' but it's kind a slow, although it covers 2.5 with the reference what 2.6/3.0 changes
[07:54] <spiv> gour: http://docs.python.org/tutorial/index.html isn't too bad either
[07:55] <spiv> gour: it depends a bit on the audience, I think.
[07:55] <gour> spiv: how much of the language is covered by tutorial?
[07:55] <gour> stuff like generators, decorators, new-classes etc.
[08:01] <spiv> gour: it covers generators, it doesn't cover decorators or new-style classes that I can see.
[08:02] <gour> spiv: thank you
[08:02] <spiv> (although new-style classes hardly warrant covering, except to say "unless you know what you're doing, always use 'class Foo(object):' rather than 'class Foo:', or use '__metaclass__ = type'".
[08:02] <spiv> )
[08:03] <gour> hmm, good to know
[08:03] <spiv> gour: http://docs.python.org/glossary.html may be another useful resource for a novice Pythonista.
[08:04] <spiv> gour: e.g. it gives a succint description of new-style class :)
[08:06] <gour> spiv: thanks a lot
[08:25] <chandlerc> do svn:externals work in bzr-svn?
[08:25] <gour> chandlerc: not (yet) :-(
[08:26] <chandlerc> k, i suspected as much
[08:26] <gour> that forces me to still fetch via svn :-/
[08:47] <jelmer> chandlerc, bzr-svn can't support externals atm since bzr itself doesn't have any feature they could be mapped to
[08:48] <chandlerc> jelmer: the sub-tree thing?
[08:48] <chandlerc> that may be an experimental feature that i was playing with, but it seemed a pretty direct mapping onto svn:externals
[08:48] <jelmer> chandlerc, subtrees always refer to a specific revision
[08:49] <jelmer> chandlerc, svn:externals can (and usually does) point at the latest revision
[08:49] <chandlerc> odd, from a subversion developer, i was told to only use svn:externals to point to a specific revision
[08:49] <chandlerc> because the other behavior isn't well defined (what version it points to isn't itself versioned)
[08:50] <lifeless> jelmer: subtrees can have policy to update to a newer rev according to the design
[08:50] <jelmer> chandlerc, sure, but they do support it and it's the most common behaviour
[08:50] <jelmer> *commonly used
[08:50] <lifeless> vila: hai, not really here
[08:50] <lifeless> vila: drop me a mail though
[08:51] <chandlerc> well, as all the projects I want to use externals in would use them locked at specific revisions... ;] any chance of partial implementation with those semantics?
[08:51] <vila> lifeless: ok, asap
[08:51] <jelmer> lifeless, sure, what I'm saying is that atm there is no such policy
[08:53] <jelmer> chandlerc, not likely while by-reference nested tree support is still experimental
[08:54] <chandlerc> k
[09:10] <vila> lifeless: email sent
[11:53] <bugabundo_work> hi
[11:54] <bugabundo_work> is it a good idea to use bzr as a TimeMachine?
[11:54] <bugabundo_work> I made two local repos on my machine
[11:54] <bugabundo_work> on for /etc and another for /home/me/
[11:54] <beuno> I don't think it is
[11:54] <beuno> it will blow up with large files
[11:55] <beuno> doesn't do binary deltas
[11:55] <beuno> etc etc et
[11:55] <bugabundo_work> I filtered *.avi *.mp3 and stuff
[11:55] <bugabundo_work> plus I'm just adding files by hand
[11:55] <bugabundo_work> not add . recursive
[11:56] <bugabundo_work> can that be the cause of
[11:56] <bugabundo_work> https://bugs.launchpad.net/bzr/+bug/286266 ?
[11:57] <bugabundo_work> it crash every time on some PDFs
[11:57] <beuno> well, if it
[11:57] <beuno> it's for text files, maybe
[11:57] <beuno> still not sure if it's the best choice
[11:58] <luks> bugabundo_work: crashes in what way?
[11:59] <bugabundo_work> it gives a backtrace
[11:59] <bugabundo_work> its attached to the LP ticket
[12:00] <luks> hmm
[12:39] <g0ph3r> hi folks, i've just tried pushing one of my branches to an FTP server of my web hoster and got temporary ftp errors 451. digging in the bazaar bugs revealed bug #154259. this bug description indicates that the ftp append/restart commands may depend on the repository format (knit in this case). my question now is: could i workaround this issue by upgrading to a newer repository format?...
[12:39] <g0ph3r> ...anybody familiar with the ftp commands required by the different repository formats?
[12:52] <spiv> g0ph3r: the pack-0.92 format (which is the default in current releases) probably does avoid using append/restart over FTP.
[12:52] <g0ph3r> hm... upgraded a temp. branch of my branch to the 1.6.1-rich-root format but still got the same errors when trying to push to the FTP server... so it seems as if there's no easy workaround available :(
[12:52] <g0ph3r> spiv: thx, but my branch is already using pack-0.92 format...
[12:52] <spiv> g0ph3r: ah, 1.6.1-rich-root should behave the same as pack-0.92 in this respect, so I guess you're stuck.
[12:52]  * g0ph3r nods
[12:53] <g0ph3r> well, would have been nice...
[12:53] <spiv> There's a limit to what we can do to workaround broken FTP servers.
[12:53] <g0ph3r> yep, unfortunately, there probably even less i can do to convince my ISP to fix their server ;)
[13:51] <lifeless> vila: I replied
[13:53] <vila> lifeless: Me too, unless you replied again but then it's in the pipe
[16:06] <trotek> .
[16:22] <strk> so, it looks like bzr-gtk plugin makes X a requirement to even pull...
[16:22] <strk> apt-get remove --purge bzr-gtk # fixed it (I think I filed a bug already, just wanted to make sure, somebody here should have it assigned IIRC)
[16:23] <strk> ops, bzr-gtk didn't fix it, must be bzr-dbus
[16:25] <strk> yep, confirmed
[17:04] <dereine> can i export a certain update between 2 versions
[17:04] <dereine> so i can copy the update to another pc and merge it
[17:05] <beuno> dereine, bzr send -r rev1..rev2
[17:05] <beuno> should do it
[17:05] <beuno> unless you just want a diff
[17:05] <dereine> thx
[17:35] <vila> jam: ping
[17:35] <jam> vila: pong
[17:36] <vila> bug #279831 is back but a bit different
[17:37] <vila> Can we chat a bit about it in around 2 hours ?
[17:37] <jam> vila: it isn't back, it was never fixed
[17:37] <jam> bzr-gtk never accepted my patch
[17:38] <vila> ouch
[17:38] <jam> I'm not sure if it got enough visibility
[17:38] <jam> lifeless didn't really think it was worth patching bzr.dev, because it is really a bug in bzr-gtk that it was expecting exactly "True"
[17:39] <vila> I'm sure it isn't, but the new case make it worst as if the gap between commit and gcommit was growing
[17:40] <jam> anyway, I'm a bit here and gone because my son is sick, but if I'm around I'm happy to chat
[17:42] <vila> jam: ok
[17:42] <vila> take care of him
[18:11] <DimmuR> hello everyone - is it possible to configure bazaar to work only with passwords (for update to and from bzr) ?
[19:22] <eka> hi all
[19:35] <luks> jelmer: hi, is there any known workaround for https://bugs.launchpad.net/bzr-svn/+bug/260416 ?
[20:54] <SmileyChris> does bzr have a command to apply a patch?
[20:54] <SmileyChris> (a diff)
[20:55] <LarstiQ> SmileyChris: `bzr patch` is in bzrtools
[20:56] <LarstiQ> SmileyChris: alternatively, the standalone patch utility will do too.
[20:56] <SmileyChris> LarstiQ: cheers, but the standalone one dosen't handle renames does it?
[20:56] <LarstiQ> SmileyChris: if you have a bundle instead of a patch, you can use `bzr pull` or `bzr merge`
[20:57] <LarstiQ> SmileyChris: if you have a plain patch produced by the diff program, that doesn't handle renames natively, no matter how you apply it.
[20:57] <SmileyChris> it's a diff from bzr
[20:57] <LarstiQ> SmileyChris: but you can use `bzr mv --after` to tell bzr about renames after they happened
[20:57] <LarstiQ> SmileyChris: produced in what way?
[20:57] <SmileyChris> bzr diff i guess
[20:57] <LarstiQ> SmileyChris: (or, can you show me the first 10 lines of it)
[20:58] <LarstiQ> SmileyChris: if `bzr diff` produced it, then it's in the same format as regular patch and diff, no added help from bzr there.
[20:58] <SmileyChris> ok, I'll just do the moves manually... thanks
[20:59] <SmileyChris> hrm, I can't - it says the new folder is not version
[20:59] <SmileyChris> *versioned
[20:59] <LarstiQ> SmileyChris: I don't know what situation produced this diff, but for distributing changes a bundle (produced by `bzr send`) is more useful
[20:59] <SmileyChris> i agree :)
[20:59] <SmileyChris> i'll let my colleague know
[21:00] <LarstiQ> SmileyChris: it complains about the new folder being unversioned even if you supply --after to mv?
[21:01] <SmileyChris> nah, I was just doing something wrong (didn't need --after)
[21:01] <LarstiQ> ok :)
[21:08] <dereine> how can i show which files changed, and not what changed
[21:11] <luks> dereine: bzr status
[21:11] <dereine> thx
[21:50] <guilhembi_> jam: hi! about https://bugs.launchpad.net/bzr-gtk/+bug/279831, it says "fix committed", but committed where?
[21:52]  * LarstiQ looks at the activity log
[21:53] <balor> Will "bzr merge -r14..14 ../project-branch" cherrypick r14 from project-branch and merge it onto the cwd?
[21:55] <LarstiQ> balor: I'd use -c14
[21:55] <balor> LarstiQ: Thanks
[21:56] <LarstiQ> balor: or -r 13..14 if you want to provide a range
[21:57] <LarstiQ> guilhembi_: seems r3767 of bzr.dev
[21:57] <LarstiQ> or no
[21:57]  * LarstiQ mistyped the bug number
[21:58] <balor> Should cherry-picking retain the providence of the patch?
[21:58] <LarstiQ> balor: the what? :) Cherry-picking doesn't record as much information as would be nice.
[21:59] <balor> LarstiQ: The ancestory of the merged patch i.e. where it came from and its change history.  But I guess not.
[22:00] <LarstiQ> balor: correct, unfortunately.
[22:00] <LarstiQ> balor: could you clarify 'change history' also?
[22:01] <LarstiQ> probably different terminology, but it sounds intrigueing :)
[22:01] <balor> LarstiQ: I think I'm talking about the entire revision tree associated with the patch....which you probably don't want to merge over :)
[22:02] <LarstiQ> just noting which revision it was should be enough for filling in later, yes
[22:11] <abpend> Anybody here?
[22:17] <poolie_> yes
[22:18] <grettke> When you create a mirror branch, do you normally use checkout or branch, and why?
[22:18] <poolie_> i'd normally branch
[22:19] <poolie_> if you don't commit in it it doesn't make much difference though
[22:19] <abpend> My question: when setting up bazaar for a central-server workflow, how is access control typically handled on the server?
[22:30] <grettke> poolie_: Understood. The workflow I'm envisioning is that there is a mainline on a shared repo on the server, I create a branch locally, then I create a "task" branch of that and merge my changes to the trunk branch and vice versa.
[22:30] <grettke> poolie_: This is based on reading the user guide along with my desired workflow.
[22:37] <balor> Silly question...If I check out -r 7 (of say 17 revisions) into a new tree.  Is there any way to upgrade r7 to r8, and then to r9 (I'm thinking about demo'ing tutorial code).
[22:43] <poolie_> balor: "update" :)
[22:44] <balor> poolie_: But update doesn't take a --revision, it'll update to the latest revision not just the next (AFAIK)
[22:44] <poolie_> hm
[22:50] <lifeless> balor: pull -r 8 source
[22:50] <balor> lifeless: thanks
[23:14] <Peng_> Wow, YUI is big..
[23:15] <beuno> blame rockstar
[23:15]  * rockstar hides
[23:15] <rockstar> Wait, why am I being blamed for YUI being big?
[23:15] <beuno> yes
[23:16] <rockstar> Suddenly, everything is so clear now.
[23:20] <beuno> rockstar, so, loggerhead tomorrow?
[23:20] <lifeless> YUI?
[23:20] <rockstar> beuno, perhaps.  I need to finish up some personal projects.
[23:20] <rockstar> lifeless, Yahoo! UI library
[23:21] <beuno> rockstar, aiight, I'll catch up with my LH stuff either way
[23:21] <Peng_> lifeless: It's a really big JavaScript library.
[23:21] <beuno> I have a branch that's almost finished to user paths instead of fileids
[23:21] <mlh> people do like jquery - it's smaller
[23:21] <rockstar> beuno, Maybe we ought to get something really quick and hack for a few hours tomorrow night.
[23:22] <beuno> rockstar, oh, sure, that's what I had in mind. Get out hands dirty
[23:22] <rockstar> mlh, jquery is also my favorite.  However Launchpad is moving to YUI, so LH coincidentally is as well.
[23:22] <beuno> but there's no rush
[23:23] <mlh>   intewesting
[23:23] <Peng_> I think adding YUI made Loggerhead's repo 20% larger. :D
[23:23] <rockstar> beuno, yea, let's make it a plan then.
[23:24] <rockstar> Peng_, in all fairness, Mochikit will go away soon.
[23:24] <beuno> rockstar, deal
[23:24] <beuno> and, well, mootools is what's going away in LH
[23:24] <beuno> but yeah, lp is lossing mochikit
[23:24] <rockstar> Ah yes, that's what I meant.
[23:24] <beuno> loosing even
[23:25] <beuno> mootools isn't small either
[23:25] <rockstar> beuno, did you get an email from me?
[23:25] <Peng_> yui-min.js /is/ smaller than MooTools.
[23:25] <beuno> rockstar, gpg?
[23:26] <beuno> if that's what you mean, than no
[23:26] <beuno> oddly enough, I've just ogtten emails from people sending from other addresses than @canonical
[23:28] <beuno> anyways
[23:28] <beuno> off to bed
[23:28] <mlh> beuno: "losing" :-)