[12:03] It doesn't say "nothing to do" if it can't find anything mergeable. [12:04] abentley: perhaps it could say '%URL is already fully merged.' [12:05] Sure. [12:05] good morning btw === bac [n=bac@canonical/launchpad/bac] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr [12:33] abently, no, it was a bundle it couldn't read; when I opened the bundle in my editor and resaved it as utf-8, I progressed to being told it didn't have \n line-endings; when I changed it to line endings, I was told a parent revision was missing [12:34] or maybe I'm misunderstand, but based on the progression, that wasn't the scenario === jml_ [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr [12:39] lifeless: ping [12:39] pong [12:39] lifeless: I'm running bzr-pqm from gutsy and getting this error: [12:39] BzrBadParameterUnicode: Parameter content is unicode but only byte-strings are permitted. [12:39] bzr 0.18.0 on python 2.5.1.final.0 (linux2) [12:39] arguments: ['/usr/bin/bzr', 'pqm-submit', '-m', '[r=kiko] Fix #134345 (ppa-tos page), #135186 (ppa page typo), #135385 (configuration files fixes for ppa) and fix poppy to store upload with g+w permission.'] [12:40] cprov: 'bzr plugins' -> pastebin [12:40] lifeless: have you seen it before ? how can I workaround it ? [12:40] run the one from lpdebs probably === asabil [n=asabil@062016174168.customer.alfanett.no] has joined #bzr [12:41] lifeless: https://pastebin.canonical.com/53/ [12:44] lifeless: right, I have missing upgrades from lpdebs. I hope they will fix the problem. (sorry, I should have checked before). Thanks === RainCT [n=RainCT@unaffiliated/rainct] has joined #bzr [12:46] hi [12:48] I just started pushing something to a new branch in Launchpad but then I realized that I forgot to commit and aborted it (Ctrl + C). Now I get bzr: ERROR: File exists: u'/~rainct/freevial/testing/.bzr': mkdir failed: unable to mkdir each time I try to push it again, and on Launchpad on the branch's page it says Launchpad could not mirror this branch 41 seconds ago. The error was: Not a branch:. I've tried with --use-exist [12:50] RainCT: you disturbed it during the initial setup [12:50] RainCT: better to let it finish, then commit, then push again to add the additional data :) [12:50] anyhow, this should fix it [12:50] python [12:50] >>> import bzrlib.bzrdir [12:51] >>> d = bzrlib.bzrdir.BzrDir.open('sftp://bazaar.launchpad.net/~rainct/freevial/testing') === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [12:51] >>> d.create_branch() [12:51] ollie: So you are saying the directory your bundle was in was not a branch? [12:51] And not inside a branch? [12:52] lifeless: the "d = ..." says bzrlib.errors.NotBranchError: Not a branch: [12:52] lifeless: just for the record, bzr-pqm (0.13~20070226-0ubuntu2) from lpdebs is working correctly. [12:52] abentley, sorry, I guess I misunderstood. the current working directory from which I tried to merge a bundle created by someone else one a separate machine was itself a branch. [12:53] When you got "Nothing to do", it's because it was merging that branch. [12:54] ok, because it failed to read the bundle [12:54] Right. [12:55] lifeless makes a good point that it should be clearer about what it's merging. [12:55] it would have been uber-helpful if it had stated that it was unable to make any sense of what I gave it [12:55] On http, that would mean no branches would ever work. [12:56] Not to say we can't do better, of course. [12:58] not being burdened by any implemenation details, it seems completely counterintuitive to pass something to merge and be told there's nothing to do (when you're looking at the bundle in your editor and can see that there is stuff) [01:01] Well, that can also happen with bundles you've already merged, so the "editor" test isn't very conclusive. === igc [n=igc@ppp121-45-197-71.lns1.bne1.internode.on.net] has joined #bzr [01:02] morning [01:02] RainCT: ok [01:03] RainCT: you need to login via lftp or sftp and delete everything in that dir [01:03] RainCT: then you can replace the d = line with [01:03] d = bzrlib.bzrdir.BzrDir.create('sftp....') [01:03] and do d.create_repository [01:03] d.create_branch() [01:03] - first one should have been do d.create_repository() [01:04] igc: morning [01:04] morning abentley [01:04] morning lifeless [01:05] abentley, no, I understand that, but I'm not speaking the abstract -- I'm talking about a scenario where the code didn't exist in the target repo and the conversation (between bzr and I) consisted of my saying "merge it" and it saying "you're good to go!" [01:05] lifeless: and how can I connect to it? (does LP even allow it?) [01:05] anyhow, I don't mean to beat a dead horse ;-) [01:05] RainCT: 'sftp bazaar.launchpad.net' === gcostello [n=gcostell@i07v-212-195-160-152.d4.club-internet.fr] has joined #bzr [01:05] RainCT: or lftp sftp://bazaar.launchpad.net [01:06] lifeless: You wrote the hooks stuff, right? [01:06] yah [01:06] I'm not finding a lot of documentation on how it's supposed to be used. [01:07] Add an entry to the Branch dict? [01:07] via a plugin? [01:07] abentley: you want a plugin to add a new hook type, or to hook into one of the hooks ? [01:07] Hook into one of the hooks. (post-push). === mw is now known as mw|out [01:08] Branch.hooks.install_hook() [01:08] plus [01:08] e.g. [01:08] Branch.hooks.install_hook('post-push', hook_function) [01:08] and to name it, which is a UI convenience [01:09] lifeless: ok. deleted it, and python continued saying it isn't a branch, but it seems now I can push to it. Thanks :D [01:09] Branch.hooks.name_hook(hook_function, 'my-do-x') [01:09] RainCT: cool [01:09] abentley: these are on the base clsas of BranchHooks [01:09] So you install it and then name it? [01:10] yeah [01:10] naming is optional [01:10] Does it predate registries? [01:11] its just so that when pb's are showing hooks running, that slow hooks are shown as english rather than as the object's __str__ === gcostello [n=gcostell@i07v-212-195-160-152.d4.club-internet.fr] has left #bzr [] [01:11] Sure. [01:11] abentley: No, it didn't seem like a good fit [01:12] I guess each hook e.g. 'post-push' could be considered a registry [01:12] Yeah. I guess I see why you did it that way. [01:13] if you were doing it in one fell swoop, it would be something like Branch.hooks.register_hook('post_push', my_push_hook, "My push hook") [01:13] yeah. install_hook could sanely take a text_name=None parameter to allow that [01:13] the name_hook method came a release after hooks were added [01:13] Ah. [01:14] so I added a separate method so that plugins can do [01:14] if get_attr(Branch.hooks, 'name_hook', None): Branch.hooks.name_hook(...) [01:14] yeah, that's a bit of a lack in python's introspection. [01:15] you can get at the signature I believe, but its just not as easy or quick [01:15] you need the introspect module which has heinous dependencies IIRC [01:16] Hmm. [01:19] When you say Graph.heads should not be on a single-key graph layered on a multi-key graph, why do you say that for heads specifically? [01:19] Well heads was under discussion [01:19] but more generally part of the work to tune packs is going to be ensure we don't spend a chunk of time just tupling and detupling things [01:19] Do you think the same thing for find_unique_lca? [01:20] so the low level key for the revisions GraphIndex is (revision_id, ) [01:20] and the Graph object is key agnostic from what I recall - or nearly so. [01:21] that is, it really works on key_type:[key_type ...] - [01:21] so just passing in the right key type should allow everything to fit together nicely [01:21] Okay. [01:22] on text indices the low level key is (file_id, revision_id) [01:23] so theres more work involved in converting every get_parent request from get_parents(revision_id) - it goes to iter_entries([(file_id, revision_id)] ) and then that gets stripped on return to give a node with parents as (revision_id,), and finally that is restored to just revision_id at the top level adapter [01:24] Graph isn't the One True implementation of its interface. There's no need to assume such translation. [01:24] I realise that; what John was proposing had that translation. [01:25] my reply to him was pointing out that we should avoid it, in however he structured his api. [01:28] I would really like to have Graph.heads for use in reconcile, which is why I ask. [01:28] definately use it [01:28] And it seems like the only code you actually have a problem with is "g = graph.Graph(entry_vf)" [01:28] reconcile is repository format specific [01:29] so theres no impact on packs by using it like that [01:30] bbiab, grabbing breakfast [01:33] lifeless: Would a VersionedFile.get_graph() method satisfy you? Then different VersionedFile implementations can specify their Graph implementation. === sandrot [n=sandro@c-71-199-230-127.hsd1.fl.comcast.net] has joined #bzr [01:35] is there a changelog available for .90 : [01:35] ? [01:39] sandrot: There is the NEWS file. [01:39] k so I have to branch [01:40] or get tar === jml_ is now known as jml [01:41] 'pulling' from another person means that the person I'm pulling from needs to have his branch accessible to me via ssh on his own box or via a server he can 'push' or upload to right? === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr [01:44] pulling works on any of the protocols we support: http, sftp, ftp, bzr, bzr+ssh or local files. [01:48] abentley: the problem is the keys that should be returned [01:48] abentley: in many respects I want to stop using VersionedFile where dataset partitioning isn't helpful [01:48] Mmm, thanks. I was just thinking that because I keep myself behind a firewall (blocking ssh) in order to have someone pull to me I have to make my branch available to my server which accepts ssh (or other protocols), meaning that in order for me to share my branch I need to push first [01:49] lifeless: Surely untupling in VersionedFileGraph.heads isn't expensive. [01:49] abentley: if it occurs only at the interface surface it isn't a problem [01:49] occuring all the way down is a problem [01:49] Right. [01:50] So doing vf.get_graph() would allow us to avoid doing it all the way down. [01:50] ok [01:51] I guess my hesitation is trying to avoid the vf interface except where it clearly makes sense. Which is probably over-exaggerated at the moment. So vf.get_graph sounds fine. [01:52] Hmm, I think what I want to achieve is decoupling 'file history' vs 'text construction'. [01:52] file history queries tend to be one off operations, not part of large things like 'branch' 'checkout' etc [01:52] That's fair. [01:52] text construction tends to be part of things like merge, and thats where the artificial VF interface causes roundtrips. === bartt [i=bartt@nat/yahoo/x-993dbf60b0cc32cb] has joined #bzr [01:53] text insertion likewise, though we can queue that to avoid round trips more effectively [01:53] Are nested repositories working? [01:53] I don't seem to be able to add a nested repository. [01:54] E.g. bzr add path/to/nested/repository only reports # of ignored files [01:54] lifeless: You are the person who wants to select graph ancestors on a per-file basis, though. [01:54] bartt: You cannot add a tree into another tree. [01:55] abentley: I don't think I'm the *only* person :). [01:56] Yes, but surely doing VersionedFileGraph.find_unique_lca is the obvious approach. [01:56] abentley: per file lookups can be grouped though [01:56] thats the obvious approach, and as long as the repo its being queried on is local it will perform fine === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr [02:05] And at present, the repo being queried is always local. === jml_ is now known as jml === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [02:08] abentley: I thought that nested tree support was added in 0.15? [02:08] So more reviews today from me starting with abentley's TreeTransform rollback one [02:08] bartt: No, only support code. It is not complete. [02:09] abentley: were you planning to tweak anything following Kuno's feedback or should I review it as is? [02:09] Thanks abentley [02:10] igc: The only thing is that I should handle errors creating the pending-deletion directory the same way as errors creating limbo are handled. [02:11] abentley: I was hoping you'd say that [02:11] I'll go ahead and review and ask for that tweak === bartt [i=bartt@nat/yahoo/x-993dbf60b0cc32cb] has left #bzr [] [02:12] Okay. [02:12] What exactly does a repo with or without "trees" mean? what exactly is a tree? [02:13] Thanks. [02:13] igc: I'm going to profile commit performance with packs today. [02:14] erm, what is a tree in the context of a shared repo === orospakr [n=orospakr@bas4-ottawa23-1177611326.dsl.bell.ca] has joined #bzr [02:15] lifeless: great. I'll push my latest code this morning in case it's of interest [02:15] igc: I'm focused on repository interactions immediately. [02:15] np [02:16] I want to see how slow the repo layer is [02:16] or has to be [02:16] igc: also, how should we collaborate; I'm working in packs; I can spin off patches for bzr.dev easily. [02:16] but not for your branch as easily [02:17] my patches should be small but frequeny. Does this work for you ? [02:17] lifeless: I'm still a few days away from using the commit-candidates branch effectively ... [02:17] righto [02:18] abentley, what igc said about the merge queue goes for me to [02:18] I need to get commit changed to incremental vs 'build from scratch' first [02:18] too [02:18] poolie: Glad to hear it. I think we have the right intentions, it's just a juggling act. [02:19] so lifeless, if you can keep pushing hard on packs and getting bzr.dev closer to using them, I'm good with that [02:20] what does a 'tree' mean in the context of a shared repo...what happends to branches in a repo when I run init-repo --trees versus init-repo --no-trees ? === cypherbios_ [n=cyr@201-15-255-16.ctaje700.dsl.brasiltelecom.net.br] has joined #bzr === cypherbios_ is now known as cypherbios [02:31] sandrot: A tree is the directory (and subdirectories) that contain your source code in editable form. See bzr help working-trees. [02:32] abentley: thanks, I'm just finding it now actually [02:32] I read a lot of shared repo docs but didn't read http://people.ubuntu.com/~ianc/doc/en/user-reference/bzr_man.html#repositories yet [02:32] seems that a working tree is similar to svn's working copy [02:38] The big difference is that SVN's working copy is never in the same location as a branch or a repository. In Bazaar, the SVN layout is called a 'checkout'. [02:38] A lightweight checkout, to be precise. [02:39] Mmm, I always assumed the working copy was the copy of code you're currently working on. So when I checkout a branch my checkout is now a 'working copy' [02:44] In SVN, that's the only way of getting a working copy. But with Bazaar, "branch", "init" and "push" can also create objects with working trees. [02:45] push doesn't create a working tree thought right? you can checkout or branch from a pushed location === orospakr [n=orospakr@bas4-ottawa23-1177611326.dsl.bell.ca] has joined #bzr [02:49] When you push to a local location, it creates a working tree, and yes, you can checkout or branch from a pushed location. === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr [02:52] Push always creates a branch, and on local locations, it also creates a working tree. [02:52] creates *or updates* I should say. [03:06] New bug: #135421 in bzr "different exit code for internal errors" [Wishlist,Triaged] https://launchpad.net/bugs/135421 === jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr [03:19] igc: Shouldn't NEWS.html be up somewhere on doc.bazaar-vcs.org? [03:19] yes [03:20] abentley: it looks like doc.bazaar-vcs.org is yet to be upgraded following the 0.90 release ... [03:21] poolie has done this in the past for the RM [03:21] I'm pretty sure I have permissions now so I can do it I think [03:21] Do we even have a link to NEWS in the documents? I tried a few guesses at the URL... [03:22] but it was 404 city, baby. [03:22] see http://people.ubuntu.com/~ianc/doc/ for what 0.90 will look like ... [03:23] clicking on "Release Notes" takes you to NEWS.html [03:23] Beauty. [03:23] We gotta turn that TOC into a sidebar or something. [03:24] Any progress with getting the pretty version of the docs online? [03:24] abentley: see http://people.ubuntu.com/~ianc/pretty_docs/ for the current pretty-docs output as well [03:24] by 'current', I mean a snapshot from a week or so back of course === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr [03:26] Sure. === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === netjoined: irc.freenode.net -> kubrick.freenode.net === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr [03:47] spiv: ping - calls? === NamNguyen [n=namnt@148.177.217.131] has joined #bzr [04:21] poolie_: I see 3 failures [04:21] and one of those is due to the failure to isolate CFLAGS === igc lunch [04:26] lifeless, only 3? [04:26] hm [04:26] have you pushed to your knits branch recently? [04:26] because that's where i pulled from [04:26] poolie_: its one commit behind [04:26] http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ right? [04:27] http://people.ubuntu.com/~robertc/baz2.0/repository is the canonical location [04:36] lifeless, i'll check that one then [04:41] one thing that concerns me ian, for commit performance [04:42] is that we're three times slower than hg, but I'm seeing our gzip time as dominating [04:42] at 80% of profiled time === Vernius [n=tomger@87.193.10.161] has joined #bzr === sandrot [n=sandro@c-71-199-230-127.hsd1.fl.comcast.net] has left #bzr ["Konversation] === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr [04:52] lifeless: Potentially, you want to store uncompressed knit records, and then gzip the whole container. [04:52] Maybe faster, probably better compression. [04:52] abentley: I'd love to know precisely what git's packing algorithm is [04:53] I think I'm saying 'there is something wrong' when hg's commit is faster and our time is in gzip [04:53] not that I disagree with your point [04:58] lifeless, ok, in that branch i have only 2 failures === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #bzr [05:08] Hi, I'm not familiar with version control systems at all (yet), and I was wondering if someone could either explain or give a link to a good explanation of how bazaar compares to things like SVN, CVS, and git. [05:16] istr that bzr's wiki has a really good explanation [05:16] i think wikipedia has something too [05:16] +comparison for both [05:18] http://bazaar-vcs.org/SCMComparisons [05:19] http://en.wikipedia.org/wiki/Comparison_of_revision_control_software [05:23] http://better-scm.berlios.de/ [05:23] jeremyb: Cool, thanks [05:24] tonyyarusso, jeremyb: The better-scm site is pretty useless. I would avoid it. [05:24] hah === jeremyb is reading http://better-scm.berlios.de/to-avoid/ [05:25] not that i would ever consider using MS Visual SourceSafe anyway [05:25] I was unable to convince the author that baz and bazaar are difference VCSes. [05:25] heh [05:26] So Bazaar is listed under "Arch", completely inappropriately. [05:26] yeah, i see it doesn't have it's own listing in the sidebar [05:26] never heard of vesta before === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr [05:27] "Note: related to Bazaar, is Bazaar-NG, which is written from scratch by the same parent company. It aims to offer some advantages over Bazaar, but is not an Arch implementation, nor is it compatible with Bazaar. A tool is available to convert Bazaar repositories into Bazaar-NG, but not the other way around. [05:27] Looks like git is sort of specialized and limited-use, CVS is becoming obsolete, and if I was going to learn something it should be Bazaar, Subversion, or both. Does that sound accurate? [05:27] "CVS is becoming obsolete" yes from some perspectives :) [05:28] Well, it lacks a number of features listed for other ones, and others (like Subversion) are listed as improvements on it. [05:28] git, bazaar, *and* mercurial not or :) [05:29] I know O'Reilly has a Subversion book - is there a comprehensive guide for Bazaar yet? [05:30] tonyyarusso: oh, sorry i misread. i thought that abentley provided the quote in jest. i will provide a better answer :) [05:31] CVS is becoming obsolete by most standards although is occasianally used for new projects and has some diehard fans [05:32] CVS is long since obsolete. What it is, is _known_. People have decades of history in it, and know it inside and out. That's worth something. [05:33] right [05:35] i wouldn't say git is specialized or limited use but it does have quirks and it's got some small hurdles for windows users. git and mercurial both have support for syncing with svn. git has more mature biderectional support. bzr has not quite stable support for writes to svn last i heard and i think the read support is better. afaik mercurial doesn't have any [05:36] I was not joking. He cannot get his facts straight. If you read that site, you will know less about version control than you did beforehand. [05:37] abentley: i thought that tonyyarusso's line quoting the site was you talking [05:37] superficially bzr, hg, and git all implement the same principles but there are variations === jeremyb tries to remember the good (or at least i remember people saying it was good) bzr/hg blog post === mdmkolbe [n=mdmkolbe@iub-vpn-192-54.noc.indiana.edu] has joined #bzr [05:39] abentley: well both his bazaar and bazaar-ng links redirect to bazaar-vcs.org so it shouldn't be too hard to convince him that they are the same. but convincing him that he used the wrong link might be a challenge [05:41] abentley: how recently did you try to convince him? the arch page has an almost 2 year old timestamp [05:43] I've got no interest in trying to convince him any further. He's demonstrated that he will just ignore inconvenient facts. He's not worth thinking about. [05:43] hah, that site has an empty irc channel [05:43] abentley: i was just wondering === jeremyb ponders [05:47] i was sure CVS allowed copies retaining history for the original and the new file. (people file bugs to get those copies done for the mozilla repo all the time) his comparison says CVS doesn't support them... [05:47] I enjoy learning new systems and I've just come off of learning and using darcs at an intermship. I've learned to like the distributed model (I'm a former svn user), and am looking for a system to use on my own projects. (I'll have compile and install at as a non-root accout.) I'm consiering mercurial, bzr and git. Can anyone point to or give a good comparisen of these? [05:48] they all can be installed in your home dir === jeremyb wonders what's happening with forest (or was that hg?) [05:51] mdmkolbe: what OS? [05:51] jeremyb: both linux (as non-root) and windows/cygwin (but I administer that system so root isn't such an issue) [05:52] hrmm [05:53] git isn't supported as well on windows but i've never tried it (i think there's some performance issues too but neither of those are based on recent data) [05:54] mdmkolbe: depends how much time you have. personally i'd just try them all [05:54] on a small scale not for a real project [05:54] (i have used git and mercurial a bit not so much bzr) [05:56] jeremyb: I'm a motivated learner except that school has started and my brain is filling up to the point where I'm discovering the need to choose what I will and won't learn (which is sad, but I guess it's part of getting older.) === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr [06:08] mdmkolbe: my personal response to your question about which version control system to use is in http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html [06:10] whoa, git is like cvs? [06:10] jeremyb: CVS doesn't. Manual mucking around in the repository does. Sorta. === jeremyb reads [06:10] fullermd? [06:10] doesn't what? ohh, moves? [06:10] Yah. [06:11] fullermd: well it can record moves as well as git can [06:11] Harsh. === lifeless is both trolling and completely serious, simultaneously === jeremyb understands [06:11] food time [06:13] fullermd: well, for mozilla, it's automated to the point where you hand a script a text file with source and destination on a single line seperated by a space and it takes care of everything === mdmkolbe puts one more stroke in the tally for bzr after reading [06:13] Yeah, but what it takes care of is still a mess. And CVS doesn't know anything about it. You just sorta have the history of the file available. [06:14] What repository format does bzr use? (I ask b/c of the claims in http://keithp.com/blog/Repository_Formats_Matter.html) [06:14] mdmkolbe: a constantly improving one [06:15] mdmkolbe: And I disagree with Keith (who is, incidentally, a good friend of mine); tool usability is what matters. [06:15] mdmkolbe: and despite the rather appealing-at-first-glance notions inside Git, I have LOST DATA with Git and NEVER LOST DATA with Bazaar. [06:16] to summarize the linked article "git is good b/c each file is writting once then never touched again; hg is bad b/c it appends to the files on each commit" [06:16] AfC: heh, that kind of puts Keith's claims in perspective [06:16] mdmkolbe: we've all read it. Most of the people here are _also_ good friends with Keith. [06:17] I'm not. I'm a poor pathetic outsider, clutching at windowsills and begging for scraps of bread. === AfC goes out for coffee === fullermd hits up AfC for spare change on the way. [06:20] How well does bzr support "software archiology"? One of the troubles with darcs I found was that of trying to track down the historical context of a change (that introduced a bug I'm attempting to fix) that isn't always captured by the patch dependancy graph. [06:22] hg has a built in function to do a binary search for the bug [06:22] i don't remember who else has what [06:22] jeremyb: ?! [06:22] all have pretty good history viewing tools [06:22] mdmkolbe: ? [06:22] mdmkolbe: you know what a binary search is, right? [06:23] jeremyb: yes, but that's not something I expected from a VC system. You just point it at 'make' and your program and ask it to recompile until the search find the change causing the bug? [06:24] i've never used it === jeremyb looks [06:24] http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension [06:25] jeremyb: thx for the link [06:25] sure [06:26] darcs is a special case there, since it doesn't do historical context... [06:26] darcs drives me nuts!!! [06:27] I always say, why drive when it's close enough to walk ;) === jeremyb thinks... === jeremyb knows he's missing something... [06:35] who's brian o'sullivan? [06:36] something wrong with his repo [06:36] or at least the web frontend [06:36] http://hg.serpentine.com/mercurial/hg/book/book/convert/book/book/book/book/book/book/book/ [06:37] /bork/bork/bork? [06:37] mdmkolbe: if you haven't seen them already, http://bazaar-vcs.org/BzrWhy lists several blog posts explaining why Bazaar is better than most alternatives (in our opinion) [06:38] oh, ooops [06:38] brian o'sullivan and that repo are both hg [06:42] Nice guy, though. Wish he were on our team. [06:44] mdmkolbe, there is a bazaar bisect extension which might be more to the point [06:45] there is also iirc 'darcs trackdown' which i think was the first system to have it [06:45] poolie_: there was an IBM paper on this at LCA 2004 [06:45] describing the technique for tracking down gcc regressions automatically [06:46] based on cvs [06:46] yes [06:46] ok, so darcs may have been the first to generalize and automate it [06:46] or maybe not === mtaylor [n=mtaylor@dsl231-061-195.sea1.dsl.speakeasy.net] has joined #bzr [06:48] lifeless, btw where you wishing for a different behaviour in vim ^O? [06:48] maybe that was someone else? [06:49] dunno [06:51] anyhow, g; takes you to the place you last changed the text [06:52] yup === fullermd didn't know that. [06:52] I usually fake it with undo. [06:52] heh === jeremyb has done the faking as well [06:55] any of ya'll actually work for canonical? [06:56] who's mccormickit.com? [06:58] where is the repo for bzr? is there a web front-end? (I mean the repo for the source to bzr) [06:59] yes [06:59] I couldn't find it from the bzr website (maybe I'm just looking in the wrong place) === jeremyb is finding it [07:00] http://bazaar-vcs.org/bzr/ === jeremyb looks some more [07:02] having trouble finding a frontend hosted by the main project but i see 2 front ends for the main repo [07:02] http://codebrowse.launchpad.net/~bzr/bzr/trunk [07:02] http://goffredo-baroncelli.homelinux.net/bazaar/bazaar-NG-dev === jeremyb remembers a better frontend for git, bzr or hg but is having trouble finding it [07:05] jeremyb: yes, some of us work for canonical === jeremyb runs across https://blueprints.launchpad.net/bzr/+spec/ignore-versioned-files [07:10] https://code.launchpad.net/~bzr/bzr/trunk is the launchpad mirror of bzr.dev [07:11] http://codebrowse.launchpad.net/~bzr/bzr/trunk [07:11] is a web ui to browse it [07:11] does bzr diff require a checkout? [07:12] haha [07:12] thumper: you already have a copy locally. [07:12] jeremyb: no, I don't [07:12] I have a branch [07:13] perhaps I should have said WorkingTree [07:14] lifeless: how come I can't do "bzr diff -r-3..-1" on a branch without a working tree? [07:14] thumper: https://bugs.launchpad.net/bzr/+bug/6700 [07:14] Launchpad bug 6700 in bzr "bzr diff -r 10..20 http://foo" unsupported" [High,Confirmed] [07:14] spiv: so a working tree is needed? [07:15] arse === jdong_ [n=jdong@ubuntu/member/jdong] has joined #bzr === lifeless_ [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr [07:27] 15:20 < lifeless> thumper: patches gratefully arsed [07:27] 15:21 < lifeless> igc: ^ remember this bug ? :) [07:27] 15:22 < lifeless> ok, thats 9ish hours, I'm calling it a day. [07:27] 15:22 < lifeless> igc: poolie and I think a gzipless repo might be an interesting test, so I'm going to overhaul the knitversionedfile code some more tomorrow === lifeless_ is now known as lifeless [07:28] lifeless: yes, haven't forgotten it :-) [07:29] lifeless: :) unfortunately I have other priorities right now [07:29] lifeless: yes, an interesting test indeed [07:30] thumper: FWIW, lifeless gave me that bug on my first day at Canonical. :-( It's still on my list but behind performance work [07:32] igc: as long as it isn't forgotten :) === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [07:32] thumper: no risk of that :-) === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr === oldmanstan [n=glesica@128.177.28.13] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr [08:14] thx all for your help === mdmkolbe [n=mdmkolbe@iub-vpn-192-54.noc.indiana.edu] has left #bzr [] === mvo [n=egon@p54A6799E.dip.t-dialin.net] has joined #bzr === cnus8n [n=cnu@59.92.88.244] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === dato [n=adeodato@84.120.252.58.dyn.user.ono.com] has joined #bzr === allenap [n=allenap@212.233.37.68] has joined #bzr === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr [09:30] Eeek. What does "Not running as bzrlib.plugins.gtk, things may break." mean? [09:30] [bzr 0.90.0, bzr-gtk 0.90.0] [09:31] ... and indeed, `bzr viz` crashes. [09:31] AfC: that the bzr-gtk plugin is not installed in a directory named just "gtk" [09:32] Yes it is... er, no its not. Typo on my part. Shit. [09:33] Called it "bzr" not "gtk". That was stupid... [09:33] (in ~/.bazaar/plugins) [09:33] dato: thanks [09:33] np === markvandenborre [n=mark@ubuntu/member/markvandenborre] has joined #bzr === tolonuga [n=aj@217.72.114.248] has joined #bzr [10:01] can anyone edit http://doc.bazaar-vcs.org/bzr.dev/server.htm and replace ":1234" with ":4155"? thanks. === dato [n=adeodato@84.120.252.58.dyn.user.ono.com] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp018.studby.uio.no] has joined #bzr [10:20] tolonuga: looks like it's generated from this file: http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20070825182243-a3w20rpadbfz8euc?file_id=server.txt-20060913044801-h939fvbwzz39gf7g-1 [10:21] tolonuga: so, anyone that can checkin there... [10:24] ok, thanks. unfortunatly I can't checkin, I'm only a stupid user looking at docs and finding tiny issues. will open a bug if noone responds here, so the issue is not forgotten. [10:36] tolonuga: you could send a bundle to the mailing list, that's the usual way for things like this === sverrej_ [n=sverrej@tul-1x-dhcp019.studby.uio.no] has joined #bzr === aadis [n=aaditya@122.167.209.222] has joined #bzr === jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === igc dinner [10:59] how can I create a mail in bundle format from a local commit? preferable something I can cut&paste into my mail app - I don't want bzr to send email itself. [11:00] bundle will spit out a bundle on stdout; you can redirect that into a file, then attach it. [11:01] ah, thanks! === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === oldmanstan is now known as oldmanstan|away === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B832.dip0.t-ipconnect.de] has joined #bzr === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr [12:39] I'm looking into using bzr to manage a few django (web framework) projects I am working on together with a friend [12:40] I would regularly be working offline (on the train) [12:41] night all [12:41] up-to-date code would be needed on each of our machines, plus an external webserver [12:41] igc: Night! Thanks for the merges. :) [12:41] what kind of workflow would you recommend? [12:43] markvandenborre: You could just use a centralised workflow, because you can commit locally when working offline... [12:43] ok, will be investigating that path [12:44] Odd_Bloke, thx a lot! [12:44] markvandenborre: That's not necessarily the only/best one to use though. [12:44] But it would work. [12:44] Odd_Bloke, I figured I would really need a feature like local commits because of my long train commutes [12:45] Odd_Bloke, you think that would be the easiest way to get started with bzr? [12:46] markvandenborre: If it makes sense in your situation, then do it. :p [12:46] :) === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr [01:09] is it bad policy to setup a central repository for web projects on a production webserver? [01:10] it's not a leaky php server, and only running sshd and apache, but still... [01:11] I can imagine it's not a good thing to have both on the same server, even if it's very well managed [01:11] any thoughts? === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr [01:18] would it be better to put the bzr repository on a physically separate machine? [01:19] lifeless: I'm uploading 0.90-1 to debian. I guess some ubuntu person will have to make sure it makes through UVF. [01:24] markvandenborre: That sounds like a site policy question. bzr certainly wouldn't care. It's not hard to move stuff around later if you change your mind... [01:25] fullermd, yes, it is a site policy question... trying to be careful about setting things up with minimal overhead, but still safe [01:26]