[00:03] <spiv> lifeless: a smarter TCP server could too
[00:03] <spiv> lifeless: I have a TODO comment somewhere about that
[00:06] <lifeless> spiv: just committed pushing to pqm now
[00:07] <rysiek|pl> hi all
[00:07] <rysiek|pl> guys, I must be missing something obvious
[00:07] <rysiek|pl> I have two branches
[00:07] <rysiek|pl> trunk
[00:07] <rysiek|pl> and, branched from trunk at rev4, dev
[00:07] <rysiek|pl> there were two revisions in dev, so dev's at rev6
[00:08] <rysiek|pl> cd trunk
[00:08] <rysiek|pl> bzr merge ../dev
[00:08] <rysiek|pl> got me what was expected in the logs
[00:08] <lifeless> you have to commit after a merge
[00:08] <rysiek|pl> but the files are just as they were in rev4!
[00:08] <rysiek|pl> I did
[00:08] <lifeless> ok
[00:08] <lifeless> did you do a 'bzr revert .' in there by chance?
[00:09] <rysiek|pl> where?
[00:09] <lifeless> in the commands you ran
[00:09] <rysiek|pl> no, I didn't use revert at all in that repo
[00:09] <lifeless> bzr log -v will show you the diffs of what when on
[00:09] <lifeless> I will bet that your merge shows up with no change
[00:10] <rysiek|pl> nope
[00:10] <rysiek|pl> as I have said
[00:10] <lifeless> that is; cd trunk; bzr diff -r -2..-1 -> no change
[00:10] <rysiek|pl> everything's fine and dandy in the logs
[00:10] <rysiek|pl> there is *some* change
[00:10] <rysiek|pl> as if it merged with rev5 not rev6
[00:11] <rysiek|pl> hmm
[00:11] <rysiek|pl> I overlooked that
[00:11] <rysiek|pl> anywhoo, trunk is now at rev5
[00:11] <rysiek|pl> dev is at rev6
[00:11] <rysiek|pl> files at trunk are at what was in dev at rev5
[00:11] <lifeless> what does 'bzr missing ../dev' show
[00:12] <rysiek|pl> http://wklej.to/Fq9L
[00:13] <lifeless> spiv: I can push ok with the [] fix; its off to pqm
[00:13] <lifeless> rysiek|pl: it certainly thinks its fully merged
[00:13] <rysiek|pl> it certainly does
[00:13] <lifeless> rysiek|pl: we can test this:
[00:13] <rysiek|pl> I'll give you both logs
[00:14] <lifeless> please do the following: http://paste.ubuntu.com/120797/
[00:14] <lifeless> (adjust paths as needed)
[00:14] <rysiek|pl> lifeless: dev branch (actually named "rysiek") log: http://wklej.to/0SMp
[00:15] <rysiek|pl> lifeless: and the trunk post merge: http://wklej.to/nsaT
[00:16] <lifeless> rysiek|pl: I don't suppose that you've forgotten to commit in dev ?
[00:16] <rysiek|pl> nay, it was at 6 when I merged, look at the log messages
[00:17] <lifeless> rysiek|pl: *dev* not trunk
[00:17] <rysiek|pl> a sec
[00:17] <lifeless> rysiek|pl: dev has a change to   tracmail/templates/list_index.html
[00:17] <lifeless> in rev 6 and not in rev 5
[00:17] <lifeless> trunk has a change to tracmail/templates/list_index.html in the merge from dev
[00:17] <rysiek|pl> http://paste.ubuntu.com/120800/
[00:17] <lifeless> so rev6 of dev is almost certainly merged just fine
[00:18] <rysiek|pl> hmm
[00:18] <rysiek|pl> I can't be *that* stupid
[00:18] <rysiek|pl> oh, ffs
[00:18] <lifeless> :)
[00:19]  * rysiek|pl bangs his head against a nearby wall... repeatedly
[00:19] <rysiek|pl> at least we broke the bore on this channel
[00:19] <lifeless> lol
[00:21] <rysiek|pl> there are days that it's better not to get outta bed
[00:21] <rysiek|pl> everything is neat and dandy now, of course
[00:22] <lifeless> cool
[00:22] <lifeless> afk for a while
[00:22] <fullermd> Correct: There are occasionally days when it's better TO get out of bed...
[00:22] <rysiek|pl> I think I'll agree to that
[00:22] <rysiek|pl> yeah, definitely
[00:26] <Peng_> Like when you've gotten a new bed and want to move over to it.
[00:30] <fullermd> If you position it right, you can just sorta roll over.
[00:30] <rysiek|pl> tested, works
[00:30] <rysiek|pl> thanks guys, you solved my big problem
[00:31] <rysiek|pl> now... just how do I move the other bed so that the laptop's power cord reaches the wall socket...
[00:44] <spiv> lifeless: great
[00:45] <spiv> lifeless: and thanks!
[00:50] <jml> igc: you da man.
[00:55] <lifeless> jml: 1.12 I think
[00:56] <lifeless> spiv: np, I like things working
[00:56] <lifeless> spiv: if the stream is always fully consumed(and I think it is) it will not have been a data loss issue
[00:56] <jml> lifeless: thanks.
[00:56] <jml> lifeless: if you'd like, you can move the notice and merge the NEWS patch :)
[00:59] <lifeless> ok, stream push is now landed *and* usable :P
[00:59] <lifeless> but not for stacked yet
[01:03] <lifeless> testing streaming push to stacked repos now
[01:07] <rysiek|pl> lifeless: thanks again
[01:07]  * rysiek|pl get's back to bed
[01:07] <rysiek|pl> cu all
[09:20] <cammoblammo> Does anyone have any idea when a more recent bzr might go into Debian unstable?
[12:45] <Goundy> hi
[12:45] <Goundy> ERROR: Selected-file commit of merges is not supported yet
[12:45] <Goundy> What the hell is that ? ^^
[12:45] <Goundy> I've 2 branches at local: main/ and working/ I commit working and then merge it into main/ then I try to commit main (to push it later) it returns this error
[12:46] <luks> do you want to merge the whole working branch or just a few files from the branch?
[12:47] <Goundy> luks the wole working branch but then I want to have different commit message for every file
[12:47] <Goundy> isn't it possible ?
[12:48] <luks> not if you want all the commit to apear as merges
[12:49] <luks> you can merge the whole branch, revert everything except one file and commit that
[12:49] <Goundy> luks i don't really care all I'm interrested in is keeping my commit message
[12:49] <Goundy> ah
[12:49] <luks> and then cherry pick individual files from the working branch
[12:49] <Goundy> luks sounds complicated nevermind am going to commit the whole branch with the same message :/
[12:49] <Goundy> thank you
[12:50] <luks> well
[12:50] <luks> if you don't care about remembering the merge at all, you can just use bzr revert --forger-merges
[12:50] <luks> bzr revert --forget-merges
[12:50] <luks> and then selectively commit
[12:50] <Goundy> Ah
[12:51] <Goundy> luks this point isn't discussed in the documentation of bazaar :/
[12:51] <Goundy> I think a book like svnbook could be very nice for that project :)
[12:51] <luks> in which part of the documenation would you expect to find it?
[12:52] <Goundy> luks well I've read the two documents for learning bazaar
[12:53] <Goundy> luks is there a bzrbook project for the future ?
[12:54] <luks> I don't know about anything that would attempt to be a complete book
[12:54] <Goundy> ah okay.. That'd be nice then :)
[12:54] <Goundy> like the svnbook => everything about svn is there..
[12:54] <luks> a lot of work, I guess :)
[12:54] <Goundy> Indeed
[12:55] <Goundy> but bazaar represents a lot of work also :P
[12:55] <Goundy> and such a book will encourage more and more developers to use this software
[14:21] <weigon> hmm, how can I get the bzr version of the remote bzr server ? (in this case launchpad.net) ?
[15:30] <lucypher> Hi, I can't undestand a thing ... How can I see that bzr ignores changes in a file?
[15:31] <lucypher> I have a file called app/core.php I have pushed this file on the repository, but I want that the future changes I do to this file will be ignored from the revisions.
[15:33] <lucypher> I've added it to .bzrignore but everytime I change the file it is changed upstream too.
[15:34] <Pieter> you can only ignore untracked files
[15:37] <lucypher> so there is no way to ignore changes in a file?
[15:38] <lucypher> If I use bzr remove -keep app/core.php it will be removed from the repo?
[20:13] <cammoblammo> Does anyone have any idea when a more recent bzr will find it's way into Debian unstable?
[20:44] <Stanlin1> helkp
[20:44] <Stanlin1> help
[20:44] <Stanlin1> how to download again the changes from a trunk
[20:52] <asabil> Stanlin1: bzr pull ?
[20:59] <eferraiuolo> Noticed the OS X 10.4 bzr 1.12 binary has been posted... Should I expect the OS X 10.5 one soon?
[21:49] <emgent> hello
[21:50] <lifeless> hi
[21:50] <emgent> seems that there is a block problem with new bzr and old bzr-tree
[21:50] <emgent> emgent@enJoy:~/Scrivania$   bzr branch lp:~emgent/ubuntu-cve-tracker/universe-security-updates
[21:50] <emgent> Format <RepositoryFormatKnit1> for lp-45944144:///~emgent/ubuntu-cve-tracker/universe-security-updates/.bzr is deprecated - please use 'bzr upgrade' to get better performance
[21:50] <emgent> Format <RepositoryFormatKnit1> for bzr+ssh://emgent@bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
[21:50] <emgent> \ [[21:50] <emgent> blocked on downloading branch..
[21:52] <emgent> and if i do bzr upgrade and try bzr update on the same branch faild with error, beacuse dont found dir/.bzr/checkout/
[22:02] <lifeless> emgent: uhm, if you hit ctrl-C it won't have finished the download
[22:03] <lifeless> the upgrade needs to be done on the server - "bzr upgrade lp:~emgent/ubuntu-cve-tracker/universe-security-updates"
[22:08] <emgent> ah kk
[22:08] <emgent> understand. danke.
[23:24] <RainCT> wgrant: so, can I give bzr a revision number when I create a stacked branch? I've just read the docs for it and they don't mention anything like this
[23:25] <wgrant> RainCT: No, you can't.
[23:25] <wgrant> Stacked branches don't let you fully do what you want.
[23:26] <RainCT> So I'd have to  bzr revert -rX; bzr push --overwrite   the original branch?
[23:26] <RainCT> so that all revisions newer than X get into the new branch?
[23:26] <wgrant> I don't quite know.
[23:27] <wgrant> I also don't think that a branch of a branch remains stacked.
[23:27] <RainCT> err... what? :P
[23:28] <wgrant> If I have a stacked branch, I don't think a branch of it will be stacked.
[23:28] <RainCT> oh
[23:30] <lifeless> RainCT: what are you trying to do ?
[23:30] <RainCT> wgrant: right, seems like it doesn't. So stacked branches are only useful for the server (ie, the computer actually hosting them, to reduce space usage)?
[23:31] <RainCT> >> I have a bzr branch which originally included source files for images, which makes it huge (>  100MB), but this was later removed. So, now I'd like to create a new branch with like the 200 last  commits (so that it doesn't include that mess and is faster to fetch the first time, but that 'bzr  diff' and such can still be used being offline in most cases) and having it linked to the original
[23:31] <RainCT>  brnch i)n case it's necessary to look up earlier revisions. How can I do this?
[23:31] <RainCT> lifeless: ^ :)
[23:31] <lifeless> RainCT: so stacked branches can't be used offline
[23:32]  * wgrant suspects history horizons to be necessary here.
[23:33] <lifeless> RainCT: they download less data to get your local tree built and new commits go into the new branch only (until you merge to the original branch or some such).
[23:33] <lifeless> RainCT: stacking will let you download less data, but it won't give you ofline support today
[23:33] <lifeless> we'd like to add that
[23:35] <RainCT> uhm.. Why do I get «Source format does not support stacking, using format: '1.6' Packs 5 (adds stacking support, requires bzr 1.6)» with «bzr branch --stacked <dir>»?
[23:36] <RainCT> «bzr upgrade» says it's already the most recent format, and I have 1.12-1~bazaar1~intrepid1 from your PPA
[23:36] <lifeless> RainCT: because the source branch format isn't one that can stack on others
[23:36] <wgrant> bzr upgrade will only take it to packs-0.92, the default.
[23:36] <lifeless> RainCT: and we try to preserve formats when possible so that people don't have accidental upgrades occuring
[23:37] <RainCT> does the format introducing stacks work with the bzr version from intrepid?
[23:37] <lifeless> RainCT: and 'bzr upgrade' takes you to the default format, which we are conservative about changing, because most folk don't like requiring other users to have the latest-and-greatest tool to access their code
[23:37] <wgrant> RainCT: Yes.
[23:37] <wgrant> But not Hardy.
[23:38] <wgrant> But the bzr PPA is always useful for fixing that.
[23:38] <lifeless>        bzr |    1.6.1-1 |      intrepid | source, amd64, i386
[23:39] <RainCT> okay, so how can I upgrade it?
[23:40] <lifeless> yu don't need to
[23:40] <lifeless> the branch --stacked worked
[23:40] <wgrant> But 'bzr upgrade --1.6', otherwise.
[23:41] <lifeless> it simply told you that it was changing the format of the target
[23:41] <lifeless> so that you won't be surprised if someone with bzr 1.4 can't access the new branch
[23:41] <RainCT> Oh. But it's taking ages to get a stacked branch from LP
[23:41] <lifeless> you just did 'bzr branch --stacked lp:foo somewherelocal' ?
[23:41] <RainCT> bzr branch --stacked lp:freevial
[23:41] <lifeless> yeah
[23:42] <lifeless> there is a bug :(
[23:42] <lifeless> it is downloading each file in the project in a separate roundtrip
[23:42] <RainCT> Oh. And is there a workaround for it?
[23:42] <lifeless> yes, wait.
[23:43] <lifeless> The bug is a flip-flop - we were really fast in 1.6 itself, but we used up too much memory
[23:43] <lifeless> now we use very little memory but are slow
[23:43] <lifeless> the next change to that inner loop should get a reasonable balance
[23:44] <RainCT> memory shouldn't be a problem here, I have 3GB free..
[23:45] <lifeless> yes, but the code doesn't know that
[23:46] <RainCT> heh yeah, I mean for the workaround, in case it uses more memory.. although nevermind that because it's not me who is going to use it anyway :P
[23:46] <lifeless> bzrlib/knit.py line 1338
[23:47] <lifeless> instead of splitting by prefix, just do it in one hit; thats the prior version that ate memory like it was going out of fashion
[23:48] <RainCT> uh.. line 1338 is  "try:"
[23:48] <RainCT> and there's no split around there
[23:49] <lifeless> oh, you don't have bzr.dev :P
[23:49] <RainCT> hehe
[23:49] <lifeless>         if include_delta_closure:
[23:49] <lifeless>             # XXX: get_content_maps performs its own index queries; allow state
[23:49] <lifeless>             # to be passed in.
[23:49] <lifeless>             non_local_keys = needed_from_fallback - absent_keys
[23:49] <lifeless>             prefix_split_keys = self._split_by_prefix(present_keys)
[23:50] <RainCT> so I change the last line to   prefix_split_keys = present_keys   ?
[23:52] <RainCT> *** Bazaar has encountered an internal error.       awesome :D
[23:53] <RainCT> well, don't worry, I'll wait until there's a new version fixing this :)
[23:53] <RainCT> wgrant, lifeless: thanks for your time!ç
[23:55] <lifeless> RainCT: np, sorry that its not good in this area at the moment
[23:58] <RainCT> good night