[00:00] spiv: that seemed to do the trick [00:00] spiv: now, it's just a matter of moving them around [00:00] spiv: but that's probably the next rev [00:00] (and pending merges shows the revs. I assume this will show up in my logs, too?) [00:01] Whatever is in pending merges will be recorded when you do "bzr commit", yes. [00:03] spiv, Verterok: I merged it, and moved stuff, and commited it. I'm happy w/ the output of `bzr log`. Thanx, guys! [00:04] eddyMul: glad I could help! [00:04] * spiv -> late breakfast [01:11] New bug: #178813 in bzr "unexpected end of regular expression" [Undecided,New] https://launchpad.net/bugs/178813 === Verterok is now known as Verterok_ [06:32] hi everyone! [06:33] What everyone? [06:33] well, presumably the people in the channel [06:33] there appear to be quite a few [06:33] although given that this is irc, I assume most of them are idle [06:36] anyway, I was reading up on the "smart server" stuff, but wasn't able to find a whole lot in the way of documentation [06:36] is it just a performance optimization? or would it also allow, say, people committing without shell or ftp accounts on the box in question? [06:45] Catfish_Man: Mostly a performance optimization. I'm not sure how possible or easy it is to do that yet, but it could certainly work. [06:46] ok. I'll set it up on my test server then and see if I can get it working [06:46] thanks [07:41] New bug: #178838 in bzr "Progress bar for annotate" [Undecided,New] https://launchpad.net/bugs/178838 [09:03] I asked about rebase previously, and I don't have access to logs to see if anyone answered [09:03] the question was: rebasing can be used to reshape the commit history into clean "logical" patches, instead of how the devel actually happened, right? If so, how exactly would I go about that? [09:03] was there any answer to that? [10:19] mathrick: There are irc logs here: http://bzr.arbash-meinel.com/irc_log/bzr/ [11:07] GaryvdM: ah, handy [11:15] hmm, no reply, so my question remains open [11:28] jelmer: poke with the above question? === GaryvdM_ is now known as GaryvdM [12:52] jelmer, ? [13:35] New bug: #178865 in bzr-eclipse "diff error for newly added but not commited files" [Undecided,New] https://launchpad.net/bugs/178865 [14:10] New bug: #178873 in bzr "IndexError exception when branching into subversion format repo" [Undecided,New] https://launchpad.net/bugs/178873 [14:51] acuster: hi [14:51] mathrick: rebase can be used to "linearalize" history [14:52] it does not do things like combine revisions or anything like that [14:52] hey, jelmer a few questions for you [14:53] hi [14:53] 1) svn;// doesn't seem to work here (possibly because of the server). Is there any advantage to using it rather than http:// [14:53] svn:// is a different protocol than http:// [14:53] it only works if the server is running the svnserve application [14:54] 2) I made a shared repo called gtnew, and did the bzr(-svn) branch so my ~/.bazaar/subversion.conf has a line "locations = file:///soft/BZR/gtnew" [14:54] do I need to do anything special to rename that dir to gtbranches? [14:55] (re 1:) right, but is bzr-svn much faster using svn:// or does it not matter? [14:55] I think svn:// is slightly faster, but I'm not sure [14:55] to bzr-svn there is no difference [14:55] the difference is all in the Subversion libraries [14:55] ok [14:56] how did you create the shared repo? It shouldn't be adding an entry to subversion.conf if you create a new shared repo [14:57] 3) can I reorganize my branches under a shared repository at will? e.g. I have sharedRepo/trunk and I'd like to make sharedRepo/original/trunk so can I just do local unix commands to change that? [14:57] no, the entry was created when I branched under that shared repo [14:58] acuster: Any reason you're branching /into/ a Subversion repository rather than into a Bazaar repository? [14:58] cd /soft/BZR/; mkdir gtnew; cd gtnew; bzr init-repo --no-trees --rich-root; bzr branch http://svn..../trunk/ . [14:58] ahh [14:58] I must be phrasing things incorrectly [14:58] you should be able to simply use mv [14:59] we have an svn server in canada; I'm trying to use bzr locally [14:59] ok [15:00] so do I need to worry about the subversion.conf file at all if I rename the bzr shared-repo directory? [15:01] jelmer: I see, git's rebase does allow you to rewrite history in such a way [15:02] (rebase --interactive + "squash" and/or "edit" merge directives) [15:03] I'd find such a rewriting tool very useful, it allows you to submit changesets with patches that follow the logical order, instead of the chronological and you don't have to expose the intermediate bugs [15:06] mathrick: patches are welcome :-) [15:06] :) [15:09] is there documentation for the subversion.conf file? [15:10] acuster: not really [15:10] acuster: the locations= setting isn't read by bzr-svn [15:11] cool. Thanks for the help. [15:11] and thanks, more importantly, for the code :-) [15:13] Glad it's useful (-: [17:17] * ddaa just spent one hour setting up eclipse+pydev+bzr [17:17] first keystroke in a python file, and it busylocks... [17:17] why do all IDEs have to suck soo much? [17:54] <__gotcha> has bzr-svn been built as a macport ? [17:54] <__gotcha> rather, has a macprot been built for bzr-svn ;-) ? [18:01] What is the coding style for imports in bzr? It seems to be a mixture of "from package import module" and "from package.module import definition". I have trouble telling when to use which. [19:17] ddaa: its in HACKING [19:17] lifeless: thanks [19:17] ddaa: and up to the developer using the thing if they want to be doing module.blah or definition; with one caveat [19:18] ddaa: things that are deliberatly monke pachable are always the former. [19:22] mh, HACKING does not seem to give any specific answer to my question. [19:22] I'm trying to clean up the bzr-git code in the way that will make jam most happy (since my code is based on his branch). [19:22] although I do have a strong preference for "from package.module import definition"... [19:23] I guess, mainly because it's the Launchpad convention. [20:43] ddaa: nice, have fun. I'd assume the imports are fine though ;) [21:12] jelmer: I'm having bzr-builddeb issues with it not being able to clean the build area [21:12] jelmer: should I be running bzr-builddeb under sudo ? [21:18] jelmer: bzr branch http://bazaar.launchpad.net/~pkg-sphinx/pkg-sphinx/trunk [21:18] will get you an easily build branch that will break on the clean step [21:19] if it's a problem in my packaging, I'd be happy to fix it - but also I thought you might want to see it if it is a bug [21:19] jelmer: ^^ [21:44] jelmer: aha! I think I might know the problem. [21:44] jelmer: the packages I'm building install binaries into /usr/bin as root and stuff... whereas python packages wouldn't have this problem? [22:24] Wow, git's arg parsing can't even handle "-ad", but requires "-a -d"? How lame. [22:25] * mtaylor is really annoyed when people can't parse args right [22:25] it got solved like, 15 years ago for crying out loud - stop re-coding it [22:25] grrr [22:25] Well, you never know. Maybe getopt() is just too slow... [22:25] then maybe someone should fix it. :) [22:25] getopt() is no solution [22:25] Interestingly, pre-repack, git loses against bzr packs for storing 1 rev of an import of the YUI library. [22:26] (size-wise) [22:26] Post-repack, it wins, though. [22:26] 11M yui.knits/.bzr [22:26] 7.9M yui.packs/.bzr [22:26] 5.7M yui.git/.git [22:26] (git was ~9.6m before repack -a -d) [22:27] It's only one rev, so there's no delta compression to be had. I wonder what git did with that extra 1.7 meg. Maybe it uses less compression by default? [22:29] git doesn't just compress between revisions. [22:29] it compresses vs arbitrary other data [22:29] Well, yeah. That's why it wins post-repack. [22:30] I'm mildly curious where the pre-repack loss comes from. [22:30] (not curious enough to really investigate, of course :) === micr0c0sm is now known as mic0|zzZ [22:49] Is there a good reason I can't branch into an existing dir? E.g.: bzr branch sftp://path/ . [22:49] bzr: ERROR: Target directory "." already exists. [22:49] It's probably mostly because doing so without some checking would be dangerous, and nobody's bothered to write checking code. [22:50] I don't know of anybody objecting to it in principle (though I hardly know everything, or even most things) [22:52] fullermd: checking what? [22:52] That the directory is empty would be sufficient, probably. [22:53] My use case is managing an existing dir that may already contain a bunch of *un*versioned stuff, like $HOME. [22:53] Mmm. Now that's more likely to raise principle objections. [22:54] And requires a lot more checking; it would probably be Wrong(tm) for branch to proceed if there are any filename conflicts, frex, but deciding whether there are can be sticky. [22:56] Maybe some sort of "clobber" option (desirable in my case) would be useful? [22:57] Could be. It would certainly be shouted down as a default, but... unusual cases are what unusual options are for :) [22:58] I'm not sure what other situations this might arise. But I'd be surprised if no one here is already managina $HOME with bzr. === Verterok_ is now known as Verterok [22:59] Some people are. I don't think anybody's tried to branch it into an existing $HOME, though. [23:00] I do seem to have it working. But it's a bit ugly to have to do the branch to create a new dir and then: cp newdir/* newdir/.[a-zA-Z]* . [23:00] You might be able to do a branch into a tree-less repo, mv the .bzr into your homedir, then co the working tree. [23:01] hmm. That sounds cleaner. [23:01] You'd have to deal with whatever conflicts it causes... [23:02] I _think_ it would tend to make the bzr-version the '.moved' variant and leave the existing files with the current name. 'revert --no-backup' would overwrite them, I think. [23:05] fullermd: I'll play around some more with this. Thanks for the advice. [23:08] (Well, I guess you'd have to fiddle a little bit to get the repo put together with the branch in that case...) [23:15] re [23:16] mtaylor: I'm not sure. You should be using something like fakeroot, even with bzr builddeb [23:16] mtaylor: james_w is the expert though, he may be able to comment on this better [23:16] jelmer: so you think I should be doing "fakeroot bzr bd" [23:16] I'm not actually sure [23:17] "bzr builddeb" has "just worked"[tm] for me [23:17] ok. :) [23:17] well, I tried a small little patch to builddeb that tries shutils.rmtree() and if that fails tries sudo rm -rf [23:17] which now works for me :) but I'm sure is not the "right" way to do it [23:24] builddeb should have a -r option like debbuild [23:24] bob2: I think it already does something [23:24] since I don't have to specify anything or configure anything [23:25] I'm sure at least one of my packages runs dh_checkroot [23:35] I have some packages that build fine and some that give me this problem [23:36] do they build ok under dpkg-buildpackge -rfakeroot? [23:36] yup [23:36] but the clean that's failiing here has nothing to do with dpkg-buildpackage [23:36] it's a clean of the build area [23:36] perhaps builddeb needs to do a debian/rules clean before it cleans the build area? [23:37] so that it can let dpkg-buildpackage invoke fakeroot/sudo as needed for the clean?