[00:01] beuno_: ping [00:02] Peng_, hi! === beuno_ is now known as beuno [00:03] beuno: About bug 247162, my patch makes it (mostly) valid, but wrong if the server's time zone isn't UTC, thanks to bug 376842. [00:03] Launchpad bug 247162 in loggerhead "atom feed does not validate" [Low,Triaged] https://launchpad.net/bugs/247162 [00:03] Launchpad bug 376842 in loggerhead "Loggerhead is time zone-naive" [Undecided,New] https://launchpad.net/bugs/376842 [00:03] \o/ [00:04] ola [00:04] hey lifeless [00:12] beuno: problem solved. thanks. [00:13] do you want me a file a bug, so you can claim some karma? [00:13] ;) [00:13] rowinggolfer, heh, I'll take the moral karma [00:20] lifeless: hi [00:20] lifeless: you working today? [00:22] yes [00:22] jam: ping [00:34] beuno: i guess we should create a milestone thingy for the next loggerhead release [00:34] mwhudson, yes! [00:34] codename? [00:34] Peng_, is bug 358336 still valid? [00:34] Launchpad bug 358336 in loggerhead "SQL cache directory isn't deleted on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/358336 [00:35] beuno: Yes. [00:35] Good morning. [00:35] Peng_, can you set it to triaged? [00:35] beuno: can you rename milestones? [00:36] mwhudson, maybe. I wouldn't bet on it. We could just say 1.16 [00:36] and put some pressure to release it for 1.16 :) [00:36] beuno: heh, ok :) [00:36] I'll create the 1.16 series [00:36] with a 1.16rc1 milestone [00:36] and a 1.16 as well [00:37] beuno: ok [00:37] thanks [00:37] I'm trying to clean up our bugs [00:40] eep, poor savannah [00:40] beuno: you're certainly sending me a lot of mail :) [00:40] Peng_, mwhudson, milestone 1.16rc1 created, target away! [00:42] "no bug left un-triaged" campaign [00:42] * Peng pokes at Peng_. [00:42] mwhudson, doesn't pastedeploy take care of bug 333755 [00:42] Launchpad bug 333755 in loggerhead "serve_branches script needs way to configure the public URL to the web server" [Undecided,New] https://launchpad.net/bugs/333755 [00:42] * Peng_ shrugs [00:43] beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/240508 is suggesting something like log --line, not a small diff i think [00:43] mwhudson, also, if you can tell me what bug 334615 is about, I'd be greatful :0 [00:43] Ubuntu bug 240508 in loggerhead "Files view should show one-line change line per directory/file" [Undecided,Won't fix] [00:43] Launchpad bug 334615 in loggerhead "Doesn't invalidate cache when ghosts filled" [Undecided,New] https://launchpad.net/bugs/334615 [00:45] jelmer, feel free to target branches at 1.16rc1 as well [00:45] especially the stuff you need for debian [00:46] beuno: i can't really remember the details for https://bugs.edge.launchpad.net/loggerhead/+bug/334615 [00:46] Ubuntu bug 334615 in loggerhead "Doesn't invalidate cache when ghosts filled" [Undecided,New] [00:47] mwhudson, maybe we can just set it to incomplet? [00:49] beuno: ok [00:49] beuno, will do [00:52] it's ironic how everything gets black if you do your job [01:53] jelmer: ping [01:53] jml: Hello [01:54] jelmer: [01:54] jelmer: I'm just being bitten by BZR_DEFAULT_INTERFACE not being in bzrlib.remote -- do you know anything about this? [01:55] jelmer: hmm. never mind. my bzr-archeology-fu is weak. [02:01] man, it's too hard to search for a thing being deleted. === cody-somerville_ is now known as cody-somerville [02:04] jml: yes; I have 'plans' [02:14] I've got some code that uses 'remote.BZR_DEFAULT_INTERFACE' -- I'm trying to figure out how the hell it ever worked at all, and what changed to make it not work. [02:16] I love it when that happens: "how does this work?"; "why is this working?"; "this _shouldn't_ be working!"; "how did this *ever* work?!?" [02:17] jml: as a starting point, r.texts.iter_lines_added_or_present_in((key for key in texts.keys() if key[0] == tree.path2id('__init__.py')) [02:20] hey! is there a command to apply a patch [02:20] path -p1 < ./patch.diff ? :) [02:21] jbalint: there is a patch command in bzrtools, but as cody-somerville says you can just apply normally ;) [02:21] yeah, patch crashes for me on windows :( [02:22] lifeless: did remote.py used to be a package? [02:22] (grammar sucks) [02:22] jml: oh, I thought it was a package [02:23] jml: so remote.py :) [02:23] jelmer used to have something like it as a plugin I thought [02:30] nfi how this worked [07:46] ciao === abentley1 is now known as abentley [08:49] vila: greetings :p [08:49] pygi: Hey ! [08:50] vila: howa re you doing? :) [08:50] pygi: fine thanks, I slept a lot this week-end :-) [08:50] happy you :P [08:51] vila: I didn't :p [10:16] hello fellows. I must be missing the correct keywords as I cannot find information on whether it is possible to move a line of revisions into a new branch. Any help? [10:26] hypest: What do you mean by "move" and "line of revisions"? [10:28] I decided that the latest 3 "trunk" commits, should really have their own branch. So I want these 3 revisions to form a new branch [10:28] bzr branch trunk newbranch [10:28] cd trunk && bzr uncommit -r -3 === Kissaki^0ff is now known as Kissaki [10:30] lifeless: that will probably do the job. I'm generally "afraid" of even thinking of using undo procedures, so that didn't cross my mind :). Thank you ;) [12:17] abentley: ping, bzrtools tests abort with: ImportError: cannot import name test_fetch_ghosts, sounds like a missing file [12:34] vila: thanks. fixed and pushed. === argv[0] is now known as mishok13 [12:44] abentley: pulled. thanks === lifeless changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [13:34] hi [13:35] hi moldy [13:35] Peng, I've updated the smart-server branch but I have no idea how to get launchpad to update the diff for the merge request [13:36] jelmer: I don't either. [13:36] jelmer, Peng_, apis, blah [13:36] nothing on the web UI yet [13:36] jml is working on it [13:37] Loggerhead should probably always use a read-only transport. [13:38] jelmer: Will keeping the smart server around have any RAM implications? [13:38] Peng_, AFAIK It shouldn't since it is stateless [13:39] I guess I should check and find out. [13:39] * Peng_ kicks bug 348308. [13:39] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 [13:40] Peng_: some, nothing major as a client [13:40] as a server it will discard branch objets etc too [13:40] lifeless: ok [13:45] Hello! serve-branches's VSZ is 560 MB branching bzr.dev. [13:46] "bzr branch" bombed out, and serve-branches's VSZ went down to 400 MB. [13:47] Mental note: smart-server-2/loggerhead/history.py:63: DeprecationWarning: bzrlib.progress.ProgressBarStack was deprecated in version 1.12. klass=bzrlib.progress.DummyProgress) [13:47] Peng_: file a bug [13:50] lifeless: About bzr branch or the progress bar thing? [13:51] lifeless, moin [13:51] Peng_: both [13:51] jelmer: gnight ;) [13:51] lifeless: subunit is in sid now, in case you're interested in having it synced to ubuntu [13:51] jelmer: I am [13:51] jelmer: it should automatically while karmic is open [13:51] lifeless, ah, don't mind me then :-) [13:52] jelmer: are there any remaining packaging bugs for it ? [13:52] lifeless, All the ones I came across (except for manpages) are fixed in the debian packging branch [13:52] have you a branch for upstream for manpages? [13:53] lifeless: I haven't bothered to write manpages yet [13:53] jelmer: oh right ;) [13:53] I thought you had from that comment [14:37] My "bzr branch" error was bug 372881. [14:37] Launchpad bug 372881 in bzr "bzr cannot branch from rocketfuel" [Critical,Confirmed] https://launchpad.net/bugs/372881 [14:37] fwiw [14:49] can I setup a repository to be autochecked out when I commit over it ? [14:49] james_w, ping [14:55] jelmer, hi [14:55] beuno, moin [14:56] visik7, not sure I understand what you mean [14:56] jelmer, where do I get a branch to test work on the UI for: https://code.edge.launchpad.net/~jelmer/loggerhead/foreign/+merge/6952 [14:56] beuno, if you have bzr-svn you can for example use svn://svn.gnome.org/svn/gnome-specimen/trunk [14:57] I'll install it [15:04] I have a shared repository and some branches within this shared repository. Is there any way to compare these branches? bzr (q)diff works within a working tree but not between branches. [15:05] jelmer: when I commit over a remote branch I would that the remote branch run a checkout on a local directory on the remote machine [15:05] visik7, I think there is a plugin for something like that, but it might only support push [15:06] called ? [15:06] Jemsquash, bzr diff -rbranch:../path/to/other/branch [15:06] visik7, push-and-update or something like that [15:08] thanks jelmer I'm being a numb nut. Having looked at the docs again I assume --old and --new will do the same?!? [15:08] Jemsquash, not sure, I've never used them [15:15] hmm I've tried the --old and --new and it only seems to work at the top level folder. I can't see any reference to -rbranch:... within the diff documentation. Where would I find reference to this in the docs? [15:23] I've done a search for rbranch on bazaar-vcs.org and not found any references. What's the best way to add documentation for this? Should I raise a bug report against the documentation? Can I do a checkout of the docs & add it myself? [15:33] Jemsquash, look for the "branch" revision specifier [15:34] "bzr help revisionspec" [15:40] vila: around? [15:41] bialix: yup [15:41] vila: bonjour [15:41] bialix: hello :) [15:41] did you help to Gary at the sprint with loggraphprovider refactoring? [15:42] Thanks Jelmer I see where I went wrong with the documentation now, both online & command line help. [15:43] Gary has changed internal structure of data about branches to improve test coverage, but this is introduce several regressions as well [15:43] Gary offline, so I've thought you could be aware of this [15:44] bialix: sorry, no, we talk about tests but we didn't pair so I don't know what he changed :-/ [15:44] how can I assign a working tree to a branch ? [15:44] jelmer: Why is the bencode revision serializer preferred over RIO? [15:45] I got bzr update [15:45] bzr: ERROR: No WorkingTree exists for... [15:45] Peng_, better apparent performance and can handle funny characters in e.g. property names [15:46] jelmer: Okay, cool. :) [15:48] jelmer, ping [15:48] jelmer, Can you take a look at http://launchpadlibrarian.net/27405730/live-helper-trunk-log.txt ? [15:50] cody-somerville, That's an outdated version of bzr-git [15:50] cody-somerville, known bug, fixed upstream [15:50] can I checkout in a different place instead of . ? [15:51] visik7, create a working tree you mean? [15:51] yes [15:52] visik7, I think you mean a lightweight checkout? [15:52] yes [15:52] but I dunno why it doesn't work [15:54] jelmer: http://dpaste.com/50548/ [15:55] visik7, does /var/www/vhosts/catellani.net/httpdocs/ contain a branch? [15:55] no [15:56] visik7, then I don't see how that command should work [15:56] I don't understand [15:57] I want to checkout the working tree in a different location than . [15:58] visik7: where is the branch you want to checkout? [15:59] webdav [15:59] bzr checkout --lightweight webdav where_you_want_the_working_tree [15:59] --files-from is something different [16:00] Actually, I have no idea what --files-from is for, but I am sure it's not for what you are trying to use it. [16:00] ok I think I got it [16:01] bzr checkout --lightweight . /destination [16:01] that can work too, if the current directory is a branch (it contains a .bzr/branch) [16:01] current dir is the repository [16:02] bzr cannot checkout a repository [16:02] it can only checkout branches [16:02] branches can be stored in a common repository [16:02] Hope that makes sense. [16:02] yes I mix repository and branches [16:02] sorry [16:03] Np, the hg and git folks are quite mixed up about those concepts, which makes it a bit harder for us to explain the distinction. [16:04] yea yea I know the difference the fact is that I usally doesn't use a bzr repository so I mix the 2 names [16:06] jam: I'd like to chat one day about diff header encoding [16:08] oh man, my last sentence was a complete mess - maybe I should think about what I'm typing [16:08] :P [16:11] i [16:11] * fullermd stabbies his mouse. [16:45] is there mac os x experts? [17:00] hi bialix [17:00] Sorry about the delay [17:00] hi jam [17:00] np [17:00] (I've had some experience with mac os x, but I wouldn't claim to be a "expert" ) [17:00] but I have to go very soon [17:00] sure [17:00] q about mac os [17:00] bialix: so in my initial impression, I would say that "bzr diff" should output strings in terminal_encoding [17:01] and "bzr diff > file.txt" should output them in user_encoding [17:01] do you know is X mandatory to use PyQt/Qt on Mac? [17:01] bialix: Qt has a native port on Mac [17:01] unlike gtk [17:02] hmmm [17:02] which has an 'in progress' direct port, but the standard install uses X [17:02] people still asking in lp answers of qbzr about installing qbzr on mac [17:02] btw, I'm releasing 0.10 today [17:03] jam: I know you already build windows installers; I hope you will package 0.10 to 1.15.1 [17:05] jam: about diff: what the best way to deal with "undecodable" filenames then (characters out of current codepage)? [17:05] bialix: for 'diff' I would just use .encode(..., 'replace') [17:05] which replaces 'illegal' characters with ? [17:06] yep, I agree [17:06] I'm just thinking about keep them in utf-8 maybe for === line [17:06] I would also like to see a command line arg "bzr diff --encoding=XXX" [17:06] just --encoding could be confusing [17:06] maybe [17:06] I believe a line like '===' is strictly for our purpose, so we can do what we want [17:06] the +++ and --- will be interpreted by patch [17:07] which is a bit trickier [17:07] yes [17:07] but I don't really think we want to do multiple forms if we can get away with it [17:07] this is why I think sometimes user should control encoding [17:09] btw, I have one more use case for this [17:09] bzr diff > out.diff; bzr patch out.diff -> failed for non-ascii [17:09] (also because we can't tell the difference between "bzr diff >out.diff" and "bzr diff | less") [17:10] bialix: that could be the 'patch' reader's fault. I really don't know the details. [17:10] jam: indeed [17:10] certainly I think it would expect to read the patch in user-encoding if it had to pick something. [17:10] that's why you should start your OWN pager [17:10] (when stdout isatty [17:10] ) [17:10] I believe `bzr patch` invoke patch utility under he hood [17:10] bialix: possibly, but I know we have patch parsing capability inside bzrlib [17:11] we use it to ensure that the patch preview from a merge diff ~ matches the actual content requested [17:11] jam: oh, neat! [17:11] I didn't know that thing was secure [17:11] well, bzr patch is from bzrtools [17:11] bialix: if it is bzrtools, it almost definitely invokes 'patch.exe' [17:12] jam: I doubt it [17:12] SamB: well, it is a bit loose, because email clients like to do bad things to text [17:12] I don't think I have a patch.exe [17:12] *I* have [17:12] I bet it invokes =patch [17:12] (that's a zshism ;-) [17:12] :-) [17:12] : [17:12] :) [17:12] anyway, there is certainly bzrtools/patch.py which has a "run_patch()" function [17:13] it means "patch as found along PATH" [17:13] right now I get: /usr/bin/patch [17:14] bialix: so... I have the feeling that this is also heavily dependent on what version of 'patch.exe' you have, and what it considers as the 8-bit string => Unicode mapping [17:14] some of you might /bin/patch.exe or something, dunno [17:15] jam: maybe [17:15] * SamB wonders why bzr diff was so slow to fail in his home directory from a cold start ... [17:16] SamB: If I was to guess, it would be the time to import all the python code we need to run [17:16] which is known to be extra bad from cold start [17:16] since python likes to stat every possible permutation for a given file [17:16] jam: I have to run; I hope we can continue later [17:16] (everywhere on sys.path, + foomodule.so, foo.so, foo.pyc, foo.py, etc.) [17:16] bialix: suer [17:16] sure [17:17] * bialix -> run [17:18] jam: oh [17:18] you seriously think it's just statting? [17:19] * SamB wonders why statting all that would be slow anyway ... [17:19] doesn't Linux cache the directory ? [17:20] maybe they should introduce a multistat call };-> [17:29] SamB: it also depends how long 'sys.path' is, etc. [17:29] I won't guarantee that is "all" it is doing. [17:29] But that is somewhat of what we've seen for "cold cache" performance. [17:29] just 'time python -c ""' is pretty slow in cold-cache situations [17:37] might be interesting to oprofile that [17:37] with kernel symbols [18:50] OH NOES! CANUCKIANS! [18:50] lol... [18:50] you've been reading my journal, Mr Burns [18:50] Exclusivement chez Bell. [18:53] mneptok, OY! I resemble that remark! [18:54] emmajane: go back to playing hockey and pretending you have a democracy. >:P [18:54] heh [18:54] * mneptok hugs his former country-mates [18:54] mneptok, it's not a democracy, it's a constitutional monarchy! sheesh! [18:54] mneptok, why'd you ever leave! [18:54] and... whatever.. it works! [18:54] FurnaceBoy: -40. 'nuff said. [18:54] mneptok, wuss [18:55] (oh, and the fact that there were no longer valid .ca work permits in our home) [18:55] mneptok, come on, it rarely gets below -30, at least here. (TO) [18:55] ah, that's more like it. [18:55] i was in .QC [18:55] ah lovely! [18:55] it gets to -30, but with the Francochill, it feels like -40 [18:57] well if you didn't feel comfortable... [18:57] you should have come here. beautiful day today. [18:57] perfect. [18:57] all the pluses of being in Canada, but not being in QC. (Though I have nothing against QC or anything French) [18:57] it's 73F here and *dry* (like every day) [18:57] yeah... but... [18:57] * FurnaceBoy drops it. [18:57] ok [18:57] so I can't push to my private branch on LP. [18:57] says diverged [18:58] but nothign I do (pull --overwrite, merge, bleh) does anything to help [18:58] * mneptok summons poolie, jml, abentley, and the other Usual Bazaar Suspects [18:59] * FurnaceBoy bets it's something simple. [18:59] * FurnaceBoy is bzr n00b [18:59] but I have succeeded before. [18:59] FurnaceBoy: Have you committed after the merge? [18:59] i actually committed before, then did a pull --overwrite, then committed again ... all in my frenzy to succeed [19:00] does that make sense? [19:00] FurnaceBoy: You say merge didn't work. Did you commit after the merge? [19:00] no, before. [19:00] merge did nothing, that's all. [19:00] FurnaceBoy: After you merge, you must commit. [19:00] says Nothing to do, in fact. [19:00] hm ok. [19:00] so i should uncommit anything I did. [19:00] then merge. then commit. [19:00] FurnaceBoy: No. [19:01] Just merge and commit is enough. [19:01] FurnaceBoy: Try typing "bzr missing :push" in your local copy. [19:02] ok. I'll turn the machine on again and retry all this. will be a little while [19:02] thx [19:17] hey, anyone want to summarize the current status/support for nested trees? [19:17] abentley: ^- maybe? [19:18] elmo: The status will be much clearer in a few hours. [19:19] Hey. I'm doing an initial push over bzr+ssh of a moderately small project, and it looks like it's stalling at the very end. [19:19] bzr 1.15 on both ends [19:20] Is that a known issue or what? [19:26] looks like there's something stalling badly on the ssh level [19:26] i.e. ctrl-C takes ages to drop into the debugger [19:27] while doing "self._write_to.write(bytes)", where self is SmartSSHClientMedium(connected=True, username=None, host='intuition', port=None) and len(bytes) == 72707. [19:28] There's no reason that sending 72k should take any time at all. Is there any known trick to deal with ssh connections that get bogged down? [20:00] hello, I've been wondering, how do I config the max length of user name for bzr blame? [20:01] the default max length seems to be 7 [20:20] maybe the "bzr gannotate" command in the bzr-gtk plugin will make you happier. [20:20] tc-rucho: ^ [20:25] I'm gonna check that out === beuno_ is now known as beuno [21:08] I've been messing with bzr for a while now and would like to know if bzr is capable of tracking the file where a content came from as well as the commit where that content was originally introduced in the repository [21:09] tc-rucho: it's not entirely clear to me what you mean with that. Bazaar tracks file renames. [21:09] LarstiQ: do you have hg arround? [21:09] I'll show you by example what I mean [21:10] tc-rucho: sure [21:11] tc-rucho: you can pastebin desired output of hg [21:12] bialix: good idea, I'll do that, LarstiQ, hang on, will format everything nicely [21:12] aww, I was hoping for an interactive tutorial :) [21:12] LarstiQ: if you prefer it that way.. I'll go on [21:12] tc-rucho: whatever works for you === beuno_ is now known as beuno [21:16] bah [21:18] he'll come back [21:19] terminator? [21:19] bialix: has been doing so for a while now, why stop? ;) [21:20] :-) [21:22] jam: ping [21:22] jam: I'm heading afk for about 30-40 minutes, but I'd like to talk to you about stacked bbc branches later [21:23] ok my weechat crashed miserably, I'm back [21:23] tc-rucho: wb [21:23] LarstiQ: http://dpaste.com/50702/ [21:24] LarstiQ: see how it tells me what file did that content come from [21:26] I suspect this is because hg support file copies and therefore hg mv == hg copy+hg remove, while in bzr mv is atomic operation [21:26] and bzr does not support file copies yet [21:26] elmo: current status is that we haven't reached agreement yet on how it should be implemented and I'll be taking a couple weeks off from working on it. [21:27] abentley: ok, thanks for the update [21:27] tc-rucho: what do the 0 and 1 signify? [21:28] LarstiQ: they are the revision short alias (there's also the hash) [21:28] tc-rucho: doh, 0 based revnos, right [21:28] and tc <- me [21:28] ;) [21:30] * LarstiQ nods [21:30] tc-rucho: locally it was 'larstiq', so I figured ;) [21:30] tc-rucho: in bzr I'd do, bzr mv file1.txt final.txt, bzr ci, bzr log -v final.txt [21:31] tc-rucho: IIUC git will track content even better, and should show you in annotate that second half of the file originated from file2.txt, not from final.txt [21:31] LarstiQ: and it only tells you the revision and the commiter, nothing more [21:31] right, git does it awesomely, but it's not an option here... multiplatform project needs multiplatform repo [21:31] tc-rucho: bzr annotate doesn't show the filename information, but the data is there because bzr explicitly tracks renames, so log -v will tell you [21:32] tc-rucho: will you need to work with non-ascii filenames? [21:32] bialix: I hope not [21:32] you're lucky [21:33] tc-rucho: (optionally) displaying the filename might be nice, but I think space is already constrained [21:33] because hg has some "problems" there [21:33] tc-rucho: with qannotate and gannotate, on highlighting a line you'll also see which files the diff touched [21:34] tc-rucho: is that sufficient for you? [21:34] LarstiQ: need to try that out [21:34] and figure out where do I get it from [21:37] anyone have some ideas on how to effectively branch from a machine in a private network that you can't reach? [21:37] tc-rucho: what's use case for this info? [21:38] bialix: keeping an intuitive tracking of code origins and where some file regarding that content was renamed [21:38] bialix: maybe bzr can just do that too, but I'm not familiar with it yet [21:39] sevenseeker: depending on how strict you mean can't reach, that would by definition be impossibble [21:39] sevenseeker: just copy the directory somewhere accessible, i guess [21:39] tc-rucho: bzr mostly tracks files, not its content [21:39] maybe I'm too used o bzr way, but I can't imagine why I need to know how that file was named year ago [21:40] it's still the same file, the name might just be different [21:41] yep [21:41] tc-rucho: I think bzr can provide you with the information you want, but it does things differently than hg [21:41] you can even swap names of 2 files, and bzr won't be confused [21:42] bialix: that's nice [21:43] * bialix agrees with LarstiQ: bzr does things a bit differently; but file copies support will be great [21:44] bialix: I like how hg let's me know what file, name, and commit, a certain piece of code of a current file was introduced [21:45] jelmer: does you have a chance to discuss file-id aliases and file copies support at last sprint? [21:45] I haven't found my way to do that in bzr yet [21:45] tc-rucho: I understand [21:45] bialix, no, we mostly looked at shorter-term things [21:45] this info looks nice [21:45] ah, forgot to mention, it also keeps track of the original autor of certain content [21:46] bialix, and with lifeless not there it would've been hard to discuss path tokens [21:46] original author? [21:46] tortoisebzr doesn't work on mapped drives? [21:46] Isaiah: I guess it disabled by default for network drives, check config [21:46] Isaiah: i believe you can enable that, but it's disabled by default [21:46] bialix: right, well, bzr does that too, but anyway [21:46] jelmer: I understand [21:47] bialix and sidnei, Ah ok that make sense [21:47] Let me check the config [21:48] Ah, why didn't I see that before! Thanks again! [21:49] tc-rucho: I guess it's more or less differences in workflow or preferred style for using vcs [21:49] and this is more fundamental to select vcs than just compare features or speed or whatever [21:50] right [21:50] tc-rucho: a two step way you would do that with bzr cli would be `bzr annotate final.txt; bzr log -p -r 2` [21:50] and hg clear winner here, because it require 1 step only. heh [21:51] or whichever revision you're interested in knowing which file it was [21:51] tc-rucho: or even `bzr st -r 1 final.txt` [21:51] bialix: right [21:52] * bialix will file a feature request for qannotate [22:07] Hmm [22:28] I use key entry via ssh for a server, can I use that key with bzr+ssh access? [22:28] yes. === ja1 is now known as jam [22:29] any of you use emacs dvc? [22:29] i'm trying to figure out how to pass arguments to 'bzr diff' in it [22:29] can I use '-i ' like with ssh? [22:30] jam: ping [22:31] hi thumper [22:31] jam: can I skype you about stacking? [22:32] sure === sabdfl1 is now known as sabdfl [22:51] hey folks [22:51] everyone make it home safely? [22:51] sabdfl: I did :) [22:54] jam: bug 382795 [22:54] Launchpad bug 382795 in launchpad-code "mirror-branch using too much memory" [Critical,New] https://launchpad.net/bugs/382795 [22:54] hi sabdfl [22:56] hi thumper, jam [22:56] glad at least you two made it :-) [22:59] * jelmer waves [23:02] Hello [23:04] I have two bzr branches: 'upstream' and 'feature'. feature is branched from 'upstream' and has 3 additional revisions. I want to pull the last two revisions from 'feature' to upstream'. Any pointer on how to do that? [23:05] being lazy and not wanting to figure out new commands, i'd make a new branch from feature, 'bzr uncommit', then merge it to trunk. [23:05] dorins: bzr merge -r ? [23:05] dorins: i'm a bzr newbie myself, that's my best guess ;p [23:06] dorins: bzr help merge and bzr help revisionspec [23:11] dash: but uncommit will remove the latest revision [23:11] dash: and dorins wants the last two revisions [23:11] moldy: I was trying to do this with bzr pull. If I use merge, wouldn't I loose the history from 'feature'? I mean the revisions from 'feature' would be combined into a single revision in 'upstrem'. [23:11] dorins: You should cherrypick merge "-r -2..-1" [23:11] davidstrauss: only from the current branch [23:11] that's why i said make a new one first :) [23:12] dash: the revision I'm trying to skip is not the last revision [23:12] dorins: merge will not lose history [23:12] dorins: i don't think you lose history, but don't take my word for it -- if in doubt, just try it [23:12] dorins: ah. [23:13] davidstrauss: ok, I'll try merge. [23:13] Thanks guys. [23:14] dorins: merge will give you a merge revision on upstream that has two subrevisions representing the content of the merge [23:15] davidstrauss: interesting. what happens with the subrevissions if I then push 'upstream' to a svn repository? [23:16] dorins: I'm not sure about that, but bzr generally has pretty non-lossy integration with svn [23:29] dorins: they remain in your local repository [23:29] if you independently branch from svn, they become "ghost revisions" [23:30] that is, revisions that are referenced from revision in the repository, but that are not themselves in the repository [23:31] you can then use "bzr fetch-ghosts" to fill them in if you have subsequent access to a repository that contains them [23:32] (hopefully jelmer will not correct me, these are mostly informed guesses) [23:32] ddaa: not sure I really get what "ghost revisions" are. Do you mean svn doesn't treat them as individual revisions? [23:33] I mean, if they are bzr commits, then they are not in the svn repository [23:34] Generally, svn does not know much about merges. [23:35] bzr-svn can record the revision id of the latest merged revision [23:35] in the svn metadata of the merge commit [23:36] ddaa: ok [23:36] Is there other way to cherypick revisions besides merge? [23:36] bzr does not track cherrypicks for you, only full merges [23:36] so cherrypick with merge is essentially the same as cherrypick with diff+patch [23:37] in other words, once you are doing cherrypicking, you can use whatever tool you like (partial merge, shelve, kdiff3), it makes no difference [23:38] But, if at all possible, you should strive to do full merges only. That will make you life, much, much easier. === Mez_ is now known as Mez [23:39] * ddaa -> bed [23:39] I understand. My problem is that after cherypicking revisions with merge, and then pushing to svn, svn doesn't know about the individual revisions that I cherypicked [23:40] so people using regular svn clients don't see the individual revisions that I pushed to svn, instead they see a single merge revision. === Kissaki is now known as Kissaki^0ff [23:59] moin