=== jml is now known as jml-laptop === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === jml [n=jml@li2-200.members.linode.com] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] === jamesh_ [n=james@222-155-39-225.jetstream.xtra.co.nz] has joined #bzr === jml [n=jml@li2-200.members.linode.com] has joined #bzr === mvo [n=egon@p54A67CC8.dip.t-dialin.net] has joined #bzr === jml-laptop [n=jml@222-155-39-225.jetstream.xtra.co.nz] has joined #bzr === jml_ [n=jml@222-155-39-225.jetstream.xtra.co.nz] has joined #bzr === n2diy_ [n=darryl@wlk-barre-208-103-147-251.dynamic-dialup.coretel.net] has joined #bzr === jml_ [n=jml@222-155-39-225.jetstream.xtra.co.nz] has joined #bzr === thumper_laptop [n=tim@222-155-39-225.jetstream.xtra.co.nz] has joined #bzr === thumper_laptop is now known as thumper === mvo [n=egon@p54A67CC8.dip.t-dialin.net] has joined #bzr === thumper_laptop [n=tim@canonical/launchpad/thumper] has joined #bzr === jml__ [n=jml@222-155-55-67.jetstream.xtra.co.nz] has joined #bzr === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === thumper_dodgy_co [n=tim@222.153.133.138] has joined #bzr === thumper_dodgy_co is now known as thumper === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr === jamesh__ is now known as jamesh [01:16] abentley: hi. I would like to still see the branch nickname from the bundle, in BB. is that possible/easy? [01:17] lifeless: I think so. [01:17] This would have to be the head revision branch nick. [01:20] hmm maybe it wasn't the nick. There was a field in the bundle header I used to read when you showed the bundle === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr [01:36] morning === tetron [i=tetron@c-24-91-136-46.hsd1.ma.comcast.net] has joined #bzr [01:41] quick Q, is there an easy way in bzr to have it embed the current repository revision to a file? [01:41] i.e. so an "about" dialog has the current build rev [01:41] Not automatically, via keyword expansion. [01:42] You can do it manually via sed'ery. Depending on language, you can use the version-info command to generate a source file containing it. [01:48] fullermd: great, thanks [01:50] Um ... does bzr support any type of keyword expansion (ala CVS)? [01:50] Nyet. [01:51] Ok ... is that on the roadmap to 1.0 land? [01:51] Don't think so... that path is pretty full of performance and suchlike. It's post-1.0. [01:51] Thanks. [01:52] Or what is thanks in Russian? [01:52] Urg. Now you're straining my knowledge of the language :p [01:52] Spasibo? === poolfool [n=poolfool@techsat21.itnes.com] has left #bzr [] === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === i386 [n=jdumay@202.47.1.18] has joined #bzr [03:01] lifeless: perhaps you're thinking of the branch's public location? that is already shown. === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === orospakr_ [n=orospakr@bas4-ottawa23-1177650137.dsl.bell.ca] has joined #bzr === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has left #bzr [] [03:31] abentley: could be [03:31] abentley: hey, got time to chat about merge base? [03:33] I'm not feeling well. === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr [03:41] abentley: oh, thats a shame. Get well soon. === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [03:41] abentley: I feel that we have a regression on merge base selection, and I'd be happy to fix it if we can chat about it at some point. === pete__c [n=pete@015-850-358.area5.spcsdns.net] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [04:03] spiv, hi [04:03] poolie: Hello [04:06] lifeless: have you looked at my reconcile patch from Friday? [04:08] spiv: no I haven't, thanks for reminding me [04:08] I will be pairing with poolie much of today === poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has joined #bzr [04:10] hi poolfool, welcome back :) [04:10] spiv, i was thinking about the default port number thing [04:10] vila: hola [04:10] Thanks ... How is life? [04:11] vila: what is transportstats? [04:11] poolfool: good :) [04:12] poolie: Hey, I sent you an email earlier today (chaffinMichael@gmail) about the redhat SPEC file ... hope it helps. [04:13] poolie: did you come to any conclusions? === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [04:45] I have a question for you guys, I have some use cases, and am not sure if bzr would work. [04:46] I have binary files 100meg-1gb [04:46] food time [04:47] but yes, bzr will work, ifyou have enough ram [04:47] lifeless: happy eating [04:47] bigdog, I use bzr to keep track of big files, one thing to keep in mind, bzr needs to put everything in memory [04:47] we're starting to address teh amount of ram needed. [04:47] so 1gb file means at least 2gb available :D [04:47] ok, I did not realize the files needed to be in memory, just the history info. [04:47] lifeless, my gfx guys will be happy to hear they can start wasting space again on 1gb files :p [04:48] beuno: these are 3d modeling files [04:48] bigdog, right, I get my guys to zip 'em up [04:48] split them if needed [04:48] not convenient, but works [05:01] guys: thanks for the info [05:03] bigdog, :D === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr [05:28] bigdog: np [05:45] spiv: thanks for the trivia [05:46] spiv: My pointy haired side wonders if it was really worth looking at the python source to find out though ;) [05:50] Wha? Of course it is. It's like spending $200 to win a $10 bet; you gotta keep your priorities straight. === bialix [i=chatzill@77.109.20.212] has joined #bzr [06:00] fullermd: I'm impressed [06:00] Hmm? [06:01] Spasibo is indeed thanks in russian [06:02] Oh, good. My memory still occasionally works :) === bialix impressed by talents of fullermd [06:04] mark used "spasibo" the other day and i was wondering what it meant [06:04] Oh, don't be _too_ impressed. I have a Russian vocabulary of maybe a half dozen words, and I'm useless with the alphabet :p [06:04] mark sabdfl? [06:04] he was in Moscow [06:05] yes [06:05] and Zvyozdny Gorodok === bialix knows a guy who meets Mark [06:06] I know only moderately more German, have forgotten much of the French I knew (which was only ever good enough to pidgin-talk my way about at its peak), can count to 6 in Korean and 10 in Spanish... [06:06] yes, star town [06:06] Luckily, I'm American, so nobody expects me to handle anything but English anyway ;> [06:07] that's why I'm impressed (a bit) === ED_bomeu [n=edoboemi@201009119139.user.veloxzone.com.br] has joined #bzr [06:07] fullermd: Americans don't speak English though ;) [06:08] lifeless: I speak the King's English. It was good enough for Elvis, it's good enough for me! === ED_bomeu [n=edoboemi@201009119139.user.veloxzone.com.br] has left #bzr [] [06:12] fullermd: do you have Blue Suede Shoes ? [06:13] They're out in my pink Cadillac. [06:13] then I guess you're good enough for the language [06:14] :) [06:16] I'm glad you think so. Otherwise, I'd'a had to don a gold lame suit and start hopping around the channel. [06:16] And NOBODY wants that... [06:16] hmmm [06:21] New bug: #150820 in bzr "hashcache is invalidated when a file's containing directory is renamed" [Wishlist,Confirmed] https://launchpad.net/bugs/150820 [06:23] ciaoish, going off net for battery === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr [06:42] lifeless: we should do beer sometime === n2diy__ [n=darryl@69.72.85.113] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [07:18] i386: definately [07:19] lifeless: a transport decorator as a plugin that will be published RSN [07:20] I wanted to play a bit with some ideas in a sandbox [07:20] vila: cool; have you seen the trace+ decorator ? [07:21] yup, give me a good laugh :) Looks like we were partly on the same track [07:21] heh [07:21] the intents are a bit different though, transportstats collect every transport method call, the analysis being done later [07:22] hmm [07:22] well nearly every [07:22] like get_transport() ? [07:22] no [07:22] like has, get, get_bytes, put_bytes, etc [07:23] so every Transport method call :) [07:23] with some exceptions like put_non_atomic_file that are written in terms of other methods [07:23] I'd like to flesh trace+ out [07:23] hmm, I don't think they should be exceptions, because a given transport may choose to implement it natively [07:24] the big part was to serialize without being to much a resource hog === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr [07:24] honestly, there are some problems, so far I aimed at something simple so that I can display bytes read bytes written latency etc [07:25] sure [07:25] sounds nice [07:26] and even for that a simple decorator may not be enough, readv and open_write_stream may need specific implementations to measure latency more correctly or real bytes read too [07:27] but I think the serialization part is mostly good so far, I have to profile a bit to see if a C implementation is needed, but the API is quite cool to use :) [07:29] let say I want to add a new method 'get_half_file(relpath, start, middle)' all I have to do is add: 'register_stat('Transport.get_half_file', TransportGetHalfFile, "%(relpath)us %(start)L %(middle)L") [07:30] and the serialization is taken care of, an TransportGetHalfFile object will be created at deserialization time with attributes (base, relpath, start, middle) [07:30] anyway I shouldn't talk that much before coffee, bbl :) [07:34] lol [07:36] time to complete the gutsy upgrade - bbl [07:37] may the repo be with you [07:37] are you running on the real hardware yet ? [07:37] I am on my server and it upgraded ok last night [07:37] still running on Parallels on my MacBook [07:38] I'll try on the raw hardware in the next week or two hopefully [07:39] for a frozen distro the churn rate is humungous [07:41] and sadly, my patch to the help explaining how to use bzr got dropped [07:42] sigh === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [07:45] igc: :( === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [08:21] New bug: #150834 in bzr-pqm "Make STARTTLS and AUTH work better" [Undecided,New] https://launchpad.net/bugs/150834 [08:21] igc, which patch? [08:42] lifeless: back now? [08:43] yes [08:43] meetings over [08:44] in a bit of searching i cannot find a dirstate bug that is fixed by this [08:44] ok [08:45] which i am a bit surprised by [08:45] I would assume it was only erroroneous on the cache side then === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:46] so now i'm trying to decide whether to [08:46] 0- just put it up to merge [08:47] 1- run under kcachegrind [08:47] 2- think harder about what kind of failure that could cause [08:47] I don't think 1 will help [08:47] i have confirmed that it's not rereading them [08:47] so, yeah, it seems redundant [08:48] I think its passing all tests [08:48] so this is fine in terms of our quality metric [08:48] it would have been nice to have closed off additional bugs [08:48] ok [08:48] it would be nice if you do think of a 'X should break under the old code' to come back to it [08:48] but I think we're at diminishing terms [08:49] *returns* [08:49] agree - just one thing - can you look at _cmp_path_by_dirblock_py and confirm for me that [08:49] the docstring is backwards [08:49] wrt negative vs positive [08:52] do you mean cmp_by_dirs ? [08:52] both of them [08:53] they all have similar docstrings and i think they're all wrong [08:53] well [08:53] only one is exposed [08:54] >>> import bzrlib.dirstate [08:54] >>> bzrlib.dirstate.cmp_by_dirs [08:54] [08:54] >>> bzrlib.dirstate.cmp_by_dirs('foo', 'bar') [08:54] 1 [08:54] >>> bzrlib.dirstate.cmp_by_dirs('bar', 'foo') [08:54] -1 [08:54] I haven't read the code === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr === bialix [n=chatzill@77.109.16.182] has joined #bzr [09:00] poolie: are you here? [09:01] hi bialix [09:01] hi poolie. when next feature freeze planning? [09:02] i'm leaving it open for a couple more days to try to land pack changes [09:03] i should send mail about that [09:03] I'd like to fix bug 129298 for 0.92 [09:03] Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress] https://launchpad.net/bugs/129298 [09:03] that would be good [09:04] I'm thinking about providing standalone installers for some plugins, like bzrtools [09:04] so this bug is show stopper for me [09:04] I think I'll send merge request in next couple of days [09:10] k [09:11] bialix: maybe there should be just one installer and it should ask you which plugins you want? [09:11] pollie: it's possible, but I'm slightly worried about size of all-in-one installer [09:12] even though now I have radiomodem and moderate quality of internet, I'm still remember dial-up days [09:12] yes, i see [09:12] bzrtools is pretty small though [09:12] right [09:13] QBzr is bigger (+3MB to installer) because it carries Qt libraries [09:13] if bzr-gtk needed to install the gtk libraries that could make it a lot bigger [09:13] exactly [09:13] yeah, that's why I think QBzr is better choice for win32: it's much smaller [09:13] oh, interesting [09:13] my leaning is toward one installer. Can we see what size it would be first before taking another path? [09:14] ok, it's doable [09:14] maybe one big one and one smaller one === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [09:14] I'll do sone experimenting tonight and post result tomorrow [09:14] thanks [09:15] anyway as sane solution, I could provide bare installer (only bzr.exe) and rich installer (with batteries included) [09:15] but I understand that there is already zoo of installers for win32 [09:15] I know it seems a small detail but multiple installers means cross-checking versions match, etc. [09:15] anything we can do to lower the barrier to entry is very valuable I think [09:16] and one installer fits into that camp IMHO === n2diy__ is now known as n2diy [09:16] IMO, rich installer with plugins is the sane answer to hsn_ who 2 days ago complains about bzr is hard to install on windows [09:17] but I'm not planning to include bzr-gtk [09:17] I dislike PyGTK bloat [09:17] sounds like QBzr is shaping up nicely though [09:17] it does [09:17] it's kind of a shame to have the duplication [09:17] well it lacks QOlive, otherwise it's very good [09:18] it's inevitable [09:18] Lukas did very nice work with side-by-side diff [09:18] in Q or G? [09:18] Q [09:19] but I'm using bzr-gtk about a year ago, may be they more similar than different [09:19] now [09:20] my point about Q vs G is: Q more windows-alike than G === bialix think that Q is first letter from "cool" === pbor [n=urk@host102-21-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === mvo [n=egon@p54A67164.dip.t-dialin.net] has joined #bzr === mwhudson_ [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === mwhudson__ [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr [09:46] spiv: hi, what's new with hpss? [09:48] What interesting branches are there, for someone useless who just likes reading changelogs? [09:49] Peng, https://code.launchpad.net/ [09:50] Sure, but there are a lot of them, I don't know what they're all for, and I don't know which ones have been merged into bzr.dev and abandoned. [09:51] what colors means [09:51] ? [09:51] green and blue? === cfbolz [n=cfbolz@p54AB8A60.dip0.t-ipconnect.de] has joined #bzr [09:51] one is 'uses bzr natively' and one is 'imported from cvs or svn' [09:52] Peng, i'm not sure what you're looking for === Peng shrugs. [09:52] Interesting changelogs. === mwhudson__ is now known as mwhudson [09:53] on bazaar, or something else? [09:53] hello mwh_ [09:53] poolie: hi [09:54] mwhudson, Peng's question is something i'd like code to answer more [09:54] 'show me some interesting code' [09:54] or interesting changes [09:56] I guess I'm curious what's going on with Bazaar. [09:56] https://code.edge.launchpad.net/~bzr/bzr/trunk plus http://bundlebuggy.aaronbentley.com/ gives a good picture [09:56] umm, packs? [09:56] http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n http://bundlebuggy.aaronbentley.com/?selected=merged [09:57] What about the hpss stuff? [09:58] ping spiv [09:59] poolie: there's https://code.edge.launchpad.net/+recently-changed-branches === cfbolz [n=cfbolz@p54AB8A60.dip0.t-ipconnect.de] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr [10:21] lifeless: transportstats pushed on launchpad bazaar.launchpad.net/~v-ladeuil/bzr/transportstats [10:25] New bug: #150860 in bzr "Transports should explicitly track whether a port was specified" [Undecided,New] https://launchpad.net/bugs/150860 === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === cfbolz [n=cfbolz@p54AB8A60.dip0.t-ipconnect.de] has joined #bzr === cfbolz_ [n=cfbolz@p54AB8A60.dip0.t-ipconnect.de] has joined #bzr === hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr === cfbolz_ is now known as cfbolz === egx0r [n=gx0r@130.225.73.246] has joined #bzr [11:07] I'm using Emacs 23.0.0.x and the bundled vc isn't all that good with bzr. Are you guys aware of any bzr plugins for Emacs or should I just start making my own? [11:09] DVC [11:11] quicksilver: Thanks! I'll look into it [11:41] $ bzr branch http://leaves.freeshell.org/envbot emerge-trunk [11:41] bzr: ERROR: http://leaves.freeshell.org/envbot/.bzr/checkout/format is redirected to http://myspace.com/redmartian [11:41] hum [11:41] how do I branch it, I can pull from it but not branch from it [11:41] odd [11:41] there is no checkout of it on server as far as I know [11:42] It's normal for there not to be checkouts on the server. [11:42] All that's needed is the ".bzr" directory. [11:42] so why this error? [11:42] and yes the .bzr is there [11:42] ... [11:43] ... [11:43] Well, http://leaves.freeshell.org/envbot/.bzr/checkout/format redirects to http://myspace.com/redmartian. [11:43] Peng, yes I wonder why I get this error when trying to pull another developer's branch [11:43] That would be why you get the error. [11:43] Peng, it seems that server redirect any non-existing file to there [11:43] That's dumb. [11:44] Is that branch using some ancient format or something? [11:44] That file isn't new. [11:44] Oh. [11:44] No .bzr/checkout at all. Which makes sense. === Peng shrugs. [11:44] I don't know why Bazaar cares about that file. [11:45] But redirecting 404s to MySpace is the dumbest thing I've ever heard of. [11:45] [11:45] Peng, I agree === AnMaster is complaining to that developer now === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr [11:55] http://pastebin.ca/730542 [11:55] anyone got any idea about that? [11:57] Peng, maybe you? [11:59] AnMaster: Not sure. Is it a checkout or a branch? [11:59] this is a branch of that repo [11:59] I know I've heard of this, I just don't remember it. [11:59] Augh, Barney. [11:59] Repository checkout (format: dirstate-tags) [11:59] Location: [11:59] repository checkout root: . [11:59] checkout of branch: http://www.vmlinux.org/jocke/bzr/bzrweb/ [11:59] shared repository: /usr/home/envbot/bzrweb [11:59] It's a checkout. [11:59] hm what [11:59] odd [11:59] bzr unbind [12:00] I think there's a bug filed on that locking error, and it might've been fixed. === mvo [n=egon@p54A67164.dip.t-dialin.net] has joined #bzr [12:00] interesting [12:02] is there any plugin or something for cherrypicking, while other version control systems support it, they don't support other features that bzr got (like support for "dumb" static pages only web servers) [12:02] Peng, so I need some combination of mercurial and bzr it seems === luks [n=lukas@wireless-235.fi.muni.cz] has joined #bzr [12:05] I have no idea. :P [12:07] mercurial doesn't have any more support for cherrypicking than bazaar does, does it? [12:08] don't think so. darcs is the king of cherrypicking [12:08] I mean, I don't think mercurial supports cherrypicking mor ethan mercurial [12:08] Mercurial has the transplant extension. [12:08] Not sure how well it does it. [12:09] bzr has the rebase plugin, too :) === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr [12:18] is there anything like git bisect for bzr? === i386_ [n=james@ppp239-169.static.internode.on.net] has joined #bzr [12:22] AnMaster: there is bzr-bisect [12:22] ah, link? [12:24] https://launchpad.net/bzr-bisect [12:24] as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py === jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr [12:29] that's not possible yet as Bazaar does not have per-file properties yet [12:29] although I guess it is possible to set revision properties with that information [12:29] jelmer, hm === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr [12:30] easy handling of back/forward merging between stable and development branch and ability to ignore some changesets from list of changes to merge back to stable branch [12:30] that is what I need [12:31] and tracking what changes have been merged back of course [12:31] jelmer, so what distributed version control systems can handle that? [12:32] you want partial merges? [12:32] as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py [12:33] oki.. darcs is the best at that.. but sucks in many other ways [12:33] but .. it's made to do exactly that [12:33] bzr isn't... it is planned [12:33] yes so I understood, but bzr got several other nice features [12:33] Zindar, any idea when [12:33] it's the one feature I really really want [12:33] post 1.0 sometime I would think [12:33] and when will that be? [12:33] this year? [12:34] AnMaster: Mercurial puts changes in their stable branch then merges them into the development branch. [12:34] 1.0 will be I think.. but.. when the cherrypicks will come.. no idea [12:34] (I mean that's how the Mercurial project handles it.) [12:34] peng: hg, git, bzr all can do it... === mvo_ [n=egon@p54A67164.dip.t-dialin.net] has joined #bzr [12:34] Peng, I need to be able to both handle forwardport and backport [12:34] but the tracking is less then optimal [12:35] and yes I understood that darcs got many other problems and I would prefer to stay with bzr, but I need this feature quite fast [12:41] AnMaster: you CAN handle it in bzr.. but it doesn't track the log, and you'll get the same thing twice when you go back and forward [12:41] so.. less then optimal [12:48] indee [12:48] indeed* [12:48] so I'm looking for a usable solution [12:49] as I can't handle it with maybe 200 changes ignored and 50 ones spread out between them that have been merged back [12:49] because it is not merging forward that is most common, merging back is [12:51] do you ever merge the backported branches (complete branch, not just cherry picking) back to the dev branch? [12:52] probably not but could happen [12:53] I don't see the problem with bzr/hg/git-like cherry picking then [12:53] they may diverge, for example if some bug fix that affects backported branch but not dev branch because dev branch have rewritten that entire module or such [12:54] but then you need a new fix, not the cherry-picked one from the dev branch [12:56] indeed [12:56] luks, but a lot of the time changes can be backported by cherry-picking [12:57] so, bzr merge -rbefore:X..X && bzr commit [12:57] that doesn't keep track of what changes I merged back last I tried [12:58] wait, before: ? [12:58] yep, but my point is that you don't need that [12:58] luks, I do when I need to see if I merged back some change or not, and if I decided to not merge it back [12:58] before: is the left-most parent revision [12:59] AnMaster: well, you see the commit message [12:59] because I can't keep track of something like what 50 revisions out of maybe 200 revisions were merged back in my head [12:59] but you still do the merges manually [12:59] cherry-picking tracking is only useful for automatic merges [01:00] (when you merge the whole branch) [01:00] svnmerge is manual (http://www.orcaware.com/svn/wiki/Svnmerge.py), yet I would call it much more useful than your suggestion [01:00] how is it more useful? [01:01] as in "possible to handle with a lot of changes" === luks still fails to see the problem [01:01] afk [01:01] the cherry picked changes will have different revnos in svn [01:02] so you still can't see which changes were merged [01:03] yes I can, because it is stored in svn properties [01:03] svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch [01:03] read the link I gave [01:03] I know about svnmerge, I [01:03] I've used it a lot [01:03] but then I found out bzr-svn :) [01:05] example: [01:05] svnmerge avail [01:05] 8074,8079-8080,8082-8083,8088-8089,8097-8098,8101-8103,8107,8109-8112,8115-8118,8121-8127,8129-8130 [01:06] svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch <-- so yes I can see what ones can be merged [01:06] $ python ./svnmerge.py integrated [01:06] 132-7508,7510-7516,7519-7525,7527-7536,7538,7553,7557-7560,7573-7576,7580-7586,7601-7603,7605,7607-7613,7615-7620,7622,7624,7626,7628,7632,7634-7664,7667-7669,7671-7675,7677-7692,7694-7714,7717-7722,7726-7727,7729-7732,7734-7741,7744-7752,7755,7762-7766,7770-7794,7796,7798-7806,7809,7814-7819,7821-7828,7832,7838,7852,7877,7879,7952,7982,7995,8003,8005,8009,8019,8023,8029,8031,8035,8037,8040,8042,8044,8066, [01:06] 8069,8071-8072,8075,8077,8084,8086,8090,8092,8099,8113,8119,8131-8132,8134,8136 [01:09] luks, so what do you mean with " so you still can't see which changes were merged" [01:10] I didn't know about 'svnmerge.py integrated' [01:10] there you are then [01:10] but this approach would really not work well in and DVCS [01:11] any [01:11] indeed === NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr [01:12] but really that is an example from inspircd's stable branch. luks could you keep track of that without something like svnmerge avail/integrated? if you could, I'm impressed by your memoru [01:12] memory* [01:13] I prefer to not keep track of things like this myself [01:13] if I have a bug, and I need to backport it, then I backport it [01:13] exactly, so I need bzr to keep track of it for me [01:13] I've never wanted to have cherry-picking on that kind of scale [01:13] maybe I just haven't worked on projects like that [01:13] and forget about it (in my head, not in my VCS) [01:14] in bzr you can have custom per-revision properties [01:14] so theoretically you could write a plugin that remembers which revisions were merges [01:14] luks, no I can't because I don't know python [01:14] the problem is that this info wouldn't be very useful if you have more than one branch [01:15] it works in svn, because you have incremental per-repo revnos [01:15] but I need some way to keep track of cherry picking on this scale and even larger [01:16] or even better you could always associate commits with bug IDs [01:16] and then check for fixed bug IDs, not revisions [01:17] sure but some bugs you discover when coding something else, then you fix it without first opening a bug [01:17] anyway didn't know you could integrate bzr with trac in such a way [01:17] well, not with trac === cfbolz_ [n=cfbolz@p54AB8A60.dip0.t-ipconnect.de] has joined #bzr [01:17] but there is 'bzr commit --fixes' [01:17] luks, and I use trac [01:18] and that doesn't work with ci --fixes afaik? [01:18] + what about reopened bugs [01:18] trac would need to be tweaked to understand this data [01:18] but yeah, it wouldn't work for reopened bugs [01:18] indeed === herzel104 [i=herzel@gateway/tor/x-2f4cb4d178e50c85] has joined #bzr [01:19] luks, but why are you so much against cherry-picking? [01:19] I can't see why [01:19] I'm not against cherry-picking at all [01:21] the problem is that in DAG-based systems it's not trivial to implement true cherry-picking, because it breaks the graph [01:21] still it is a feature I need :) [01:21]