[12:03] <abentley> It doesn't say "nothing to do" if it can't find anything mergeable.
[12:04] <lifeless> abentley: perhaps it could say '%URL is already fully merged.'
[12:05] <abentley> Sure.
[12:05] <lifeless> good morning btw
[12:33] <ollie> 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] <ollie> or maybe I'm misunderstand, but based on the progression, that wasn't the scenario
[12:39] <cprov> lifeless: ping
[12:39] <lifeless> pong
[12:39] <cprov> lifeless: I'm running bzr-pqm from gutsy and getting this error:
[12:39] <cprov> BzrBadParameterUnicode: Parameter content is unicode but only byte-strings are permitted.
[12:39] <cprov> bzr 0.18.0 on python 2.5.1.final.0 (linux2)
[12:39] <cprov> 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] <lifeless> cprov: 'bzr plugins' -> pastebin
[12:40] <cprov> lifeless: have you seen it before ? how can I workaround it ?
[12:40] <lifeless> run the one from lpdebs probably
[12:41] <cprov> lifeless: https://pastebin.canonical.com/53/
[12:44] <cprov> lifeless: right, I have missing upgrades from lpdebs. I hope they will fix the problem. (sorry, I should have checked before). Thanks
[12:46] <RainCT> hi
[12:48] <RainCT> 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] <lifeless> RainCT: you disturbed it during the initial setup
[12:50] <lifeless> RainCT: better to let it finish, then commit, then push again to add the additional data :)
[12:50] <lifeless> anyhow, this should fix it
[12:50] <lifeless> python
[12:50] <lifeless> >>> import bzrlib.bzrdir
[12:51] <lifeless> >>> d = bzrlib.bzrdir.BzrDir.open('sftp://bazaar.launchpad.net/~rainct/freevial/testing')
[12:51] <lifeless> >>> d.create_branch()
[12:51] <abentley> ollie: So you are saying the directory your bundle was in was not a branch?
[12:51] <abentley> And not inside a branch?
[12:52] <RainCT> lifeless: the "d = ..." says  bzrlib.errors.NotBranchError: Not a branch:
[12:52] <cprov> lifeless: just for the record,  bzr-pqm (0.13~20070226-0ubuntu2) from lpdebs is working correctly.
[12:52] <ollie> 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] <abentley> When you got "Nothing to do", it's because it was merging that branch.
[12:54] <ollie> ok, because it failed to read the bundle
[12:54] <abentley> Right.
[12:55] <abentley> lifeless makes a good point that it should be clearer about what it's merging.
[12:55] <ollie> 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] <abentley> On http, that would mean no branches would ever work.
[12:56] <abentley> Not to say we can't do better, of course.
[12:58] <ollie> 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] <abentley> Well, that can also happen with bundles you've already merged, so the "editor" test isn't very conclusive.
[01:02] <igc> morning
[01:02] <lifeless> RainCT: ok
[01:03] <lifeless> RainCT: you need to login via lftp or sftp and delete everything in that dir
[01:03] <lifeless> RainCT: then you can replace the d = line with
[01:03] <lifeless> d = bzrlib.bzrdir.BzrDir.create('sftp....')
[01:03] <lifeless> and do d.create_repository
[01:03] <lifeless> d.create_branch()
[01:03] <lifeless>  - first one should have been do d.create_repository()
[01:04] <abentley> igc: morning
[01:04] <igc> morning abentley
[01:04] <igc> morning lifeless
[01:05] <ollie> 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] <RainCT> lifeless: and how can I connect to it? (does LP even allow it?)
[01:05] <ollie> anyhow, I don't mean to beat a dead horse ;-)
[01:05] <lifeless> RainCT: 'sftp bazaar.launchpad.net'
[01:05] <lifeless> RainCT: or lftp sftp://bazaar.launchpad.net
[01:06] <abentley> lifeless: You wrote the hooks stuff, right?
[01:06] <lifeless> yah
[01:06] <abentley> I'm not finding a lot of documentation on how it's supposed to be used.
[01:07] <abentley> Add an entry to the Branch dict?
[01:07] <abentley> via a plugin?
[01:07] <lifeless> abentley: you want a plugin to add a new hook type, or to hook into one of the hooks ?
[01:07] <abentley> Hook into one of the hooks.  (post-push).
[01:08] <lifeless> Branch.hooks.install_hook()
[01:08] <lifeless> plus
[01:08] <lifeless> e.g.
[01:08] <lifeless> Branch.hooks.install_hook('post-push', hook_function)
[01:08] <lifeless> and to name it, which is a UI convenience
[01:09] <RainCT> 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] <lifeless> Branch.hooks.name_hook(hook_function, 'my-do-x')
[01:09] <lifeless> RainCT: cool
[01:09] <lifeless> abentley: these are on the base clsas of BranchHooks
[01:09] <abentley> So you install it and then name it?
[01:10] <lifeless> yeah
[01:10] <lifeless> naming is optional
[01:10] <abentley> Does it predate registries?
[01:11] <lifeless> 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__
[01:11] <abentley> Sure.
[01:11] <lifeless> abentley: No, it didn't seem like a good fit
[01:12] <lifeless> I guess each hook e.g. 'post-push' could be considered a registry
[01:12] <abentley> Yeah.  I guess I see why you did it that way.
[01:13] <abentley> 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] <lifeless> yeah. install_hook could sanely take a text_name=None parameter to allow that
[01:13] <lifeless> the name_hook method came a release after hooks were added
[01:13] <abentley> Ah.
[01:14] <lifeless> so I added a separate method so that plugins can do
[01:14] <lifeless> if get_attr(Branch.hooks, 'name_hook', None): Branch.hooks.name_hook(...)
[01:14] <abentley> yeah, that's a bit of a lack in python's introspection.
[01:15] <lifeless> you can get at the signature I believe, but its just not as easy or quick
[01:15] <lifeless> you need the introspect module which has heinous dependencies IIRC
[01:16] <abentley> Hmm.
[01:19] <abentley> 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] <lifeless> Well heads was under discussion
[01:19] <lifeless> 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] <abentley> Do you think the same thing for find_unique_lca?
[01:20] <lifeless> so the low level key for the revisions GraphIndex is (revision_id, )
[01:20] <lifeless> and the Graph object is key agnostic from what I recall - or nearly so.
[01:21] <lifeless> that is, it really works on key_type:[key_type ...]  -
[01:21] <lifeless> so just passing in the right key type should allow everything to fit together nicely
[01:21] <abentley> Okay.
[01:22] <lifeless> on text indices the low level key is (file_id, revision_id)
[01:23] <lifeless> 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] <abentley> Graph isn't the One True implementation of its interface.  There's no need to assume such translation.
[01:24] <lifeless> I realise that; what John was proposing had that translation.
[01:25] <lifeless> my reply to him was pointing out that we should avoid it, in however he structured his api.
[01:28] <abentley> I would really like to have Graph.heads for use in reconcile, which is why I ask.
[01:28] <lifeless> definately use it
[01:28] <abentley> And it seems like the only code you actually have a problem with is "g = graph.Graph(entry_vf)"
[01:28] <lifeless> reconcile is repository format specific
[01:29] <lifeless> so theres no impact on packs by using it like that
[01:30] <lifeless> bbiab, grabbing breakfast
[01:33] <abentley> lifeless: Would a VersionedFile.get_graph() method satisfy you?  Then different VersionedFile implementations can specify their Graph implementation.
[01:35] <sandrot> is there a changelog available for .90 :
[01:35] <sandrot> ?
[01:39] <abentley> sandrot: There is the NEWS file.
[01:39] <sandrot> k so I have to branch
[01:40] <sandrot> or get tar
[01:41] <sandrot> '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?
[01:44] <abentley> pulling works on any of the protocols we support: http, sftp, ftp, bzr, bzr+ssh or local files.
[01:48] <lifeless> abentley: the problem is the keys that should be returned
[01:48] <lifeless> abentley: in many respects I want to stop using VersionedFile where dataset partitioning isn't helpful
[01:48] <sandrot> 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] <abentley> lifeless: Surely untupling in VersionedFileGraph.heads isn't expensive.
[01:49] <lifeless> abentley: if it occurs only at the interface surface it isn't a problem
[01:49] <lifeless> occuring all the way down is a problem
[01:49] <abentley> Right.
[01:50] <abentley> So doing vf.get_graph() would allow us to avoid doing it all the way down.
[01:50] <lifeless> ok
[01:51] <lifeless> 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] <lifeless> Hmm, I think what I want to achieve is decoupling 'file history' vs 'text construction'.
[01:52] <lifeless> file history queries tend to be one off operations, not part of large things like 'branch' 'checkout' etc
[01:52] <abentley> That's fair.
[01:52] <lifeless> text construction tends to be part of things like merge, and thats where the artificial VF interface causes roundtrips.
[01:53] <lifeless> text insertion likewise, though we can queue that to avoid round trips more effectively
[01:53] <bartt> Are nested repositories working?
[01:53] <bartt> I don't seem to be able to add a nested repository.
[01:54] <bartt> E.g. bzr add path/to/nested/repository only reports # of ignored files
[01:54] <abentley> lifeless: You are the person who wants to select graph ancestors on a per-file basis, though.
[01:54] <abentley> bartt: You cannot add a tree into another tree.
[01:55] <lifeless> abentley: I don't think I'm the *only* person :).
[01:56] <abentley> Yes, but surely doing VersionedFileGraph.find_unique_lca is the obvious approach.
[01:56] <lifeless> abentley: per file lookups can be grouped though
[01:56] <lifeless> thats the obvious approach, and as long as the repo its being queried on is local it will perform fine
[02:05] <abentley> And at present, the repo being queried is always local.
[02:08] <bartt> abentley: I thought that nested tree support was added in 0.15?
[02:08] <igc> So more reviews today from me starting with abentley's TreeTransform rollback one
[02:08] <abentley> bartt: No, only support code.  It is not complete.
[02:09] <igc> abentley: were you planning to tweak anything following Kuno's feedback or should I review it as is?
[02:09] <bartt> Thanks abentley
[02:10] <abentley> 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] <igc> abentley: I was hoping you'd say that
[02:11] <igc> I'll go ahead and review and ask for that tweak
[02:12] <abentley> Okay.
[02:12] <sandrot> What exactly does a repo with or without "trees" mean? what exactly is a tree?
[02:13] <abentley> Thanks.
[02:13] <lifeless> igc: I'm going to profile commit performance with packs today.
[02:14] <sandrot> erm, what is a tree in the context of a shared repo
[02:15] <igc> lifeless: great. I'll push my latest code this morning in case it's of interest
[02:15] <lifeless> igc: I'm focused on repository interactions immediately.
[02:15] <igc> np
[02:16] <lifeless> I want to see how slow the repo layer is
[02:16] <lifeless> or has to be
[02:16] <lifeless> igc: also, how should we collaborate; I'm working in packs; I can spin off patches for bzr.dev easily.
[02:16] <lifeless> but not for your branch as easily
[02:17] <lifeless> my patches should be small but frequeny. Does this work for you ?
[02:17] <igc> lifeless: I'm still a few days away from using the commit-candidates branch effectively ...
[02:17] <lifeless> righto
[02:18] <poolie> abentley, what igc said about the merge queue goes for me to
[02:18] <igc> I need to get commit changed to incremental vs 'build from scratch' first
[02:18] <poolie> too
[02:18] <abentley> poolie: Glad to hear it.  I think we have the right intentions, it's just a juggling act.
[02:19] <igc> 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] <sandrot> 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 ?
[02:31] <abentley> sandrot: A tree is the directory (and subdirectories) that contain your source code in editable form.  See bzr help working-trees.
[02:32] <sandrot> abentley: thanks, I'm just finding it now actually
[02:32] <sandrot> 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] <sandrot> seems that a working tree is similar to svn's working copy
[02:38] <abentley> 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] <abentley> A lightweight checkout, to be precise.
[02:39] <sandrot> 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] <abentley> 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] <sandrot> push doesn't create a working tree thought right? you can checkout or branch from a pushed location
[02:49] <abentley> When you push to a local location, it creates a working tree, and yes, you can checkout or branch from a pushed location.
[02:52] <abentley> Push always creates a branch, and on local locations, it also creates a working tree.
[02:52] <abentley> creates *or updates* I should say.
[03:06] <ubotu> New bug: #135421 in bzr "different exit code for internal errors" [Wishlist,Triaged]  https://launchpad.net/bugs/135421
[03:19] <abentley> igc: Shouldn't NEWS.html be up somewhere on doc.bazaar-vcs.org?
[03:19] <igc> yes
[03:20] <igc> abentley: it looks like doc.bazaar-vcs.org is yet to be upgraded following the 0.90 release ...
[03:21] <igc> poolie has done this in the past for the RM
[03:21] <igc> I'm pretty sure I have permissions now so I can do it I think
[03:21] <abentley> Do we even have a link to NEWS in the documents?  I tried a few guesses at the URL...
[03:22] <abentley> but it was 404 city, baby.
[03:22] <igc> see http://people.ubuntu.com/~ianc/doc/ for what 0.90 will look like ...
[03:23] <igc> clicking on "Release Notes" takes you to NEWS.html
[03:23] <abentley> Beauty.
[03:23] <abentley> We gotta turn that TOC into a sidebar or something.
[03:24] <abentley> Any progress with getting the pretty version of the docs online?
[03:24] <igc> abentley: see http://people.ubuntu.com/~ianc/pretty_docs/ for the current pretty-docs output as well
[03:24] <igc> by 'current', I mean a snapshot from a week or so back of course
[03:26] <abentley> Sure.
[03:47] <lifeless> spiv: ping - calls?
[04:21] <lifeless> poolie_: I see 3 failures
[04:21] <lifeless> and one of those is due to the failure to isolate CFLAGS
[04:26] <poolie_> lifeless, only 3?
[04:26] <poolie_> hm
[04:26] <poolie_> have you pushed to your knits branch recently?
[04:26] <poolie_>  because that's where i pulled from
[04:26] <lifeless> poolie_: its one commit behind
[04:26] <poolie_> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ right?
[04:27] <lifeless> http://people.ubuntu.com/~robertc/baz2.0/repository is the canonical location
[04:36] <poolie_> lifeless, i'll check that one then
[04:41] <lifeless> one thing that concerns me ian, for commit performance
[04:42] <lifeless> is that we're three times slower than hg, but I'm seeing our gzip time as dominating
[04:42] <lifeless> at 80% of profiled time
[04:52] <abentley> lifeless: Potentially, you want to store uncompressed knit records, and then gzip the whole container.
[04:52] <abentley> Maybe faster, probably better compression.
[04:52] <lifeless> abentley: I'd love to know precisely what git's packing algorithm is
[04:53] <lifeless> I think I'm saying 'there is something wrong' when hg's commit is faster and our time is in gzip
[04:53] <lifeless> not that I disagree with your point
[04:58] <poolie_> lifeless, ok, in that branch i have only 2 failures
[05:08] <tonyyarusso> 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] <jeremyb> istr that bzr's wiki has a really good explanation
[05:16] <jeremyb> i think wikipedia has something too
[05:16] <jeremyb> +comparison for both
[05:18] <jeremyb> http://bazaar-vcs.org/SCMComparisons
[05:19] <jeremyb> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
[05:23] <jeremyb> http://better-scm.berlios.de/
[05:23] <tonyyarusso> jeremyb: Cool, thanks
[05:24] <abentley> tonyyarusso, jeremyb: The better-scm site is pretty useless.  I would avoid it.
[05:24] <jeremyb> hah
[05:25] <jeremyb> not that i would ever consider using MS Visual SourceSafe anyway
[05:25] <abentley> I was unable to convince the author that baz and bazaar are difference VCSes.
[05:25] <jeremyb> heh
[05:26] <abentley> So Bazaar is listed under "Arch", completely inappropriately.
[05:26] <jeremyb> yeah, i see it doesn't have it's own listing in the sidebar
[05:26] <jeremyb> never heard of vesta before
[05:27] <jeremyb> "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] <tonyyarusso> 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] <jeremyb> "CVS is becoming obsolete" yes from some perspectives :)
[05:28] <tonyyarusso> Well, it lacks a number of features listed for other ones, and others (like Subversion) are listed as improvements on it.
[05:28] <jeremyb> git, bazaar, *and* mercurial not or :)
[05:29] <tonyyarusso> I know O'Reilly has a Subversion book - is there a comprehensive guide for Bazaar yet?
[05:30] <jeremyb> tonyyarusso: oh, sorry i misread.  i thought that abentley provided the quote in jest.  i will provide a better answer :)
[05:31] <jeremyb> CVS is becoming obsolete by most standards although is occasianally used for new projects and has some diehard fans
[05:32] <fullermd> 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] <jeremyb> right
[05:35] <jeremyb> 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] <abentley> 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] <jeremyb> abentley: i thought that tonyyarusso's line quoting the site was you talking
[05:37] <jeremyb> superficially bzr, hg, and git all implement the same principles but there are variations
[05:39] <jeremyb> 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] <jeremyb> abentley: how recently did you try to convince him?  the arch page has an almost 2 year old timestamp
[05:43] <abentley> 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] <jeremyb> hah, that site has an empty irc channel
[05:43] <jeremyb> abentley: i was just wondering
[05:47] <jeremyb> 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] <mdmkolbe> 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] <jeremyb> they all can be installed in your home dir
[05:51] <jeremyb> mdmkolbe: what OS?
[05:51] <mdmkolbe> jeremyb: both linux (as non-root) and windows/cygwin (but I administer that system so root isn't such an issue)
[05:52] <jeremyb> hrmm
[05:53] <jeremyb> 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] <jeremyb> mdmkolbe: depends how much time you have.  personally i'd just try them all
[05:54] <jeremyb> on a small scale not for a real project
[05:54] <jeremyb> (i have used git and mercurial a bit not so much bzr)
[05:56] <mdmkolbe> 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.)
[06:08] <AfC> 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] <jeremyb> whoa, git is like cvs?
[06:10] <fullermd> jeremyb: CVS doesn't.  Manual mucking around in the repository does.  Sorta.
[06:10] <jeremyb> fullermd?
[06:10] <jeremyb> doesn't what?  ohh, moves?
[06:10] <fullermd> Yah.
[06:11] <lifeless> fullermd: well it can record moves as well as git can
[06:11] <fullermd> Harsh.
[06:11] <lifeless> food time
[06:13] <jeremyb> 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
[06:13] <fullermd> 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] <mdmkolbe> What repository format does bzr use?  (I ask b/c of the claims in http://keithp.com/blog/Repository_Formats_Matter.html)
[06:14] <AfC> mdmkolbe: a constantly improving one
[06:15] <AfC> mdmkolbe: And I disagree with Keith (who is, incidentally, a good friend of mine); tool usability is what matters.
[06:15] <AfC> 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] <mdmkolbe> 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] <mdmkolbe> AfC: heh, that kind of puts Keith's claims in perspective
[06:16] <AfC> mdmkolbe: we've all read it. Most of the people here are _also_ good friends with Keith.
[06:17] <fullermd> I'm not.  I'm a poor pathetic outsider, clutching at windowsills and begging for scraps of bread.
[06:20] <mdmkolbe> 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] <jeremyb> hg has a built in function to do a binary search for the bug
[06:22] <jeremyb> i don't remember who else has what
[06:22] <mdmkolbe> jeremyb: ?!
[06:22] <jeremyb> all have pretty good history viewing tools
[06:22] <jeremyb> mdmkolbe: ?
[06:22] <jeremyb> mdmkolbe: you know what a binary search is, right?
[06:23] <mdmkolbe> 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] <jeremyb> i've never used it
[06:24] <jeremyb> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension
[06:25] <mdmkolbe> jeremyb: thx for the link
[06:25] <jeremyb> sure
[06:26] <fullermd> darcs is a special case there, since it doesn't do historical context...
[06:26] <jeremyb> darcs drives me nuts!!!
[06:27] <fullermd> I always say, why drive when it's close enough to walk   ;)
[06:35] <jeremyb> who's brian o'sullivan?
[06:36] <jeremyb> something wrong with his repo
[06:36] <jeremyb> or at least the web frontend
[06:36] <jeremyb> http://hg.serpentine.com/mercurial/hg/book/book/convert/book/book/book/book/book/book/book/
[06:37] <fullermd> /bork/bork/bork?
[06:37] <igc> 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] <jeremyb> oh, ooops
[06:38] <jeremyb> brian o'sullivan and that repo are both hg
[06:42] <abentley> Nice guy, though.  Wish he were on our team.
[06:44] <poolie_> mdmkolbe, there is a bazaar bisect extension which might be more to the point
[06:45] <poolie_> there is also iirc 'darcs trackdown' which i think was the first system to have it
[06:45] <lifeless> poolie_: there was an IBM paper on this at LCA 2004
[06:45] <lifeless> describing the technique for tracking down gcc regressions automatically
[06:46] <poolie_> based on cvs
[06:46] <lifeless> yes
[06:46] <poolie_> ok, so darcs may have been the first to generalize and automate it
[06:46] <poolie_> or maybe not
[06:48] <poolie_> lifeless, btw where you wishing for a different behaviour in vim ^O?
[06:48] <poolie_> maybe that was someone else?
[06:49] <lifeless> dunno
[06:51] <poolie_> anyhow, g; takes you to the place you last changed the text
[06:52] <lifeless> yup
[06:52] <fullermd> I usually fake it with undo.
[06:52] <jeremyb> heh
[06:55] <jeremyb> any of ya'll actually work for canonical?
[06:56] <jeremyb> who's mccormickit.com?
[06:58] <mdmkolbe> where is the repo for bzr?  is there a web front-end?  (I mean the repo for the source to bzr)
[06:59] <jeremyb> yes
[06:59] <mdmkolbe> I couldn't find it from the bzr website (maybe I'm just looking in the wrong place)
[07:00] <jeremyb> http://bazaar-vcs.org/bzr/
[07:02] <jeremyb> having trouble finding a frontend hosted by the main project but i see 2 front ends for the main repo
[07:02] <jeremyb> http://codebrowse.launchpad.net/~bzr/bzr/trunk
[07:02] <jeremyb> http://goffredo-baroncelli.homelinux.net/bazaar/bazaar-NG-dev
[07:05] <lifeless> jeremyb: yes, some of us work for canonical
[07:10] <lifeless> https://code.launchpad.net/~bzr/bzr/trunk is the launchpad mirror of bzr.dev
[07:11] <lifeless> http://codebrowse.launchpad.net/~bzr/bzr/trunk
[07:11] <lifeless> is a web ui to browse it
[07:11] <thumper> does bzr diff require a checkout?
[07:12] <jeremyb> haha
[07:12] <jeremyb> thumper: you already have a copy locally.
[07:12] <thumper> jeremyb: no, I don't
[07:12] <thumper> I have a branch
[07:13] <thumper> perhaps I should have said WorkingTree
[07:14] <thumper> lifeless: how come I can't do "bzr diff -r-3..-1" on a branch without a working tree?
[07:14] <spiv> thumper: https://bugs.launchpad.net/bzr/+bug/6700
[07:14] <ubotu> Launchpad bug 6700 in bzr "bzr diff -r 10..20 http://foo" unsupported" [High,Confirmed] 
[07:14] <thumper> spiv: so a working tree is needed?
[07:15] <thumper> arse
[07:27] <lifeless_> 15:20 < lifeless> thumper: patches gratefully arsed
[07:27] <lifeless_> 15:21 < lifeless> igc: ^ remember this bug ? :)
[07:27] <lifeless_> 15:22 < lifeless> ok, thats 9ish hours, I'm calling it a day.
[07:27] <lifeless_> 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
[07:28] <igc> lifeless: yes, haven't forgotten it :-)
[07:29] <thumper> lifeless: :) unfortunately I have other priorities right now
[07:29] <igc> lifeless: yes, an interesting test indeed
[07:30] <igc> 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] <thumper> igc: as long as it isn't forgotten :)
[07:32] <igc> thumper: no risk of that :-)
[08:14] <mdmkolbe> thx all for your help
[09:30] <AfC> Eeek. What does "Not running as bzrlib.plugins.gtk, things may break." mean?
[09:30] <AfC> [bzr 0.90.0, bzr-gtk 0.90.0] 
[09:31] <AfC> ... and indeed, `bzr viz` crashes.
[09:31] <dato> AfC: that the bzr-gtk plugin is not installed in a directory named just "gtk"
[09:32] <AfC> Yes it is... er, no its not. Typo on my part. Shit.
[09:33] <AfC> Called it "bzr" not "gtk". That was stupid...
[09:33] <AfC> (in ~/.bazaar/plugins)
[09:33] <AfC> dato: thanks
[09:33] <dato> np
[10:01] <tolonuga> can anyone edit http://doc.bazaar-vcs.org/bzr.dev/server.htm and replace ":1234" with ":4155"? thanks.
[10:20] <jeremyb> 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] <jeremyb> tolonuga: so, anyone that can checkin there...
[10:24] <tolonuga> 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] <mwhudson> tolonuga: you could send a bundle to the mailing list, that's the usual way for things like this
[10:59] <tolonuga> 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] <fullermd> bundle will spit out a bundle on stdout; you can redirect that into a file, then attach it.
[11:01] <tolonuga> ah, thanks!
[12:39] <markvandenborre> I'm looking into using bzr to manage a few django (web framework) projects I am working on together with a friend
[12:40] <markvandenborre> I would regularly be working offline (on the train)
[12:41] <igc> night all
[12:41] <markvandenborre> up-to-date code would be needed on each of our machines, plus an external webserver
[12:41] <Odd_Bloke> igc: Night!  Thanks for the merges. :)
[12:41] <markvandenborre> what kind of workflow would you recommend?
[12:43] <Odd_Bloke> markvandenborre: You could just use a centralised workflow, because you can commit locally when working offline...
[12:43] <markvandenborre> ok, will be investigating that path
[12:44] <markvandenborre> Odd_Bloke, thx a lot!
[12:44] <Odd_Bloke> markvandenborre: That's not necessarily the only/best one to use though.
[12:44] <Odd_Bloke> But it would work.
[12:44] <markvandenborre> Odd_Bloke, I figured I would really need a feature like local commits because of my long train commutes
[12:45] <markvandenborre> Odd_Bloke, you think that would be the easiest way to get started with bzr?
[12:46] <Odd_Bloke> markvandenborre: If it makes sense in your situation, then do it. :p
[12:46] <markvandenborre> :)
[01:09] <markvandenborre> is it bad policy to setup a central repository for web projects on a production webserver?
[01:10] <markvandenborre> it's not a leaky php server, and only running sshd and apache, but still...
[01:11] <markvandenborre> 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] <markvandenborre> any thoughts?
[01:18] <markvandenborre> would it be better to put the bzr repository on a physically separate machine?
[01:19] <dato> 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] <fullermd> 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] <markvandenborre> fullermd, yes, it is a site policy question... trying to be careful about setting things up with minimal overhead, but still safe
[01:26] <markvandenborre> fullermd, your remark about easy of moving is definitely interesting!
[01:26] <markvandenborre> thx!
[01:26] <fullermd> As a handwavy position statement, I tend to think that if a server gets cracked, the VCS history is probably one of the least interesting things on it...
[01:27] <markvandenborre> you're probably right about that
[01:27] <fullermd> (situations change cases, of course, but as a general rule)
[01:27] <fullermd> I'm all about putting all your eggs in one basket, and watching that basket like a hawk   ;)
[01:27] <markvandenborre> now on a machine without php, with only 80 and 22 open, that might be a sound policy
[01:28] <markvandenborre> you're probably right that I'm too paranoid
[01:29] <fullermd> On the flip side, if there's no particular reason _not_ to have the central repo on the server server, there's also probably no particular reason _to_ have it there.
[01:31] <markvandenborre> fullermd, it's a bit stupid to put up a separate (virtual) machine just for bzr
[01:33] <fullermd> Probably, yeah.
[01:39] <cnus8n> hi, is there any link to a tutorial on setting up a bazaar with webdav?
[01:50] <laga> hey guys. i've just done a "bzr revert" - how can i revert the revert itself?
[01:50] <laga> eg undo it?
[02:04] <markvandenborre> Odd_Bloke, in the situation that I just described (2 developers, web development, frequent offline commits), is there also a comfortable way to do without a central repository?
[02:17] <gabe_> laga: just revert to the most recent commit
[02:17] <gabe_> markvandenborre: you can use push/pull
[02:17] <gabe_> markvandenborre:  i.e. a decentralised system
[02:18] <laga> gabe_: i made a change, reverted said change and now i want to go to the state before the revert
[02:19] <gabe_> if you don't have a commit of that change then you can't
[02:19] <gabe_> unless you manually redo it
[02:22] <siretart> lifeless: are you working on getting bzr 0.90 into gutsy?
[02:25] <markvandenborre> gabe_, thx
[02:26] <laga> gabe_: thanks.
[02:26] <markvandenborre> gabe_, how would I then be able to sync stuff with the other guy when I am at a remote site?
[02:26] <laga> gabe_: lucky me - it was not a crucial change :)
[02:26] <gabe_> markvandenborre: np you can read all about pull push and merge on the documentation part of the bazaar site
[02:32] <gabe_> yer
[02:33] <gabe_> markvandenborre:  to sync stuff with a remote computer you would need access to it via the internet. I personally have ssh setup. In this case you can push or pull bzr repositories using sftp
[02:34] <gabe_> does the other guy have ssh running?
[02:34] <markvandenborre> gabe_, yes, but his provider blocks every port below 1024
[02:34] <gabe_> well either get him to run ssh daemon on a high port
[02:34] <fullermd> Well.  There are two distinct questions here...
[02:35] <gabe_> or try http or the built in bzr server on  a high port
[02:35] <fullermd> One is "do you work centralized [i.e., on a shared branch]  or decentralized [on individual branches you merge back and forth] ".
[02:35] <gabe_> but you would also need port forwarding if he is beind a NAT or firewall
[02:35] <fullermd> The other is "If (b), how do you access each other's branches"
[02:36] <gabe_> markvandenborre: in this case I think it is easiest to have a central server that you can both push or pull from
[02:36] <fullermd> You can go (b) decentralized, with no shared trunk, but still use a central server to reach each other's branches.
[02:36] <gabe_> so he can put his changes on the server and you can pull them to yur comptuer
[02:36] <gabe_> then you don't need to worry about firewall, NAT, and blocked ports
[02:37] <AfC> fullermd: that's more or less what we do
[02:40] <mdmkolbe> In bzr what is the correct way to construct a self contained set of patches to be sent upstream? (e.g. darcs send --output foo.patch-bundle)
[02:41] <dato> mdmkolbe: `bzr send -o foo.patch-bundle` should work
[02:41] <dato> mdmkolbe: if your bzr is a bit old and does not have send, use `bzr bundle >foo.patch`
[02:42] <fullermd> For values of "a bit old" that mean "some ancient version released more than 18 hours ago"...
[02:42] <dato> fullermd: oh, 0.18 didn't have it?
[02:42] <mdmkolbe> data: there is no "bzr send" in my version ... ok bundle-revisions works
[02:42] <mdmkolbe> thx
[02:42] <fullermd> Nah, the send stuff is new in 0.90.
[02:43] <dato> mdmkolbe: it should be smart at guessing what to diff against, but you can specify the location of the branch you branched from as an argument
[02:45] <mdmkolbe> dato: if it guesses wrong will that be detected at patch application time?  (e.g. take A and make branch B from it;  commit a change to B; branch C from B; commit a change to C that depends on changes made in B;  make a patch that should have been between C and A but I did it wrong and it's actually from C to B and try to apply that to A).
[02:48] <dato> mdmkolbe: it will be detected because it will fail to apply. and note that, while "a change to C that depends on changes made in B" makes sense in the darcs world, in bzr if you branch from B, revisions in C will *always* depend on revisions in B even if the changes are in different files
[02:48] <dato> (so it is normally recommended that you branch from A instead of B if you know the changes are independent)
[02:50] <mdmkolbe> dato: thx, the "note that..." part actually helps my understanding of the bzr model quite a lot.
[02:51] <dato> :)
[04:00] <mr_daemon> Hello!
[04:01] <mr_daemon> I just got into bazaar, and I quite like it so far. I might event switch from svn, actually. However I can't get sftp:// or bzr+ssh:// to work with the Windows client... I used the standalone installer...
[04:02] <mr_daemon> This is basically what happens: bzr: ERROR: paramiko.SFTPError: Garbage packet received
[04:03] <bwinton> Can you stfp or ssh in to the same server from your Windows box?
[04:03] <mr_daemon> Yes, it works fine.
[04:03] <mr_daemon> I can checkout, get, pull and push to that server with a Linux or OS X client
[04:03] <bwinton> Did you google "paramiko.SFTPError: Garbage packet received"?
[04:04] <mr_daemon> I must admit I didn't because I just noticed the error above the stack trace as I came on here. So, to google it is.
[04:04] <bwinton> (It looks like it's a bug in the version of Paramiko that ships with the Windows installer...  Which version of bzr are you using again?)
[04:04] <bwinton> https://lists.ubuntu.com/archives/bazaar/2007q2/024210.html
[04:06] <mr_daemon> I'm using stable, which is 0.18
[04:07] <bwinton> Hmm...  (I think that's what I'm using as well, but I might have upgraded to 0.90...)
[04:07] <bwinton> (Oops., coffee time.  Back in a few.)
[04:08] <mr_daemon> Yeah, I'm overdue for a break as well. Thanks for you assistance, too :)
[04:08] <bwinton> My pleasure!  Hopefully someone can help you out a little more...
[04:08] <Lo-lan-do> What's the difference between sftp:// and bzr+ssh://?
[04:09] <Lo-lan-do> (I mean, the user-visible difference, I don't much care about the internals :-)
[04:09] <bwinton> One uses SFTP, the other uses ssh to spawn a bzr process on the remote machine...
[04:09] <fullermd> One uses sftp, the other uses bzr over ssh  ;)
[04:09] <bwinton> Dang.  I dunno, then.
[04:15] <mr_daemon> Well, when I try bzr+ssh the error is a tad more explicit, it prints out the output from the ssh server.
[04:16] <mr_daemon> bzr: ERROR: Generic bzr smart protocol error: bad response ("user@host's password: \r")
[04:17] <Lo-lan-do> Maybe it only works with ssh keys?
[04:17] <Lo-lan-do> (Feel free to ignore me, I haven't touched Windows in years)
[04:17] <mr_daemon> Could be. Let me try, I'll just pop a public key in with putty then try again.
[04:17] <mr_daemon> haha, that's fine. I'm more of a unix guy stuck on windows right now, so I'm just trying to cope.
[04:17] <asabil> hi all
[04:18] <asabil> is there any way to be able to checkout on repositories ? (not branches)
[04:18] <fullermd> No.
[04:19] <asabil> so that it would be possible to checkout the root of the repository and get all the projects (that's what svn users are used to apprently)
[04:19] <asabil> fullermd: what would you suggest then ?
[04:19] <asabil> creating one huge branch ?
[04:20] <Lo-lan-do> Multiple branches linked with the subtree thingy?
[04:21] <asabil> oO, how do you link branches ?
[04:21] <asabil> any doc ?
[04:21] <fullermd> Eek, no...   I suggest managing user expectations.  With a blunt object   ;)
[04:21] <Lo-lan-do> Haha, doc.
[04:21] <fullermd> Well, first I think you finish implementing subtrees...
[04:22] <asabil> ???
[04:22] <dato> asabil: it's easy to write a small script that downloads all existing branches in a repository, and there is already code (in bzrtools) to update all of them with one command.
[04:23] <asabil> ok dato, the thing is just that I have to deal with windows developers, and I need to make it as stupid-proof as possible
[04:23] <asabil> thanks
[04:23] <mr_daemon> Okay I just tried with public/private keypair, and it seems paramiko is ignoring the ssh agent and still asks for a password...
[04:23] <dato> well, then you'd probably want for that small script to be a command in bzrtools, but it does not exist yet.
[04:24] <NamNguyen> does anyone know how bundlebuggy work?
[04:24] <bwinton> abentley does.
[04:24] <NamNguyen> he sure does, but he's not around
[04:25] <NamNguyen> does pqm allow me to review patches before merging them?
[04:26] <NamNguyen> there is so little docs on either of them
[04:28] <bwinton> I believe it does, since people on the bzr list talk about merging patches manually...
[04:29] <NamNguyen> bwinton, i might have made myself unclear but by reviewing i was refering to a similar approach as bundlebuggy
[04:29] <bwinton> For instance...
[04:29] <NamNguyen> i.e. it's gotta be approved before being merged
[04:29] <fullermd> pqm merges when you send it.  You review before that.
[04:29] <mr_daemon> OKAY nevermind me. Actually bzr 0.18 on windows, the self-contained bundle, works with sftp -- but you have to use ssh keypairs.
[04:29] <NamNguyen> that's what i understand from the description
[04:30] <mr_daemon> Somehow the password prompt makes paramiko choke.
[04:30] <NamNguyen> fullermd, do you know if bundlebuggy talks to pqm to initiate the merge after a merge request is approved?
[04:30] <fullermd> AFAIK, bb and pqm don't have anything at all to do with each other.
[04:31] <fullermd> bb just grabs patches off the ML and keeps track of who's voted what on them.
[04:31] <NamNguyen> then how is patch merged?
[04:31] <fullermd> One of the developers mails it to pqm.
[04:31] <NamNguyen> by forwarding?
[04:32] <fullermd> I think most of 'em use a bzr plugin.
[04:32] <fullermd> I don't think you can forward a patch to pqm, you send it a command and a branch location to merge from.
[04:34] <NamNguyen> does that mean 1. the developer merges the patch himself, 2. he publishes that branch, 3. pqm then merges from it?
[04:34] <fullermd> Yah.
[04:34] <NamNguyen> woot, quite some work there
[04:35] <NamNguyen> pqm could have just read a merge directive
[04:35] <fullermd> Well, in much the sense that bzr could have just run server-side hooks via the smart server...
[04:36] <NamNguyen> what kind of hook? i only know about post_commit hook
[04:37] <fullermd> Any hook.  It was an abstract comparison.
[04:37] <NamNguyen> oh, alright
[04:37] <fullermd> Either one is just a SMOP.  Nobody's done the P.
[04:37] <fullermd> (at least, I don't think anyone has)
[04:37] <mr_daemon> Wait -- bazaar has post_commit hooks too? Okay, I'm definitely sold.
[04:38] <NamNguyen> mr_daemon, er, what VCS doesn't have post_commit hook?
[04:38] <NamNguyen> i'm curious
[04:39] <mr_daemon> Well, I was just spoiled by how easy it was to write a post commit hook for subversion.
[04:42] <mr_daemon> But actually -- Darcs doesn't.
[04:42] <mr_daemon> Which was the only other VCS I actually sort-of liked.
[04:42] <mr_daemon> Well, before bzr that is.
[04:43] <Lo-lan-do> Does RCS have hooks? :-)
[04:45] <fullermd> I think RCS _is_ a hook   :p
[04:45] <Lo-lan-do> Good point.
[05:04] <kanhaiya_kk> NamNguyen: hi
[05:05] <kanhaiya_kk> you there ?
[05:08] <kanhaiya_kk> can anybody help me ?
[05:08] <kanhaiya_kk> i ll tell me present status first
[05:08] <bwinton> Maybe.  What's your problem?
[05:08] <kanhaiya_kk> i have checkedout the source on .16 and .17 machine
[05:08] <kanhaiya_kk> same source
[05:09] <kanhaiya_kk> first i edited the test.html file on .16 machine and then on .17
[05:09] <kanhaiya_kk> and then i done commit and update
[05:09] <kanhaiya_kk> first on .16 and then on .17
[05:10] <kanhaiya_kk> while doing on .17 it was giving some errors...due to conflicts.
[05:10] <kanhaiya_kk> so how to resolve such conflicts ? or is there any other method to handle such situation ?
[05:10] <kanhaiya_kk> bwinton: now your turn.
[05:11] <bwinton> Googling for "bzr how to resolve conflicts" gives me the following urls:
[05:11] <bwinton> http://muffinresearch.co.uk/archives/2007/06/05/dealing-with-conflicts-in-bazaar-version-control/
[05:11] <bwinton> http://bazaar-vcs.org/Tutorials/CentralizedWorkflow#id16
[05:11] <kanhaiya_kk> bwinton: okay thank you
[05:11] <bwinton> Are either of those helpful?
[05:11] <kanhaiya_kk> i ll check and get back to you
[05:12] <bwinton> (OOps, that second one should have been http://bazaar-vcs.org/Tutorials/CentralizedWorkflow#merging-changes-back instead...)
[05:14] <kanhaiya_kk> okay wait
[05:18] <kanhaiya_kk> bwinton: that somewhat manual process...
[05:19] <kanhaiya_kk> how can we avoid for conflicts ?
[05:19] <kanhaiya_kk> bwinton: because, if group like us working on same project means, conflicts ll take place every hour.
[05:20] <kanhaiya_kk> so i want to avoid such situations.
[05:21] <dato> kanhaiya_kk: conflicts only arise when two people modify the same line in incompatible ways. that should be less frequent that you paint.
[05:21] <kanhaiya_kk> dato: okay
[05:22] <kanhaiya_kk> if 2 developers edit the same file, but not the same lines, then conflict ll not arise na ?
[05:22] <dato> kanhaiya_kk: no, it won't
[05:23] <kanhaiya_kk> okay good
[05:23] <kanhaiya_kk> i ll test it...wait
[05:30] <bwinton> Cursed IRC client...  Did I miss anything?
[05:30] <dato> 17:23 <kanhaiya_kk> i ll test it...wait
[05:30] <dato> that was the last line
[05:30] <bwinton> 'k.  Cool, thanks!
[05:31] <bwinton> (Say, does anyone know if there's a way to get ubotu to msg me the last n lines?  So that I don't have to ask next time?)
[05:32] <kanhaiya_kk> dato: thanks...it is working fine
[05:57] <ness> Hi, I want to factor out some functions of one source file into a new one. Can I somehow make bzr sorta retain the version history of these functions (for merging)?
[06:02] <bwinton> This is getting kind of tiresome...
[06:25] <mwhudson> so i'm talking about bzr at pyconuk in a couple of weeks
[06:25] <mwhudson> my slides are at http://python.net/crew/mwh/pyconuk07_bzr.pdf
[06:25] <mwhudson> comments welcome :)
[06:29] <james_w> ness: no, sorry that is not possible.
[06:29] <bwinton> mwh: "Bazaar aims to be safe, friendly, free and fast" In that order?
[06:29] <ness> james_w: ok
[06:29] <mwh> bwinton: it's what bazaar-vcs.org _used_ to say on it's front page
[06:30] <NamNguyen> i dont quite get the idea of "aims to be free"
[06:30] <NamNguyen> it's either free, or non-free
[06:30] <bwinton> mwh: On "Working With Others", you might want to mention that push doesn't update the remote server.  i.e. the files won't be there.
[06:32] <mwh> bwinton: hmm
[06:32] <bwinton> mwh: Colour in your pictures would be nice, if its easy to do.  If not, they're fine...
[06:32] <bwinton> (I mention the push-not-update because it bit me when I started, and has bitten at least three other people that I've seen...)
[06:32] <mwh> i was engaged in extreme rushing for a deadline with the pictures, but it got pushed back
[06:32] <NamNguyen> darn, bundle buggy requires procmail
[06:33] <mwh> it would be good to make them a bit prettier, indeed
[06:34] <mwh> i'll mention what push does out loud, i think, i don't want to clutter the file
[06:34] <mwh> file -> slide
[06:34] <bwinton> mwh: Cool.  In the some pictures, should rev B be "B+i" or "B+1", and if it's "B+i", should the "i" be an "n", and should it look more like the server (with the multiple revs stacked)?
[06:34] <mwh> bwinton: heh, the B+i think is a hack because i didn't want to get into talking about how revisions are numbered in bzr
[06:35] <bwinton> Okay, but I think you can sweep it all under the rug, and just call it "B"...  No, wait...
[06:36] <mwh> and perhaps trying to indicate machines on the diagrams is a bit unfair
[06:36] <bwinton> How about A (living on the server), B (on your machine), and C (on his machine)?
[06:36] <mwh> they should probably be branches
[06:36] <bwinton> Then you can have B+1, C+1, B+2...
[06:36] <mwh> bwinton: yeah, that works
[06:36] <bwinton> I think the separate machines are a good idea...
[06:37] <bwinton> It drives home the "You don't need the server" feature.
[06:37] <bwinton> If you could put the other two machines inside a picture of an airplane, that would be cool, but completely excessive.  ;)
[06:38] <mwh> hehe
[06:38] <bwinton> Also, back near the first slide, "Distributed means there is no privileged central location" perhaps should be "Distributed means there doesn't have to be a privileged central location", since in the workflows, you say "Centralized  all data lives on a single server, like Subversion", where there is obviously a (socially-)privileged central location.
[06:40] <bwinton> In "Better Centralization", s/emacs/notepad/ ;)
[06:40] <NfNit|oop> bwinton: but implementation-wise, that central copy is equal to all others.
[06:40] <NfNit|oop> And I think that's the important part.
[06:40] <bwinton> Nf: Kind of, but G*d help you if you release off of the non-central copy...
[06:41] <bwinton> Like I said, it's socially (not technically) privileged.
[06:41] <NfNit|oop> why?   In fact, releasing off of a non-central branch might be a good idea.
[06:41] <NfNit|oop> so your central version can be a "dev".
[06:41] <radix> I agree with bwinton; it's worth pointing out that it's not *necessarily* centralized
[06:41] <NfNit|oop> and your non-central one a "stable".
[06:42] <bwinton> Nf: then I would argue that you've actually gotten the notions of  "central" and "non-central" backwards.  ;)
[06:42] <radix> I have talked with many people who didn't want to go with bzr because they thought they couldn't have a central branch.
[06:42] <bwinton> Nf: It's a terminology issue at that point, I believe.
[06:43] <NfNitLoop> radix: Oh?   Hmm, I guess in that case it does merit pointing that out.
[06:43] <NfNitLoop> But it wasn't log into my reading about bzr that I found the page on workflows and that all got cleared up.
[06:44] <bwinton> mwh: In "Better Centralization", I might change the background colour of "co", and then later on in "Working Distributedly", use a new background colour for "branch", to highlight the major user-level difference between the two...
[06:44] <bwinton> mwh: Basically answer the question "Why do changes stay local in one case, but not the other?".
[06:47] <mwh> bwinton: maybe i should have the centralized workflow use vim and the distributed use emacs :)
[06:47] <mwh> (and then mention that emacs is obviously superior)
[06:48] <james_w> dato: thanks for the quick upload.
[06:48] <bwinton> Heh.  :)  Anyone who can't code in "cat > filename"/"copy con filename" doesn't deserve the label "Programmer".
[06:49] <mwh> bwinton: at a higher level, do you think it's a reasonable selection and ordering of topics?
[06:49] <bwinton> Let me check in a second...
[06:49] <bwinton> I'm almost at the end.
[06:50] <mwh> it's probably too much, it's only a 30 minute talk
[06:51] <bwinton> Maybe not...  People tend to talk fairly quickly...
[06:51] <bwinton> At least, I tend to talk fairly quickly...  :)
[06:53] <bwinton> The pictures are 14 of the slides, and those should go by really fast.
[06:53] <mwh> certainly
[06:53] <mwh> it's 40 slides in keynote
[06:54] <bwinton> If you're running short, you could drop the Launchpad portion.
[06:54] <bwinton> That's odd, it says 49 in the pdf.
[06:55] <bwinton> Actually, why is the Launchpad stuff in there?
[06:56] <mwh> well, partly because my job is working on launchpad/bazaar integration :)
[06:56] <mwh> the reason that the pdf has more pages is that keynote makes a slide per 'build step' of each slide
[06:57] <bwinton> Ahhh...  Makes sense.
[06:59] <bwinton> It seems good to me, if you can fit it all in.  It's hard to say more without knowing the what the audience is going to be like...
[06:59] <dato> james_w: np
[06:59] <mwh> it's the first time this conference has happened, so noone really does :)
[07:00] <bwinton> If it's all people who have seen bzr (i.e. me), you could skip some of the earlier stuff, and concentrate on the launchpad bits.  If it's people who haven't heard of a DVCS, then the earlier stuff would be more useful.
[07:00] <bwinton> Maybe ask at the start, and flip past the appropriate slides, then.
[07:00] <mwh> i think i want the talk to be about 40% advertisement for dvcs, 40% advert for bzr and 20% on launchpad/bzr
[07:00] <mwh> bwinton: yeah
[07:00] <bwinton> So you don't plan on giving it 110%, then?  ;)
[07:01] <mwh> bwinton: i'm not expecting most people to have used a dvcs
[07:02] <bwinton> I wouldn't have either, but there was Linus' talk at Google on Git...  I hear that's been pretty popular...
[07:02] <bwinton> So even if they haven't used a dvcs, they might have heard about them.
[07:02] <gabe_> there some mercurial screencast on google video also
[07:03] <bwinton> Yeah, I saw that one as well...  Bryan O'Sullivan (I think) is a pretty good speaker.
[08:40] <matkor> Hi !. Can I update many working trees at once ? like bzr update this that and/that/dir/too ?
[08:59] <mr_daemon> matkor: Uninteresting trivia, but if you're on unix with bash, you can probably get away with doing this:
[08:59] <mr_daemon> for i in this that and/that/dir/too ; pushd $i && bzr update && popd ; done
[09:31] <matkor> If mr_daemon: I would have to give password each time when using sftp transports
[09:31] <mr_daemon> matkor, That is true, but you could also use private/public keypairs, feed them into ssh-agent beforehand, and enjoy the blissful automated action of this.
[09:32] <mr_daemon> This is clumsy, but the only quick way i could think of =/
[09:33] <matkor> mr_daemon: OK. thank you very much
[09:34] <Lo-lan-do> If all remote repos are on the same host, there's a trick that allows SSH to reuse an existing connection.
[09:34] <Lo-lan-do> ControlMaster or something.
[09:34] <Lo-lan-do> I don't know if it re-asks for passwords, though.
[09:37] <mwh> new version of my slides: http://python.net/crew/mwh/pyconuk07_bzr.pdf
[09:41] <Odd_Bloke> mwh: Ooh, pretty. :)
[09:46] <bwinton> mwh:  I finally figured out what was bugging me with A+i/A+2i...  It seems like he's progressing twice as fast as you are!  What do you think about changing it to A+i and A+i2?
[09:47] <mwh> it's _supposed_ to be an allusion to complex numbers :)
[09:47] <bwinton> Yeah, i kind of got that, but he's still going from i to twice i in the time that it takes me to go from 2 to 3...  :)
[09:47] <bwinton> (It's certainly complex.  ;) )
[09:49] <hstuart> mw, few quick comments: on page 2 it seems odd to add (technically speaking) from slide 2 to slide 3 when there are releaved points below that; p. 33: you can work on a train? perhaps revise to: you can work while travelling?; p. 41: consider different bullets for different levels, e.g. boxes for the second level (also other slides); the quality of your logo is much too low, it'll look severely pixelated when projected
[09:49] <hstuart> mwh, even
[09:49] <hstuart> mwh, also it annoys me that the sans-serif font in your drawings writes 1 as I
[09:49] <mwh> bwinton: i'm ditching the A+i vs A+1 stuff
[09:49] <mwh> it's just confusing
[09:50] <bwinton> That's probably for the best...  What are you going to replace it with?
[09:51] <bwinton> hstuart: I was going to suggest he change "on a train", to "on a plane, train, or automobile", because who doesn't like a good Steve Martin/John Candy movie?
[09:53] <hstuart> heh
[09:53] <bwinton> (With the caveat that if you're the one driving any of the previous, perhaps you shouldn't be coding...)
[09:55] <mw> wrong mw :)
[09:55] <dato> mwh: I think both should read A+1
[09:55] <dato> or s/should/could/ :)
[09:56] <mwh> dato: err
[09:56] <mwh> dato: no thanks :)
[09:56] <dato> well, sooner or later people will have to deal with that
[09:56] <hstuart> mw, I blame tab completion :D
[09:57] <dato> gives you a nice opportunity to say "the revno does not uniqly represent a revision" or something like that
[09:57] <bwinton> That's why I like to go with unique prefixes for my name.  ;)
[09:57] <mwh> new version uploaded
[09:58] <mwh> with the font of just "1" carefully changed on lots of slides :)
[09:58] <mwh> dato: i'd rather write in a mini revid
[09:59] <dato> mwh: your call :)
[09:59] <hstuart> mwh, well, the rest of my concerns are still present in the new version ;)
[09:59] <mwh> hstuart: indeed
[09:59] <mwh> hstuart: i think i respectfully disagree with you on most of them
[10:00] <hstuart> mwh, heh ok, no worries
[10:01] <bwinton> Is the logo actually too low-res?  I figured it'ld just be the SVG version, and so wouldn't matter what resolution it's projected at...
[10:01] <hstuart> bwinton, you can try to zoom in. Looks like an embedded png
[10:01] <bwinton> I guess at 300% I can see the pixels...
[10:01] <mwh> it's a png
[10:02] <mwh> but most projectors are 1024x768 at best
[10:03] <hstuart> *shrug* I might just be overly picky with such things
[10:03] <Lo-lan-do> Hm.  Is this a Bazaar presentation, or just a pretext to plug Launchpad?
[10:04] <bwinton> Lld: A bit of both, I believe...
[10:04] <mwh> i would like to embed the svg, somehow i doubt keynote supports that
[10:04] <bwinton> To quote """[13:00]  mwh: i think i want the talk to be about 40% advertisement for dvcs, 40% advert for bzr and 20% on launchpad/bzr"""
[10:04] <mwh> Lo-lan-do: would "is that a chip i see on your shoulder?" be an overly unfair response to that?
[10:05] <Lo-lan-do> I don't know.  I've heard the idiom, but I have no clue as to what it means, I'm afraid :-)
[10:05] <Lo-lan-do> (Yay for being French)
[10:05] <mwh> Lo-lan-do: of course it's not "just a pretext to plug launchpad"
[10:06] <bwinton> mwh: Would http://www.xml.com/pub/a/2004/01/07/keynote.html be of any use to you?
[10:06] <bwinton> (Hmm, apparently not.)
[10:07] <mwh> bwinton: probably not, and certainly not given that i have another talk to write for the same conference :-)
[10:34] <bwinton> Okay, I'm off.  Have a fun evening, everyone!
[10:59] <Janzert> mwh: very minor (i.e. just ignore me) nit/bug in the talk, pg. 37 first link reads +login but tries to link to +register
[10:59] <mwh> Janzert: thanks
[10:59] <mwh> hooray keynote
[11:10] <lifeless> morning
[11:12] <thumper> morning
[11:26] <abadger1999> abentley: ping
[11:26] <abentley> pong
[11:26] <abadger1999> abentley: We're doing a license audit of Fedora packages and I noticed that trac+bzr doesn't have a GPL version in any of the source files.
[11:27] <abadger1999> Because of the wierd wording of the GPLv2 we're being told to mark that as "any version of the GPL"
[11:27] <abadger1999> Is that what you intend?  Or GPLv2? Or GPLv2+?
[11:28] <abentley> I'm not the sole author of trac+bzr.
[11:28] <abentley> I'd certainly place my code as GPL2+
[11:29] <abadger1999> Yeah... I gather that anyone of you (the authors) can choose the GPL version as it's currently under any version that the receiver of the code chooses.
[11:31] <abadger1999> Would you be upset if I list it as GPL+ (Meaning GPL any version)?  I can certainly do that until someone decides they are authorized to add a version to a source file.
[11:32] <abadger1999> I just like to ping someone about this when I see a COPYING file that's GPLv2 but the lack of version-in-code means we consider it GPL+.
[11:33] <abentley> abadger1999: This means also GPL1, I supposed?
[11:33] <abadger1999> Yeah.
[11:34] <abentley> That would bother me a bit.  Clearly the authors intended 2, and possibly 2+.
[11:34] <abadger1999> Exactly my problem :-(
[11:35] <lifeless> so the issue is this clause
[11:35] <abentley> To me, it is clear that it was intended to be distributed under 2, and any other version is not clear.
[11:35] <lifeless> If the Program does not specify a version number of
[11:35] <lifeless> this License, you may choose any version ever published by the Free Software
[11:36] <lifeless> Foundation.
[11:36] <lifeless> if the readme or *something* does not says 'Version 2 GPL or later, see COPYING for the licence'
[11:36] <lifeless> then that clause makes it the recipients choice.
[11:37] <lifeless> abadger1999: I'd strongly argue that a README or something else is sufficient, not a per-file heading (to satisfy the clause - because the clause talks PROGRAM)
[11:38] <abadger1999> lifeless: Sure.  I'll take that.  Although, license in the source is definitely preferable (as it's unambiguous at that point)
[11:38] <lifeless> abentley: and easy fix is for you set version 2, because you are *an* author, you can just say 'I chose version 2+ for my modifications, which is compatible with the licence'
[11:39] <abentley> We don't have a version specified anywhere that I can tell.
[11:39] <abadger1999> bzr+trac just doesn't have a GPL version anywhere except the COPYING file.
[11:40] <abadger1999> lifeless: +1  That would make the work as a whole GPLv2+ which makes the license clear.
[11:40] <abentley> Okay, I will specify 2+ for my version of trac+bzr.
[11:41] <abentley> Do you want a source code change before you apply that?
[11:41] <abadger1999> abentley: It would be great for the notice to show up in the files I pull from your repo.
[11:44] <poolie> good morning
[11:45] <lifeless> mornink
[11:48] <poolie> lifeless, i'm going to separate out a branch for you that adds to the pack repository the ability to store and get texts by hash
[11:49] <lifeless> poolie: ok
[11:49] <lifeless> I saw some commits in that direction;
[11:49] <poolie> i thought it'd be better to review them separately first
[11:50] <abentley> abadger1999: Okay, revno 181 has GPL 2+ in the README and the main source file.
[11:50] <lifeless> is it the sha of the representation in the repo or the sha of the reconstituted text
[11:50] <poolie> i think it's a good way to try out the splitting even if we don't finally want them addressed that way
[11:50] <lifeless> will they be delta compressed
[11:50] <poolie> lifeless, at the moment they are not compressed
[11:50] <poolie> so they're the same
[11:50] <abadger1999> abentley: Thank you much.  Helps me keep the lawyers happy while doing what I think the developers intend  :-)
[11:50] <poolie> neither dictionary compressed or delta compressed
[11:50] <lifeless> (not because I care about the answers, but I want the interface to be clear about what it is delivering)
[11:50] <poolie> hello abadger
[11:51] <abadger1999> poolie: greetings
[11:51] <lifeless> poolie: I'm doing a knit format bump to make it more flexible and the index optional.
[11:51] <poolie> oh, you're not the badger i thought you were :)
[11:51] <poolie> but hello anyhow
[11:51] <lifeless> hes a badger not b badger :)
[11:52] <poolie> anyhow the interface would be defined as the hash of the reconstituted text
[11:52] <poolie> you may have also seen i was making a base class with some of the repeated code between the two knit formats
[11:52] <lifeless> two knit formats ?
[11:53] <poolie> i mean, two knit-in-pack repository classes
[11:53] <abadger1999> :-)  I was notified that my lawsuit was going well the other day and had to call Texas collect to clarify that I'm a different badger.
[11:53] <lifeless> oh; uhm; I'd rather not do that, because of the unclarity about the subtrees stuff
[11:54] <lifeless> Moving things into PackCollection is how I planned to reduce the duplication
[11:55] <poolie> what unclarity?
[11:56] <lifeless> I believe some of the subtrees policy is expressed by what class; some by attributes, some by code
[11:56] <lifeless> so a base class will bring in multiple inheritance
[11:57] <abentley> abadger1999: So what's the status of trac+bzr?  Is it in fedora already, or in the next release?
[11:58] <abadger1999> abentley: It's in Fedora already.   Let me lookup which versions its built for
[11:59] <abadger1999> abentley: Fedora 6,7, devel (will be 8) and RHEL-5  It's the trac-bazaar-plugin package.
[11:59] <poolie> yes, it did bring in mixin style MI
[12:00] <poolie> i'm not a fan of MI in general but it's better than copy and paste
[12:00] <abentley> abadger1999: So I could say "since Fedora Core 6"?
[12:00] <lifeless> I guess; I worry it will just stick around, what I had hope to achieve was just a few delegated methods
[12:00] <abadger1999> Yep.  That would be accurate.
[12:00] <lifeless> which while technically copy n paste is hardly so
[12:01] <lifeless> what I'd really like to achieve is a single class that can be parameterised by the format to enable/disable subtrees