[01:31] <BasicOSX> How long is the delay between PQM play to showing up on code.launchpad.net/~bzr/ ?
[01:42] <lifeless> that will depend on the mirror frequency
[01:43] <lifeless> the place pqm pushes is http://bazaar-vcs.org/bzr/bzr.(dev|1.14)
[01:43] <lifeless> and that should be immediate
[03:35] <BasicOSX> lifeless:  PQM success at 6:23pm CDT merge lp:~tanner/bzr/bzr.1.14.1 http://bazaar-vcs.org/bzr/bzr.1.14, but https://code.launchpad.net/~bzr/bzr/bzr.1.14 still doesn't show the commit
[03:54] <Peng_> BasicOSX: It was last mirrored 5 hours ago. Is 6:23pm CDT less than 5 hours ago?
[03:55] <Peng_> BasicOSX: It'll be mirrored again in a few minutes.
[03:56] <BasicOSX> Peng:  it's 9:56pm now
[03:57] <BasicOSX> Just getting priv email about 1.14.1 and asking where it is, from what I can tell it's in there, just LP doesn't show it yet via log
[04:24] <Peng_> BasicOSX: Well anyway it's been mirrored now. You should tell people to use the upstream branch if they want it to be up-to-the-minute.
[04:25] <BasicOSX> still logs don't show the merge
[04:25] <BasicOSX> heh
[04:26] <BasicOSX> nm, helps if I refresh web page
[06:32] <bob2> nice, bzr conflicts scans for conflict markers automagically
[06:46] <fullermd> Y'know...   I'm sure S. Turnbull is a smart guy, and I'm willing to believe he's trying to add to a discussion rather than just troll, but sometimes...
[06:47] <fullermd> Half his mails, I can't tell what he's trying to say, and the half I can figure out always seem to be talking about something totally unrelated to the thread it's posted on.
[06:47] <davidstrauss> fullermd: totally agreed
[06:48] <davidstrauss> fullermd: and it doesn't seem like he's putting a completely genuine effort into being knowledgeable on what he discusses
[13:36] <vadi2> Hi. I upgraded my bzr from the ubuntu ppa, and all of the g* commands broke - it says gtk+ wants an api version of 1, 13, 0 while only 1, 14, 0 is available. But there are no upgrades available.
[13:36] <vadi2> Is there a package available somewhere else?
[13:39] <jonnydee1> vadi2: AFAIK this has been fixed in the already released bzr 1.14.1 version
[13:40] <jonnydee1> but that release isn't available through the ppa repository yet. I guess, you have to wait a few days....
[13:41] <vadi2> Alright.
[14:47] <alf_> Hello, I am planning to start a new project using bzr and I was wondering what format is the best to use (for my case). As it won't be made public yet I was thinking of using 1.14-rich-root. Is 1.14-rich-root the format that will be used in bzr 2.0?
[14:49] <Peng_> alf_: No, something better will be. (Probably --development6-rich-root (which is still experimental, so you shouldn't use it), or it might be modified further.)
[14:49] <Peng_> alf_: Using 1.14-rich-root sounds okay to me. Although if it's a public project, I'd make the public branches use an older format to be friendly to people with old clients.
[14:53] <alf_> Peng_: It will be made public at some point in the future, hopefully around the time bzr 2.0 comes out. At this time, I am more interested in forwards compatibility (being able to easily upgrade) so that when bzr 2.0 comes will be able to use the new format without problems.
[14:54] <alf_> Note, that I don't plan to use svn so I am only going for rich-root because I guess the default will be rich-root in the future (or rather the only option).
[14:54] <LarstiQ> alf_: for forwards compatibility 1.14-rich-root should be an ok choice (but so should almost all formats)
[14:54] <LarstiQ> alf_: agreed.
[14:56] <alf_> Another question: does launchpad currently support 1.14 formats?
[14:57] <LarstiQ> alf_: 1.14 differs from 1.9 only in the workingtree afaik. And lp supports 1.9 repository/branch format.
[14:58] <maxb> From the descriptions of the formats in "bzr help current-formats", it sounds like rich-root-pack would be equally as forward-compatible as 1.14-rich-root - is this not the case?
[14:58] <LarstiQ> alf_: having said that 1.14 is really new. Unless you have reasons to use what it provides I would personally go for something that allows older clients to operate.
[14:59] <LarstiQ> maxb: that is indeed the case.
[14:59] <alf_> LarstiQ: eg 1.9?
[14:59] <LarstiQ> alf_: that, or rich-root-pack for what I'd consider the lower limit.
[15:03] <jonnydee1> Hi LarstiQ: Would it be possible for you to confirm bug https://bugs.launchpad.net/bzr/+bug/370551 and also classify it to some other 'Importance' state as 'Unknown'?
[15:03] <jonnydee1> I think, because 'bzr mv --auto' is officially a new feature in bzr 1.14, this bug should be resolved in neear future. Otherwise, I think, 'bzr mv --auto' is unusable...
[15:09] <LarstiQ> jonnydee1: done
[15:09]  * LarstiQ goes grocery shopping
[15:09] <jonnydee1> You're great!!! Thanks a lot :D
[15:09] <LarstiQ> jonnydee1: still need to fix the bug though :)
[15:10] <jonnydee1> yes, of course, but now tihs bug will not be "forgotten" :)
[15:10] <Peng_> Never say never! :D
[15:11] <LarstiQ> jonnydee1: it helps that you care about it
[15:12] <jonnydee1> LarstiQ: cool :)
[15:12] <jonnydee1> Peng_: Never, Never, Never, Never, Never, Never, Never... ;)
[15:51] <ronny> anyone aware of bzr has a way to plug in "smarter" merge algorithms
[15:51] <ronny> like take partial/subdir merges into account
[16:58] <LarstiQ> spiv: if you could advise me on #250451 I'd appreciate it.
[17:49] <xnox> Can I import pristine-tars into existing packaging branch? I want to get rid of my tarballs/ directory.
[17:53] <james_w> xnox: not currently
[18:27] <MattCampbell> Is there a written overview of Bazaar's current repository format, something like chapter 3 of Bryan O'Sullivan's Mercurial book?  I'd like to have some understanding of how files, revisions, and branches are represented.
[20:29] <MattCampbell> Does Bazaar work with Python 2.6 yet?
[20:29]  * AmanicA trying to figure out how the config is being reset when running blackbox tests, because I need to do that for rules based config too
[20:30] <AmanicA> MattCambel: AFAIK it does, the tests pass
[20:30] <AmanicA> and since I'm on jaunty it seems that I'm using python 2.6
[20:31] <AmanicA> so it looks like its working
[20:32] <LarstiQ> MattCampbell: afaik it has had patches to work on 2.7 even. Is there a specific reason you think it might not work on 2.6?
[20:44] <MattCampbell> When I try to build bzr on Windows with Python 2.6 and Pyrex 0.9.3, I get a TypeError about the arguments to swig_sources
[20:45] <MattCampbell> bzr 0.14.1
[20:45] <LarstiQ> 1.14.1 I presume.
[20:45] <LarstiQ> MattCampbell: did you see John's post about building on windows?
[20:46] <MattCampbell> No
[20:49] <TheDJACR> When using bzr distributed, as a team, which is the better choice in section 6.2.5 of the User Guide?
[20:50] <LarstiQ> MattCampbell: https://lists.ubuntu.com/archives/bazaar/2009q2/057797.html
[20:50] <LarstiQ> TheDJACR: could you give me a link? I haven't got the User Guide memorized :)
[20:51] <TheDJACR> LarstiQ: Heh, sure :p. I was reading a paper copy
[20:51] <TheDJACR> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#organizing-branches
[20:53] <TheDJACR> Also, are there any Bazaar web portal/project management tools?
[20:53] <LarstiQ> TheDJACR: it's a bit a matter of taste. If you are dilligently working in feature branches and only commit in trunk to merge them, I'd go with the checkout.
[20:54] <LarstiQ> TheDJACR: you mean like trac? Redmine works with Bazaar.
[20:54] <TheDJACR> Cool, thanks LarstiQ
[20:55] <LarstiQ> (and there is support for trac, but the trac model doesn't mesh well with dvcs, there are users of trac bzr, YMMV)
[20:57] <TheDJACR> LarstiQ: So I would checkout the trunk, and branch a feature/bugfix. I would update the trunk, merge with the feature and commit the trunk?
[20:59] <LarstiQ> TheDJACR: merge the feature into trunk, yes
[20:59] <TheDJACR> Sounds cool.
[21:00] <TheDJACR> LarstiQ: How would you compare bzr to hg and git?
[21:00] <LarstiQ> TheDJACR: I can't fairly do that having near zero recent experience with hg and git.
[21:01] <LarstiQ> I know some things about them, but my knowledge might no longer be up to date.
[21:01] <TheDJACR> Ok, thanks anyway.
[21:01] <LarstiQ> TheDJACR: if you have a more specific question, I might be able to answer it.
[21:02] <TheDJACR> Okay :)
[21:02] <LarstiQ> TheDJACR: as an example, afaik, git still does (and probably always will) apply a heuristic to detect renames instead of tracking them explicitly.
[21:03] <LarstiQ> wether that is an issue or not differs for people.
[21:05] <LarstiQ> TheDJACR: another thing is of course that bzr and hg are mostly written in python. Git used to be shell, c, perl, and more, not sure where it's at now.
[21:14] <cdecarlo> hi, I want to set up a bzr repository to work with the decentralized workflow, but the docs have me guessing if I create the repos as shown in the solo workflow or the centralized workflow, what should I do?
[21:15] <LarstiQ> cdecarlo: I'd assume the setup is (nearly) the same. Could you point me at the specific (parts of) documentation that is unclear?
[21:17] <cdecarlo> LarstiQ, I think what's got me confused is the terminology, here's an example http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id60
[21:18] <gotgenes> Is there a way to pop off a series of revisions similar to `git reset --hard REVNO`?
[21:18] <LarstiQ> gotgenes: you'll have to explain what that git command does.
[21:19] <cdecarlo> LarstiQ, the bzr branch sftp://central... , so I'm understanding that centralhost/srv/bzr/PROJECT/trunk is where all the code is, right?
[21:19] <LarstiQ> gotgenes: it could be revert, uncommit or pull depending on what reset --hard means.
[21:19] <gotgenes> LarstiQ: You're at revision 14. You want to go back to revision 11, and you want to remove all commit information from 12, 13 and 14. In this case, you do `git reset --hard 11`
[21:19] <gotgenes> now you have commit info for revisions 1 through 11
[21:19] <gotgenes> and 12-14 no longer "exist"
[21:20] <LarstiQ> gotgenes: `bzr pull -r 11 --overwrite` I'd say.
[21:20] <cdecarlo> LarstiQ, so on the server, do I first create the project and all it's code in /srv/bzr/PROJECT/trunk?
[21:21] <LarstiQ> cdecarlo: I would start locally, and then push to the server.
[21:21] <LarstiQ> cdecarlo: the repository layout on the server would be the same as locally, although without working trees, and having the complete set of interesting branches.
[21:22] <LarstiQ> gotgenes: `bzr revert -r 11` would be for just making the working tree state be that of revision 11.
[21:22] <cdecarlo> LarstiQ, ah, so /srv/bzr/PROJECT and /srv/bzr/PROJECT/trunk wouldn't need to exist first on the server
[21:22]  * LarstiQ slaps self
[21:22] <cdecarlo> ?
[21:22] <LarstiQ> gotgenes: sorry, `bzr uncommit -r 11` is more natural.
[21:23] <gotgenes> LarstiQ: That does get the tree state to r11 but it doesn't remove the commit information
[21:23] <LarstiQ> gotgenes: correct.
[21:23] <gotgenes> LarstiQ: Ah
[21:23] <gotgenes> Yes, that's it, I think
[21:23] <LarstiQ> cdecarlo: correct.
[21:24] <cdecarlo> LarstiQ, weird, for some reason I find that unsettling
[21:24] <cdecarlo> :)
[21:24] <LarstiQ> cdecarlo: there is nothing technically special about the central server, it is on equal footing with your local branches. It is just easy for us humans to have a blessed central location.
[21:24] <LarstiQ> cdecarlo: welcome to the world of decentralisation :)