[00:00] can someone tell me what bzr-rebase does exactly, or smack me and tell me to just get the plugin and play with it? [00:00] it sound intriguing but I guess I don't completely understand what it's doing from the wiki's description [00:00] its a tool for discarding history [00:00] and making it hard to merge with people [00:01] ok tell me about why not to use it after telling me what it does :) [00:01] or making it linear, not having nested commits [00:01] but can be used to make the 'revision graph' look 'clean', and some projects consider this more important than good merging and collaboration. [00:01] jdong: what it does is transcribe the content of commits to a new revision graph [00:01] beuno: you don't need rebase to do that [00:01] lifeless: so it essentially extracts the patch associated with each commit in a child branch and linearly commits it to the parent branch? [00:02] lifeless, you don [00:02] er, you don't? [00:02] beuno: merge; bzr revert --forget-merges; bzr commit [00:02] jdong: no, bzr is not patch based. [00:02] lifeless, ah, right, but that's on a per-commit basis [00:03] though it's interesting to know, I've needed that a few times [00:03] lifeless: the operation that it rebase does is similar to a merge in end result, but not in history, correct? [00:03] beuno: concurrency is endemic to collaboration; trying to hide it is a lie. [00:03] wow I can't type coherently today [00:04] jdong: no, because it _discards history_ [00:04] lifeless: in what way? [00:04] (ok I think I should just play with bzr-rebase to find out for myself) [00:04] jdong: anyone following the branch that has been rebased can no longer follow it; they have to start over [00:04] lifeless: oh.... ouch. [00:04] jdong: the revision graph is what gives you the ability to do merges at all [00:04] lifeless, assuming that you always have non-conflicting merges, it shouldn't actually loose any useful history, no? [00:05] aaaaaaaah, interesting... [00:05] beuno: it always loses history === jamesh_ is now known as jamesh [00:05] _not_ what I need then :D [00:05] beuno: if you are a leaf node in the contributor graph, then the impact of this loss is minor or even trivial. [00:05] it should be stressed that i's more of a cosmetic thing [00:06] beuno: if you are not a leaf node in the contributor graph, then every node following you has pointers to revisions that your branch no longer refers to [00:06] beuno: imagine if linus rebased the linux mainline to insert a new commit a few days ago, which he'd done on a 'private mainline' or something [00:07] eep, what does a KeyError on a pack during commit mean? [00:07] bzr: ERROR: exceptions.KeyError: 'sftp://linerva/%7E/docs/.bzr/repository/upload/zq5x7hmwfonjtr1jgpd9.pack' [00:07] beuno: so - if you want to encourage a strict hub and spoke merge graph, rebase may fit the leaf nodes only [00:07] beuno: but if there are no leaf nodes, noone can use rebase without impact [00:08] lifeless, I see. I understand why you're so pesimistic about it now :D [00:08] jdong: no idea; what bzr version? try it again ? [00:09] 1.0 locally, 1.1.0rc was used a bit remotely, seems to happen consistently with this commit (9 pngs) [00:09] file a bug [00:09] get the backtrace from ~/.bzr.log [00:10] will do [00:10] New bug: #191402 in bzr "bzr resolve fails on files with certain strings" [Undecided,New] https://launchpad.net/bugs/191402 [00:21] New bug: #191409 in bzr "commit on bound branch yields KeyError" [Undecided,New] https://launchpad.net/bugs/191409 [00:24] lifeless: ^^ filed. Let me know if any more information would be helpful [00:28] lifeless: odd, looked like bzr+ssh:// worked fine (remote smartserver is 1.1.0~rc) [00:42] anyway to find out in which revision a file was removed? [00:43] or to get a log of a file not currently in a working tree? [00:44] mtaylor: probably not best way, but bzr log -v shows all the add/modify/deletes associated with each commit.... [00:44] mtaylor: so you can pipe that to less and search through it for a filename [00:44] the first catch should be the deleted revision [00:45] there are two grep plugins, aren't there? Maybe one of those can help [00:46] cool. that worked [00:47] so now if I want to revert the deleted file to that rev... ? [00:47] I actually want to restore that file and another, and then revert two other files to the state they were in that rev [00:47] mtaylor, you can: bzr cat dir/file -r revno [00:47] hm [00:47] cat it to a file [00:47] yeah [00:47] and there you have it [00:48] bzr cat dir/file -r revno > new_file [00:48] well hot-damn, look at that [00:48] mtaylor: please file a bug [00:48] lifeless: against what? [00:48] mtaylor: probably against log deleted_file_name not working [00:49] mtaylor: using revert to reinstate a deleted file to an old version [00:49] ah. ok [00:49] mtaylor: because you want to restore the file id too [00:49] lifeless: shouldn't there be a way to log old_file_name too? [00:49] mtaylor: I think there is one for deleted-way-back file names not working. we need a syntax for saying 'this file in that revision' [00:49] that doesn't involve a long grep [00:50] mtaylor: also, for your case, to restore the file name I suggest you do: [00:50] bzr merge -r 0..before:DELETEDIN ./path/to/filename [00:50] mtaylor: rather than playing games with cat [00:52] lifeless: can I give that a list of filenames? [00:52] mtaylor: no, not yet. there is a bug about that ;) [00:52] mtaylor: OTOH you can give it a directory :) [00:52] if a directory was deleted [00:53] well, I actually do want to cherry pick file from the dir... [00:53] but that's why bash has for! [00:53] for file in..... [00:54] beuno: jdong: for reference, 'revert' is an alias for a special form of merge. So problems with revert can usually be addressed by using merge in a clever way. [00:54] this matters because you get better results with log afterwards. [00:54] and with merge [00:54] lifeless: thanks. I should put this channel in my autojoin. I've learned more here the past 20 minutes than my entire day :) [00:56] lifeless, but won't you have to manage conflicts for a file you actually want to overwrite with a previous version? [00:56] beuno: rarely [00:57] beuno: anyhow, note that this is the exception, normally just revert will DTRT [00:57] lifeless, interesting. Thanks for the tip [01:04] lifeless: interesting, it seems like the problem is pushing over sftp onto an OpenAFS filesystem causes all kinds of blowups that I didn't notice before [01:04] bzr: ERROR: Generic path error: 'x5mcow4qnooegj14jua7.fetch': Failure: unable to rename to '../packs/e99efc4177e3d29106b0219514f8c3c4.pack') [01:04] that's a new one [01:05] lifeless: is there any way to get paramiko or whatever the SFTP backend is to give more debugging info? [01:16] jdong, there may not be a debug option, but there is a debug setting in paramiko [01:16] i'm just not sure how it's exposed [01:16] it may be an environment variable [01:17] separately, the failure i have at the moment is bzrlib.tests.blackbox.test_bundle_info.TestBundleInfo.test_bundle_info [02:11] i'm planning to fix bug 189771 by keeping a record of plugins that failed to load, [02:11] Launchpad bug 189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771 [02:11] and having the test suite fail if that list is nonempty [02:15] poolie: that sounds good to me [02:15] i think the other dirstate thing is now merged [02:15] god and pqm willing [02:26] poolie: I don't know that the launchpad plugin fails to load [02:27] poolie: it may be that the tests for it fail to load, but that that is a soft error. [02:27] true [02:27] poolie: if its the plugin failing to load, perhaps a test that all present plugins load ? [02:28] (said test disabled by --no-plugins of course) [02:28] ok actually it does load [02:29] if its the tests for it failing to load; then I think failing to load a test containing module should be a hard error not a soft error [02:29] I've always thought this :) [02:29] as in - don't run any tests, just stop cold [02:33] right [02:33] and it'd be a simple way to fix it [02:33] if you don't like it, you can always use --no-plugins [03:16] poolie: can you land the 1.3 NEWS sections etc asap [03:16] poolie: its a blocker for doing merges to mainline, unless you're going to fixup NEWS for us :) [03:17] hmm, well not 1.3, but at least the markers for what is 1.2 [03:17] lifeless, sure [03:17] (this is why its in the release process docs) [03:18] i have not got up to that part of the process yet [03:19] ah [03:19] so technically I can land something in mainline still. _cool_ [03:19] :> [03:26] lifeless, i'm submitting that patch now [03:26] the static declarations in symbol_versioning are a bit ugly [03:26] remember to check you merges to NEWS go into the right place [03:26] which patch? [03:26] to call it 1.3dev [03:26] oh the release stuff [03:26] yes [03:27] I'll hold off this merge then [03:27] I suspect your release process is somewhat difference in internal nature than mine [03:30] thumper: so why did you add test_lp_registration when there is test_register already ? [03:31] lifeless: test_register was testing the register branch command [03:31] and the rpc [03:31] lifeless: whereas test_lp_registration was testing the launchpad xmlprc bits [03:31] lifeless, also your change to use edge seems to break the tests, now that they're running, but probably in a straightforward way [03:32] poolie: well, when my change landed all the tests passed :) [03:32] thumper: for instance, test_register has test_mock_server_registration, testing the service directly [03:33] lifeless: I was pairing with abentley to do this [03:33] lifeless: and he suggested it and it seemed reasonable at the time [03:33] thats fine, I am worried that we either have duplication, or confusion. [03:33] if there is no duplication then its at best confusing to me [03:33] i think i will merge the files and dedupe [03:33] because test_register is just blackbox tests [03:34] thanks poolie [03:34] the tests in test_lp_registration are very simple and explicit, I don't think there is any duplication [03:34] is *not* [03:34] I don't have a strong opinion one way or the other [03:34] the tests could be moved if that would help unconfuse you [03:35] poolie has already said he will [03:35] poolie: But using --no-plugins means I can't use gselftest to run my tests... [03:35] ! i didn't know of gselftest [03:35] abentley: [03:36] abentley: tests that fail to load are still broken; I _really_ want hard errors on all such things [03:36] abentley: I don't really care if its expressed as a failing test ('all test scripts loaded'), or as an earlier error ('failed to create test suite') [03:36] lifeless: I think I agree. [03:37] There are some plugins I don't run because their test suites don't pass. [03:37] abentley, so you mean you want it shown as a failure, but other tests should run? [03:38] poolie: I think that would be fine. [03:39] I think its unneeded complexity though [03:39] note that this is only when the plugin's tests can't even be imported [03:39] as failing to run any tests is much easier to signal [03:39] hopefully that's rare [03:40] I think mainly I was saying that --no-plugins is not a panacea. [03:41] But the plugin should be fixed, and I have a low tolerence for broken plugins. [03:41] I have a very big ~/.bazaar/plugins/inactive directory [03:48] lifeless, re indenting of news, you want the asterisks in column 5? [03:50] poolie: yes [04:00] * igc bbl [04:05] lifeless, spiv: patch for 189771 sent, would appreciate if someone could look at it [04:05] i'm going out for a bit [04:05] New bug: #191449 in bzr-gtk "tests should skip if there's no $DISPLAY" [Undecided,New] https://launchpad.net/bugs/191449 === Verterok is now known as Verterok_ [04:43] bleh what a day of little-tasks [04:46] time for some coding [04:53] lifeless: im getting another me here at work [04:53] so they can do those sorts of things :) [04:53] didn't they break the mold? === asac_ is now known as asac [04:55] haha [04:55] urgh [04:55] large PNG is large [05:09] hee: AttributeError: '_PreviewTree' object has no attribute 'get_symlink_target' [05:10] i guess we didn't think that code was complete [05:19] mwhudson: nopes. [05:50] New bug: #191466 in bzr "bzr update on missing file does nothing. svn update brings back file." [Undecided,New] https://launchpad.net/bugs/191466 [06:35] lifeless, what do you mean "5 spaces rather than 2"? [07:35] rather than 4 [07:36] from [07:36] here [07:36] from [07:36] here [07:36] thats what the diff shows [07:36] thought so [07:36] did you have an objection to vila's patch other than the trace thing? [07:37] vila? or alexander? [07:43] vila [07:43] regarding setup.py [07:44] * igc dinner === aadis_ is now known as aadis [08:45] poolie: oh right the test cleanup one? [08:45] poolie: note vs info ? [08:50] yes [08:52] poolie: I hadn't seen his follow up [08:52] iz fine [08:53] i have a tarball [09:15] night all === zmanuel is now known as z-man [09:32] yay, rc1 [10:51] if i do a cvsps-import, what exactly do i have ? layoutwise? [11:09] hi, i need some help with bzr. Any body??? [11:10] There are lots of people here. Go ahead an ask. [11:10] since yesterday, i try to use "bzr branch http://bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta", and the transmission stop as you can see with this part of tcpdump output. [11:11] 08:04:52.496764 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: P 2615850:2616810(960) ack 6326 win 8416 [11:11] 08:04:52.496852 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 [11:11] 08:04:52.510477 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2616810:2618250(1440) ack 6326 win 8416 [11:11] 08:04:52.510582 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 [11:11] 08:04:52.524143 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2618250:2619690(1440) ack 6326 win 8416 [11:11] 08:04:52.524272 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 [11:11] 08:04:52.537799 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2619690:2621130(1440) ack 6326 win 8416 [11:11] 08:04:52.537903 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 [11:11] 08:04:52.551418 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2621130:2622570(1440) ack 6326 win 8416 [11:11] 08:04:52.551511 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 [11:11] 08:04:52.565075 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2622570:2624010(1440) ack 6326 win 8416 [11:11] 08:04:52.565177 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 Please use http://pastebin.org/ [11:11] please :D [11:12] my screnn show this "| [= ] Transferring 0/4" [11:12] sorry [11:12] cropalat, does bzr output an error? [11:12] beuno, no [11:12] but it get out with timeout [11:12] cropalat, doesn't seem bzr-related than [11:13] what version of bzr are you using? [11:13] Bazaar (bzr) 1.0.0 [11:14] cropalat, seems good enough. It's probably related to some problem with your ISP [11:14] you can try updating to the latest bzr if you want to try _something_ on your end [11:14] 1.1 es the latest release [11:14] i will get the traffic to see. Thanks [11:15] my distro are working with 1.0 [11:15] cropalat, what distro would that be? [11:15] Ubuntu 7.10 [11:16] cropalat, you can get the lastest from: https://launchpad.net/~bzr/+archive [11:16] either add the ppa to your sources.list, or just plain download and install the deb [11:16] beuno, what is new in this version? [11:17] cropalat, nothing significant enough that would fix your timeout, but it won't hurt :D [11:19] beuno, thanks [11:20] cropalat, np [11:23] beuno, where the bzr put the temp files? [11:24] cropalat: yourbranch/.bzr/ [11:26] garyvdm, any specia name? [11:27] cropalat - sorry - I don't understand [11:27] What are you looking for> [11:27] *? [11:29] garyvdm, how can i identify where the bzr are storing the download data at this time? [11:29] yourbranch/.bzr [11:29] where yourbranch is the dir you are creating the branch in [11:32] ok [11:33] If you bzr branch mybranch and it stop half way you can cd mybranch then bzr pull and it will carry on from where it stopped [12:05] hello, this is somewhat OT, but is it possible for your patiencediff to output only the *characters* that differ, not the whole line? [12:06] you can split the input on characters, not lines [12:06] but then it will be very slow, obviously [12:06] how would that work? [12:06] list("foobar") -> ['f', 'o', ...] [12:06] well actually i don't wont characters, just the subsets that differ [12:07] hello world vs hell0_world, in such a case 0_ [12:08] mikeX: yes the algorithm can do this [12:08] mikeX: and our internal code too [12:08] can you point me to the files that require modification for changing the output then? [12:08] mikeX: but its much more expensive (if each line was 80 characters, and it was a linear cost, 80 times slower, but its > linear, upto quadratic worst case) [12:09] mikeX: what you could do is something slightly different, and on the differing lines run the more expensive algorithm [12:09] bzrlib.diff has the bulk of the diff high level logic [12:10] thanks a lot [12:10] gnight [12:10] oh also [12:11] check out bzrlib.tests - there is a thing in there -assertEqualDiff that does a character level diff output [12:12] mikeX: PatienceSequenceMatcher(None, "hello world", "hell0_world").get_opcodes() [12:18] that's greak, thanks luk [12:18] s === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:46] is there a bzr plugin yet that can act like a "branch aggregrator" [13:46] i.e. check X different branch locations for new commits [13:51] jdong: Even if there was, would there be any difference between that and a shell script? [13:51] awilkins: well other than from a UI perspective, no. [13:52] that would be a final fallback if there weren't a plugin AND I wasn't willing to write one :) [13:52] Sort of like a branch manager GUI? [13:52] Keeps track of all your branches and such? [13:53] kind of like let's say "foobar" has a large developer community, with 20+ branches [13:54] right now, if I want to check for new commits from one of the developers, I'd have to keep track of 20 branch URLs by hand [13:54] or edit aliases by hand in a text editor... both of which are kind of annoying [13:54] I'd love to be able to do like "cd foobar; bzr check-related-branches" [13:55] and get a quick summary of type "Branch $foo has $n new revisions" === aadis_ is now known as aadis === asak_ is now known as asak [14:40] hi [14:40] if i have 5 branches and want to put them into a shared repository that i have just created using "bzr init-repo" what would be the command to use? [14:41] Just push them there [14:41] bzr branch [14:41] i want to pull 1 branch as a trunk, and put other 4 in branches/ [14:41] oh, or push [14:41] LeoNerd: thanks [14:41] hmm, PatienceSequenceMatcher seems to yield very bad results for unicode strings [14:45] hmm I get bzr: ERROR: No WorkingTree exists for "file:///home/ignas/src/schooltool.devtools/.bzr/checkout/" if I try bzr mkdir branches in the central repository [14:46] You just want to use mkdir for branches/... [14:46] oh === asak_ is now known as asak [14:55] New bug: #191569 in bzr "Cannot set "whoami" at a repository level" [Undecided,New] https://launchpad.net/bugs/191569 [15:00] New bug: #191572 in bzr "KeyError when pulling from svn repo." [Undecided,New] https://launchpad.net/bugs/191572 [15:10] New bug: #191576 in bzr "TypeError when using `bzr branch` on an svn repository" [Undecided,New] https://launchpad.net/bugs/191576 [15:23] abentley: hi. do you think `shelf show` could use colors like `shelve` itself does, and maybe gain a --no-color switch? [15:24] dato: I don't remember what shelf show does. [15:24] display the contents of a patch from the shelf [15:25] basically `cat $topofshelf` [15:25] Yeah, I think that's reasonable. [15:26] would you like a bug? I'm afraid time doesn't allow me to offer anything else =) [15:27] dato: Launchpad actually provides for feature requests as "blueprints". [15:28] * dato guesses he has the "wishlist bug" concept very hard wired in his brain [15:29] * abentley doesn't like it when people say his software has bugs just because it doesn't have a feature they want :-) === maw is now known as mw [15:30] I actually prefer the Trac approach of "Issues" being "Bugs", "Enhancements" and "Tasks". [15:32] fuck [15:32] had a network outage, now the bzr-gtk trunk is locked, and break-lock ain't working [15:32] Any packagers of bzr & company for Ubuntu/Debian/etc around? [15:32] abadger1999: yes [15:33] Do you guys do anything out of the ordinary to manage the large number of bzr plugins? [15:34] schierbeck: Pastebin us a traceback, and I can take a look. [15:34] abadger1999: yes: most of them are not packaged [15:34] personally I wanted to create a big package with a selection of the most useful ones [15:34] but several core people disliked the idea [15:34] dato: Yeah, that would make my day as well :-) [15:35] and I'm afraid I'm not going to spend my time in creating 10 or 12 different packages for such tiny stuff [15:35] dato: Isn't that what I do? ;-) [15:35] abentley: well, the only thing i get which resembles an error is "Disconnecting: Received extended_data after EOF on channel 0." [15:35] right after using break-lock on the remote branch [15:35] abentley: hehe [15:36] abentley: That's why bzrtools is packaged for Fedora but bzr-{dbus,avahi,bisect} is not :-) [15:37] schierbeck: That resembles a bug we had with old versions of Paramiko. [15:37] But it was a harmless message [15:37] maybe, but the locks are not released [15:37] actually, it just resets the lock time [15:38] schierbeck: Okay, so you probably have a couple of "bzr serve" processes running on the server. === asak_ is now known as asak [15:38] If there was an effort to get things into a single upstream product (like bzrtools) and make releases as part of that product then there'd be more uptake of the individual utilities. [15:38] You should be able to run break-lock several times. [15:39] abentley: yeah, it seems like it [15:39] i'll try [15:39] * abadger1999 resigns himself to asking for more bzr related packagers on the fedora lists [15:39] Each time you break-lock, a bzr process should stop. [15:39] abentley: that worked! thanks! [15:40] schierbeck: No problem. [15:42] abadger1999: and what do the packagers say? they'll do more packages? [15:42] i've drunk an unhealthy amount of coffee today... [15:42] dato: I'm guessing I'll get a bunch of people telling me to use git :-/ [15:42] abadger1999: heh [15:43] dato: I don't think the overlap between packagers and bzr users is very high in Fedora ATM. [15:43] abadger1999: there are a lot of git fanboys in debian as well [15:43] abadger1999: Could you post something to the list? If the authors are amenable, I'd be happy to incorporate more stuff into bzrtools. [15:43] damn, abentley was faster about the list bit [15:43] abentley: I sure can. [15:43] :) [15:44] And that's not exclusive with shipping the plugins separately. [15:44] Anything to help me scale more effectively :-) [15:45] how do I do a push without being in the branch, like bzr push /path/to/some-repo sftp://place-for-push ? [15:45] abentley: Oh? Meaning you'd help manage releases as separate tarballs from the bzrtools tree? [15:46] abadger1999: Meaning that bzr-dbus can be provided as a standalone plugin and as part of bzrtools. [15:46] abentley: okay. that would be awesome for packagers. [15:47] * dato bbl [15:47] I suppose the converse also applies, if people think bzrtools is getting too big. [16:02] * awilkins sulks because there is no dbus on Windows [16:02] There were rumours of a port [16:03] Cursory searching reveals one [16:03] I mean, it wouldn't be hard, windows is thick with IPC methods it could wrap [16:03] Only wanted to see if commit-notifier worked [16:04] It puts an icon in the toolbar then dies :-) [16:09] * Debolaz has a dbus-daemon.exe running on his Windows XP box. [16:09] At least according to task manager. :) [16:35] Hey, can I get bzr diff to do colour diffs with paging like git can do? [16:35] Right, I've switched from svk to bzr for my working-at-home needs from the SVN repo [16:36] awilkins, do you have issues where bzr eats all available ram (due to a bug in libsvn) when doing a big svn checkout? [16:36] orospakr: Yes, I have that problem, esp on my big repo [16:37] awilkins, it's been ongoing for years. [16:37] orospakr: Alas, it's now failing on something else, having successully converted about 7900 / 9000 revisions [16:37] recently I finally saw some activity on the svn bug tracker about this issue. [16:37] harsh. [16:38] You can at least resume it after it MemoryErrors you [16:38] But now it's the same KeyError on a pack each time [16:38] It's in the upload folder which makes no sense to me because it's PULLING not pushing [16:38] Go figure. [16:38] There's a bug in for it [16:39] #191572 === Mez__ is now known as Mez [16:42] I think increasingly SVN is going to end up as the nice, safe, steady backend for roving teams of developers using wild and crazy new VCS tools [16:43] Despite all the effort they put in for v 1.5 [16:44] And when TortoiseBzr or TortoiseGit are done, SVN will really start to die. [16:45] Tortoise ought to be possible - just use the common idiom and a plugin backend [16:46] Should cover bzr, mtn, hg, git ; there aren't too many radical differences there. === LarstiQ_ is now known as LarstiQ [16:51] cd .. [16:51] oops === bigdo1 is now known as bigdog === awilkins is now known as awilkins_away [17:10] orospakr: "bzrtools" provides cdiff. You can also use diff --using colordiff. The pager side is generally done using |less -R. [18:56] folks, help me understand something: apparently i can commit just one subdir of branch by "bzr commit dir" but how to update just some file/subdir? "bzr update dir" updates whole branch. [18:57] for general reading and comments: http://news.launchpad.net/general/the-great-source-code-supermarket [18:57] zurgutt, I'm not sure that's actually possible [18:57] bzr help update says "bzr update [DIR]" [18:58] That should probably say "bzr update [BRANCH]" instead... [18:59]