[01:16] <lifeless> abentley: hi. I would like to still see the branch nickname from the bundle, in BB. is that possible/easy?
[01:17] <abentley> lifeless: I think so.
[01:17] <abentley> This would have to be the head revision branch nick.
[01:20] <lifeless> hmm maybe it wasn't the nick. There was a field in the bundle header I used to read when you showed the bundle
[01:36] <igc> morning
[01:41] <tetron> quick Q, is there an easy way in bzr to have it embed the current repository revision to a file?
[01:41] <tetron> i.e. so an "about" dialog has the current build rev
[01:41] <fullermd> Not automatically, via keyword expansion.
[01:42] <fullermd> 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] <tetron> fullermd: great, thanks
[01:50] <poolfool> Um ... does bzr support any type of keyword expansion (ala CVS)?
[01:50] <fullermd> Nyet.
[01:51] <poolfool> Ok ... is that on the roadmap to 1.0 land?
[01:51] <fullermd> Don't think so...   that path is pretty full of performance and suchlike.  It's post-1.0.
[01:51] <poolfool> Thanks.
[01:52] <poolfool> Or what is thanks in Russian?
[01:52] <fullermd> Urg.  Now you're straining my knowledge of the language   :p
[01:52] <fullermd> Spasibo?
[03:01] <abentley> lifeless: perhaps you're thinking of the branch's public location?  that is already shown.
[03:31] <lifeless> abentley: could be
[03:31] <lifeless> abentley: hey, got time to chat about merge base?
[03:33] <abentley> I'm not feeling well.
[03:41] <lifeless> abentley: oh, thats a shame. Get well soon.
[03:41] <lifeless> 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.
[04:03] <poolie> spiv, hi
[04:03] <spiv> poolie: Hello
[04:06] <spiv> lifeless: have you looked at my reconcile patch from Friday?
[04:08] <lifeless> spiv: no I haven't, thanks for reminding me
[04:08] <lifeless> I will be pairing with poolie much of today
[04:10] <lifeless> hi poolfool, welcome back :)
[04:10] <poolie> spiv, i was thinking about the default port number thing
[04:10] <lifeless> vila: hola
[04:10] <poolfool> Thanks ... How is life?
[04:11] <lifeless> vila: what is transportstats?
[04:11] <lifeless> poolfool: good :)
[04:12] <poolfool> poolie: Hey, I sent you an email earlier today (chaffinMichael@gmail) about the redhat SPEC file ... hope it helps.
[04:13] <spiv> poolie: did you come to any conclusions?
[04:45] <bigdog> I have a question for you guys,  I have some use cases, and am not sure if bzr would work.
[04:46] <bigdog> I have binary files 100meg-1gb
[04:46] <lifeless> food time
[04:47] <lifeless> but yes, bzr will work, ifyou have enough ram
[04:47] <bigdog> lifeless: happy eating
[04:47] <beuno> 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] <lifeless> we're starting to address teh amount of ram needed.
[04:47] <beuno> so 1gb file means at least 2gb available  :D
[04:47] <bigdog> ok, I did not realize the files needed to be in memory, just the history info.
[04:47] <beuno> lifeless, my gfx guys will be happy to hear they can start wasting space again on 1gb files  :p
[04:48] <bigdog> beuno: these are 3d modeling files
[04:48] <beuno> bigdog, right, I get my guys to zip 'em up
[04:48] <beuno> split them if needed
[04:48] <beuno> not convenient, but works
[05:01] <bigdog> guys: thanks for the info
[05:03] <beuno> bigdog, :D
[05:28] <lifeless> bigdog: np
[05:45] <lifeless> spiv: thanks for the trivia
[05:46] <lifeless> spiv: My pointy haired side wonders if it was really worth looking at the python source to find out though ;)
[05:50] <fullermd> Wha?  Of course it is.  It's like spending $200 to win a $10 bet; you gotta keep your priorities straight.
[06:00] <bialix> fullermd: I'm impressed
[06:00] <fullermd> Hmm?
[06:01] <bialix> Spasibo is indeed thanks in russian
[06:02] <fullermd> Oh, good.  My memory still occasionally works   :)
[06:04] <poolie> mark used "spasibo" the other day and i was wondering what it meant
[06:04] <fullermd> 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] <bialix> mark sabdfl?
[06:04] <bialix> he was in Moscow
[06:05] <poolie> yes
[06:05] <poolie> and Zvyozdny Gorodok
[06:06] <fullermd> 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] <bialix> yes, star town
[06:06] <fullermd> Luckily, I'm American, so nobody expects me to handle anything but English anyway   ;>
[06:07] <bialix> that's why I'm impressed (a bit)
[06:07] <lifeless> fullermd: Americans don't speak English though ;)
[06:08] <fullermd> lifeless: I speak the King's English.  It was good enough for Elvis, it's good enough for me!
[06:12] <lifeless> fullermd: do you have Blue Suede Shoes ?
[06:13] <fullermd> They're out in my pink Cadillac.
[06:13] <lifeless> then I guess you're good enough for the language
[06:14] <lifeless> :)
[06:16] <fullermd> 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] <fullermd> And NOBODY wants that...
[06:16] <lifeless> hmmm
[06:21] <ubotu> 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] <lifeless> ciaoish, going off net for battery
[06:42] <i386> lifeless: we should do beer sometime
[07:18] <lifeless> i386: definately
[07:19] <vila> lifeless: a transport decorator as a plugin that will be published RSN
[07:20] <vila> I wanted to play a bit with some ideas in a sandbox
[07:20] <lifeless> vila: cool; have you seen the trace+ decorator ?
[07:21] <vila> yup, give me a good laugh :) Looks like we were partly on the same track
[07:21] <lifeless> heh
[07:21] <vila> the intents are a bit different though, transportstats collect every transport method call, the analysis being done later
[07:22] <lifeless> hmm
[07:22] <vila> well nearly every
[07:22] <lifeless> like get_transport() ?
[07:22] <vila> no
[07:22] <vila> like has, get, get_bytes, put_bytes, etc
[07:23] <lifeless> so every Transport method call :)
[07:23] <vila> with some exceptions like put_non_atomic_file that are written in terms of other methods
[07:23] <lifeless> I'd like to flesh trace+ out
[07:23] <lifeless> hmm, I don't think they should be exceptions, because a given transport may choose to implement it natively
[07:24] <vila> the big part was to serialize without being to much a resource hog
[07:24] <vila> 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] <lifeless> sure
[07:25] <lifeless> sounds nice
[07:26] <vila> 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] <vila> 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] <vila> 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] <vila> and the serialization is taken care of, an TransportGetHalfFile object will be created at deserialization time with attributes (base, relpath, start, middle)
[07:30] <vila> anyway I shouldn't talk that much before coffee, bbl :)
[07:34] <lifeless> lol
[07:36] <igc> time to complete the gutsy upgrade - bbl
[07:37] <lifeless> may the repo be with you
[07:37] <lifeless> are you running on the real hardware yet ?
[07:37] <igc> I am on my server and it upgraded ok last night
[07:37] <igc> still running on Parallels on my MacBook
[07:38] <igc> I'll try on the raw hardware in the next week or two hopefully
[07:39] <lifeless> for a frozen distro the churn rate is humungous
[07:41] <igc> and sadly, my patch to the help explaining how to use bzr got dropped
[07:42] <igc> sigh
[07:45] <lifeless> igc: :(
[08:21] <ubotu> New bug: #150834 in bzr-pqm "Make STARTTLS and AUTH work better" [Undecided,New]  https://launchpad.net/bugs/150834
[08:21] <poolie> igc, which patch?
[08:42] <poolie> lifeless: back now?
[08:43] <lifeless> yes
[08:43] <lifeless> meetings over
[08:44] <poolie> in a bit of searching i cannot find a dirstate bug that is fixed by this
[08:44] <lifeless> ok
[08:45] <poolie> which i am a bit surprised by
[08:45] <lifeless> I would assume it was only erroroneous on the cache side then
[08:46] <poolie> so now i'm trying to decide whether to
[08:46] <poolie> 0- just put it up to merge
[08:47] <poolie> 1- run under kcachegrind
[08:47] <poolie> 2- think harder about what kind of failure that could cause
[08:47] <lifeless> I don't think 1 will help
[08:47] <poolie> i have confirmed that it's not rereading them
[08:47] <poolie> so, yeah, it seems redundant
[08:48] <lifeless> I think its passing all tests
[08:48] <lifeless> so this is fine in terms of our quality metric
[08:48] <poolie> it would have been nice to have closed off additional bugs
[08:48] <poolie> ok
[08:48] <lifeless> it would be nice if you do think of a 'X should break under the old code' to come back to it
[08:48] <lifeless> but I think we're at diminishing terms
[08:49] <lifeless> *returns*
[08:49] <poolie> agree - just one thing - can you look at _cmp_path_by_dirblock_py and confirm for me that
[08:49] <poolie> the docstring is backwards
[08:49] <poolie> wrt negative vs positive
[08:52] <lifeless> do you mean cmp_by_dirs ?
[08:52] <poolie> both of them
[08:53] <poolie> they all have similar docstrings and i think they're all wrong
[08:53] <lifeless> well
[08:53] <lifeless> only one is exposed
[08:54] <lifeless> >>> import bzrlib.dirstate
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs
[08:54] <lifeless> <function cmp_by_dirs_py at 0x2b178b89db90>
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs('foo', 'bar')
[08:54] <lifeless> 1
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs('bar', 'foo')
[08:54] <lifeless> -1
[08:54] <lifeless> I haven't read the code
[09:00] <bialix> poolie: are you here?
[09:01] <poolie> hi bialix
[09:01] <bialix> hi poolie. when next feature freeze planning?
[09:02] <poolie> i'm leaving it open for a couple more days to try to land pack changes
[09:03] <poolie> i should send mail about that
[09:03] <bialix> I'd like to fix bug 129298 for 0.92
[09:03] <ubotu> Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress]  https://launchpad.net/bugs/129298
[09:03] <poolie> that would be good
[09:04] <bialix> I'm thinking about providing standalone installers for some plugins, like bzrtools
[09:04] <bialix> so this bug is show stopper for me
[09:04] <bialix> I think I'll send merge request in next couple of days
[09:10] <poolie> k
[09:11] <poolie> bialix: maybe there should be just one installer and it should ask you which plugins you want?
[09:11] <bialix> pollie: it's possible, but I'm slightly worried about size of all-in-one installer
[09:12] <bialix> even though now I have radiomodem and moderate quality of internet, I'm still remember dial-up days
[09:12] <poolie> yes, i see
[09:12] <bialix> bzrtools is pretty small though
[09:12] <poolie> right
[09:13] <bialix> QBzr is bigger (+3MB to installer) because it carries Qt libraries
[09:13] <poolie> if bzr-gtk needed to install the gtk libraries that could make it a lot bigger
[09:13] <poolie> exactly
[09:13] <bialix> yeah, that's why I think QBzr is better choice for win32: it's much smaller
[09:13] <poolie> oh, interesting
[09:13] <igc> my leaning is toward one installer. Can we see what size it would be first before taking another path?
[09:14] <bialix> ok, it's doable
[09:14] <poolie> maybe one big one and one smaller one
[09:14] <bialix> I'll do sone experimenting tonight and post result tomorrow
[09:14] <igc> thanks
[09:15] <bialix> anyway as sane solution, I could provide bare installer (only bzr.exe) and rich installer (with batteries included)
[09:15] <bialix> but I understand that there is already zoo of installers for win32
[09:15] <igc> I know it seems a small detail but multiple installers means cross-checking versions match, etc.
[09:15] <igc> anything we can do to lower the barrier to entry is very valuable I think
[09:16] <igc> and one installer fits into that camp IMHO
[09:16] <bialix> 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] <bialix> but I'm not planning to include bzr-gtk
[09:17] <bialix> I dislike PyGTK bloat
[09:17] <igc> sounds like QBzr is shaping up nicely though
[09:17] <poolie> it does
[09:17] <poolie> it's kind of a shame to have the duplication
[09:17] <bialix> well it lacks QOlive, otherwise it's very good
[09:18] <bialix> it's inevitable
[09:18] <bialix> Lukas did very nice work with side-by-side diff
[09:18] <poolie> in Q or G?
[09:18] <bialix> Q
[09:19] <bialix> but I'm using bzr-gtk about a year ago, may be they more similar than different
[09:19] <bialix> now
[09:20] <bialix> my point about Q vs G is: Q more windows-alike than G
[09:46] <poolie> spiv: hi, what's new with hpss?
[09:48] <Peng> What interesting branches are there, for someone useless who just likes reading changelogs?
[09:49] <poolie> Peng, https://code.launchpad.net/
[09:50] <Peng> 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] <bialix> what colors means
[09:51] <bialix> ?
[09:51] <bialix> green and blue?
[09:51] <poolie> one is 'uses bzr natively' and one is 'imported from cvs or svn'
[09:52] <poolie> Peng, i'm not sure what you're looking for
[09:52] <Peng> Interesting changelogs.
[09:53] <poolie> on bazaar, or something else?
[09:53] <poolie> hello mwh_
[09:53] <mwhudson> poolie: hi
[09:54] <poolie> mwhudson, Peng's question is something i'd like code to answer more
[09:54] <poolie> 'show me some interesting code'
[09:54] <poolie> or interesting changes
[09:56] <Peng> I guess I'm curious what's going on with Bazaar.
[09:56] <poolie> https://code.edge.launchpad.net/~bzr/bzr/trunk plus http://bundlebuggy.aaronbentley.com/ gives a good picture
[09:56] <bialix> umm, packs?
[09:56] <poolie> http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n http://bundlebuggy.aaronbentley.com/?selected=merged
[09:57] <Peng> What about the hpss stuff?
[09:58] <poolie> ping spiv
[09:59] <mwhudson> poolie: there's https://code.edge.launchpad.net/+recently-changed-branches
[10:21] <vila> lifeless: transportstats pushed on launchpad bazaar.launchpad.net/~v-ladeuil/bzr/transportstats
[10:25] <ubotu> New bug: #150860 in bzr "Transports should explicitly track whether a port was specified" [Undecided,New]  https://launchpad.net/bugs/150860
[11:07] <egx0r> 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] <quicksilver> DVC
[11:11] <egx0r> quicksilver: Thanks! I'll look into it
[11:41] <AnMaster> $ bzr branch http://leaves.freeshell.org/envbot emerge-trunk
[11:41] <AnMaster> bzr: ERROR: http://leaves.freeshell.org/envbot/.bzr/checkout/format is redirected to http://myspace.com/redmartian
[11:41] <AnMaster> hum
[11:41] <AnMaster> how do I branch it, I can pull from it but not branch from it
[11:41] <AnMaster> odd
[11:41] <AnMaster> there is no checkout of it on server as far as I know
[11:42] <Peng> It's normal for there not to be checkouts on the server.
[11:42] <Peng> All that's needed is the ".bzr" directory.
[11:42] <AnMaster> so why this error?
[11:42] <AnMaster> and yes the .bzr is there
[11:42] <AnMaster> ...
[11:43] <Peng> ...
[11:43] <Peng> Well, http://leaves.freeshell.org/envbot/.bzr/checkout/format redirects to http://myspace.com/redmartian.
[11:43] <AnMaster> Peng, yes I wonder why I get this error when trying to pull another developer's branch
[11:43] <Peng> That would be why you get the error.
[11:43] <AnMaster> Peng, it seems that server redirect any non-existing file to there
[11:43] <Peng> That's dumb.
[11:44] <Peng> Is that branch using some ancient format or something?
[11:44] <Peng> That file isn't new.
[11:44] <Peng> Oh.
[11:44] <Peng> No .bzr/checkout at all. Which makes sense.
[11:44] <Peng> I don't know why Bazaar cares about that file.
[11:45] <Peng> But redirecting 404s to MySpace is the dumbest thing I've ever heard of.

