[00:25] <_amanica_> were we supposed to stop using bundle-buggy already? [00:26] <_amanica_> nevermind, I need to sleep now. will ask again another time.. [02:04] LUSERS [02:04] been a long time since I last used irc.. anyone here that might be able to answer a bazaar question? [02:04] ... [02:07] I am trying to set up repository with multiple projects and traditional trunk, branches, tags, etc.. Documewntation has left me guessing twixt no-trees and conmtainers === FryGuy_ is now known as FryGuy- [07:04] hello igc? [10:08] Is it possible to change an author name on old bzr revisions? [10:08] Like say one of my team members got married, and she wants her married name on her old bzr revisions. [10:08] How would I go about doing that? [10:09] Was she married when she made those commits? [10:09] Is that a no? [10:09] It's not. [10:10] There are ways, but if anyone has done anything based on those revs (incl. merges etc) then it'll be a total and complete arse [10:10] And basically involves replaying history [10:10] IIRC [10:10] They haven't. [10:10] It's just commits in trunk [10:10] And noone else has committed after her commits which need changing? [10:10] Uhhhhhhhhh [10:10] She committed r77 [10:10] We're pushing 700 >_< [10:11] Then there's stuff "based" on the commits [10:11] Social problem. [10:11] She needs to understand that the past is the past. [10:11] Well uhhh [10:11] Same as I cope with the fact that some of the early commits in one project I never thought I'd publish have change comments like "feh, moosed." [10:11] She doesn't like her old last name for reasons I can't disclose on channel ._. [10:11] There's no way to change it? [10:11] Not without replaying history entirely IIRC [10:12] and that'll break any in-flight branches you might have, or any of your users might have [10:12] So I can just set my clock back to 2006 and redo it all? >_> [10:12] If we have users that would be news to me [10:12] Is she wanting you to fix all the backups to not contain her old name too? [10:13] Backups? [10:13] Those get erased after they're old [10:13] Because bzr is incremental and includes all of history [10:13] It truly sounds like she should just stop worrying, names are hardly a critical thing. [10:13] Maybe there's two backups? [10:13] awilcox: Now, if only it were possible to *guarantee* that nothing else will corrupt historical data [10:56] Hello, can I use bzr to maintain a package that I've merge from Ubuntu ? [10:57] Yes? [10:58] it's gnome-games, === Kissaki^0ff is now known as Kissaki [11:28] I did bzr branch lp:~ubuntu-desktop/gnome-games/ubuntu [11:28] then changed in the packaging [11:29] so, if I do bzr push [11:29] how can I maintain the diff for following versions ? [11:30] just do bzr pull lp:~ubuntu-desktop/gnome-games/ubuntu for every new version or what ? [12:25] AnAnt: If you've committed new revisions, you'd have to use "bzr merge", but sure. [12:25] AnAnt: I don't know the best practices for packaging branches, though, [13:10] How can I run the bazaar unit test suite? [13:11] bzr selftest [13:12] (and then go make lunch or something :)) [13:15] luks: How long does a test suite run normally take? I see that bzr has more than 19000 tests. [13:16] I don't remember [13:16] I used to be more than 30 minutes, but that was over a year ago [13:17] is there a possibility to run only some tests? bzr selftest or something like that? [13:17] bzr selftest test_name_pattern [13:17] there is also an option to run only a specific module [13:17] see bzr help selftest [13:18] luks: Thanks :-) (running the self-test after every generation of a new RPM packages seems to be a good way to ensure everything is still working) [13:19] not sure if the maintainers of the build machines will be happy about it :) [13:19] luks: Probably I have to ask - given the current rate the full run will take ~ 1 1/2 hours... [14:12] hello [14:12] what is the intended purpose of bzr nick? [14:12] hi [14:17] What is the expected key id for the signature of the bzr release tarballs? They seem to be signed by Robert Tanner but this is not mentioned in the installation FAQ.. [14:18] scfe: signed by the RM, which differs per release. [14:18] LarstiQ: But the InstallationFAQ does not mention the release manager for 1.14/1.15 [14:19] so who is the release manager for 1.14/1.15? [14:20] gioele: it's a nick name for a particular branch, e.g. "trunk", "fix-bug-42342", "jelmer", etc [14:20] scfe: 1.14 was Bob Tanner, 1.15 I haven't paid attention to [14:21] scfe: note that http://bazaar-vcs.org/InstallationFaq hasn't been updated since 0.13 [14:22] * LarstiQ doesn't know if they're mentioned somewhere else [14:23] jelmer: I knew that. I just found the real use: nick are preserved no matter what arguments you use to clone a branch. A renamed dir keeps the original nick (unless set again after the clone) [14:24] gioele: right. It's more that in absence of an explicit nick it defaults to the basename of the branch root. [14:29] LarstiQ: looks like. However I found a ml post (https://lists.ubuntu.com/archives/bazaar/2009q1/055151.html) for his nomination. And obviously he signed the 1.14 which ubuntu ships so I guess key id 0x0DDBE378 should be okay. [14:32] OK, I've added another term to CategoryTerm: http://bazaar-vcs.org/Nick [14:33] scfe: if, given a released version, you want to know who the RM was, it's easier to check the -announce list: https://lists.ubuntu.com/archives/bazaar-announce/ [14:33] scfe: the release announcement will be made by the RM [14:34] now Bob includes his gpg fingerprint in his mails *checks to see if other RMs mention the signature* [14:35] seems not [14:37] scfe: bzr/doc/developers/release.txt mentions to upload and link the sig from http://bazaar-vcs.org/Download , would also stating it to be explicitly mentioned in the announcement help your use case? [14:39] LarstiQ: I needed to ensure that the signature is legitimate. Mentioning key id and/or checksums would definitely help (from a distro perspective you can't be paranoid enough ;-) [14:40] scfe: well, they're mentioned next to the release itself on http://bazaar-vcs.org/Download [14:41] someone could potentially change that, but they could also send mail [14:41] scfe: so I'm wondering which source you're willing to trust :) [14:41] On that page I only fig the sig. But how can I verify that the key used for the sig is legitimate? (e.g. someone hacked the server and put his own binaries/sigs there) [14:41] * LarstiQ nods [14:41] scfe: yes, how do you? [14:41] LarstiQ: A release announcement on a mailing list which is mirrored by many web sites mentioning the key should be okay. [14:42] scfe: ok, then lets include that in the release policy. [14:42] LarstiQ: Thanks :-) [14:58] does it ever make sense to update an unbound branch, or to pull a bound branch? [14:59] jelmer: hi! [14:59] jelmer: just saw you the script didn't reproduce the bug for you [15:00] Tak: yes. [15:01] Tak: firstly, update makes sense in a working tree context. Now consider from remote `bzr push host/unbound`. The working tree will now be out of date wrt its branch. [15:01] Tak: hence the push-and-update plugin [15:01] Tak: pulling in a bound branch will pull to it's master. [15:02] Tak: so they do both make sense, but for different usage then what you had in mind I think. [15:04] ok, that's fine [15:05] I just want to make sure I shouldn't be hiding "Update" when the branch is unbound, and vice-versa [15:05] Tak: afaik those are the only usages, if you can provide that in a different way you might get away with it. [15:05] Tak: it's a balancing act between not confusing users and giving them the power to accomplish things. [15:06] Tak: in bzr too, it could be debated if this behaviour is what we want. [15:06] since I agree it isn't entirely obvious [15:06] Tak: so if you have a better workflow model, please share! :) [15:06] heh [15:21] hi. has anyone experience with clue-bzrserver? I cannot manage to get it running, and there is almost no documentation. Or can anyone recommend me the simplest way to have authentication on commit/push without having to expose the full path on the server? (the way bzr+ssh works). [16:22] What would be the best way to search for commits by a particular user? I can't see anything in bzr log about it, and bzr search doesn't appear to either. [16:23] ricardokirkner: I think rocky or pygi are the people to talk to [16:23] servilio: hi [16:24] jelmer: hi! [16:24] jelmer: as usual, thanks for the help/info... I will ping them later then [16:24] servilio: Yeah, I couldn't reproduce it but then realized I was testing with an older version of bzr-svn [16:24] so I'll give it another try in a few minutes [16:24] jelmer: ok, let me know [16:27] * pickscrape resorts to bzr log -n0 | less [17:30] hello [17:30] i screwed up my repo on launchpad, i don't know why [17:30] how can i get it working again? [17:30] (link coming..) [17:31] https://code.launchpad.net/~c10ud/emesene/emesene-crazy [17:31] it shows two faulty revisions, it should show 1341 [17:34] is 1341 the revision at which you branched from somewhere else? [17:35] yes, i screwed up while trying to create another branch of this one [17:36] so is it that you don't want those two revisions in the branch? [17:37] yep [17:37] i don't even know why they got 1 and two.. [17:38] if you click "all revisions" it shows them as 1342 and 1343 [17:39] oh, right, but i tried reverting and didn't work...i'll try again [17:39] $ bzr branch lp:~c10ud/emesene/emesene-crazy [17:39] Branched 2 revision(s). [17:39] see? [17:40] $ bzr revert -r1341 [17:40] bzr: ERROR: Requested revision: u'1341' does not exist in branch: BzrBranch6('file:///home/riky/msn/emesene-crazy/' [17:44] from the branch's perspective, you want to revert to r0 (bzr log) [17:45] hmm, no, that's notn right [17:46] :s [17:47] anyway fortunately there's another repo in there that contains exactly what i need.. if it can help [17:47] it's stopped exactly at rev 1341 [17:47] `bzr uncommit -r0` seems to do what you want [17:47] or you could rebranch from the other [17:49] if i uncommit, then i must push directly or commit? [17:50] ok, i tried.. if i commit i get a newer revision: 1 [17:50] pushing make no difference [17:54] maybe found [17:54] let's try [17:57] i was using revid's but seems i can't get to previous numeration, when i commit i still get 1 or two...mmm [18:00] * maxb wonders if "bzr push --overwrite" is what C10uD wants? [18:01] after uncommit? [18:04] anyway, yes now i killed the latest two changes [18:04] but still, i get 1 as the latest commit id === nevans1 is now known as nevans [18:30] C10uD: is there some reason you're so concerned about the revision numbers? [18:32] just win the machine, i guess [18:35] * LarstiQ looks at the branch [18:39] $ cat .bzr/branch/last-revision [18:39] 0 c10ud.dev@gmail.com-20090518152659-6p2z7bbujksrzjn5 [18:39] what if i edit this? [18:40] i'll do it [18:41] that seems like A Bad Idea [18:41] but, seems it worked (!) [18:41] C10uD: you can change it, but you generalyl shouldn't have to [18:41] let's see web interface [18:42] it worked ._. [18:42] so simple, wtf [18:42] brb food, thanks for your support guys [18:42] :) [18:58] Ok, I can pretty much guess what the answer is ; but... when editing branch metadata (like `.bzr/branch/location`) in vim, they become broken (because of vim's obstinate insistence of tacking a line ending to the end of every line). Workaround ; don't use an editor that follows this convention, or use the binary mode of vim (by passing -b). But would people be open to making Bazaar tolerant of this condition? [19:04] awilkins: I think so [19:04] Ooh, goody [19:05] awilkins: what is .bzr/branch/location used for though? I don't have that file [19:06] It's used in lightweight checkouts to point to the location of the branch [19:06] Mine appeared to have been orphaned so I was editing it to point to a new spot [19:34] so i haven't quite pinpointed the exact way to reproduce the bug, but using bzr+ssh to a remote host that i have ControlMaster configured for in my .ssh/config file seems to break that ssh connection semi-regularly [19:34] it seems bzr keeps the connection open [19:35] so if i started a shell session first, it freezes [19:35] if i used bzr first and try to connect via ssh, ssh never seems to connect (like the control pipe isn't responding) [19:36] i'd like to let bzr use ssh connection multiplexing, but as a workaround is there a way to tell bzr what options to pass to its ssh subprocess? [20:17] When running bzr checkout --lightweight, the control directory is not supposed to come along, correct? [20:17] mib_dbs1teqz: it is supposed to come along, but contain almost no data [20:18] Ah [20:18] mib_dbs1teqz: for no control directory at all, use "bzr export" [20:18] Excellent; it's for pulling onto a live web server, so that would be best [20:19] mib_dbs1teqz: if you need to keep a checkout without control directory on a web server up to date, use bzr upload [20:21] What is the difference between that and export? [20:28] mib_dbs1teqz: export doesn't work incrementally [20:28] For small projects, would there be any noticeable advantage? [20:29] I think export will complain if you use it incrementally [20:29] OK. [21:05] jelmer: is there some way to just disable the whole "discovering tags" step in bzr-svn? [21:06] it's always by far the longest part of push or pull to the repo, and I don't really care that much if bzr-svn knows about the svn tags dir. [21:18] hm, the wiki seems to advocate ssh multiplexing yet it seems awfully buggy to me: http://bazaar-vcs.org/Bzr_and_SSH [21:18] nevans: it should be very quick in newer versions [21:19] schmichael: I haven't ahd any trouble with it [21:19] jelmer: really? damn, wonder whats going on for me. ubuntu 9.04 locally and debian lenny remotely fwiw [21:21] hm, think bzr-avahi or dbus could be to blame? i'll try disabling them [21:21] Does Bazaar have anything similar to externals in Subversion? [21:22] MattCampbell: not yet, but work is underway [21:45] how do i display the current rev # like "hg id"? [21:45] ah revno [21:48] Offtopic : does `top` have a problem reporting process memory allocation beyond 2GB (on a 64-bit kernel) ? [22:26] Is there any way to take my uncommitted changes and apply them to another branch? [22:27] Since the branch I have the changes in is bound... [22:27] awmcclain: you can use bzr merge --uncommitted [22:27] dash: Perfect. === Kissaki is now known as Kissaki^0ff [23:54] how do i make a patch? [23:59] Ddorda: bzr diff > file.diff [23:59] thanks