[00:00] <eddyMul> spiv: that seemed to do the trick
[00:00] <eddyMul> spiv: now, it's just a matter of moving them around
[00:00] <eddyMul> spiv: but that's probably the next rev
[00:00] <eddyMul> (and pending merges shows the revs. I assume this will show up in my logs, too?)
[00:01] <spiv> Whatever is in pending merges will be recorded when you do "bzr commit", yes.
[00:03] <eddyMul> spiv, Verterok: I merged it, and moved stuff, and commited it. I'm happy w/ the output of `bzr log`. Thanx, guys!
[00:04] <spiv> eddyMul: glad I could help!
[00:04]  * spiv -> late breakfast
[01:11] <ubotu> New bug: #178813 in bzr "unexpected end of regular expression" [Undecided,New] https://launchpad.net/bugs/178813
[06:32] <Catfish_Man> hi everyone!
[06:33] <Peng> What everyone?
[06:33] <Catfish_Man> well, presumably the people in the channel
[06:33] <Catfish_Man> there appear to be quite a few
[06:33] <Catfish_Man> although given that this is irc, I assume most of them are idle
[06:36] <Catfish_Man> 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] <Catfish_Man> 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] <Peng> 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] <Catfish_Man> ok. I'll set it up on my test server then and see if I can get it working
[06:46] <Catfish_Man> thanks
[07:41] <ubotu> New bug: #178838 in bzr "Progress bar for annotate" [Undecided,New] https://launchpad.net/bugs/178838
[09:03] <mathrick> I asked about rebase previously, and I don't have access to logs to see if anyone answered
[09:03] <mathrick> 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] <mathrick> was there any answer to that?
[10:19] <GaryvdM> mathrick: There are irc logs here: http://bzr.arbash-meinel.com/irc_log/bzr/
[11:07] <mathrick> GaryvdM: ah, handy
[11:15] <mathrick> hmm, no reply, so my question remains open
[11:28] <mathrick> jelmer: poke with the above question?
[12:52] <acuster> jelmer, ?
[13:35] <ubotu> New bug: #178865 in bzr-eclipse "diff error for newly added but not commited files" [Undecided,New] https://launchpad.net/bugs/178865
[14:10] <ubotu> New bug: #178873 in bzr "IndexError exception when branching into subversion format repo" [Undecided,New] https://launchpad.net/bugs/178873
[14:51] <jelmer> acuster: hi
[14:51] <jelmer> mathrick: rebase can be used to "linearalize" history
[14:52] <jelmer> it does not do things like combine revisions or anything like that
[14:52] <acuster> hey, jelmer a few questions for you
[14:53] <jelmer> hi
[14:53] <acuster> 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] <jelmer> svn:// is a different protocol than http://
[14:53] <jelmer> it only works if the server is running the svnserve application
[14:54] <acuster> 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] <acuster> do I need to do anything special to rename that dir to gtbranches?
[14:55] <acuster> (re 1:) right, but is bzr-svn much faster using svn:// or does it not matter?
[14:55] <jelmer> I think svn:// is slightly faster, but I'm not sure
[14:55] <jelmer> to bzr-svn there is no difference
[14:55] <jelmer> the difference is all in the Subversion libraries
[14:55] <acuster> ok
[14:56] <jelmer> 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] <acuster> 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] <acuster> no, the entry was created when I branched under that shared repo
[14:58] <jelmer> acuster: Any reason you're branching /into/ a Subversion repository rather than into a Bazaar repository?
[14:58] <acuster> cd /soft/BZR/; mkdir gtnew; cd gtnew; bzr init-repo --no-trees --rich-root; bzr branch http://svn..../trunk/ .
[14:58] <jelmer> ahh
[14:58] <acuster> I must be phrasing things incorrectly
[14:58] <jelmer> you should be able to simply use mv
[14:59] <acuster> we have an svn server in canada; I'm trying to use bzr locally
[14:59] <acuster> ok
[15:00] <acuster> so do I need to worry about the subversion.conf file at all if I rename the bzr shared-repo directory?
[15:01] <mathrick> jelmer: I see, git's rebase does allow you to rewrite history in such a way
[15:02] <mathrick> (rebase --interactive + "squash" and/or "edit" merge directives)
[15:03] <mathrick> 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] <jelmer> mathrick: patches are welcome :-)
[15:06] <mathrick> :)
[15:09] <acuster> is there documentation for the subversion.conf file?
[15:10] <jelmer> acuster: not really
[15:10] <jelmer> acuster: the locations= setting isn't read by bzr-svn
[15:11] <acuster> cool. Thanks for the help.
[15:11] <acuster> and thanks, more importantly, for the code :-)
[15:13] <jelmer> Glad it's useful (-:
[17:17]  * ddaa just spent one hour setting up eclipse+pydev+bzr
[17:17] <ddaa> first keystroke in a python file, and it busylocks...
[17:17] <ddaa> 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] <ddaa> 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] <lifeless> ddaa: its in HACKING
[19:17] <ddaa> lifeless: thanks
[19:17] <lifeless> ddaa: and up to the developer using the thing if they want to be doing module.blah or definition; with one caveat
[19:18] <lifeless> ddaa: things that are deliberatly monke pachable are always the former.
[19:22] <ddaa> mh, HACKING does not seem to give any specific answer to my question.
[19:22] <ddaa> 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] <ddaa> although I do have a strong preference for "from package.module import definition"...
[19:23] <ddaa> I guess, mainly because it's the Launchpad convention.
[20:43] <lifeless> ddaa: nice, have fun. I'd assume the imports are fine though ;)
[21:12] <mtaylor> jelmer: I'm having bzr-builddeb issues with it not being able to clean the build area
[21:12] <mtaylor> jelmer: should I be running bzr-builddeb under sudo ?
[21:18] <mtaylor> jelmer: bzr branch http://bazaar.launchpad.net/~pkg-sphinx/pkg-sphinx/trunk
[21:18] <mtaylor> will get you an easily build branch that will break on the clean step
[21:19] <mtaylor> 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] <mtaylor> jelmer: ^^
[21:44] <mtaylor> jelmer: aha! I think I might know the problem.
[21:44] <mtaylor> 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] <fullermd> 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] <mtaylor> it got solved like, 15 years ago for crying out loud - stop re-coding it
[22:25] <mtaylor> grrr
[22:25] <fullermd> Well, you never know.  Maybe getopt() is just too slow...
[22:25] <mtaylor> then maybe someone should fix it. :)
[22:25] <foom> getopt() is no solution
[22:25] <fullermd> Interestingly, pre-repack, git loses against bzr packs for storing 1 rev of an import of the YUI library.
[22:26] <fullermd> (size-wise)
[22:26] <fullermd> Post-repack, it wins, though.
[22:26] <fullermd>  11M    yui.knits/.bzr
[22:26] <fullermd> 7.9M    yui.packs/.bzr
[22:26] <fullermd> 5.7M    yui.git/.git
[22:26] <fullermd> (git was ~9.6m before repack -a -d)
[22:27] <fullermd> 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] <foom> git doesn't just compress between revisions.
[22:29] <foom> it compresses vs arbitrary other data
[22:29] <fullermd> Well, yeah.  That's why it wins post-repack.
[22:30] <fullermd> I'm mildly curious where the pre-repack loss comes from.
[22:30] <fullermd> (not curious enough to really investigate, of course  :)
[22:49] <MicahElliott> Is there a good reason I can't branch into an existing dir?  E.g.: bzr branch sftp://path/ .
[22:49] <MicahElliott> bzr: ERROR: Target directory "." already exists.
[22:49] <fullermd> It's probably mostly because doing so without some checking would be dangerous, and nobody's bothered to write checking code.
[22:50] <fullermd> I don't know of anybody objecting to it in principle (though I hardly know everything, or even most things)
[22:52] <MicahElliott> fullermd: checking what?
[22:52] <fullermd> That the directory is empty would be sufficient, probably.
[22:53] <MicahElliott> My use case is managing an existing dir that may already contain a bunch of *un*versioned stuff, like $HOME.
[22:53] <fullermd> Mmm.  Now that's more likely to raise principle objections.
[22:54] <fullermd> 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] <MicahElliott> Maybe some sort of "clobber" option (desirable in my case) would be useful?
[22:57] <fullermd> Could be.  It would certainly be shouted down as a default, but...   unusual cases are what unusual options are for   :)
[22:58] <MicahElliott> 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.
[22:59] <fullermd> Some people are.  I don't think anybody's tried to branch it into an existing $HOME, though.
[23:00] <MicahElliott> 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] <fullermd> 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] <MicahElliott> hmm.  That sounds cleaner.
[23:01] <fullermd> You'd have to deal with whatever conflicts it causes...
[23:02] <fullermd> 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] <MicahElliott> fullermd: I'll play around some more with this.  Thanks for the advice.
[23:08] <fullermd> (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] <jelmer> re
[23:16] <jelmer> mtaylor: I'm not sure. You should be using something like fakeroot, even with bzr builddeb
[23:16] <jelmer> mtaylor: james_w is the expert though, he may be able to comment on this better
[23:16] <mtaylor> jelmer: so you think I should be doing "fakeroot bzr bd"
[23:16] <jelmer> I'm not actually sure
[23:17] <jelmer> "bzr builddeb" has "just worked"[tm] for me
[23:17] <mtaylor> ok. :)
[23:17] <mtaylor> well, I tried a small little patch to builddeb that tries shutils.rmtree() and if that fails tries sudo rm -rf
[23:17] <mtaylor> which now works for me :) but I'm sure is not the "right" way to do it
[23:24] <bob2> builddeb should have a -r option like debbuild
[23:24] <jelmer> bob2: I think it already does something
[23:24] <jelmer> since I don't have to specify anything or configure anything
[23:25] <jelmer> I'm sure at least one of my packages runs dh_checkroot
[23:35] <mtaylor> I have some packages that build fine and some that give me this problem
[23:36] <bob2> do they build ok under dpkg-buildpackge -rfakeroot?
[23:36] <mtaylor> yup
[23:36] <mtaylor> but the clean that's failiing here has nothing to do with dpkg-buildpackage
[23:36] <mtaylor> it's a clean of the build area
[23:36] <mtaylor> perhaps builddeb needs to do a debian/rules clean before it cleans the build area?
[23:37] <mtaylor> so that it can let dpkg-buildpackage invoke fakeroot/sudo as needed for the clean?