[11:45] <AnMaster> Peng, I agree
[11:55] <AnMaster>  http://pastebin.ca/730542
[11:55] <AnMaster> anyone got any idea about that?
[11:57] <AnMaster> Peng, maybe you?
[11:59] <Peng> AnMaster: Not sure. Is it a checkout or a branch?
[11:59] <AnMaster> this is a branch of that repo
[11:59] <Peng> I know I've heard of this, I just don't remember it.
[11:59] <Peng> Augh, Barney.
[11:59] <AnMaster> Repository checkout (format: dirstate-tags)
[11:59] <AnMaster> Location:
[11:59] <AnMaster>   repository checkout root: .
[11:59] <AnMaster>         checkout of branch: http://www.vmlinux.org/jocke/bzr/bzrweb/
[11:59] <AnMaster>          shared repository: /usr/home/envbot/bzrweb
[11:59] <Peng> It's a checkout.
[11:59] <AnMaster> hm what
[11:59] <AnMaster> odd
[11:59] <Peng> bzr unbind
[12:00] <Peng> I think there's a bug filed on that locking error, and it might've been fixed.
[12:00] <AnMaster> interesting
[12:02] <AnMaster> 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] <AnMaster> Peng, so I need some combination of mercurial and bzr it seems
[12:05] <Peng> I have no idea. :P
[12:07] <mwhudson> mercurial doesn't have any more support for cherrypicking than bazaar does, does it?
[12:08] <jelmer> don't think so. darcs is the king of cherrypicking
[12:08] <jelmer> I mean, I don't think mercurial supports cherrypicking mor ethan mercurial
[12:08] <Peng> Mercurial has the transplant extension.
[12:08] <Peng> Not sure how well it does it.
[12:09] <mwhudson> bzr has the rebase plugin, too :)
[12:18] <AnMaster> is there anything like git bisect for bzr?
[12:22] <jelmer> AnMaster: there is bzr-bisect
[12:22] <AnMaster> ah, link?
[12:24] <jelmer> https://launchpad.net/bzr-bisect
[12:24] <AnMaster> as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
[12:29] <jelmer> that's not possible yet as Bazaar does not have per-file properties yet
[12:29] <jelmer> although I guess it is possible to set revision properties with that information
[12:29] <AnMaster> jelmer, hm
[12:30] <AnMaster> 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] <AnMaster> that is what I need
[12:31] <AnMaster> and tracking what changes have been merged back of course
[12:31] <AnMaster> jelmer, so what distributed version control systems can handle that?
[12:32] <Zindar> you want partial merges?
 as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
