| 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:00 |
| spiv | Whatever is in pending merges will be recorded when you do "bzr commit", yes. | 00:01 |
| eddyMul | spiv, Verterok: I merged it, and moved stuff, and commited it. I'm happy w/ the output of `bzr log`. Thanx, guys! | 00:03 |
| spiv | eddyMul: glad I could help! | 00:04 |
| * spiv -> late breakfast | 00:04 | |
| ubotu | New bug: #178813 in bzr "unexpected end of regular expression" [Undecided,New] https://launchpad.net/bugs/178813 | 01:11 |
| === Verterok is now known as Verterok_ | ||
| Catfish_Man | hi everyone! | 06:32 |
| 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:33 |
| 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:36 |
| 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:45 |
| 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 | 06:46 |
| ubotu | New bug: #178838 in bzr "Progress bar for annotate" [Undecided,New] https://launchpad.net/bugs/178838 | 07:41 |
| 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? | 09:03 |
| GaryvdM | mathrick: There are irc logs here: http://bzr.arbash-meinel.com/irc_log/bzr/ | 10:19 |
| mathrick | GaryvdM: ah, handy | 11:07 |
| mathrick | hmm, no reply, so my question remains open | 11:15 |
| mathrick | jelmer: poke with the above question? | 11:28 |
| === GaryvdM_ is now known as GaryvdM | ||
| acuster | jelmer, ? | 12:52 |
| ubotu | New bug: #178865 in bzr-eclipse "diff error for newly added but not commited files" [Undecided,New] https://launchpad.net/bugs/178865 | 13:35 |
| ubotu | New bug: #178873 in bzr "IndexError exception when branching into subversion format repo" [Undecided,New] https://launchpad.net/bugs/178873 | 14:10 |
| jelmer | acuster: hi | 14:51 |
| jelmer | mathrick: rebase can be used to "linearalize" history | 14:51 |
| jelmer | it does not do things like combine revisions or anything like that | 14:52 |
| acuster | hey, jelmer a few questions for you | 14:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| acuster | we have an svn server in canada; I'm trying to use bzr locally | 14:59 |
| acuster | ok | 14:59 |
| acuster | so do I need to worry about the subversion.conf file at all if I rename the bzr shared-repo directory? | 15:00 |
| mathrick | jelmer: I see, git's rebase does allow you to rewrite history in such a way | 15:01 |
| mathrick | (rebase --interactive + "squash" and/or "edit" merge directives) | 15:02 |
| 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:03 |
| jelmer | mathrick: patches are welcome :-) | 15:06 |
| mathrick | :) | 15:06 |
| acuster | is there documentation for the subversion.conf file? | 15:09 |
| jelmer | acuster: not really | 15:10 |
| jelmer | acuster: the locations= setting isn't read by bzr-svn | 15:10 |
| acuster | cool. Thanks for the help. | 15:11 |
| acuster | and thanks, more importantly, for the code :-) | 15:11 |
| jelmer | Glad it's useful (-: | 15:13 |
| * 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:17 |
| __gotcha | has bzr-svn been built as a macport ? | 17:54 |
| __gotcha | rather, has a macprot been built for bzr-svn ;-) ? | 17:54 |
| 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. | 18:01 |
| 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:17 |
| lifeless | ddaa: things that are deliberatly monke pachable are always the former. | 19:18 |
| 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:22 |
| ddaa | I guess, mainly because it's the Launchpad convention. | 19:23 |
| lifeless | ddaa: nice, have fun. I'd assume the imports are fine though ;) | 20:43 |
| 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:12 |
| 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:18 |
| 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:19 |
| 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? | 21:44 |
| fullermd | Wow, git's arg parsing can't even handle "-ad", but requires "-a -d"? How lame. | 22:24 |
| * 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| fullermd | I'm mildly curious where the pre-repack loss comes from. | 22:30 |
| fullermd | (not curious enough to really investigate, of course :) | 22:30 |
| === micr0c0sm is now known as mic0|zzZ | ||
| 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:49 |
| fullermd | I don't know of anybody objecting to it in principle (though I hardly know everything, or even most things) | 22:50 |
| MicahElliott | fullermd: checking what? | 22:52 |
| fullermd | That the directory is empty would be sufficient, probably. | 22:52 |
| 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:53 |
| 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:54 |
| MicahElliott | Maybe some sort of "clobber" option (desirable in my case) would be useful? | 22:56 |
| fullermd | Could be. It would certainly be shouted down as a default, but... unusual cases are what unusual options are for :) | 22:57 |
| 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:58 |
| === Verterok_ is now known as Verterok | ||
| fullermd | Some people are. I don't think anybody's tried to branch it into an existing $HOME, though. | 22:59 |
| 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:00 |
| MicahElliott | hmm. That sounds cleaner. | 23:01 |
| fullermd | You'd have to deal with whatever conflicts it causes... | 23:01 |
| 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:02 |
| MicahElliott | fullermd: I'll play around some more with this. Thanks for the advice. | 23:05 |
| 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:08 |
| jelmer | re | 23:15 |
| 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:16 |
| 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:17 |
| 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:24 |
| jelmer | I'm sure at least one of my packages runs dh_checkroot | 23:25 |
| mtaylor | I have some packages that build fine and some that give me this problem | 23:35 |
| 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:36 |
| mtaylor | so that it can let dpkg-buildpackage invoke fakeroot/sudo as needed for the clean? | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!