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