[12:33] <Zindar> oki.. darcs is the best at that.. but sucks in many other ways
[12:33] <Zindar> but .. it's made to do exactly that
[12:33] <Zindar> bzr isn't... it is planned
[12:33] <AnMaster> yes so I understood, but bzr got several other nice features
[12:33] <AnMaster> Zindar, any idea when
[12:33] <Zindar> it's the one feature I really really want
[12:33] <Zindar> post 1.0 sometime I would think
[12:33] <AnMaster> and when will that be?
[12:33] <AnMaster> this year?
[12:34] <Peng> AnMaster: Mercurial puts changes in their stable branch then merges them into the development branch.
[12:34] <Zindar> 1.0 will be I think.. but.. when the cherrypicks will come.. no idea
[12:34] <Peng> (I mean that's how the Mercurial project handles it.)
[12:34] <Zindar> peng: hg, git, bzr all can do it...
[12:34] <AnMaster> Peng, I need to be able to both handle forwardport and backport
[12:34] <Zindar> but the tracking is less then optimal
[12:35] <AnMaster> 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] <Zindar> 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] <Zindar> so.. less then optimal
[12:48] <AnMaster> indee
[12:48] <AnMaster> indeed*
[12:48] <AnMaster> so I'm looking for a usable solution
[12:49] <AnMaster> 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] <AnMaster> because it is not merging forward that is most common, merging back is
[12:51] <luks> do you ever merge the backported branches (complete branch, not just cherry picking) back to the dev branch?
[12:52] <AnMaster> probably not but could happen
[12:53] <luks> I don't see the problem with bzr/hg/git-like cherry picking then
[12:53] <AnMaster> 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] <luks> but then you need a new fix, not the cherry-picked one from the dev branch
[12:56] <AnMaster> indeed
[12:56] <AnMaster> luks, but a lot of the time changes can be backported by cherry-picking
[12:57] <luks> so, bzr merge -rbefore:X..X && bzr commit
[12:57] <AnMaster> that doesn't keep track of what changes I merged back last I tried
[12:58] <AnMaster> wait, before: ?
[12:58] <luks> yep, but my point is that you don't need that
[12:58] <AnMaster> 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] <luks> before: is the left-most parent revision
[12:59] <luks> AnMaster: well, you see the commit message
[12:59] <AnMaster> 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] <luks> but you still do the merges manually
[12:59] <luks> cherry-picking tracking is only useful for automatic merges
[01:00] <luks> (when you merge the whole branch)
[01:00] <AnMaster> svnmerge is manual (http://www.orcaware.com/svn/wiki/Svnmerge.py), yet I would call it much more useful than your suggestion
[01:00] <luks> how is it more useful?
[01:01] <AnMaster> as in "possible to handle with a lot of changes"
[01:01] <AnMaster> afk
[01:01] <luks> the cherry picked changes will have different revnos in svn
[01:02] <luks> so you still can't see which changes were merged
[01:03] <AnMaster> yes I can, because it is stored in svn properties
[01:03] <luks> 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] <AnMaster> read the link I gave
[01:03] <luks> I know about svnmerge, I
[01:03] <luks> I've used it a lot
[01:03] <luks> but then I found out bzr-svn :)
[01:05] <AnMaster> example:
[01:05] <AnMaster> svnmerge avail
[01:05] <AnMaster> 8074,8079-8080,8082-8083,8088-8089,8097-8098,8101-8103,8107,8109-8112,8115-8118,8121-8127,8129-8130
 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] <AnMaster> $ python ./svnmerge.py integrated
