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