| fullermd | Well, I think with bzr:// your access-control options currently reside in your firewall... | 00:00 |
|---|---|---|
| ekimus | and filesystem hopefully | 00:00 |
| ekimus | time for bed today, time for bzr tomorrow :) - thanks for clarifications | 00:02 |
| fullermd | Oh, I guess. I'd assumed you wouldn't have anything under bzr://'s root except what you wanted to serve. | 00:02 |
| lifeless | bzr has a soft chroot facility | 00:03 |
| lifeless | you can limit it to a branch/repo easily | 00:03 |
| lifeless | and auth is done via the protocol | 00:03 |
| lifeless | e.g. ssh, or http provide authentication | 00:03 |
| lifeless | raw bzr:// does not currently have authentication, so its only suitable for anonymous access | 00:03 |
| lifeless | abentley: ping | 00:09 |
| abentley | ping | 00:09 |
| lifeless | looking at this graph thing | 00:09 |
| lifeless | I'd like to change heads() to use a single parents() call each iteration | 00:09 |
| lifeless | rather than having a set of searchers | 00:09 |
| abentley | So then how do you know when you're done? | 00:11 |
| lifeless | I'm decoupling the points we're at search wise from the parents() lookup | 00:13 |
| lifeless | so there would still be a searcher concept but its not being used to retrieve data | 00:13 |
| kiko | hey guys | 00:14 |
| lifeless | this means that each iteration will have just one parents() lookup, rather than one per side | 00:14 |
| kiko | lifeless, do we need medusa to run the bzrlib tests? | 00:14 |
| lifeless | the ftp ones yes | 00:14 |
| kiko | lifeless, were these enabled recently? | 00:15 |
| lifeless | they auto enable if they can | 00:15 |
| lifeless | if you' | 00:15 |
| kiko | odd | 00:15 |
| lifeless | if you're running the tests via bzr selftest it won't error if its absent | 00:15 |
| kiko | bzr: ERROR: exceptions.UserWarning: You must install medusa (http://www.amk.ca/python/code/medusa.html) for FTP tests | 00:15 |
| kiko | bzr 0.18.0 on python 2.4.3.final.0 (linux2) | 00:16 |
| kiko | arguments: ['./bzr', 'selftest', '-v'] | 00:16 |
| kiko | ** please send this report to bazaar@lists.ubuntu.com | 00:16 |
| * kiko scratches head | 00:16 | |
| lifeless | if you're running make check, which we use for regression tests on pqm, then it requires all optional modules to be present | 00:16 |
| kiko | no | 00:16 |
| kiko | it's being run like this: | 00:16 |
| kiko | python -Werror ./bzr selftest -v | 00:16 |
| lifeless | well | 00:17 |
| abentley | lifeless: Well, my inclination would be to have the searchers conspire to reduce lookups. | 00:17 |
| lifeless | remote the -Werror if you want to be able to not have medusa installed | 00:17 |
| abentley | But I wouldn't oppose your approach. | 00:18 |
| lifeless | ok | 00:18 |
| lifeless | I'll spend some time grokking the code more | 00:18 |
| abentley | i.e. you do next(), and it causes all searchers to buffer their next output. | 00:20 |
| lifeless | I think there are really three concepts here | 00:23 |
| lifeless | A 'reachability cache' | 00:23 |
| lifeless | or 'searched revisions' or something like that | 00:23 |
| lifeless | 'getting parents' | 00:23 |
| lifeless | 'choosing what revisions to examine next' | 00:24 |
| lifeless | I'll fiddle somewhat. Firstly I'm going to instrument it slightly to figure out what its looking at at the moment | 00:24 |
| lifeless | oh, hmm. just notced | 00:26 |
| lifeless | KnitParentsProvider looks up single parents at a time | 00:26 |
| lifeless | I'll fix this first | 00:26 |
| lifeless | abentley: btw, a note on the api, if I might | 00:28 |
| === kiko is now known as kiko-zzz | ||
| lifeless | get_parents(["x", "x"]) seems to be awkward, it might be nicer to do the self-associating style of result I've done in the index layer | 00:29 |
| poolie | kiko, lifeless, that does seem to be a bug that it's giving a warning not a missing dependency - just old code i guess | 00:29 |
| abentley | yes? | 00:30 |
| poolie | lifeless, it looks like the packs megapatch still needs more reading, so i'm going to do that today | 00:31 |
| poolie | unless something else comes up... | 00:31 |
| lifeless | abentley: yah, if you cast the query into a set, or want to gather answers by the best IO pattern, you have to buffer and do housekeeping in the parents provider; but the caller actually doesn't really care AFAICT. | 00:31 |
| abentley | I'm just doubtful that, in general, splitting the "searcher" part from the "parents retrieval" part is actually going to lead to more readable code. | 00:34 |
| lifeless | I'll be careful ;) | 00:34 |
| lifeless | for now, I'm just implementing _make_parents_provider and get_parents directly on PackRepository | 00:34 |
| abentley | Yes, that will be much nicer. | 00:35 |
| lifeless | its a necessary step | 00:35 |
| lifeless | it may not be sufficient, we'll see | 00:35 |
| lifeless | much better | 00:40 |
| lifeless | still kinda slow | 00:40 |
| lifeless | but much better | 00:40 |
| lifeless | (it was fast enough I didn't have time to ctrl-C it) | 00:40 |
| lifeless | poolie: yes, reading the packs patch is good | 00:41 |
| igc | morning all | 00:42 |
| lifeless | hi igc | 00:43 |
| lifeless | bbiab, getting food | 00:43 |
| igc | hi lifeless | 00:43 |
| lifeless | while this test runs | 00:43 |
| === mw is now known as mw|out | ||
| lifeless | poolie_: igc: incremental patch 2842 sent to bazaar-commits, and pushing now | 01:32 |
| igc | thanks | 01:33 |
| lifeless | hi nDuff , how are you ? | 01:42 |
| nDuff | busy. | 01:42 |
| nDuff | interesting times. | 01:42 |
| nDuff | yourself? | 01:42 |
| lifeless | You live in China ? | 01:42 |
| nDuff | heh, no. | 01:42 |
| lifeless | Busy - putting the polish on our new repo format. | 01:42 |
| fullermd | Which also has a negative effect on times, one hopes ;) | 01:44 |
| ubotu | New bug: #153774 in bzr "Unreachable network raises an AssertationError (bzr+ssh)" [Undecided,New] https://launchpad.net/bugs/153774 | 01:45 |
| nDuff | How are 'yall doing performance-wise these days in comparison with mercurial? I'm looking for a way to track the upstream portage tree we're using to build our servers; it's over 100,000 files, there are lots of removes and adds of similar files on a regular basis, but we don't care about much in terms of functionality beyond basic snapshotting. | 01:47 |
| lifeless | on my laptop | 01:48 |
| lifeless | with crypted disk | 01:48 |
| lifeless | committing a 55K tree with a few changes, without specifying those files, is 20 seconds | 01:48 |
| nDuff | hmm. | 01:49 |
| nDuff | I'll probably want to benchmark current bzr for my use case, then | 01:49 |
| lifeless | we're working on bring that down by a factor of four in the next month | 01:49 |
| lifeless | you'll want to benchmark with the packs repository format | 01:49 |
| lifeless | this drops the number of files in your repository [for your scenario] from 200,000 to 5 * log10(commits) * 10 as an upper bound | 01:50 |
| lifeless | specifically a 100000 file repo with 10000 commits will have 5 data files. 10001 commits will have 10, as will 10010 etc, 10002 will have 15 data files. | 01:51 |
| nDuff | is that included in 0.91? | 01:52 |
| lifeless | nope. | 01:52 |
| lifeless | its what I'm polishing right now, the patch is being reviewed at the moment. | 01:53 |
| lifeless | I can throw up a tarball easily for you | 01:53 |
| nDuff | if you could do that, or just point me at somewhere I can pull from. | 01:53 |
| lifeless | the place its hosted is in pack format already - I'm dogfooding :) | 01:53 |
| nDuff | ahh. | 01:53 |
| nDuff | a tarball, then, yes. | 01:54 |
| lifeless | http://people.ubuntu.com/~robertc/packs.tar.bz2 | 01:56 |
| lifeless | you need pyrex to build the C extensions, which you'll want for benchmarking | 01:56 |
| lifeless | what else, oh yeah, committing a merge is currently pathologically slow; its a bug in the logic in the new format that I'm fixing right now. | 01:56 |
| lifeless | (by pathologically, I mean 180 times slower than a non-merge commit) | 01:57 |
| lifeless | you can run from source, just 'make' in the source dir, then symlink something to 'bzr' | 01:57 |
| lifeless | oh, and the last thing is that we currently don't remove the obsoleted files - the .bzr/repository/obsolete-packs/ directory - in production this will be not used | 01:58 |
| lifeless | to make a pack branch, do 'bzr init --experimental' | 01:59 |
| nDuff | I'm not worried about merging, so that WORKSFORME. | 02:05 |
| nDuff | I'll be sure to exclude the contents of obsolete-packs when determining space efficiency. | 02:05 |
| lifeless | yah | 02:05 |
| lifeless | we haven't optimised for space yet | 02:05 |
| lifeless | thats probably another month or two down the track | 02:05 |
| lifeless | we've got some very promising research figures though | 02:06 |
| lifeless | jelmer: I think I've found one cause of additional reads | 02:10 |
| lifeless | so, merge commits are improved lol ... 45 times slower | 02:25 |
| * lifeless codes some more | 02:26 | |
| lifeless | 15 times slower | 02:31 |
| fullermd | Hm. I estimate that given your current rate, if you can keep that up for another 2 hours we'll be about 50x as fast as cp ;) | 02:31 |
| lifeless | rofl | 02:32 |
| fullermd | Extrapolation FTW! | 02:32 |
| piedoggie | I tried upgrading an ubuntu 6.06 system to the latest bzr using apt-get banned it only knows about version 0 .17. Is this the latest release supported for dapper or am I doing something wrong? | 03:22 |
| * igc food | 03:29 | |
| * piedoggie tosses pizza | 03:29 | |
| ubotu | New bug: #153786 in bzr "pack repositories do not retry when concurrent operations pack" [Undecided,New] https://launchpad.net/bugs/153786 | 03:30 |
| ubotu | New bug: #153787 in bzr "annotation is slow in pack repositories" [Undecided,New] https://launchpad.net/bugs/153787 | 03:35 |
| ubotu | New bug: #153788 in bzr "pushing from packs to knits is slow and does not indicate why" [Undecided,New] https://launchpad.net/bugs/153788 | 03:55 |
| ubotu | New bug: #153789 in bzr "old packs are kept indefinately" [Undecided,New] https://launchpad.net/bugs/153789 | 03:55 |
| lifeless | abentley: still around ? | 04:22 |
| lifeless | abentley: I've found the bug | 04:26 |
| lifeless | abentley: find_seen_ancestors accesses 1000's of revisions | 04:26 |
| poolie_ | lifeless, to confirm, there's no good reason why our pqm needs to use https? | 04:50 |
| === jdong_ is now known as jdonginator | ||
| lifeless | poolie_: ack | 04:52 |
| lifeless | hows the review going? | 04:52 |
| poolie_ | interruptedly, but getting more into it now | 04:52 |
| poolie_ | one more question, about the bug of problems when retiring packs | 04:52 |
| poolie_ | would it work better, i wonder | 04:53 |
| poolie_ | to not move the packs, but instead keep a journal of retired packs | 04:53 |
| poolie_ | and just exclude them from the index | 04:53 |
| lifeless | two problems with that | 04:53 |
| lifeless | one is reconcile/gc operations where you want to change the data clients see | 04:54 |
| lifeless | the second is that it becomes a clock synchronisation problem | 04:54 |
| lifeless | (if you do it by count of operations a fast client breaks slow clients, if you do it by clock a bad clock results in clients being broken) | 04:54 |
| lifeless | not to say its the wrong solution | 04:55 |
| lifeless | but I don't think its any more complete, just will have some impact on frequency | 04:55 |
| poolie_ | hm | 04:57 |
| === jeremyb_ is now known as jeremyb | ||
| lifeless | spiv: is the search order of a set stable in a single process? | 05:58 |
| lifeless | spiv: that is if I have a set S, and do list(S) == list(S) is that guaranteed true ? | 05:59 |
| spiv | lifeless: I don't think so. | 06:01 |
| spiv | lifeless: because values with colliding hashes might come out differently, iirc. | 06:01 |
| spiv | lifeless: http://rafb.net/p/WV5cRP27.html demonstrates a case where s_a == s_b, but list(s_a) != list(s_b). | 06:07 |
| lifeless | spiv: I don't care about different list instances | 06:07 |
| lifeless | spiv: just repeated iterations of the same list. | 06:07 |
| lifeless | I have an API to use that returns a list for the things in an iterable; if I pass in a set to it, I need the same iteration order to zip them back up again | 06:08 |
| spiv | If the two sets are constructed the same way, and are manipulated the same way (so have the same sequence of additions, removals, etc), then in CPython you're probably safe. | 06:08 |
| lifeless | no | 06:10 |
| lifeless | SAME INSTANCE | 06:10 |
| spiv | Or if you're asking about the same set object, with no changes to the state of that set object between listifications, that's probably safe as well. | 06:10 |
| lifeless | sorry for shouting but it was clearly not getting through | 06:10 |
| spiv | But I don't think that's guaranteed. | 06:10 |
| lifeless | I'm looking for more than "probably" | 06:10 |
| spiv | Shouting on IRC doesn't hurt ears, I'll cope :) | 06:10 |
| lifeless | :) | 06:11 |
| lifeless | still somewhat rude :0 | 06:11 |
| i386 | Your so polite lifeless, yet irc so vile.. | 06:12 |
| i386 | wait, ive been drinking with you before. I take it all back | 06:13 |
| spiv | lifeless: yeah, I cannot find any guarantees on that in the documentation (or source) for set or for frozenset. It strikes me as something that it might be uncontroversial for frozensets to guarantee, but I doubt python-dev would extend that to sets. | 06:16 |
| lifeless | i386: :) | 06:22 |
| lifeless | spiv: thanks | 06:32 |
| Tesla|Work | sabdfl: hi, man :-) | 06:42 |
| poolie_ | lifeless, hi, more than half done | 07:42 |
| poolie_ | lifeless, several of the methods changed to return tuples- can you remind me why? | 07:42 |
| lifeless | two reasons | 07:44 |
| lifeless | historical data isn't meant to be mutable, so tuples are a better fit | 07:44 |
| lifeless | GraphIndex, which backs mapped knits returns tuples | 07:44 |
| lifeless | so the test was broken as some repo's returned lists and some tuples, so I had to coerce it one way or the other | 07:45 |
| lifeless | and I chose tuples | 07:45 |
| soren | If I have some code that I'd like automatically contain the revision number of the bzr tree it's in, how would I do that? Should I add a call to "bzr revno" somewhere in my build system to save it, or is there something like CVS' magic $Revision$ markers or something entirely different? | 08:21 |
| mwhudson | i'm pretty sure there's nothing like $Revision$ | 08:23 |
| mwhudson | you could probably write a post-commit-hook to put it in a file somewhere, i guess | 08:23 |
| spiv | There's no $Revision$ magic at the moment. Keyword substitution leads to awkward problems that we haven't tackled yet. | 08:24 |
| soren | Ah, bzr has post-commit-hooks? I did not even know that. /me blushes | 08:24 |
| mwhudson | at least, i think it does :) | 08:26 |
| poolie_ | soren, you should use the version-info command to write it into a file | 08:29 |
| soren | poolie_: Ok. | 08:30 |
| soren | poolie_: How about commit hooks? Does bzr have anything like that? | 08:30 |
| poolie_ | soren, yes, though at the moment they're exposed as python hooks not as shell commands | 08:32 |
| soren | poolie_: Oh, ok. | 08:33 |
| poolie_ | basically, you should write a python module in ~/.bazaar/plugins/ | 08:33 |
| poolie_ | and have that call | 08:33 |
| poolie_ | Branch.hooks.install_hook('post_commit', your_hook_here) | 08:34 |
| poolie_ | we know many people would like to just specify a shell command and we will try to do that soon | 08:34 |
| soren | poolie_: Right. I'd especially like the commit hooks to be part of the source repository so that anyone using the source tree will have them. | 08:35 |
| sabdfl | spiv: does your "speed up reconcile" patch also speed up check? | 08:53 |
| spiv | sabdfl: it does, but it would only speed up the new checks added by the reconcile work. | 08:57 |
| spiv | sabdfl: so I expect it will still be very slow. | 08:57 |
| sabdfl | thanks spiv. i had to ^C a check on LP yesterday after 5 hours when it hit 1.7GB RAM | 08:57 |
| spiv | Ouch. | 08:57 |
| sabdfl | any prospect of cutting that down easily? | 08:58 |
| spiv | I don't know of any good reason why it needs to consume unbounded memory, so quite possibly. | 08:58 |
| spiv | That does smell a bit funny. The check/reconcile code is a bit ugly, it has to delve into the sorts of details I didn't even know existed until quite recently :) | 08:59 |
| spiv | But I would not be surprised to find there's something grossly inefficient lurking in that code. | 08:59 |
| === poolie_ is now known as poolie | ||
| fullermd | Does seem like a section of the code that hasn't gotten much optimization attention. | 09:10 |
| fullermd | After all, only pessimists would run check in the first place ;) | 09:10 |
| mwhudson | you would think that check could work one revision at a time and so that memory use shouldn't really grow | 09:18 |
| mwhudson | maybe that's naive though | 09:19 |
| * fullermd points and laughs at mwhudson's naivete. | 09:20 | |
| === ealden_ is now known as ealden | ||
| zerok | hi :) | 09:38 |
| === mwh_ is now known as mwh | ||
| Slant_Laptop | I checked out a Subversion repo using bzr. Then branched it to do some work. Now I can't remerge my work... apparently the repository formats are incompatible. Can anyone help me merge my code back upstream? | 12:28 |
| Lo-lan-do | What's your error message? | 12:30 |
| === kiko-zzz is now known as kiko | ||
| niemeyer | Would you guys have anything to do with this spam: Britney Spears poses nude in Bazaar | 12:32 |
| === mrevell is now known as mrevell-lunch | ||
| Slant_Laptop | bzr: ERROR: Repository KnitRepository('file:///home/scott/Projects/transit/move-to-paste/.bzr/') is not compatible with repository KnitRepository3('file:///home/scott/Projects/transit/transit-svn/.bzr/') | 12:34 |
| Slant_Laptop | Lo-lan-do: Sorry, that was to you. | 12:35 |
| Lo-lan-do | How recent is your bzr-svn? | 12:36 |
| Lo-lan-do | You may have to do "bzr upgrade --format=dirstate-with-subtree" | 12:37 |
| Slant_Laptop | Lo-lan-do: On which repo? | 12:45 |
| Slant_Laptop | Lo-lan-do: Bazaar (bzr) 0.90.0 | 12:45 |
| zerok | no release this month? ;) | 12:49 |
| jelmer | Lo-lan-do, the non-bzr-svn one | 12:50 |
| jelmer | zerok: been delayed a bit in order to have packs (new, much faster, format) in | 12:51 |
| Slant_Laptop | Grr. | 12:54 |
| Lo-lan-do | Slant_Laptop: I think "<jelmer> Lo-lan-do, the non-bzr-svn one" was for you | 12:54 |
| Slant_Laptop | Now it appears to have forgotten the common ancestor. | 12:54 |
| Slant_Laptop | :-\ | 12:54 |
| jelmer | Slant_Laptop, was the original branch created using bzr-svn 0.3? | 12:55 |
| Lo-lan-do | jelmer: Will bzr-svn use that packs format, or will it keep its own non-documented format? | 12:55 |
| Slant_Laptop | jelmer: I don't know. Whatever is in gutsy. How can I check? | 12:55 |
| jelmer | Lo-lan-do: dirstate-with-subtree is not bzr-svn specific | 12:55 |
| jelmer | it was meant to be the next format (as part of the move to nested trees) | 12:56 |
| Lo-lan-do | jelmer: I know, but apparently only bzr-svn uses it... | 12:56 |
| jelmer | Lo-lan-do: bzr-svn requires a format that supports subtree data | 12:56 |
| jelmer | there will be a variant of packs that supports subtrees as well | 12:57 |
| Slant_Laptop | Ok, so now I'm trying to merge the branch back into the svn checkout... | 12:57 |
| Slant_Laptop | How can I manually specify the common ancestor? | 12:57 |
| Slant_Laptop | (Which I happen to know is rev 80) | 12:57 |
| jelmer | I think you should be able to do something like 'bzr merge -r80..' | 12:57 |
| jelmer | but that will just do a cherrypick, not track history | 12:58 |
| Slant_Laptop | It says "all changes applied succesfully" but no changes have actually been made. | 12:58 |
| jelmer | perhaps "-r80..-1" or something | 12:59 |
| Slant_Laptop | Wee. | 12:59 |
| Slant_Laptop | Exception. | 12:59 |
| Slant_Laptop | That was fun. | 13:01 |
| Slant_Laptop | My X session died. | 13:01 |
| Slant_Laptop | I missed anything that may have been said, sorry. | 13:01 |
| Lo-lan-do | Slant_Laptop: You didn't miss anything | 13:01 |
| Slant_Laptop | Darn. ;-) | 13:01 |
| Slant_Laptop | Well, then it does seem I'm kinda screwed. There isn't any way to get these patches upstream? | 13:02 |
| jelmer | Slant_Laptop: What exception did you get? | 13:02 |
| Lo-lan-do | You can always try a bzr diff -rsomething and commit the patch to SVN by hand | 13:02 |
| Slant_Laptop | jelmer: One sec, I'll pastebi. | 13:03 |
| Slant_Laptop | jelmer: http://pastebin.com/d168541a8 | 13:04 |
| jelmer | Slant_Laptop: if this is a public project, please file a bug.. that shouldn't happen :-) | 13:06 |
| Slant_Laptop | jelmer: It's not, sorry. :-( | 13:06 |
| jelmer | other than that, I'd recommend just using diff and patch like Lo-lan-do says | 13:06 |
| jelmer | or perhaps version 0.1 of the rebase plugin | 13:06 |
| Slant_Laptop | There's an awful lot of patches and logs. Darn. | 13:07 |
| Slant_Laptop | Rebase? | 13:07 |
| Lo-lan-do | jelmer: By the way, current bzr-svn refuses to work with bzr 0.91. Is that deliberate? | 13:07 |
| Slant_Laptop | Lo-lan-do: I thought there was a way to export a series of patches with the version information attached to them, and then merge that into a tree? | 13:08 |
| Lo-lan-do | That may be what's referred to as "bundles", but I haven't tried that yet. | 13:09 |
| jelmer | Slant_Laptop: yes, but that uses the same mechanism as merge | 13:10 |
| jelmer | Lo-lan-do: yes, there were incompatible changes so the next version of bzr-svn will only be compatible with 0.92 | 13:10 |
| Lo-lan-do | I see. | 13:10 |
| Slant_Laptop | jelmer: Oh, darn. | 13:11 |
| jelmer | Slant_Laptop: rebase (a plugin) just replays the commits while retaining commit metadata | 13:11 |
| jelmer | Slant_Laptop: You may be able to use 0.1 of that (http://bazaar-vcs.org/Rebase) | 13:12 |
| Slant_Laptop | jelmer: Checking that out. | 13:13 |
| zerok | jelmer, cool :D (sorry for the late reply... too many windows open :S ) | 13:13 |
| zerok | faster is great ... on my 12" powerbook bzr is dead slow :( | 13:14 |
| jelmer | mwh: your push bug should be fixed now | 13:14 |
| Slant_Laptop | Is there a way to install plugins without needing root? | 13:18 |
| Slant_Laptop | :-\ | 13:18 |
| dato | sure. install them under ~/.bazaar/plugins/name_of_the_plugin | 13:19 |
| Slant_Laptop | dato: Cool. Thanks. | 13:21 |
| dato | Slant_Laptop: just note that the directory names should not contain hyphens. eg. install bzr-svn under plugins/bzr_svn or plugins/svn | 13:22 |
| Slant_Laptop | jelmer: Umm. Haha, I'm getting the same error. :-D | 13:23 |
| jelmer | abentley: ping | 13:24 |
| jelmer | abentley: do you have any idea what could be causing the error at http://pastebin.com/d168541a8 ? | 13:25 |
| Slant_Laptop | jelmer: How do you tell rebase the ... uh, base? | 13:26 |
| jelmer | Slant_Laptop: sorry, I have a class to attend right now | 13:26 |
| Slant_Laptop | jelmer: Ok. Thanks for your help thus far. | 13:26 |
| jelmer | if you'd rather fix this than use diff+patch, please send me an email (jelmer@samba.org) | 13:26 |
| Slant_Laptop | jelmer: I kinda need to commit several hours ago. ;-) So I'll be writing a script to diff+path now. Thanks, though. | 13:27 |
| === mrevell-lunch is now known as mrevell | ||
| sabdfl | does one need to run bzr check before bzr reconcile, or can one just run bzr reconcile? | 14:14 |
| zeasier | need some help with bazaar advocacy | 14:30 |
| zeasier | discussing using it at work | 14:30 |
| zeasier | been using it a while personally and don't have much experience with svn | 14:30 |
| zeasier | some one mentioned atomic commits | 14:30 |
| uws | zeasier: bzr has those as well | 14:31 |
| zeasier | where if part of the commit goes wrong the whole commit gets rolled back | 14:31 |
| zeasier | yeah i thought it did | 14:31 |
| uws | zeasier: cvs had per-file revisions, which sucks since it can leave you in an inconsistent state afaik | 14:31 |
| zeasier | yeah that's why i wasn't prepared for that question, never used cvs | 14:32 |
| uws | zeasier: and you can also use bzr in a centralised way, i.e. you have to be up-to-date to the "main" branch before you can commit | 14:33 |
| sabdfl | zeasier: you can use it both distributed, and centralised like SVN | 14:33 |
| zeasier | yeah i've heard of this | 14:33 |
| zeasier | mostly been using it decentralized so far | 14:33 |
| zeasier | making good progress though only our sys admin needs convincing | 14:34 |
| uws | zeasier: server requirements are NONE. | 14:34 |
| zeasier | bosses seem to be alright with it | 14:34 |
| zeasier | yeah that's very apealing | 14:34 |
| uws | zeasier: but you can run a smart server for performance | 14:35 |
| uws | but sftp/ssh access is enough | 14:35 |
| zeasier | i was pretty happy with the built in ssh support in the fiesty release | 14:35 |
| uws | that's the recommended way to use it indeed | 14:35 |
| zeasier | though looks like we'll be using the central bzr apt repo, because of days like today | 14:36 |
| zeasier | where half of the office has time to upgrade and the other doesn't | 14:36 |
| zeasier | don't know how picky bzr is about different versions | 14:37 |
| zeasier | but don't want to push our luck | 14:37 |
| uws | latest versions are pretty compatible with each other | 14:37 |
| zerok | small question regarding the centralized approach: when commiting to the central repo, are there some hooks that could be used on the server to for example send update mails or update a feed? | 14:41 |
| === mw|out is now known as mw | ||
| zeasier | that sounds like a plugin issue (don't know the answer) might try to find some docs on plugin apis | 14:46 |
| zerok | yeah, i was just wondering since i found some docs on the hooks but everything smelled very client-sidey ;) | 14:49 |
| zeasier | one thing you could do is create a wrapper script | 14:49 |
| zeasier | like zbzr or something | 14:50 |
| zeasier | intercept commit commands and send what you want | 14:50 |
| zeasier | then forward the rest to bzr | 14:50 |
| zeasier | in anycase i'd imagine any solution you use would have to be client side | 14:51 |
| zeasier | unless the smart server has hooks or something | 14:51 |
| zerok | yeah. tnx :) | 14:52 |
| zeasier | (again don't take my words as authority) | 14:52 |
| zerok | ;-) | 14:53 |
| zerok | anyway: time to go home. cu later :-) | 14:53 |
| === bac_afk is now known as babc | ||
| === babc is now known as bac | ||
| === cprov is now known as cprov-lunch | ||
| === Solarion_ is now known as Solarion | ||
| hsn_ | bzr on windows is using builtin ssh client? | 16:54 |
| hsn_ | i need to setup public key auth | 16:55 |
| jelmer | yes, it's using paramiko | 16:55 |
| jelmer | it should be able to talk to pageant, for example | 16:56 |
| hsn_ | oh, it works | 17:02 |
| hsn_ | how to reference user home directory in sftp url? sftp://hsn@10.0.0.2/~hsn/java-devel/ dont works | 17:03 |
| === kiko is now known as kiko-fud | ||
| * zerok wants to thank whoever insisted on making the api that simple :D http://dpaste.com/22802/ | 18:22 | |
| james_w | zerok: we tried to stop them. | 18:29 |
| zerok | i can imagine :) | 18:29 |
| dato | oh, dpaste.com is pretty | 18:55 |
| jam-laptop | yeah, though it breaks all the indentation | 18:56 |
| Peng | dpaste.com sucks. When you reply to a paste, it doesn't link them together. | 18:56 |
| jam-laptop | unless there isn't any | 18:56 |
| jam-laptop | But it is a little weird to iterate over all entries just to take the last one | 18:56 |
| dato | jam-laptop: really? that'd be, uhm, bad. | 18:56 |
| jam-laptop | I suppose it is a little bit prettier than http://rafb.net/p/a6VXmd22.html | 18:58 |
| dato | I use rafb.net, but it annoys me when I have to paste non-ascii stuff: always serves my utf8 as latin1 | 18:59 |
| Peng | http://paste.pocoo.org/ ? | 18:59 |
| zerok | jam-laptop, sure, it was just a quick-hack :) | 19:00 |
| mwhudson | rafb only seems to keep pastes for about a day | 19:00 |
| dato | jam-laptop: indentation seems to work here? | 19:01 |
| jam-laptop | dato: yeah, I just misread the initial post, it didn't indent anything | 19:01 |
| dato | ok | 19:01 |
| zerok | jam-laptop, and i couldn't find a simple way to get the last changelog entry for that specified file without iterating over all the revisions in the first place ;) | 19:01 |
| jam-laptop | I can't say I like the color scheme of: http://paste.pocoo.org/show/6556/ | 19:02 |
| jam-laptop | but it seems to have the same level of syntax highlighting as dpaste | 19:02 |
| zerok | looks like the default pygments | 19:02 |
| jam-laptop | zerok: try this one | 19:02 |
| jam-laptop | zerok: http://paste.pocoo.org/show/6557/ | 19:03 |
| jam-laptop | ie.revision is the last revision that modified the file | 19:03 |
| jam-laptop | I think the difference between that and the log stuff | 19:04 |
| zerok | ah thanks :) | 19:04 |
| jam-laptop | is that the log will also track down entries that merged it | 19:04 |
| jam-laptop | (So if I change setup.py and you merge it without changing, ie.revision points to me, but log will also include your merge) | 19:04 |
| zerok | requires an explicit read-lock i guess :) | 19:04 |
| jam-laptop | zerok: yeah | 19:04 |
| jam-laptop | But i would do that anyway | 19:04 |
| jam-laptop | http://paste.pocoo.org/show/6559/ | 19:05 |
| zerok | yeah sure, this was just more or less a quick hack to find out if this would end up like that expedition i had with hg in the same territory :P | 19:05 |
| jam-laptop | Otherwise it has to read the working state for the path2id | 19:05 |
| jam-laptop | and then read it again for the .inventory | 19:05 |
| jam-laptop | zerok: was it better or worse ? | 19:05 |
| zerok | well, i'm still on the whole hg thing so bzr beat it by an hour so far :P | 19:06 |
| zerok | bzrlib.errors.InvalidRevisionId: Invalid revision-id {None} in KnitRepository('file:///Users/zerok/projects/rstsuite/.bzr/') :S | 19:06 |
| jam-laptop | ... oh, that is because this is the working tree. | 19:06 |
| jam-laptop | sorry, you want the basis | 19:06 |
| zerok | np, speed isn't really an issue with this project when it comes to determining that timestamp :) | 19:07 |
| jam-laptop | http://paste.pocoo.org/show/6560/ | 19:08 |
| jam-laptop | zerok: you could also look into "bzr version-info --all --format=python" | 19:08 |
| zerok | O_o | 19:09 |
| jam-laptop | It dumps the state of the whole tree | 19:09 |
| zerok | well, it will be used inside of a python program :-) | 19:09 |
| jam-laptop | and some basic information about the revisions to this poin | 19:10 |
| zerok | thanks again :) | 19:10 |
| jam-laptop | point | 19:10 |
| jam-laptop | There is also a --format=rio | 19:10 |
| jam-laptop | and I think we are about to merge a --format=C | 19:10 |
| zerok | O_o | 19:10 |
| zerok | there shouldn't be any problem with unicode in changelog messages, right? | 19:12 |
| jam-laptop | zerok: We support Unicode messages | 19:15 |
| jam-laptop | Problems are up to you :) | 19:15 |
| zerok | ah ok, just wanted to make sure :) | 19:15 |
| jam-laptop | For example, trying to commit a iso-8859-1 formatted message and your LANG=C | 19:15 |
| jam-laptop | or LANG=en_US.UTF-8 | 19:16 |
| jam-laptop | The one we see the most often is someone trying to use Unicode | 19:16 |
| jam-laptop | but their system claims to be ASCII | 19:16 |
| zerok | :S | 19:16 |
| jam-laptop | (thus we have no way to interpret it) | 19:16 |
| zerok | i had some problems a while back thanks to probably a broken bash or simply a missing font for my terminal and just switched to a VEDITOR ;-) | 19:17 |
| === kiko-fud is now known as kiko | ||
| ubotu | New bug: #154021 in bzr-eclipse "Reverse odering of revisions in Bazaar Log window" [Undecided,New] https://launchpad.net/bugs/154021 | 20:01 |
| gotgenes | What's the syntax to rolling back changes on a file using bzr merge? | 20:05 |
| james_w | gotgenes: you want to make the contents of a file the same as it was a few revisions ago? | 20:08 |
| james_w | or you want to remove the changes made by a commit a few commits back in the history? | 20:08 |
| gotgenes | james_w: that would be a bzr revert | 20:08 |
| james_w | yes | 20:09 |
| gotgenes | james_w: is there a way to strip out changes from a particular revision? | 20:09 |
| gotgenes | the second item | 20:09 |
| hendrixski | hey is this a good chanel to ask questions, or is it a dev channel? | 20:10 |
| james_w | gotgenes: bzr merge -r -3..-4 | 20:10 |
| james_w | and then bzr revert the files that you want to keep the same. | 20:11 |
| ubotu | New bug: #154023 in bzr-eclipse "Missing message in Push progress dialog" [Undecided,New] https://launchpad.net/bugs/154023 | 20:11 |
| james_w | I think that should work. | 20:11 |
| james_w | hendrixski: this is a perfect place to ask, go ahead. | 20:11 |
| hendrixski | james_w, cool | 20:11 |
| james_w | though it might not be the best place to get answers :) | 20:11 |
| hendrixski | I'm joining a startup. and we're contemplating cersion control | 20:12 |
| hendrixski | I heard a talk by Linus about git, and why people who use SVN or CVS are "stupid and ugly" | 20:12 |
| gotgenes | haha | 20:12 |
| gotgenes | I love that talk... | 20:12 |
| hendrixski | and I heard bzr was easier to use | 20:13 |
| james_w | hendrixski: I wouldn't listen to that too much. | 20:13 |
| Lo-lan-do | According to Linus, half of the people on Earth are stupid and ugly. | 20:13 |
| Lo-lan-do | And it's not always the same half, even. | 20:13 |
| hendrixski | gotgenes, yeah, he was telling Google developers that they're stupid | 20:13 |
| gotgenes | hendrixski: I think Bryan O'Sullivan's talk on Mercurial was much more informative | 20:13 |
| gotgenes | per DSCM | 20:13 |
| gotgenes | or DRCS | 20:13 |
| james_w | hendrixski: bzr does aim to be easier to use than git yes. with it is is up to you though. | 20:13 |
| hendrixski | Lo-lan-do, lol everyone except him | 20:13 |
| gotgenes | or however you like to call it | 20:13 |
| hendrixski | gotgenes, ah, I'll add that to list of things to research | 20:14 |
| hendrixski | so... the question then is... for a business, that will be developing on top of some open source applications, and also makeing some proprietary components is bzr something we should consider? | 20:14 |
| gotgenes | hendrixski: check out some of my del.icio.us links http://del.icio.us/gotgenes/dscm | 20:15 |
| gotgenes | the mercurial talk is in there | 20:15 |
| * hendrixski check out gotgenes stuff real quick like | 20:15 | |
| gotgenes | after reading through, I decided on Bazaar | 20:15 |
| james_w | hendrixski: I would say consider it definately, it might suit you perfectly. | 20:16 |
| hendrixski | gotgenes, now, DSCM stands for? | 20:16 |
| james_w | hendrixski: first I would work out how you are likely to want to work, and see which systems allow you to do that. | 20:16 |
| zerok | hendrixski, distributed source code management | 20:17 |
| hendrixski | zerok, ah, makes sense | 20:17 |
| james_w | hendrixski: then, as there will be at least one that can do what you want try them out and have a play, and see how they feel. | 20:17 |
| james_w | hendrixski: I am assuming as you are a startup you will have developers that are happy using advanced tools, would I be correct? | 20:17 |
| hendrixski | james_w, yeah, that's part of what we're trying to decide... if we're going to be working in the "there's only one official branch, and one lead dev who merges" or if we'll have everyone merge... | 20:17 |
| hendrixski | james_w, that would be correct. We're all about the latest tools. Ubuntu, Xen, etc. etc. | 20:18 |
| james_w | hendrixski: yeah, bear in mind that a distributed system allows you to defer that decision somewhat. | 20:18 |
| hendrixski | james_w, although, bzr is kind of a new tool as well, and "all the rage" | 20:18 |
| gotgenes | hendrixski: What I like about Bazaar is that it still allows the centralized model to be used until the dev team has figured out how to move to the distributed model | 20:19 |
| hendrixski | james_w, ah, that is a benefit | 20:19 |
| james_w | hendrixski: also Bazaar allows you to work in a SVN style, where you don't even have to worry about merging, and then when you want to do more then you can go for it without affecting the other team members. | 20:19 |
| * gotgenes points to james_w | 20:19 | |
| gotgenes | what he said | 20:19 |
| zerok | hendrixski, well, basically all candidates imo are still quite young :) | 20:19 |
| gotgenes | zerok: exactly | 20:20 |
| gotgenes | but my impression with Bazaar is that the project has direction | 20:20 |
| zerok | hendrixski, linux-only or do you also plan to support various operating systems? | 20:20 |
| hendrixski | james_w, gotgenes, so basically one can set bazaar to "svn mode" and it has the look and feel of a centralized system... just with easier merges? | 20:21 |
| james_w | hendrixski: many people prefer lots of branches and plenty of merging, but some feel that gets in their way. | 20:21 |
| hendrixski | zerok, mostly linux... it's for an appliance, and long term we'll need to make windows programs to interface with it. | 20:21 |
| james_w | hendrixski: yes, for the core commands then 'alias svn=bzr' almost works. | 20:21 |
| hendrixski | nice | 20:21 |
| james_w | (i.e. bzr checkout, bzr commit, bzr update, bzr revert etc.) | 20:21 |
| zerok | hendrixski, in this case it will probably also be a criterium how easy the dvcs is to install on the platform | 20:22 |
| james_w | hendrixski: do you have existing codebases? | 20:22 |
| hendrixski | yeah, the too many branches thing scares me too. When linux said " everybody has their own branch, sometimes many"... that sonuds like too much work | 20:22 |
| gotgenes | hendrixski: http://doc.bazaar-vcs.org/bzr.dev/centralized_workflow.html | 20:22 |
| james_w | once you get used to it it can be very empowering, but it does make you keep a lot in your head. | 20:23 |
| hendrixski | zerok, my understanding is that any ftp server will do, right? plus you can host a branch off your laptop, no? | 20:23 |
| gotgenes | hendrixski: http://bazaar-vcs.org/Workflows | 20:23 |
| zerok | hendrixski, yes, but i'm talking more about the "client" :) | 20:24 |
| * hendrixski checks out the workflow link really quickly | 20:24 | |
| zerok | for example there are some tools that are quite a pain to install on windows | 20:24 |
| hendrixski | zerok, ah. that's good to know | 20:25 |
| zerok | also some require additional tools for merging | 20:25 |
| hendrixski | zerok, such as? | 20:26 |
| zerok | hg requires a 3-way-merging tool since it does no merging by itself | 20:26 |
| zerok | or conflict resolution that is | 20:26 |
| hendrixski | james_w, about your code-base question: we have two open source projects that we'll be working with, those code bases exist... and we have a few things we've tinkered with, but for the most part... no, no code base of our own yet. very early stage | 20:27 |
| hendrixski | zerok, hg? | 20:27 |
| zerok | mercurial, hg http://www.selenic.com/mercurial | 20:27 |
| * hendrixski check out link | 20:28 | |
| hendrixski | zerok, ah... hg = mercury, so it's the company name... lol | 20:28 |
| zerok | more the product name, but yeah :) | 20:28 |
| zerok | as has been said, there are 3-5 options you have and you will probably do best by just checking them all out ;) | 20:29 |
| hendrixski | james_w, so does bzr also work well for pulling from upstream svn servers and making our downstream modifications? | 20:29 |
| james_w | hendrixski: you don't have to say what they are, but how large are the codebases? (no of files in working tree). | 20:29 |
| james_w | hendrixski: the marvellous bzr-svn does that. | 20:30 |
| hendrixski | zerok, yeah. we may just do that, I just have a TON of questions to help me know what to expect. :-) | 20:30 |
| hendrixski | james_w, and that's still beta, right? is it industry deployment ready? | 20:30 |
| hendrixski | one is about 15,000 files, one is probably 4,000 files | 20:31 |
| james_w | yeah, I guess it's still beta. jelmer is very responsive, and it works well on a lot of things, but I wouldn't embed it in a product or anything yet. | 20:32 |
| hendrixski | very little of it will be modifying that code base... more just building on it. | 20:32 |
| jelmer | pulling data out of svn works pretty well, pushing data into it has a couple of open bugs | 20:32 |
| gotgenes | james_w: Do you know where the documentation on how to use bzr-svn to convert a Subversion repository to a bzr repo is? I successfully installed bzr but am not sure how to use it. | 20:32 |
| james_w | hendrixski: you've probably heard that bzr isn't the best for performace, and those sizes are quite large, but things should be getting better. | 20:33 |
| gotgenes | er, installed bzr-svn | 20:33 |
| jelmer | (none very big though) | 20:33 |
| james_w | gotgenes: bzr branch svn://whatever/trunk/ | 20:33 |
| hendrixski | james_w, ah, and that just made me realize, bzr itself is not at version 1.0 yet... is it production-ready? | 20:33 |
| james_w | gotgenes: there is also svn-import if you want a full import of everything. | 20:33 |
| hendrixski | actually... how do I check the number of files in a directory? | 20:34 |
| jam-laptop | hendrixski: well, we have 8k+ unit tests which make sure we don't do anything foolish | 20:35 |
| zerok | hendrixski, including subdirectories? | 20:35 |
| jam-laptop | I would argue that we have been more stable than most for a long time | 20:35 |
| zerok | hendrixski, find . | wc -l | 20:35 |
| hendrixski | zerok, yeah | 20:35 |
| gotgenes | james_w: how does svn-import work? bzr svn-import is an unknown command | 20:35 |
| jam-laptop | We are also approaching 1.0 | 20:35 |
| hendrixski | ah, nice | 20:35 |
| jam-laptop | (hence the jump to 0.90+) | 20:35 |
| hendrixski | oh... wow, way smaller than I thought... they're both at about 5K files | 20:36 |
| james_w | there have been a few of regressions recently, so it's not perfect, but generally it is stable. | 20:36 |
| james_w | hendrixski: jam-laptop will be able to give you and idea of the performance of that better than me. | 20:36 |
| james_w | hendrixski: there are many people who run of the tip of bzr.dev (i.e. always running development code), and there are few problems that hit. | 20:37 |
| jam-laptop | james_w: yeah, well we made some pretty major changes recently, and part of that ended up jumping from 6k tests to 8k :) | 20:37 |
| hendrixski | jam-laptop, james_w, ah, so _mostly_ stable, would there be anything that would be considered a "show=stopper" like, it eats your code base if you misspell something? | 20:37 |
| jam-laptop | hendrixski: not that kind of bugs | 20:38 |
| hendrixski | ok | 20:38 |
| hendrixski | well. from everything I'm hearing here it sounds like I'll tell the coworkers that we should try it out | 20:39 |
| hendrixski | now, I can just apt-get it in Ubuntu and try it out, right? with that svn command james_w mentioned up above. no other major headaches? | 20:40 |
| jam-laptop | hendrixski: sure, though you may want to add the new apt repository | 20:43 |
| jam-laptop | http://bazaar-vcs.org/releases/debs/ | 20:44 |
| jam-laptop | with fiesty,edgy,dapper depending on what you are using | 20:44 |
| jam-laptop | (We are on a monthly release cycle, so you can usually get something a bit better from there) | 20:44 |
| jam-laptop | 0.15 specifically was one of the ones with some regressions in our rename tracking | 20:45 |
| jam-laptop | (The biggest regressions we've had are that sometimes Bazaar gets confused about the working tree, we've never, to my knowledge, had data loss from committed data that wasn't hardware problems) | 20:45 |
| hendrixski | ah, well.. gonna be switching to gutsy as soon as we verify (on a VM) that it doesn't break anything... but that repo you listed will always have a newer version? | 20:45 |
| jam-laptop | I'm not sure which version gutsy has, but it obviously had a freeze a month or so ago | 20:46 |
| hendrixski | yeah, .15 is the one I see on the feisty repo's now. By regression, you mean a step back where things went afoul, right? | 20:46 |
| jam-laptop | just a "echo deb http://bazaar-vcs.org/releases/debs/gutsy ./ >> /etc/apt/sources.list" | 20:46 |
| jam-laptop | hendrixski: something that worked in 0.14 stopped working in 0.15 | 20:46 |
| jam-laptop | (regression) | 20:46 |
| hendrixski | oh, I just added it using vim... I guess it's faster to echo, huh | 20:47 |
| jam-laptop | 0.16 fixed almost all of them | 20:47 |
| jam-laptop | 0.17 squashed the last ones I knew of | 20:47 |
| hendrixski | I C | 20:47 |
| hendrixski | good thing I'm not gonna be test driving .15 then :-) | 20:47 |
| hendrixski | that probably saved me a headache and a half. thanks jam-laptop :-) | 20:47 |
| jam-laptop | yeah, I know we wanted to get an update into the official Feisty repos | 20:49 |
| jam-laptop | but they are pretty strong about not abusing "Security" | 20:49 |
| jam-laptop | since it wasn't a strictly security issue | 20:49 |
| jam-laptop | And I'm not sure what the other issues were with the other 'backports' or whatever | 20:49 |
| hendrixski | and they didn't want to put in a few dpatch's into the packages to fix the regressions? | 20:50 |
| jam-laptop | Well, the fixes came long after Feisty was released | 20:51 |
| jam-laptop | well, after | 20:51 |
| jam-laptop | only like a month :) | 20:51 |
| hendrixski | well, in a 6 month release cycle, a month is a long time | 20:51 |
| jam-laptop | 0.15 was a pretty massive upgrade over 0.14 in other respects, it just brought a lot of code in | 20:52 |
| jam-laptop | and there were a couple bits that weren't correct | 20:52 |
| jam-laptop | mostly on handling projects with lots of files. | 20:52 |
| jam-laptop | 5k shouldn't be a problem | 20:52 |
| hendrixski | :-/ oh, the sources.list thing... had to change it to **vcs.org/releases debs/ for apt to accept it :-/ | 20:53 |
| jam-laptop | hendrixski: sounds like you are still missing some bits | 20:54 |
| jam-laptop | it *should* be | 20:54 |
| jam-laptop | deb http://bazaar-vcs.org/releases/debs/gutsy ./ | 20:54 |
| jam-laptop | or | 20:54 |
| jam-laptop | deb http://bazaar-vcs.org/releases/debs/feisty ./ | 20:54 |
| jam-laptop | in your case | 20:54 |
| hendrixski | and I'm missing a gpg key | 20:54 |
| hendrixski | yeah, I cw'ed gutsy to feisty | 20:55 |
| hendrixski | meh, I'll figure it out | 20:56 |
| jam-laptop | I think it is a | 20:56 |
| jam-laptop | gpg --recv-key XXX | 20:56 |
| jam-laptop | gpg --export XXX | sudo apt-key add | 20:56 |
| jam-laptop | sorry | 20:56 |
| jam-laptop | gpg --export XXX | sudo apt-key add - | 20:56 |
| hendrixski | I gotta get back to "real work" and not "dicking around on IRC" ... even though I solve more problems on here than anywhere else | 20:57 |
| jam-laptop | hendrixski http://bazaar-vcs.org/DistroDownloads | 20:57 |
| hendrixski | ah, right, gpg --export | 20:57 |
| jam-laptop | gpg --keyserver subkeys.pgp.net --keyserver-options http-proxy --recv-key EEA6AD6A | 20:57 |
| jam-laptop | gpg --armor --export EEA6AD6A | sudo apt-key add - | 20:57 |
| james_w | hendrixski: sounds like 'research' to me, I'd class that as real work. | 20:59 |
| hendrixski | man, I have to comment out all the ubuntu repositories in my sources. list 'cause they're slow as balls... I guess their servers are going at a snails pace due to gutsy frenzy | 21:01 |
| hsn_ | there is new ubuntu release? | 21:02 |
| jam-laptop | yeah | 21:02 |
| hendrixski | james_w, I would too, I guess my coworkers went on IRC a few times and talked about... whatever, porn or something, so they think it's a bunch of neck-beards talking about useless crap | 21:02 |
| jam-laptop | gutsy is out | 21:02 |
| hendrixski | hsn_, yeah, 7.10 hit servers today | 21:03 |
| jam-laptop | I thought 'apt-get install' was a bit slower than usual | 21:03 |
| james_w | jam-laptop: is .get_weave_or_empty going to stick around. It sounds weave specific. Is it just an unfortunate name to get something with a generic interface? | 21:03 |
| jam-laptop | According to the other channel | 21:04 |
| jam-laptop | Ubuntu is going at about 7Gb/s | 21:04 |
| hendrixski | yeah, those servers are handling about 6 million people downloading an entire distro... in one day | 21:04 |
| jam-laptop | And if you count mirrors | 21:04 |
| jam-laptop | it is something like 18 Gb/s | 21:04 |
| jam-laptop | Apparently to be an official US mirror you need >50Mb/s | 21:05 |
| jam-laptop | (just reading this from the other channel) | 21:05 |
| hendrixski | sweet. got it to show up version .16 | 21:08 |
| ubotu | New bug: #154045 in bzr-eclipse "Add support for bound branches" [Undecided,New] https://launchpad.net/bugs/154045 | 21:20 |
| sohmestra | I've got bzr-svn (0.4) installed, along with python-svn, and subversion on debian etch. However, when I attempt to branch a subversion branch, it tells me that the python svn bindings aren't installed. | 21:27 |
| sohmestra | see: http://dpaste.com/22833/ | 21:27 |
| jelmer | sohmestra: you need python-subversion, not python-svn | 21:27 |
| sohmestra | doh! | 21:27 |
| ubotu | New bug: #154047 in bzr-eclipse "Add push after commit checkbox into commit dialog" [Undecided,New] https://launchpad.net/bugs/154047 | 21:31 |
| dato | (http://chistera.yi.org/~adeodato/code/scripts/web/dpaste/) | 21:32 |
| jelmer | dato: after some more thought | 21:34 |
| jelmer | dato: I don't think merges can be rebased at all | 21:34 |
| jam-laptop | jelmer: why couldn't you rebase them? | 21:49 |
| jam-laptop | I suppose it should have human intervention | 21:49 |
| jam-laptop | but it would just be repeating the merge with a new parent | 21:49 |
| jam-laptop | Or it could even be implemented as replaying the diff | 21:50 |
| jelmer | jam-laptop: right, so you'd be replaying a merge | 21:50 |
| jam-laptop | and just setting the merge parent | 21:50 |
| jelmer | rather than reapplying the diff | 21:50 |
| jam-laptop | I would guess that is actually more what users would want (replaying the diff) | 21:50 |
| jam-laptop | since it is likely to have whatever fixes they did | 21:50 |
| jam-laptop | At least in my head "rebase" is redo what I did over here | 21:51 |
| jam-laptop | So replaying the diff is reasonable | 21:51 |
| jelmer | but if the branch on top of which you're rebasing already has a part of the changes you are trying to rebase things blow up | 21:51 |
| jam-laptop | (I would actually implement it as a cherrypicked merge over and over again) | 21:51 |
| jelmer | and that's usually the case | 21:51 |
| jelmer | yes, a cherry picked merge is what it's doing at the moment | 21:52 |
| jam-laptop | If the branch you are rebasing above already has the changes you are rebasing you have the same problem | 21:52 |
| jam-laptop | I suppose that is less common | 21:52 |
| jam-laptop | than if you had a merge | 21:52 |
| jam-laptop | jelmer: I think it is common if you are rebasing against Trunk and you have done some merges against trunk | 21:52 |
| jam-laptop | It is not common if you are merging a 3rd party's changes | 21:53 |
| jelmer | jam-laptop: the situation here is | 21:53 |
| jelmer | where you have done some hacking of your own | 21:53 |
| jelmer | then merged trunk and committed that merge | 21:53 |
| jelmer | than ran 'bzr rebase' | 21:53 |
| jelmer | s/than/then/ | 21:53 |
| jam-laptop | You could use ancestry checks to determine which is reasonable | 21:54 |
| jam-laptop | (if the merged revision is already present, skip it, else redo the diff and set the merge) | 21:54 |
| jam-laptop | http://rafb.net/p/Fc4Gny15.html | 21:55 |
| jam-laptop | Certainly it doesn't make sense to set A as the merge parent of C | 21:55 |
| jelmer | right | 21:55 |
| jam-laptop | but http://rafb.net/p/7z0Slc86.html | 21:56 |
| jam-laptop | If you are rebasing C on top of B | 21:56 |
| jam-laptop | (ignore F in that graph) | 21:56 |
| jam-laptop | You would want to keep D | 21:57 |
| jam-laptop | merging into E | 21:57 |
| dato | jelmer: mmm, was your comment actually directed at me? | 21:57 |
| jelmer | dato: yes, because of bug 126743 | 21:58 |
| ubotu | Launchpad bug 126743 in bzr-rebase "failure rebasing a merge" [High,Triaged] https://launchpad.net/bugs/126743 | 21:58 |
| jelmer | jam-laptop: thanks | 21:58 |
| dato | ah, thanks for the pointer. as if I could remember that. ;-) | 21:58 |
| jelmer | vila: ping | 22:29 |
| === cfbolz__ is now known as cfbolz_ | ||
| poolie | good morning | 23:15 |
| mwhudson | hello poolie | 23:19 |
| abentley | jelmer: It looks like that cherrypick is trying to add a file to a directory that isn't versioned. | 23:33 |
| jelmer | abentley: Is it ok for it to fail that way or is this a sign one of the trees is broken or perhaps a bug in merge? | 23:35 |
| abentley | I'd call it broken handling of an obscure conflict. | 23:35 |
| abentley | Definitely a bug in merge. | 23:36 |
| jelmer | abentley: ah, thanks | 23:41 |
| jam-laptop | poolie: good morning | 23:53 |
| poolie | jam-laptop, hi | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!