[01:06] <AnMaster> 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] <AnMaster> 8069,8071-8072,8075,8077,8084,8086,8090,8092,8099,8113,8119,8131-8132,8134,8136
[01:09] <AnMaster> luks, so what do you mean with "<luks> so you still can't see which changes were merged"
[01:10] <luks> I didn't know about 'svnmerge.py integrated'
[01:10] <AnMaster> there you are then
[01:10] <luks> but this approach would really not work well in and DVCS
[01:11] <luks> any
[01:11] <AnMaster> indeed
[01:12] <AnMaster> 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] <AnMaster> memory*
[01:13] <luks> I prefer to not keep track of things like this myself
[01:13] <luks> if I have a bug, and I need to backport it, then I backport it
[01:13] <AnMaster> exactly, so I need bzr to keep track of it for me
[01:13] <quicksilver> I've never wanted to have cherry-picking on that kind of scale
[01:13] <quicksilver> maybe I just haven't worked on projects like that
[01:13] <luks> and forget about it (in my head, not in my VCS)
[01:14] <luks> in bzr you can have custom per-revision properties
[01:14] <luks> so theoretically you could write a plugin that remembers which revisions were merges
[01:14] <AnMaster> luks, no I can't because I don't know python
[01:14] <luks> the problem is that this info wouldn't be very useful if you have more than one branch
[01:15] <luks> it works in svn, because you have incremental per-repo revnos
[01:15] <AnMaster> but I need some way to keep track of cherry picking on this scale and even larger
[01:16] <luks> or even better you could always associate commits with bug IDs
[01:16] <luks> and then check for fixed bug IDs, not revisions
[01:17] <AnMaster> sure but some bugs you discover when coding something else, then you fix it without first opening a bug
[01:17] <AnMaster> anyway didn't know you could integrate bzr with trac in such a way
[01:17] <luks> well, not with trac
[01:17] <luks> but there is 'bzr commit --fixes'
[01:17] <AnMaster> luks, and I use trac
[01:18] <AnMaster> and that doesn't work with ci --fixes afaik?
[01:18] <AnMaster> + what about reopened bugs
[01:18] <luks> trac would need to be tweaked to understand this data
[01:18] <luks> but yeah, it wouldn't work for reopened bugs
[01:18] <AnMaster> indeed
[01:19] <AnMaster> luks, but why are you so much against cherry-picking?
[01:19] <AnMaster> I can't see why
[01:19] <luks> I'm not against cherry-picking at all
[01:21] <luks> the problem is that in DAG-based systems it's not trivial to implement true cherry-picking, because it breaks the graph
[01:21] <AnMaster> still it is a feature I need :)
[01:21] <quicksilver> There is an objection to cherry-picking which is that it is unsound, because revisions potentially depend on all preceding revisions
[01:21] <hsn_> i need cherry pick as well
[01:22] <quicksilver> however, if the programmer is prepared to deal with the unsoundness then that's his problem
[01:22] <AnMaster> quicksilver, maybe, but what would you suggest instead to handle stuff like the example above
[01:22] <luks> AnMaster: I think you need a list of manually merges changes, not a true cherry-picking
[01:23] <quicksilver> AnMaster: I would bzr merge in the changes I wanted; or in some cases apply diffs by hand if the commit was not atomic enough
[01:23] <quicksilver> AnMaster: and I'd make notes of what I was doing in the commit message
[01:23] <luks> e.g. I use https://code.edge.launchpad.net/~luks/+junk/bzr-pick for semi-automatic cherry-picking
[01:23] <quicksilver> AnMaster: if the scale of the problem grew larger, I would structure my commit messages in some standard way
[01:23] <quicksilver> AnMaster: and then write tools to gnerate the right messages and parse the log file
[01:23] <luks> it would be trivial to add revision properties to remember the origianl revision IDS
[01:23] <luks> and give you the list later
[01:24] <luks> but I don't think the list would be useful to you
[01:24] <AnMaster> luks, something like svnmerge indeed, and I normally merge 1) from other developers stable branch to my stable, and other developers trunk to my trunk. 2) from my trunk to my stable and from my stable to my trunk
[01:24] <AnMaster> not really from other devlopers trunk to my stable
[01:24] <AnMaster> luks, "+junk"?
[01:25] <luks> "+junk" = no product in launchpad
[01:25] <AnMaster> ah
[01:25] <luks> the plugin does nothing else but: bzr merge -r before:X..X && bzr commit
[01:25] <luks> but it's nice to have it in one step, and don't have to copy&paste commit messages
[01:26] <quicksilver> AnMaster: mind you, I wasn't actually *objecting* to cherry picking
[01:26] <quicksilver> AnMaster: I was just letting you know what an objection might be
[01:26] <AnMaster> hm
[01:26] <quicksilver> it's not clear that it has a sound semantic model :)
[01:27] <AnMaster> ok, still it is clear to me that not having some system to handle the problem is unsound for developers
[01:27] <AnMaster> ;P
[01:28] <quicksilver> generally speaking, I don't share changesets between branches to that extent
[01:28] <quicksilver> if they are that close, I merge them
[01:28] <quicksilver> if they're not close, I don't bother to keep back and forward porting stuff :P
[01:29] <AnMaster> depends. for inspircd (using svn), it is about 1.1 is stable and there are new maintenance releases of it, while 1.2 (trunk) is rewriting some core parts, still code in many of it's modules is mostly the same
[01:29] <quicksilver> certainly there are many different ways to organise projects
[01:30] <quicksilver> and many different ways to use your VCS
[01:30] <AnMaster> 1.2 changes how it handles nicks for example by changing to using UUIDs for users to track them instead of using nick for it
[01:31] <AnMaster> and my irc related project that uses bazaar is now about first stable version too, and we would benefit from the same development model, apart from that we also need to be distributed
[03:13] <zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
[03:14] <schierbeck> jelmer: hello
[03:15] <corporate_cookie> Is the default python interpreter usually specified with a symlink ?
[03:18] <quicksilver> on debian that's certainly typical
[03:18] <corporate_cookie> thanks quicksilver
[03:18] <quicksilver> debian (and debian-derived OSes) symlink binaries via /etc/alternatives
[03:19] <corporate_cookie> this is what i thought ..however i changed the symlink on RHEL4..and the default interpreter did not change
[03:19] <corporate_cookie> alas : )
[03:21] <quicksilver> to be honest, default is a fiddly concept
[03:21] <quicksilver> what actually *matters* is what the #! line says
[03:21] <quicksilver> if your #! says /usr/bin/python2.3 then it's going to use that
[03:21] <quicksilver> if #! says /usr/bin/python and /usr/bin/python is a symlink, then that's fine
[03:22] <zorg_the_false> q. i run kubuntu feisty, any suggestion for a 'good' ui frontend ?
[03:25] <corporate_cookie> quicksilver: ...alas I'm just a lazy bum who doesn't want to change quite a few #! lines
[03:27] <zorg_the_false> sudo apt-get install bzr-gtk -> "bzr-gtk: Depends: bzr (< 0.91~) but 0.91-2 is to be installed"
[03:28] <quicksilver> corporate_cookie: then blat a symlink over whatever the #! is pointing at
[03:28] <zorg_the_false> but0.91-2 is the one provided by the repository
[03:28] <quicksilver> corporate_cookie: so if the #! is /usr/bin/python2.3, make that a symlink to what you want
[03:29] <corporate_cookie> thanks quicksilver
[03:29] <zorg_the_false> ah ok the repository doesnt contains the last version of bzr-gtk
[03:29] <zorg_the_false> it is only available from source
[04:26] <jelmer> schierbeck, hi
[05:38] <AnMaster> hm launchpad seems quite ubutntu specific, it should really be more distro neutral
[05:38] <AnMaster> to be any useful
[05:39] <AnMaster> of course not sure what is the right place to complain about that
[05:39] <mrevell> jelmer: Hi - can you answer a quick question about lp:
[05:39] <mrevell> AnMaster: Hi
[05:39] <mrevell> AnMaster: I work for the Launchpad team
[05:40] <mrevell> AnMaster: What changes would you like to see to Launchpad to make it more distro neutral?
[05:40] <AnMaster> mrevell, I'm a FreeBSD user so all the ubutntu stuff in the settings for user account seems a bit offending
[05:40] <eolo> hi all. I have a dramatic problem with official docs!! Is there a straightforward 'howto' to start a bzr smart server accessed via bzr+ssh?
[05:40] <AnMaster> like ubuntuwiki, why would I want that
[05:41] <AnMaster> if you want a wiki, why not a launchpad wiki instead
[05:41] <Peng> eolo: The only setup needed is bzr in the PATH ..
[05:41] <AnMaster> why force it to be ubuntu wiki
[05:41] <AnMaster> "This is your wiki name in the Ubuntu wiki. You cannot remove it because without it you won't be able to login there."
[05:41] <AnMaster> ...
[05:41] <AnMaster> I have no plans to login there
[05:41] <radix> AnMaster: I use Launchpad without doing anything related to Ubuntu at all, and it doesn't get in the way at all
[05:42] <AnMaster> "Ubuntero:  No (apply now)  "
[05:42] <AnMaster> what is that btw?
[05:42] <eolo> Peng: what do you mean, bzr is by default in the path: /usr/bin/bzr
[05:42] <mrevell> AnMaster: Right, I see. The Ubuntu wiki uses Launchpad to authenticate users. Does it get in your way?
[05:42] <mrevell> AnMaster: An Ubuntero is someone who has signed the Ubuntu Code of Conduct.
[05:42] <AnMaster> mrevell, not really I guess but why not make it distro neutral.
[05:43] <AnMaster> ok so what about <other distro> wiki/code of conduct
[05:43] <luks> eolo, then it should just work, no need to 'start' anything except your ssh server
[05:43] <AnMaster> do you support that too?
[05:43] <AnMaster> :)
[05:43] <eolo> Peng: The server starts but i cannot connect to it to branch
[05:43] <eolo> perhaps i'm using wrong addresses
[05:44] <AnMaster> mrevell, if you did fine, it is this ubuntu fixation that gets irritating for non-ubuntu users
[05:44] <AnMaster> mrevell, by the way, is the code for launchpad open source?
[05:44] <mrevell> AnMaster: You can add other wikis to your Launchpad profile. I'll post a message to the launchpad-users list with your comments. Ubuntu has obviously been a major user of Launchpad since the beginning but more and more projects are now using Launchpad. I'll raise your concerns with the LP team.
[05:44] <Peng> eolo: Well then, it should work.
[05:45] <eolo> i shouldn't issue the command bzr serve?
[05:45] <luks> bzr serve is for bzr://
[05:45] <eolo> and for bzr+ssh?
[05:45] <mrevell> AnMaster: Launchpad isn't yet open source but I know that our aim is to release it as open source.
[05:45] <luks> eolo, a ssh server
[05:46] <AnMaster> mrevell, ah nice. oh and at least it shouldn't list ubuntu wiki at contact details
[05:46] <AnMaster> or at least be possible to disable that
[05:46] <AnMaster> can't find where to disable it
[05:46] <mrevell> AnMaster: I think the wiki is listed under contact details as it's an opportunity to tell more people where to find out more about you.
[05:47] <AnMaster> mrevell, and the way you do wiki user pages indicate they should be in root namespace of wiki
[05:47] <luks> mrevell, not if it's wiki.ubuntu.com and the person doesn't use it :)
[05:47] <AnMaster> some people use mediawiki and such where that is not the case
[05:47] <mrevell> AnMaster: You mean rather than MediaWiki's User:Name?
[05:47] <AnMaster> exactly
[05:48] <AnMaster> then my username is still Name and base url is still http://foo.whatever  but url to user page is not http://foo.whatever/Name
[05:48] <eolo> so if i have a bzr repo in /home/user/django-projects an a remote host which command should i use to branch from there?
[05:48] <mrevell> AnMaster: You could type User:YourName in the box, that's no problem.
[05:48] <mrevell> luks: I think we have a bug about this actually. Let me find it
[05:49] <AnMaster> mrevell, and really as luks said, that wiki I never visited or plan to visit
[05:49] <eolo> ?? Should i have initialized the repo in a special way?... sorry about silly question
[05:50] <luks> eolo, bzr branch bzr+ssh://example.com/home/user/django-projects/project
[05:50] <AnMaster> mrevell, and another detail, some developers may not be tied to any specific os/distro
[05:50] <AnMaster> even though FreeBSD is my primary OS
[05:50] <AnMaster> I also use OpenSolaris and OpenBSD
[05:51] <AnMaster> and sometimes even linux (Slackware mainly then)
[05:51] <mrevell> AnMaster: Here's a link to a bug report that deals with your complaint: https://bugs.launchpad.net/launchpad/+bug/29542 Would you mind adding your comments there? I'll still raise your issue with the LP team
[05:51] <ubotu> Launchpad bug 29542 in launchpad "Launchpad pages have hardcoded references to Ubuntu" [Medium,Confirmed] 
[05:52] <AnMaster> ubotu? argh this place is infected ;)
[05:52] <eolo> luks: ERROR: Not a branch: ????
[05:52] <luks> eolo, do you have a branch there?
[05:52] <AnMaster> elmo, try sftp too instead of bzr+ssh I guess
[05:53] <AnMaster> mrevell, is pasting parts of irc log ok? I'm not motivated to write it down once again
[05:53] <mrevell> AnMaster: So long as it's edited to be specific to the issue, that's fine.
[05:54] <AnMaster> indeed I will cut out other bits of course
[05:55] <mrevell> AnMaster: thanks :)
[05:57] <AnMaster> mrevell, btw you don't need to highlight me on every line, once every now and then works fine
[05:57] <AnMaster> ;P
[06:00] <AnMaster> mrevell, for bug tracker, any special stuff needed to make it not mess up newlines
[06:00] <AnMaster> like {{{ }}} of trac
[06:00] <AnMaster> or <pre> or whatever of others
[06:01] <mrevell> There isn't a pre-formatted option for the LP bug tracker.
[06:01] <AnMaster> no preview button I notice
[06:01] <radix> LP bug comment text is already pre-formatted, it won't mess up your new lines
[06:01] <AnMaster> ah seems to be pre-formatted anyway good
[06:01] <radix> (and description text)
[06:01] <AnMaster> radix, well I see that now, but other systems are not the same
[06:02] <AnMaster> mrevell, anyway added comment with what I think is relevant
[06:02] <mrevell> AnMaster: Thanks!
[06:02] <AnMaster> mrevell, what language is launchpad in?
[06:03] <mrevell> Python
[06:03] <AnMaster> would it work with fastcgi or does it depend on a LAMP setup or such?
[06:04] <AnMaster> something to note for when you make it open source
[06:04] <AnMaster> mrevell, :)
[06:07] <AnMaster> mrevell, hm this "ppa" seems ubuntu specific too
[06:08] <mrevell> AnMaster: Launchpad is built around a PostgreSQL, modified Zope and Apache setup.
[06:08] <AnMaster> should be called "uppa" then ;)
[06:09] <mrevell> as for PPA, yes right now it is Ubuntu specific but it may well be made available for other distros in the future. I think the plan is to complete the beta and get it into production and then to look at what might come next.
[06:09] <AnMaster> mrevell, so ppa is a server side build system to build for different arches?
[06:10] <AnMaster> C/C++ and a few more sure
[06:10] <mrevell> PPA is a build system, yes, but also an apt repository hosting service. It supports x86 and AMD64 atm
[06:10] <mrevell> AnMaster: We should probably take this to #launchpad if we carry on. Don't want to hijack the bzr channel :)
[06:11] <AnMaster> ah ok didn't know about that channel
[06:11] <AnMaster> mrevell, just one thing: <ubotu> Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[06:11] <AnMaster> huh?
[06:12] <mrevell> Where did you see that?
[06:12] <AnMaster> in /msg here on freenode
[06:13] <AnMaster> I didn't say anything to it in /msg or anything
[06:13] <AnMaster> so I don't know what it is on about
[06:13] <AnMaster> mrevell, any idea?
[06:13] <mrevell> AnMaster: Let me look into that for you
[06:14] <AnMaster> I did not enter any irc info into my profile, or rather I did, and then removed it directly
[06:18] <AnMaster> mrevell, so what caused it?
[06:20] <mrevell> AnMaster: I'm not all that familiar with Ubotu but there's a page that explains more about it at https://wiki.ubuntu.com/UbuntuBots The person that maintains ubotu - seveas - appears to be offline atm
[06:20] <AnMaster> mrevell, well I can't be bothered to try to find that person, so if you like you said will handle it, fine for me
[06:20] <AnMaster> :)
[06:21] <mrevell> I'll see what I can find out for you
[06:22] <AnMaster> as far as I know I didn't give it any command...
[06:22] <AnMaster> mrevell, btw, the message was at 17:52:23 (UTC+2)
[06:23] <mrevell> ok, thanks
[06:23] <AnMaster> hm
 ubotu? argh this place is infected ;)
