[00:57] <aboSamoor> I am trying to add svn folders to bzr, I got this message "bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'"
[01:08] <lifeless> see my reply in #launchpad
[03:55] <Peng_> Err.. bzr just did an autopack. .bzr.log said it was packing from 14 packs to 10, but instead it packed them down to...3. I don't get it.
[03:56] <Peng_> (I mean, it was right about there being 14 initially.)
[09:08] <lifeless> Peng_: it lied
[09:08] <lifeless> Peng_: please file a bug
[09:09] <lifeless> Peng_: (what it really meant was 'all but two of the packs needs to be combined' -> 3 (its simpler and more efficient than the original code
[09:09] <lifeless> but the debug output is the original plan of what would happen
[09:15] <Peng_> Oh.
[09:17] <Peng_> It should've combined them into 2 packs anyway. It left one with only like 2 revisions in it. :\
[09:23] <lifeless>   Peng_ well, could be a bug
[09:24] <Peng_> Wait...what do you mean? It was originally going to leave 10 packs, but changed its mind after writing the debug message?
[09:25] <Peng_> Well, I filed bug 295486. Kinda crappy title though.
[09:51] <Peng_> lifeless: Not to be a stalker, but you seem to have identical branches at lp:~lifeless/+junk/bzr-index2 and lp:~lifeless/+junk/index2.
[10:30] <fullermd> Peng_: Don't try and act innocent.  We all saw you checking out his branches.
[13:50] <RedLizard> What is usually done with a feature branch once the feature is stable and has been merged into the trunk? I don't want it to clutter the branch namespace for all eternity, yet I do want it available for all eternity.
[13:54] <LarstiQ> RedLizard: I usually do nothing to it, or move it out of the way.
[13:54] <yml> Hello, I am having some hard time to understand how to make bzr happy after a big reorganisation in my project.
[13:55] <RedLizard> LarstiQ: i would like to mark it as "closed for development" in some way
[13:55] <LarstiQ> RedLizard: mv it to done/ ?
[13:55] <yml> In fact I have moved/rename some folder in the terminal an now I try to make bzr aware of this modification
[13:56] <LarstiQ> yml: bzr mv --after oldname newname
[13:56] <LarstiQ> yml: this may be a little tricky if you have also done renames of children of that directory, it is doable but a bit more work than ideal
[13:56] <yml> LarstiQ:  thanks I am going to try this
[13:57] <yml> LarstiQ: I have not done any renaming of the children
[13:57] <RedLizard> LarstiQ: that should work, i think
[13:57] <LarstiQ> yml: good :)
[13:57] <yml> LarstiQ:  bzr mv --after django_glue/* projects/simple_project/
[13:57] <yml> bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned.
[13:58] <LarstiQ> RedLizard: ime that is enough to clear the namespace isssue.
[13:58] <LarstiQ> yml: are you sure that is what you want?
[13:58] <LarstiQ> yml: could you describe the rename you did?
[13:59] <RedLizard> LarstiQ: optimally, i'd like the branch to be destroyed, and its history contained in the history of the trunk, available by "zooming in" on the merge commit
[13:59] <LarstiQ> RedLizard: if not, you can always delete a branch, since it's revisions are all merged into trunk, you can always recreate it when necessary
[13:59] <LarstiQ> RedLizard: but why bother?
[13:59] <LarstiQ> the burden of keeping around old branhces is very low
[14:00] <yml> Bzr was aware of a folder named django-glue in the root of my bzr directory then I did mv django_glue projects/simple_project
[14:00] <LarstiQ> yml: right, so it looks to me that should be 'bzr mv --after django_glue projects/simple_project' then
[14:00] <RedLizard> LarstiQ: because otherwise, i'd have to keep my branch names unique for all eternity
[14:00] <LarstiQ> yml: without the /* wildcard, that would be moving the children of django_glue, not django_glue itself
[14:01] <RedLizard> LarstiQ: i can't call my branches 'test' or something similar
[14:01] <yml> LarstiQ: bzr mv --after django_glue projects/simple_project
[14:01] <yml> bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned.
[14:01] <yml> same thing
[14:01] <LarstiQ> RedLizard: eh, a branch called 'test' imo is not worthy of staying around, nuke it :)
[14:01] <LarstiQ> yml: what version of bzr are you using? and is projects/ versioned?
[14:01] <RedLizard> LarstiQ: but the history will still be available in the trunk? great :)
[14:02] <LarstiQ> RedLizard: yes, absolutely
[14:02] <RedLizard> :)
[14:02] <yml> no project is not yet versionned
[14:02] <LarstiQ> `bzr branch trunk -r tip_revision_of_test resurrected-test` to bring it back
[14:03] <yml> and I amusing bzr : Bazaar (bzr) 1.3.1
[14:03] <LarstiQ> yml: did projects/ previously exist, or did you mkdir it for this reorginasation?
[14:04] <yml> I mkdir project
[14:04] <yml> for this reorganisation
[14:05] <LarstiQ> yml: try 'bzr add --no-recurse projects/' before you do the mv --after
[14:06] <yml> same thing
[14:07] <yml> I also try to bzr add projects/simple_project before doing the mv but it also didn't work
[14:08] <LarstiQ> right, that you do not want to do
[14:08] <LarstiQ> yml: in my small test it worked, but let me try with 1.3.1 instead of 1.9
[14:10] <yml> LarstiQ: Is there an easy way to update to 1.9 on ubuntu
[14:10] <yml> by easy I mean sudo apt-get install ...  :-)
[14:11] <LarstiQ> yml: yes, there is
[14:11] <jelmer> 'morning yml, LarstiQ
[14:11] <LarstiQ> moguh jelmer
[14:11] <yml> ok so might be an option if you found out that it is not working with 1.3.1
[14:11] <LarstiQ> yml: use the bzr ppa, https://launchpad.net/~bzr/+archive
[14:12] <LarstiQ> yml: just a moment though
[14:12] <LarstiQ> yml: I'll give you my test script, maybe what I'm doing is too simplistic and doesn't actually cover your case
[14:13] <yml> ok
[14:16] <LarstiQ> yml: indeed, 1.5 and up succeed where 1.3 does not
[14:17] <LarstiQ> yml: http://rafb.net/p/AFkUPw64.html fwiw
[14:18] <yml> LarstiQ: Excellent news
[14:19] <yml> LarstiQ: so now I just have to move to the latest bzr
[14:19] <yml> does bzr-svn is working on 1.9 ?
[14:19] <jelmer> yml: yes, with bzr-svn 0.4.14
[14:20] <LarstiQ> jelmer: oh! you did a release, sweet!
[14:20] <yml> jelmer: How can I install it on ubuntu ?
[14:20] <yml> apt-get install ?
[14:21] <jelmer> I don't think it's been uploaded to the PPA yet or synced from Debian
[14:21] <LarstiQ> the ppa has 0.4.13-2
[14:21] <jelmer> you may be able to install the Debian package or otherwise install from source
[14:30] <yml> LarstiQ: thank you very much for your help
[14:30] <yml> 1.9 solve my issue
[14:31] <yml> Is it just me and my happyness or does bzr status is faster ?
[14:31] <yml> jelmer: do you have an idea when the PPA will be updated?
[14:32] <LarstiQ> yml: there have been improvements to status speed between 1.3 and 1.9, so that's entirely possible :)
[14:35] <yml> Thank you so much for your effort in bzr
[14:35] <yml> for some reason that I cannot explain I just feel good with it
[14:36] <yml> the only thing missing to me at the moment is a bzr-git
[14:36] <yml> it is such a pain for me each time I have to work with git
[14:37] <jelmer> yml: you may want to subscribe to bug 293009
[14:41] <yml> jelmer: I am actually on hardy
[14:42] <yml> but I get the same error message when I try to apt-get install bzr-svn
[14:42] <jelmer> the packages are always uploaded for all ubuntu releases at the same time
[14:44] <yml> thank I will wait for its resolution
[15:05] <Flyser_> Hi. is it possible to use bzr for my local repository and then push it to a remote svn server?
[15:16] <jelmer> Flyser_, hi
[15:16] <jelmer> Flyser_, yes
[17:16] <jelmer> jszakmeister|awa, hi
[18:47] <RedLizard> How can I restore a branch that I merged into some other branch in the past?
[18:49] <luks> RedLizard: get the latest revision number of the merged branch and run: bzr branch -rX orig new
[18:51] <RedLizard> and how do I get the latest revision number of the merged branch?
[18:51] <RedLizard> it doesn't appear in `bzr log`
[18:53] <luks> it should, if the branch was merged
[18:53] <luks> (and you don't have bzr log aliased to something like bzr log --short)
[18:54] <RedLizard> http://pastebin.com/m60c521ed
[18:54] <RedLizard> no revision number there
[18:57] <LarstiQ> RedLizard: revid:redlizard@ruud0-20081108134022-03073670ea55866a
[18:57] <LarstiQ> RedLizard: what version of bzr is that?
[18:57] <LarstiQ> or, what custom logformatter are you using?
[18:57] <luks> what version of bzr is it?
[18:57] <RedLizard> 0.11.0
[18:57] <LarstiQ> right :)
[18:57] <LarstiQ> RedLizard: etch?
[18:58] <RedLizard> yup
[18:58]  * LarstiQ hasn't seen that log output in a loooong time
[18:58] <luks> me neither :)
[18:58] <luks> I was confused by the merged line
[18:58] <LarstiQ> RedLizard: anyway, `bzr branch -r revid:redlizard@ruud0-20081108134022-03073670ea55866a resurrect`
[18:58] <LarstiQ> RedLizard: veel plezier :)
[18:59] <LarstiQ> RedLizard: (fwiw, we're up to 1.9 now)
[18:59]  * RedLizard wonders what gave him away
[18:59] <LarstiQ> RedLizard: 'gemerged'
[18:59] <RedLizard> ah :)
[19:01] <RedLizard> it works
[19:02] <RedLizard> good :)
[19:05] <RedLizard> Is there any reason I should _really_ upgrade from 0.11.0?
[19:06] <LarstiQ> If you're not interacting with anyone else, 0.11 will work fine.
[19:06] <LarstiQ> That is, other bzr branches might be in a format 0.11 does not understand.
[19:07] <LarstiQ> And, if you're asking for help, it pays to mention the version you're using :)
[19:07] <RedLizard> yes, i noticed
[19:07] <RedLizard> (stupid debian testing on development servers :p)
[19:08] <LarstiQ> hmm, isn't testing lenny by now?
[19:08] <RedLizard> yes
[19:09] <LarstiQ> that should have bzr 1.5
[19:09] <RedLizard> it does
[19:09] <LarstiQ> which, for this discussion, has a logformat that looks more familiar to us ;)
[19:12] <RedLizard> are the ubuntu packages on launchpad debian etch compatible?
[19:13] <LarstiQ> in the ppa? I believe not
[19:14] <LarstiQ> RedLizard: do you need a system wide bzr? Or is running from source good enough?
[19:14] <LarstiQ> RedLizard: 1.5 is in etch-backports fwiw
[19:14] <luks> etch-backports has 1.5
[19:14] <luks> he
[19:15]  * luks is too slow
[19:15] <RedLizard> LarstiQ: yeah, but then i'd get the entire backports repository
[19:16] <LarstiQ> RedLizard: personally, I run bzr from ~/src/bzr/<version>/bzr
[19:18] <RedLizard> hm, given that bzr depends only on python, the ubuntu packages will probably work fine on etch
[19:18]  * RedLizard tries
[19:18] <luks> it contains compiled code
[19:19] <LarstiQ> and the packaging standards might be different, say python-central
[19:19] <luks> you might have better luck just dpkg -i the deb from backports
[19:20] <RedLizard> why doesn't launchpad contain a debian repos as well, by the way?
[19:20] <strk> how to release al stale lock ?
[19:20] <strk> held by strk@gnash on host gnash [process #32194]
[19:20] <luks> bzr break-lock
[19:21] <strk> thx
[19:21] <RedLizard> hm, the ubuntu package doesn't work :(
[19:22] <LarstiQ> RedLizard: that is something that may happen in the future, but it requires buildd maintenance per suite.
[19:23] <LarstiQ> RedLizard: as well as the entire archive.
[19:25] <RedLizard> true
[19:26] <LarstiQ> RedLizard: so, I'd either try the etch backports .deb, or download and unpack a tarball, and run from that
[19:26] <RedLizard> LarstiQ: actually, i think i will build my own debian package
[19:27] <LarstiQ> ok :)
[19:30] <RedLizard> will `bzr branch` respect the repos format of the origin?
[19:30] <LarstiQ> RedLizard: if it can, yes.
[19:31] <LarstiQ> so branching from 0.11, hack hack, 0.11 should be able to pull the changes back
[19:31] <LarstiQ> RedLizard: just don't `bzr upgrade` it with 1.9 :)
[19:31] <RedLizard> LarstiQ: of course
[19:31] <LarstiQ> or branch it into a shared repo that uses a different format
[19:33] <RedLizard> hm, you really have to be quite careful when working together using different bzr versions
[19:34] <RedLizard> especially if you don't use a single repository for everything
[19:35]  * LarstiQ blinks
[19:35] <LarstiQ> RedLizard: what do you mean? Having one repository for all your branches would make collaborating with older clients almost impossible.
[19:37] <LarstiQ> RedLizard: do note 0.11 is over 2 years old (roughly half the projects lifetime) and pre 1.0
[19:37] <RedLizard> LarstiQ: unless the repository is in an old format
[19:37] <LarstiQ> RedLizard: which then makes other things impossible, like, say, bzr-svn
[19:38] <RedLizard> LarstiQ: so, the only solution is to make sure everyone uses the latest version at all times?
[19:39] <jelmer> RedLizard, the current default format has been supported since version 0.92, which is about a year old
[19:39] <LarstiQ> RedLizard: no, if you have one repository per project (which is good practice anyway), you should have an easy time of staying compatible with the least capable clients that work on that project
[19:39] <LarstiQ> RedLizard: that should reduce the friction to a level of not having to think about it
[19:41] <RedLizard> LarstiQ: good point
[19:41] <RedLizard> jelmer: good, that makes things easier... getting everyone to run >= 0.92 looks reasonable
[19:41] <LarstiQ> RedLizard: if you just have standalone branches, the only point where you run into trouble is by running upgrade yourself.
[19:44] <LarstiQ> RedLizard: but yeah, there is room for error
[19:45] <RedLizard> LarstiQ: not much if the default format is quite old
[19:45] <LarstiQ> RedLizard: right, in default cases you're safe
[19:46] <LarstiQ> RedLizard: but it's still possible to have a non-default repo, branch something old into that, work, try to get it back in, and notice the format got upgraded when you branched it
[19:47] <RedLizard> LarstiQ: won't it be saved in the default format again when merging it back in?
[19:48] <LarstiQ> RedLizard: if it's compatible, yeah. Not so when you are trying to stuff rich-root in non-rich-root

[19:48]  * LarstiQ has some dinner and goes off to a verdiepingsfeetsje
[19:48] <LarstiQ> modulo spelling bugs
[19:49] <RedLizard> have fun
[19:49] <LarstiQ> thanks
[19:57] <RedLizard> How can I init a branch on a remote server?
[19:58] <Kinnison> bzr init sftp://blahblahblah
[19:58] <Kinnison> :-)
[19:58] <LarstiQ> RedLizard: bzr init remote/path, or (my preference) work locally and publish changes when you have them
[19:58] <LarstiQ> Kinnison!
[19:58] <LarstiQ> Kinnison: how are you?
[19:58] <Kinnison> LarstiQ: Good thanks, busy busy busy :-)
[19:58] <RedLizard> bzr: ERROR: sftp://$PATH/.bzr/ is not a local path.
[19:59] <LarstiQ> Kinnison: that explains the not having seen you in a while ;)
[19:59] <Kinnison> LarstiQ: well that, and not going to any ubuntu/canonical confs due to lack of cash :-)
[19:59] <LarstiQ> RedLizard: yeah, I may have fixed that post 0.11
[19:59] <RedLizard> LarstiQ: this is using 1.5
[19:59]  * LarstiQ blinks
[20:00] <LarstiQ> RedLizard: do you have paramiko installed?
[20:00] <RedLizard> LarstiQ: yes
[20:00] <RedLizard> LarstiQ: i do have a bazaar config file automatically created with 0.11, if that matters
[20:01] <LarstiQ> RedLizard: it works for me, what exact command did you try? (~/src/bzr/1.5/bzr init sftp://localhost/tmp/hagedis in my case)
[20:01] <RedLizard> LarstiQ: which, on inspection, does not contain anything relevant
[20:02] <RedLizard> LarstiQ: update: it gives me that error message, but it has in fact succeeded
[20:02] <RedLizard> LarstiQ: that is, on trying it a second time (unmodified), i get:
[20:02] <RedLizard> bzr: ERROR: Already a branch: "sftp://10.0.2.100/home/redlizard/repo".
[20:03] <RedLizard> LarstiQ: also, i forgot: i init-repo'd that directory just before init'ing it
[20:03] <LarstiQ> I recall old code trying to open a workingtree on the branch that just got inited, even when remote. It sounds roughly like that.
[20:03] <LarstiQ> RedLizard: ah.
[20:05] <LarstiQ> RedLizard: was that a mistake, or did you conciously do it that way?
[20:05] <RedLizard> LarstiQ: i did it conciously
[20:05] <LarstiQ> ok, in that case, why? :)
[20:06]  * LarstiQ files a bug that co-locating a branch and a shared repo remotely gives a confusing message
[20:06] <LarstiQ> RedLizard: it is not a normal thing to do
[20:06] <RedLizard> LarstiQ: really? I thought it is a common optimization
[20:07] <RedLizard> LarstiQ: appearantly i misunderstood something; what exactly IS the common optimization using init-repo?
[20:08] <LarstiQ> RedLizard: the optimization only helps if you store multiple branches in a repository, at which point having the root of repo _also_ be a branch is weird.
[20:08] <LarstiQ> RedLizard: bzr init-repo sftp://host/repo; bzr init sftp://host/repo/branch;
[20:09] <RedLizard> LarstiQ: i use (read: am planning to use) the "nested branches" layout
[20:10] <RedLizard> LarstiQ: in which case having the shared repo also being the root branch sounds logical
[20:10] <LarstiQ> RedLizard: it could be. I still doubt it.
[20:11] <RedLizard> LarstiQ: what's so strange about it?
[20:12] <LarstiQ> RedLizard: the relation of the branch at the root to the other branches.
[20:12] <RedLizard> LarstiQ: otherwise, i would have /host/project (a --no-trees repo) containing only a directory trunk (a branch) containing other branches (recursively)
[20:12] <RedLizard> *containing only a directory "trunk"
[20:13] <LarstiQ> RedLizard: ah, I think I see what is going on here.
[20:14] <LarstiQ> RedLizard: what branches are in trunk/ then?
[20:14] <RedLizard> LarstiQ: feature branches, probably
[20:14] <RedLizard> LarstiQ: see section 10.2.2 of the user guide
[20:14] <LarstiQ> RedLizard: why wouldn't they be siblings of trunk, instead of children?
[20:15] <LarstiQ> RedLizard: just a moment, still filing that bug
[20:16] <RedLizard> LarstiQ: because they are created from trunk, and will ultimately be merged back into the trunk (a clear parent-child relation)
[20:18] <RedLizard> LarstiQ: and child objects residing in the parent directory is a Good Thing from a logical standpoint
[20:19] <LarstiQ> RedLizard: hmja. I disagree about there existing a parent/child relationship, but I see your point.
[20:19]  * LarstiQ looks at the user guide
[20:19] <RedLizard> LarstiQ: permanent forks (say, splitting off 2.6 (the new unstable) from 2.4 (stable)) would be siblings of trunk
[20:20] <RedLizard> LarstiQ: which, come to think of it, is a good reason not to have trunk equal the repository root
[20:21] <LarstiQ> RedLizard: right. From my point of view any branch is equal in footing to trunk.
[20:22] <RedLizard> LarstiQ: even feature branches, which only exist for a short period of time, only to be merged back into the trunk?
[20:23] <LarstiQ> RedLizard: yes. But they're not very likely to exist in a central repository anyway, but live on my machine.
[20:23] <RedLizard> LarstiQ: unless you work on a project on multiple machines
[20:24] <LarstiQ> RedLizard: but I see some merit in nesting like that.
[20:24] <LarstiQ> RedLizard: https://bugs.edge.launchpad.net/bzr/+bug/295704 btw
[20:25] <pygi> hello people
[20:25] <LarstiQ> hmm, should be 'and' instead of 'a', a well
[20:25] <pygi> me needs some numbers about bzr if possible
[20:27] <pygi> anyone awake? :)
[20:27] <LarstiQ> pygi: you didn't ask a question yet ;P
[20:27] <pygi> truuue :)
[20:28] <pygi> basically, number of projects using bzr, and some high-profile names of projects ;)
[20:28] <LarstiQ> RedLizard: I still think it's unnatural, but I might be oldfashioned ;)
[20:29]  * LarstiQ doesn't know of research into the former
[20:29] <jelmer> pygi, http://bazaar-vcs.org/WhoUsesBzr
[20:30] <pygi> jelmer, ok, and how about number of downloads? :)
[20:30] <jelmer> pygi, I don't think that's easy to track
[20:30] <pygi> jelmer, indeed it isn't
[20:30] <jelmer> as most people get bzr from their distribution
[20:31] <pygi> jelmer, right
[20:32] <pygi> jelmer, just trying to convince some people to do some bzr stuff, and this will help ;)
[20:32] <LarstiQ> pygi: who are those people? Are they convinced by 'ubuntu, launchpad, mysql'?
[20:33] <pygi> LarstiQ, O'Reilly :)
[20:33] <LarstiQ> pygi: aha :)
[20:33] <jelmer> pygi, you may want to check ubuntu's popcon
[20:34] <pygi> LarstiQ, I think mysql accounts for lot more then ubuntu & LP ;)
[20:34] <jelmer> pygi, IIRC that lists bzr as the second most popular DVCS
[20:34] <LarstiQ> pygi: depends what they are looking for
[20:35] <pygi> LarstiQ, true that too
[20:36] <pygi> LarstiQ, I guess adoption rate by external projects
[20:37] <LarstiQ> pygi: right
[20:37] <pygi> LarstiQ, and we can't really consider LP & ubuntu external :p
[20:38] <LarstiQ> pygi: tried the very scientific approach of looking at amount of google hits?
[20:41]  * LarstiQ now really is off
[20:41] <pygi> LarstiQ, laters, and thanks
[20:45] <pygi> jelmer, thank you too, data sent ;)
[20:45] <jelmer> np, hope you can convince them :-)
[20:46] <lifeless> Peng_: yeah, its the 'locations defaults override remember values' annoyance; I really must fix that
[20:47] <pygi> everyone wants to do a Git book, but bzr one is different stuff...
[20:48] <RedLizard> pygi: probably because bazaar is easy enough that you can use it without a book :p
[20:49] <pygi> RedLizard, actually, I'm talking from publishers POV ...
[20:50] <Pieter> I'd guess it is because there are more git users
[20:50] <pygi> Pieter, indeed
[20:50] <RedLizard> pygi: I was just kidding. I guess git is popular for one reason: that the linux development team uses (and wrote) it ;)
[20:50] <RedLizard> therefore, instant fame
[20:51] <jelmer> afaik there was a bzr book on the way
[20:51] <Pieter> git didn't become really popular until about a year ago, and it's been in use for the kernel for 2-3 years now
[20:51] <jelmer> not sure how far they got though
[20:51] <pygi> jelmer, yea, I heard that too ... but nothing new on it since ages ...
[20:52] <pygi> I talked about the book with few people here some time ago :)
[20:53] <pygi> Pieter, well, it was VERY unfriendly before
[20:58]  * jelmer still uses git reluctantly
[21:01] <pygi> jelmer, what project do you use it for?
[21:02] <jelmer> samba mainly, but also several other projects I've contributed to (ikiwiki, loudmouth, etckeeper, btslink)
[21:03] <pygi> aha
[21:03] <jelmer> this is one of the reasons why picking a vcs is so different than picking an editor - it affects not just you, but the rest of the project as well
[21:04] <pygi> true
[21:14] <Pieter> you can always use git-bzr ;)
[21:18] <jelmer> :-)
[21:18] <jelmer> Seriously though, I'm not sure how that helps me, it still forces me to use the git UI
[21:20] <Pieter> only to push to git, you can use bzr for all the other stuff
[21:21] <jelmer> Doesn't gain me an awful lot, it still e.g. requires a local copy of the git repo and a more complex way to upload to the remote git repo
[21:21] <jelmer> bzr-git should come close, once I finish implementing remote fetch support
[21:24] <Pieter> :) I guess it's more useful the other way around, as git has real branch and remote support
[21:24] <jelmer> I would say it the other way around, being the bzr adept that I am :-)
[21:25] <jelmer> git requires you to fetch data locally before you can do anything with it, bzr allows you to work directly on remote data
[21:26] <jelmer> it would indeed be nice to have git-like branches in bzr, I think that's actually my top-wishlist-item atm
[21:31] <pygi> jelmer, wasn't there some work going on getting those?
[21:33] <jelmer> not afaik
[21:33] <jelmer> it shouldn't be too hard to implement, just nobody hasn't done it yet
[21:33] <jelmer> and it would require a format change
[21:33] <emmajane> In other news: this is the best use of the internets ever... live web cam of PUPPIES. http://cdn1.ustream.tv/swf/4/viewer.45.swf?cid=317016
[21:34]  * emmajane apologies and encourages you to resume normal activities. :)
[21:34] <jelmer> lol :-)
[21:34] <emmajane> :)
[21:36]  * jelmer fears he'll just end up looking at puppies all evening, rather than adding new awesome bzr features
[21:36] <emmajane> LOL
[21:36] <emmajane> +1
[21:38] <emmajane> jelmer, screen casting has just taken a dramatic back seat to puppy watching. :)
[21:39] <Pieter> it has sound too \o/
[21:40] <jelmer> emmajane, :-)
[21:40] <emmajane> Pieter, yup :)
[21:40] <emmajane> must be supper time?
[21:40] <Pieter> that's what they thought
[21:40] <jelmer> and there's 8000 more people watching, amazing
[21:40] <emmajane> one of them have been assigned box duty... for our viewing pleasure. :)
[21:42] <emmajane> back later. :)
[21:46] <pygi> jelmer, more format changes :P
[21:48] <pygi> jelmer, I don't think people would like that :)
[22:21] <jelmer> beer o'clock
[22:22] <jelmer> g'night *