[05:00] <rsingh> hello all
[05:00] <rsingh> i was able to push my code onto my production server, no problem. i have now used branch to pull that code onto another machine, my laptop, and it worked
[05:01] <rsingh> the problem is that i cannot see anything on my browser if i run the webapp
[05:01] <rsingh> my index.php comes up as blank on the browser, though there is code in that file
[05:02] <lifeless> you probably can get the code visible on your server by doing 'bzr checkout .' in that directory
[05:02] <lifeless> there is a plugin though, designed specifically for publishing websites, called 'bzr-upload' which may suite your needs even more closely
[05:03] <rsingh> lifeless: sorry, that didn't do the trick
[05:03] <rsingh> lifeless: it's just strange that my browser doesn't output anything from index.php
[05:04] <rsingh> hold up, lemme check something
[05:07] <rsingh> alright, i figured it out
[05:07] <rsingh> my index.php was using an incorrect (on my local) path to my framework files
[05:08] <rsingh> anways, thanks for your help lifeless
[05:08] <lifeless> ah!
[05:08] <lifeless> cool
[08:35] <jam1> morning all
[10:17] <jelmer> jam1: You seem to be in luck, we never have weather this nice around easter :)
[11:27] <quotemstr> What's the easiest way to collpase multiple revisions into one?
[11:28] <quotemstr> Say I have a local branch with lots of commits that make changes, undo mistakes, fix typos, and so on, but want to push upstream a single, neat change.
[11:28] <quotemstr> I could take a diff, revert to the parent revision, then just apply the diff with patch, but that feels ugly.
[11:48] <lifeless> quotemstr: generally in bzr folk don't feel the urge because the tool is good enough to show good diffs
[11:48] <lifeless> quotemstr: but if you feel the urge there are a couple of recipes. The most robust one (doesn't care if you've meged from upstream etc) is:
[11:49] <lifeless> make a fresh branch from upstream; bzr merge your branch; bzr revert --forget-merges; bzr commit -m "shiny"
[11:49] <lifeless> night all
[12:03] <kgoetz> isn't there a rebase plugin that would do something like that ?
[12:04] <Tak> rebasing doesn't have anything to do with collapsing changesets
[12:14] <kgoetz> hm, i thought thats almost exactly what people used rebase for
[12:14] <AfC> Rebase will preserve the number and nature of the commits - it just fucks history.
[12:15] <maxb> People get confused because git rebase -i does lots of things which are not technically rebasing
[12:17] <kgoetz> maxb: that'll be where the confusion comes from. i hear people rabit on about it all the time
[12:17] <kgoetz> AfC: interesting feature
[12:17] <jelmer> it would be interesting to have some way to reshape the revision graph
[12:17] <jelmer> there are some valid use cases for it
[12:22] <Tak> collapsing?
[12:23] <jelmer> no, but reshaping a history graph e.g. when combining parallel imports
[12:40] <bialix> hi jelmer
[12:41] <bialix> I've landed the support in qbzr for configurable tab width today
[12:41] <bialix> https://code.launchpad.net/~abudden/qbzr/qbzr-tabstop-width/+merge/56553
[12:42] <bialix> we store tab width settings in bazaar.conf (and could be branch.conf) as tab_width = N
[12:42] <bialix> you may want use it for bzr-gtk
[12:43] <jelmer> bialix: cool, I'll be sure to give it a try some time
[12:44] <bialix> ok
[16:56] <LeoNerd> How intelligent are the globs in .bzrignore? Can I set an entire regexp? I want to ignore  (MY)?META.(yml|json)
[16:56] <LeoNerd> Er.. \.  as a regexp
[16:57] <beuno> AFAIK, they are proper regexes
[16:58] <maxb> bzr help ignore ?
[16:59] <maxb> They're globs by default, because that's the clearest and simplest option for most things, but you can use a RE: prefix if you want
[17:21] <LeoNerd> Ahh OK
[17:22]  * LeoNerd finds ~/.bazaar/ignore, adds globally :)
[18:29] <glob> morning all; 'bzr status' is reporting a file as missing (it's a .moved file); how do i tell it that i don't care about that file?
[18:31] <glob> the documentation for status doesn't even list 'missing' as a possible state
[18:34] <glob> nevermind; i figured it out...
[18:34] <glob> i created an empty file with the same filename that bzr said was missing
[18:34] <glob> bzr reported this file now as 'added'
[18:34] <glob> then i deleted the file with 'bzr del'
[19:03] <Fidelix> Hello. I already have a repo in a remote server. I made a tar.gz, downloaded my project from the remote server and unpacked on my PC. Now I want to put the files on my PC under VC. Can someone instruct me to do that?
[19:23] <achiang> hello, seeing a strange oddity i don't understand. i add a new file (mylib.so) to a directory that is versioned by bzr. bzr status should then say it is an unknown file, but it doesn't see it at all. i don't seem to have a .bzrignore anywhere that i can tell
[19:24] <fullermd> .so's are in the default ignore list.
[19:25] <achiang> so how do i whitelist it?
[19:26] <achiang> just bzr add it specifically?
[19:26] <fullermd> You probably don't want to take it out of the default ignores, since everybody will assume they're there.  You can...  yeah, I type too slow   :p
[19:26] <fullermd> ignore just means that 'status' doesn't consider it unknown, and a recursive 'add' won't automatically add it.
[19:26] <fullermd> You can still add it manually, no problem.
[19:26] <achiang> ok
[19:26] <achiang> that was a little sneaky
[19:26] <achiang> but i got it now, thanks
[19:33] <ChrisWoollard> Evening all.
[19:34] <ChrisWoollard> Does anybody know how i can export a list of people that have contributed / commited to a bzr branch?
[19:48] <fullermd> There's something in the stats plugin that counts up revs by author, AIR...
[19:49] <ChrisWoollard> do you have a url for that plugin?
[19:51] <ChrisWoollard> i think i have found it
[19:51] <ChrisWoollard> thanks
[19:51] <Fidelix_> Hello. I already have a repo in a remote server. I made a tar.gz, downloaded my project from the remote server and unpacked on my PC. Now I want to put the files on my PC under VC. Can someone instruct me to do that?
[19:52] <m4n1sh> is Jelmer here?
[19:52] <m4n1sh> what is his nick?
[20:27] <LeoNerd> ugh.... since when did "bzr up" decide to become "bzr merge" if there's divergent history, without prompting?
[20:27] <LeoNerd> It totally ruins my branch :/
[20:27] <LeoNerd> and how can I have it back on the "throw an error if there's divergent history" behaviour?
[20:30] <fullermd> That would be the "bound branch" side of things coming around to bite.  It's always done that...
[20:31] <LeoNerd> I don't recall it doing so
[20:31] <LeoNerd> bzr up  always used to fail with an error about divergent history
[20:32] <glyph> LeoNerd: bound branches have always done that for me
[20:32] <glyph> LeoNerd: otoh that's why I don't use bound branches :)
[20:32] <LeoNerd> Interesting.... mine haven't... :/
[20:32] <LeoNerd> Hrmmm
[20:33] <LeoNerd> In that case.. hrmm.... any way I can fix it currently..? and separately, any way I can make it not do that again in future?
[20:33] <LeoNerd> I want my workdir back in its divergent state, so I can rebase it
[20:34] <fullermd> No automated way.  You can dig around for the revid and set it as the head.
[20:34] <LeoNerd> Ahyes... remind me..? bzr heads --something to list it...
[20:36] <fullermd> The default position is 'heads --dead'.  I'm not sure if the head counts as dead if it's a parent of the WT.
[20:36] <fullermd> Probably does; I think it only considers branches as enlivenating.
[20:36] <fullermd> (better still would be to bzr list-workingtree-parents of course...  only a minor issue with that)
[20:37] <LeoNerd> So having found the revid, now what?
[20:38] <fullermd> unbind and pull --overwrite
[20:38] <LeoNerd> Excellent, that got it
[20:39] <LeoNerd> rebase, push..done..
[22:00] <Fidelix_> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
[22:00] <Fidelix_> I can't checkout.
[22:25] <DC> Hi, I have a question about repositories and file permissions on Linux. I have a shared repository that I use with some friends via sftp protocol. On the machine that hosts the repository we have different Linux logins, but we are on the same group. I've created a shared repository (with group write permissions), but when someone pushes a new branch into this shared rep., the branch is created without the right write
[22:25] <DC>  permissions to the group. Is there any way to manage these permissions automatically with bazaar or each user must always correct the permissions manually after each push?
[22:27] <fullermd> No, branches are just created with umask.  Now, you could try fiddling that; if bzr is the main/only use for those logins, that can be fruitful.
[22:27] <james_w> the setgid bit may help if you need groups to make it work
[22:28] <fullermd> That won't help in perpetuating g+w.
[22:28] <DC> I tryed the setgid, but it only guarantees that the group will be created correctly, not with g+w.
[22:30] <DC> These logins are from our student network, not only for bzr. And the machines are not administrated by us. We don't have bzr nor acl.
[22:31] <fullermd> If you have access to root, you could setup a cron job to run through the dirs and make sure branches are g+w with an appropriate regularity.
[22:32] <DC> Even if each user fixes the permissions after new
[22:32] <DC> each new push, is there a chance that a new file with the wrong permissions get created during a commit?
[22:34] <DC> If this is the case, one should take care of permissions on each bzr operation and not only after pushes, which kind of sucks. :(
[22:40] <fullermd> Files inside the repository inherit permissions.  Pretty sure all the internal branch files do too.
[22:40] <fullermd> It's creation of branches that doesn't, because in a sense they have nowhere to inherit from.
[22:41] <DC> Well, maybe they could respect the permissions from the shared repository (if it is a shared rep).
[22:42] <DC> But it is good to know that at least inside the branch the permissions will be respected. Thanks, fullermd.
[22:42] <fullermd> Yeah, it would be nice.  Or some path-based config somewhere.
[22:44] <m4n1sh> jelmer: ping
[22:44] <DC> That would be nice too!
[22:45] <jelmer> m4n1sh: hi!
[22:45] <m4n1sh> jelmer: I am working on zeitgeist-dataprovider
[22:45] <m4n1sh> and I saw you proposed a merge
[22:45] <m4n1sh> this
[22:45] <m4n1sh> https://code.launchpad.net/~jelmer/zeitgeist-dataproviders/bzr-dbus/+merge/53128
[22:45] <m4n1sh> jelmer: I was about to merge it
[22:45] <m4n1sh> then I noticed a small issue
[22:46] <m4n1sh> jelmer: the original code is copyrighted to Markus Korn
[22:46] <m4n1sh> but the code here does not show his name as copyright holder
[22:46] <m4n1sh> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/view/head:/hook.py
[22:46] <m4n1sh> only as author
[22:47] <m4n1sh> I am not sure if you and thekorn talked on this
[22:48] <m4n1sh> jelmer: please leave your comment here. https://code.launchpad.net/~jelmer/zeitgeist-dataproviders/bzr-dbus/+merge/53128
[22:48] <m4n1sh> I need to sleep
[22:48] <m4n1sh> Good night
[22:48] <jelmer> m4n1sh: the version in bzr-dbus is an older one
[22:49] <m4n1sh> jelmer: it can be updated
[22:49] <jelmer> IIRC I discussed with Markus whether it was ok to merge it into bzr-dbus when I merged the original version
[22:49] <m4n1sh> hmm
[22:49] <m4n1sh> I think then he should not worry much
[22:49] <m4n1sh> AFAIK he has signed the contributer agreement too
[22:50] <m4n1sh> will ask markus tomorrow before merging
[22:57] <Fidelix__> Jesus... bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
[22:57] <Fidelix__> What is this?
[23:20] <maxb> jelmer: Do you understand this python-support / python-central nonsense with bzr-fastimport?
[23:21] <jelmer> maxb: yeah
[23:21] <maxb> I thought I did, but the daily PPA package of bzr-fastimport doesn't seem to suffer from the issue
[23:21] <jelmer> maxb: the daily package uses dh_python2
[23:21] <maxb> But only on natty
[23:21] <maxb> I'm testing in a lucid chroot
[23:22] <jelmer> maxb: have you tried installing/reinstalling bzr and bzr-fastimport in a different order?
[23:23] <maxb> I tried a couple of orders
[23:23] <maxb> But yes, I'm now getting suspicious of bzr's random ordering of plugin loading
[23:26] <maxb> nope, it's stubbornly not reproducing :-/
[23:30] <maxb> Huh, this couldn't be a mad python2.7 incompatibility, could it?
[23:31] <maxb> hmm, nope
[23:32] <jelmer> dh_python2 / python-support incompatibility?
[23:33] <jelmer> though I think the bzr in natty still uses python-central IIRC?
[23:35] <maxb> Ah, got it
[23:35] <maxb> The problem is that bzr in natty uses dh_python2
[23:35] <maxb> Whereas bzr in PPAs for << natty uses python-support
[23:36] <maxb> If bzr core is using python-support, it picks up plugins using python-support OK
[23:36] <maxb> Python namespace packages make me sad :-(
[23:37] <jelmer> dh_python2 ftw
[23:39] <maxb> I think allowing python-central and python-support to both exist was one of the nastier mistakes made in Debian packaging :-/
[23:40] <jelmer> maxb: me too
[23:40] <jelmer> glad it's finally over, though it's unfortunate we needed a third solution to get there
[23:41] <maxb> "over"
[23:41] <maxb> ha
[23:41] <maxb> I'm currently pondering how I might backport python2.6 to etch at work
[23:41] <jelmer> maxb: you people and your "stable" releases
[23:42] <jelmer> maxb: but yeah, you have a point.. it'll be a problem for a while more unfortunately :-/
[23:42] <maxb> It could be worse
[23:42] <maxb> At least I'm no longer compelled to deploy stuff on Slackware 10.0 servers (mostly)
[23:45] <jelmer> maxb: oh, fwiw, I'm also a PPU now
[23:45] <maxb> Ah, useful