[06:23] <AnMaster> was at that point
[06:23] <AnMaster> silly of it to react on that if that is what it did
[06:40] <LarstiQ> 6/names
[06:40] <LarstiQ> meh
[06:41] <LarstiQ> :)
[06:56] <acuster> Hey all, how do I cleanup a bzr branch? i.e. bzr branch trunk working, then I want to blow away working?
[06:58] <mwhudson> rm -rf
[06:58] <jaavaaguru__> rm -rf working?
[06:58] <acuster> and the shared repository doesn't mind?
[06:58] <acuster> how does it clean itself up?
[06:59] <mwhudson> ah, you can end up with some unreferenced revisions in there
[06:59] <mwhudson> my general approach to that is to not care
[07:00] <mwhudson> though i think there's a plugin that can remove them
[07:03] <acuster> that kind of cruft has a way of coming back to bite me
[07:04] <acuster> ah, so bzr needs a remove-branch command
[07:25] <zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
[07:57] <james_w> zorg_the_false: I'm not sure. I think it has basic functionality.
[07:58] <zorg_the_false> james_w: ok. i dont need big funky. but i do need stability...
[07:58] <zorg_the_false> aka this is my text editor when i code :)
[07:58] <zorg_the_false> let me code, dont crash :)
[08:20] <ubotu> New bug: #151027 in bzr "[bug]  RepoFetcher run between the same location" [Low,Triaged]  https://launchpad.net/bugs/151027
[08:35] <dennda> hi there
[08:35] <dennda> i have a problem with pushing my updates
[08:36] <dennda> http://pastebin.ca/731020
[08:36] <dennda> any idea why that is
[08:38] <fullermd> http isn't writable, so you can't push over it.
[08:38] <dennda> thats https. and if i am not totally mistaken, this worked once
[08:39] <dennda> anyways: how can I solve this then?
[08:39] <fullermd> https is just http with bits scrambled  ;p
[08:39] <james_w> dennda: you need to use sftp://
[08:39] <fullermd> You want to use bzr+ssh instead (or sftp, but bzr+ssh is better)
[08:39] <fullermd> The LP page for that branch should tell you the URL via that scheme.
[08:40] <dennda> bzr +ssh says Permission denied (publickey).
[08:42] <dennda> err
[08:42] <dennda> no ssh key
[08:42] <dennda> that's probably it
[08:42] <fullermd> LP only does key auth.
[08:49] <joes2> hi. any sysadmins around for the apache server which hosts the wiki?
[08:50] <joes2> i'm the sysadmin for apache.org, and would like to help you with your spam problem
[08:51] <james_w> joes2: great, thanks. I'm not sure who the admins are. There was some discussion on the list about the spam problem recently.
[08:51] <james_w> I think the admins are canonical's sysadmin tead.
[08:51] <james_w> s/tead/team/
[08:53] <Peng> tead: team lead? :)
[08:54] <joes2> those guys don't hang out here?
[08:55] <james_w> sometimes, I'm not sure who all the team are, so I can't say for sure.
[08:55] <james_w> joes2: if you would post to the list I am sure you would get somewhere. I don't think there is anyone who really knows online at the moment.
[08:55] <joes2> which list?
[08:55] <james_w> unless you want to wait a couple of hours for lifeless or poolie
[08:56] <james_w> bazaar@lists.canonical.com at least someone will know who to contact.
[08:56] <joes2> it's not urgent.  at apache.org i think we've managed to drive the spammer off.
[08:56] <joes2> i was wondering if the same thing would work for your wiki
[08:57] <james_w> that's good, it would be great to use your skills. Sorry I can't give you the information that you need right now.
[08:57] <joes2> are they on .eu time?
[08:57] <james_w> .au
[08:58] <joes2> ok. i'll try back later then. thanks for the info
[08:58] <james_w> thanks.
[09:09] <baijiutong> does anyone know if it's possible to use bzr-svn to only push to svn repos when you tell it to?
[09:10] <baijiutong> when i do a 'ci' on a repo that i've cloned from a svn repo, it pushes it to the svn repo
[09:12] <baijiutong> i'm almost brand new to bazaar, so maybe that's not the right workflow for things.
[09:31] <james_w> baijiutong: you probably want to run 'bzr unbind'
[09:31] <baijiutong> okay
[09:32] <baijiutong> will that allow me to push back to the svn repo, or should i be using branches and merges for that?
[09:32] <james_w> baijiutong: in future if you use 'bzr branch' instead of 'bzr checkout' then you will get what you want.
[09:33] <james_w> see 'bzr help checkouts' for some more information on the difference.
[09:33] <baijiutong> i figured that out playing about just now, sorry :)
[09:34] <james_w> baijiutong: no problem. I'm glad you are sorted.
[09:34] <baijiutong> someone's finally got a patch for the python subversion bindings at least proposed to macports
[09:34] <baijiutong> so this is my first chance to really play around with bzr.. :)
[09:42] <baijiutong> ahh, and then from that branch, when you want to commit to svn, you push it there
[09:43] <baijiutong> oh, too bad it does them each as individual commits.. i was hoping to hide stupid mistakes i make on my own from my coworkers :P
[09:51] <dash> I've got uncommitted changes in my WC. I'd like to make a new branch and commit those changes to that branch, instead of the current one.
[09:51] <dash> is there an obvious command for doing that?
[09:51] <dash> or should I branch first, commit, then rename the directories? :)
[09:51] <fullermd> branch ; merge --uncommitted
[09:51] <dash> aha.
[09:51] <dash> i sort of remember that now.
[09:51] <fullermd> Well, that way works too, and may be easier.
[09:51] <fullermd> Or even commit, branch the old rev, and rename the dirs.