[00:07] <poolie> igc, do you want to talk about benchmarking some time?
[00:07] <igc> poolie: sure
[00:07] <igc> you call me?
[00:07] <poolie> ok
[00:32] <dysinger> Noob Q : So will bzr rewind my local commits when I rebase and then apply them again?
[00:32] <dysinger> like git ?
[00:35] <dysinger> Er sorry I should RTFM http://bazaar-vcs.org/Rebase
[00:36] <lifeless> dysinger: you can do that if you want yes
[00:36] <dysinger> what RTFM ? :)
[00:36] <lifeless> dysinger: our community rarely uses rebase because its very bad for collaboration
[00:36] <dysinger> Well it's useful when your team uses SVN IMO
[00:37] <lifeless> why?
[00:37] <dysinger> I guess because I have some of the team on SVN and some on DVCS
[00:37] <dysinger> so the we could all just pull from each other except some people are only commiting to SVN
[00:37] <lifeless> I still don't get what rebase does for you; just merge and commit and away you go
[00:37] <lifeless> you don't need rebase for that at all
[00:38] <dysinger> I guess my mind is polluted with git-svn
[00:38] <dysinger> :)
[00:38] <dysinger> BZR will be a fun new (hopefully simpler) experience
[00:38] <lifeless> when someone commits to svn, you 'bzr merge' to get their stuff into your branch
[00:38] <lifeless> when you want to commit to svn, you do 'bzr checkout svn:///' merge and commit
[00:39] <dysinger> Git treats SVN as a whole separate add on side-car which sucks.
[00:39] <lifeless> indeed
[00:39]  * AfC just read the URL about rebase above and *still* doesn't get what it's for. {sigh}
[00:39] <lifeless> it would be extremly hard to do other with gits design
[00:39] <lifeless> AfC: rebase is for folk that care about having a 'pretty revision graph'
[00:39] <AfC> I guess
[00:39] <lifeless> AfC: more than having effective collaboration
[00:40] <dysinger> Well rebase is awesome for things like:  Fore example I am tracking bazaar but I don't have commit access - so I can rebase and re-apply my commits on top of the latest head.
[00:40] <lifeless> dysinger: or you can just merge.
[00:40] <dysinger> ko
[00:40] <dysinger> ok
[00:40] <dysinger> So I guess yeah - why would you have rebase then ?
[00:41] <lifeless> dysinger: your commits are preserved and if you have shared your commits with other people they don't have to resync specially when you merge, like people have to with rebase
[00:41] <lifeless> dysinger: as I say above, rebase is about 'revision graph prettiness'
[00:41] <dysinger> I see
[00:41] <lifeless> some people care intensely about that; for them we have rebase ;)
[00:41] <AfC> lifeless: huh. Thanks. [I'll admit that there some ... concerns ... that I have about the human usefulness of the revision graph as presented by log and viz UIs at present, but it doesn't seem to be a rebase related thing]
[00:41] <dysinger> that would be me
[00:42] <lifeless> rebase can /also/ be used for some internal trickiness related to changing translations between bzr and svn and other such systems, but thats more using the core logic than using the commands
[00:42] <lifeless> dysinger: well, you may find you care less with bzr's log layout :)
[00:43] <dysinger> i am looking forward to playing with it.
[00:44] <dysinger> So the pastable install script for OS - X, BZR 1.1, SVN w/ patch, bzr-svn is different than http://bazaar-vcs.org/BzrForeignBranches/Subversion says to do it.  http://bazaar-vcs.org/BzrForeignBranches/Subversion does NOT work on OS X.
[00:44] <dysinger> Should I put it somewhere for others?
[00:45] <lifeless> dysinger: cool, edit that page and add a version for os X
[00:45] <dysinger> K
[00:50] <Peng> "Bazaar-NG branch format 5" is dirstate, right? Why is it listed as "unnamed" in bzr info?
[00:51] <lifeless> Peng: the format name reporting is bogus, there is a bug on it
[00:51] <lifeless> Peng: format 5 with knits and dirstate is 'dirstate'
[00:51] <lifeless> Peng: format 5 with packs is 'unnamed'
[00:52] <Peng> Ahhh, ok.
[00:52] <Peng> Yeah, I'm using packs.
[00:52] <Peng> Ok.
[00:54] <Peng> Thanks for the explanation. :)
[00:57] <dysinger> ok I updated bzr-svn wiki with the right install info for OS X
[00:59] <dysinger> jelmer thanks for hanging in there - it's working now!  I am off to play with some svn repos
[01:14] <poolie> dysinger, thanks!
[02:11] <dysinger> So who's an expert on light-weight branching?
[02:13] <lifeless> fsvo expert many people
[02:13] <lifeless> just ask :)
[02:17] <dysinger> So I need a plugin? https://launchpad.net/bzr-lightweight-branch
[02:18] <dysinger> I want to checkout from svn once and then branch off that for topics - but I don't want to copy the whole branch everytime - that would be rudundant and huge.  Git does this with the --shared and --references flags.
[02:19] <dysinger> I also heard you can have many branches within the same directory like Git
[02:19] <dysinger> Maybe that would be better
[02:19] <bob2> create a repository (need to use init-repo --rich-root) and branch into that
[02:19] <bob2> er, from svn into that
[02:21] <dysinger> So instead of branching right from svn with bzr branch svn:///..... I do it this way?
[02:21] <bob2> well, you make the repository, then use "bzr branch svn..." to branch into that repository
[02:21] <dysinger> mkdir project ; cd project ; bzr init-repo --rich-root ; bzr branch svn:///some/url ./
[02:21] <bob2> you can't really have multiple branches "within the same directory like Git"
[02:22] <bob2> you can have a repository, which contains branches (each is a dir), and it efficiently shares data between them, so you're not using N times as much space for N branches
[02:23] <bob2> "bzr init-repo --rich-root ~/repository/ ; bzr branch svnL//blah ~/repository/trunk/ ; bzr branch ~/repository/trunk/ ~/repository/the-feature-I-am-working-on"
[02:23] <dysinger> So if I already branched off of svn directly do i have to do it again this way?
[02:24] <bob2> --no-trees is optional for init-repo, and means it does not include checkouts of the branches along with the branches
[02:24] <foom> bob2: sure you can; bzr switch will let you do exactly that.
[02:24] <dysinger> I thought I read you could
[02:24] <bob2> you should be able to branch from the existing checkout into the repository
[02:24] <dysinger> In the bzr vs git page
[02:24] <bob2> foom: that was the next bit
[02:24] <foom> bob2: oh okay. :)
[02:24] <bob2> dysinger: you can, though, quickly switch between branches in a checkout using bzr switch, like foom says
[02:25] <dysinger> that's what I need
[02:25] <dysinger> I don't want new IDE setup on every branch
[02:25] <dysinger> I just want to switch between branches fast.
[02:27] <bob2> that's what I use switch for, works well
[02:27] <lifeless> dysinger: if you already branched from svn into dir FOO
[02:27] <lifeless> dysinger: then this:
[02:27] <lifeless> bzr init --rich-root myrepo
[02:27] <lifeless> bzr branch $FOO myrepo/svntrunk
[02:27] <dysinger> awesome that's what I want then - though I am glad about the light-weight branch-to-another dir option too - I like how flexible bzr is
[02:27] <lifeless> dysinger: will transfer the data into the repo
[02:28] <bob2> not init-repo?
[02:32] <AfC> dysinger: When I started working with bzr, the `bzr switch` command was ... unavailable ... and so we developed an alternate approach to dealing with the "and I sure as hell don't want to have to reconfigure my IDE every time I branch" meme
[02:32] <AfC> dysinger: we have the source code in .../project/mainline .../project/branch1 .../project/branh2, etc
[02:33] <AfC> dysinger: where .../project is created with `bzr init-repository`
[02:33] <lifeless> bob2: oh yeah, I meant to type init-repo
[02:33] <AfC> dysinger: and the first branch was `bzr init mainline`
[02:34] <dysinger> AFC: lemme guess - symlinks?
[02:34] <AfC> dysinger: all subsequent branches were, of course, created with the `bzr branch` aka `bzr clone` command
[02:34] <AfC> dysinger: yes, that's where I'm heading
[02:34] <AfC> dysinger:
[02:34] <dysinger> OK
[02:34] <dysinger> I like the switch option - I'll try that.
[02:34] <AfC> dysinger: then (this is Eclipse, but whatever), in
[02:34] <dysinger> I am using eclipse too
[02:35] <AfC> Eclipse's ~/workspace we have
[02:35] <AfC> ~/workspace/projectname ->.../project/whicheverbranch
[02:35] <dysinger> With eclipse and maven it's easier - mvn eclipse:eclipse can generate project files on the fly then you can import them with the mult-project import plugin.
[02:35] <AfC> and we just move the symlink.
[02:36] <dysinger> ok thanks AfC
[02:36] <AfC> You don't need maven, but whatever.
[02:36] <dysinger> I Do - but that's not related to this.
[02:37] <dysinger> So do I need the --rich-root to work with switch ?
[02:38] <dysinger> Does the lightweight branching occur automatically when you are within a rich root ?
[02:38] <AfC> Also, be aware that `bzr switch` evolved from a different concept that Git's. The Bazaar hackers are working on it, but it wasn't a high priority until recently, and the current implementation is somewhat specific.
[02:39] <abentley> AfC: The switch command is quite similar to its bzrtools incarnation, so a bug report on the data loss you encountered would still be welcome.
[02:39] <dysinger> Heh yeah - I am just coming over from Git so I am wanting that switch thing
[02:40] <lifeless> dysinger: no, lightweight always requires the option
[02:40] <AfC> abentley: did I mention your name? Was a talking to you? Did I say data loss?
[02:40] <lifeless> lol!
[02:40] <dysinger> whoa
[02:41] <abentley> AfC: No, though you hinted at something to do with the bzrtools incarnation.
[02:41] <dysinger> When I branch from svn and then branch again somewhere else (like into a rich repo as suggested above) can I commit back to svn directly?
[02:41] <lifeless> dysinger: yes, just push
[02:41] <abentley> AfC: But in general, I feel free to join in conversations on public fora like IRC.
[02:42] <lifeless> dysinger: or simply bind/do a a checkout from svn (using bzr checkout) again.
[02:42] <lifeless> dysinger: the shared repository will mean that only new data is copied, so it will be nice and fast
[02:42] <AfC> dysinger: for what it's worth, you're getting on into the area where experience will fill in the blanks. Bazaar is *very* powerful, you can trust it implicitly, but it does work a wee bit differently that Git and you'll probably need to work with it a bit before you catch on to the differences.
[02:42] <dysinger> ok
[02:42] <dysinger> Just getting my feet wet today
[02:43] <AfC> dysinger: that's obviously from my own experience, but beware that it doesn't quite do things Gits way. That's neither good nor bad, but if you think in purely Git terms you may beat your head a bit.
[02:43] <AfC> dysinger: yeah, so just try stuff a bit.
[02:43] <dysinger> Is the --lightweight plugin needed to do light-weight branching ? You guys didn't mention it above but it's on the plugin page.
[02:43] <AfC> dysinger: even creating a full branch or two for a moment to try stuff (including commits and merges) lthen throwing them away won't cost you anything.
[02:44] <lifeless> dysinger: no
[02:44] <lifeless> dysinger: I have no idea about that plugin
[02:44]  * AfC watches another new user flail with the question of what the heck is "lightweight"
[02:44] <dysinger> AfC - I have already done that - I have pushed and pulled and merged like nuts over the last week.  Today I just got bzr-svn working and now I want to use it for real.
[02:45] <AfC> dysinger: sweet.
[02:45] <AfC> dysinger: guess what I'm saying is that you can keep at the experimentation for sure (at least on the Bazaar side)
[02:45] <AfC> dysinger: and if you have access to create dummy repos on the svn side you're really set
[02:45] <dysinger> But "for real" means checking out a real very large svn project.  I didn't want to copy it everytime I made a branch.
[02:45] <lifeless> dysinger: you don't have to; init-repo and you're done
[02:46] <AfC> The other guys will want to know: how large is large?
[02:46] <AfC> [The Bazaar hackers, of which I am not one, are especially interested in Bazaar performance and usability on huge projects]
[02:46] <dysinger> It's probably not large by your guys standards sorry.  Only about 5000 commits but it's about 500MB
[02:47] <AfC> The svn repo is 500MB, a clean checkout is 500MB, or the release tarball is 500MB?
[02:47] <lifeless> spiv/abentley if you feel like doing a review SearchResult would love one
[02:47] <abentley> Sorry, I have to go rock out.
[02:48] <spiv> lifeless: ok, I'll take a look sometime this afternoon
[02:48] <lifeless> abentley: enjoy!
[02:49] <lifeless> spiv: thanks; I have fetch converted to use SearchResult now
[02:49] <lifeless> making sure all tests pass and that branch will go up; then onto hpss integration
[02:49] <foom> AfC: unfortunately it's still really bad. :P
[02:50] <foom> but at least it's gone from really *really* bad to only really bad. :)
[02:50] <AfC> foom: progress! :)
[02:51] <AfC> Abstractly, I wonder where the break point is. Number of revisions? Size of repository? Size of code:revision ratio?
[02:52] <spiv> lifeless: sweet
[02:52] <lifeless> dysinger: the lightweight /branching/ plugin gives you 'partial history'; its reduces the data the repository stores rather than having no repository (which is what lightweight checkouts do)
[02:53] <foom> from my understanding, the current speed issues are related to loading the index, which I guess is related to number of revisions
[02:53] <lifeless> dysinger: erm, no I'm wrong
[02:53] <foom> but I don't actually know, all I know is that it's still pretty slow. :)
[02:53] <lifeless> dysinger: its the same as 'bzr cbranch' which is a bzrtools plugin, AFAICT
[02:53] <foom> (for a 60krev repo)
[02:53] <lifeless> foom: speed issues in what operations?
[02:54] <foom> say, log.
[02:54] <lifeless> thats due to log doing a global sort on the revisions
[02:55] <AfC> (ie, where does Bazaar go from being a wonderful experience to choking? I imagine that most people working on or evaluating Bazaar, except possibly lifeless, haven't seen the cumulative effect of a marginal one-more-wafer-thin revision; most try to import some huge 20 year old project and something isn't cool and so they give up)
[02:55] <lifeless> and yes index speed matters there; the current indices are good at partial loads but not so hot at full loads
[02:55] <dysinger> Sorry guys - all / most of this is already plain as day over in http://doc.bazaar-vcs.org/latest/en/user-guide/index.html - you guys should tell me to RTFM ! :)
[02:55] <lifeless> dysinger: we're a friendly lot :]
[02:57] <lifeless> 50% done no failures
[03:18]  * AfC goes for coffee. dysinger, I hope bzr goes well for you. Good luck.
[03:19] <lifeless> patch sent
[03:27] <lifeless> spiv: ping
[03:27] <lifeless> spiv: what is the current verb for 'pull revisions' that I should be replacing ?
[03:29] <lifeless> spiv: and why are there two verbs for it ? SmartServerRepositoryStreamKnitDataForRevisions
[03:30] <spiv> lifeless: there's two, because one buffers everything, and the other sends the response in chunks
[03:30] <lifeless> I see two for the same request object
[03:31] <spiv> Oh, ugh, I see.
[03:31] <spiv> I wonder how that happened...
[03:31] <lifeless> Repository.stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions and  Repository.chunked_stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions
[03:31] <lifeless> I iz confused
[03:32] <spiv> stream_knit_data_for_revisions is the original, buffering one.
[03:32] <lifeless> ok
[03:32] <lifeless> is there one that is not in a release yet ?
[03:32] <spiv> stream_revisions_chunked is the right verb for the better, chunking one.
[03:34] <lifeless> spiv: is stream_revisions_chunked in 1.1 ?
[03:34] <spiv> chunked_stream_knit_data_for_revisions should not exist.
[03:34] <spiv> stream_revisions_chunked has not been in a release.
[03:34] <spiv> (and neither has chunked_stream_knit_data_for_revisions, thankfully)
[03:34] <lifeless> k
[03:34] <lifeless> I'll delete one and alter the other
[03:34] <spiv> lifeless: thanks
[03:34] <spiv> lifeless: and thanks for spotting it!
[03:40] <pattern> can bazaar version symbolic links?
[03:40] <Manfre> how do I tell bzr to use an SSH key while doing bzr push bzr+ssh?
[03:45] <pattern> looks like bazaar can version symbolic links  :)
[03:45] <pattern> aya
[03:45] <pattern> yay even :)
[03:45] <bob2> Manfre: just does it for me
[03:46] <Manfre> i'm on windows
[03:46] <bob2> ah, dunno then
[03:47] <bob2> http://bazaar-vcs.org/Bzr_and_SSH
[03:53] <Manfre> thanks
[03:56] <Manfre> cool...it's working
[04:05] <Manfre> i successfully pushed a branch up to launchpad
[04:12] <lifeless> spiv: I'm running more and more into 'RemoteRepository has duplicate code cause its not a subclass'
[04:42] <lostylost> Hey, does anyone know if there would be compatibility issues commiting to a remote repo with bzr1 from a local bzr1.1 client?
[04:43] <lifeless> lostylost: there should not be, but we recommend that bzr servers run the latest release for best performance
[04:43] <lostylost> that makes sense
[04:43] <lostylost> I have had a few errors with bzr lately and it's getting me nervous
[04:44] <spiv> lostylost: what sort of errors?
[04:45] <lostylost> I lost a complete revision, I think due to my rashness. I was committing locally to a repo. When I tried to commit it said to update, so I did. It gave an error message.
[04:45] <lostylost> I can't recall exactly what it said
[04:45] <spiv> lostylost: your ~/.bzr.log may still have the error in it
[04:46] <lostylost> something about to check the .bzr/checkout/pending-deletes
[04:46] <lostylost> anyway, it said to delete the ones in there, I foolishly manually deleted them thinking everything would still be in the repo
[04:46] <lostylost> somehow I lost a whole revision
[04:47] <lostylost> Check the bzr log hey
[04:47] <lostylost> I would like to understand what happened for next time
[04:49] <lostylost> all that was in the directory was files with numerical names...
[04:54] <lifeless> lostylost: if you ever have to look inside .bzr there is a bug of some sort; ask a question here or on launchpad
[04:54] <lostylost> cheers
[04:55] <lostylost> ImmortalPendingDeletion: Unable to delete transform temporary directory D:/invoice/trunk/.bzr/checkout/pending-deletion.  Please examine D:/invoice/trunk/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.
[04:55] <lostylost> that is the error message I got
[04:56] <lostylost> I just deleted all the stuff in there, thinking it was "temporary" working directory stuff
[04:56] <lifeless> its things that are to be deleted
[04:56] <lifeless> during the application of a merge/update/pull
[04:56] <lostylost> so if I actually deleted them they wouldn't have been then?
[04:56] <lostylost> ?
[04:57] <lostylost> or are they all moved there temporarily?
[04:57] <lostylost> hrmm
[04:57] <lostylost> just the actual working tree files?
[04:57] <bob2> how do files end up there rather than just conflicting?
[04:57] <lostylost> how come a whole local commit disappeared, along with it's message?
[04:58] <lostylost> I shouldn't have been so rash, damn it :(
[04:59] <lostylost> bob2: it was an "ERROR:"
[05:00] <lifeless> lostylost: the update should have left your local commit as a pending merge
[05:00] <lifeless> lostylost: the bug that caused the update to fail probably left the tree unupdated; the commit is still in your repository
[05:00] <lostylost> I don't see it by running bzr log --forward
[05:01] <lostylost> I have only 19, should be 20
[05:01] <lifeless> lostylost: if you install the bzr heads plugin, you can do 'bzr heads' to find it
[05:01] <lostylost> thank you!
[05:01] <lostylost> hope yet
[05:02] <Solarion> so, when you merge, you merge into the working directory?
[05:02] <Solarion> you can't merge up?
[05:02] <bob2> merge doesn't commit, so no
[05:03] <Solarion> merge doesn't commit?
[05:03] <bob2> merge merges changes into your working tree
[05:03] <lifeless> merge generates a tree with the combination of two existing commits
[05:03] <lifeless> this gives you the ability to review what you are merging
[05:04] <lifeless> and then do 'bzr commit' to save it
[05:05] <Solarion> right
[05:05] <Solarion> that makes sense.
[05:05] <Solarion> I really like that the log has all of the previous logs in it.
[05:06] <bob2> do git hg etc do the nested log thing?
[05:06] <Solarion> no idea
[05:06] <Solarion> I found bzr and it was tasty crack, so here I am.
[05:08] <lifeless> bob2: hg doesn't
[05:08] <lifeless> bob2: AFAIR git doesn't
[05:08] <Solarion> how does one manage a remote bzr branch?
[05:09] <Solarion> (without logging in, cd'ing to the dir, and then running commands there)
[05:10] <Solarion> in fact, I'm now doing the 3-branch interface between svn and bzr so that I can stay sane and keep my collaborator happy.  :)
[05:10] <bob2> push to it and/or checking it out and commiting to it
[05:10] <Solarion> :(
[05:10] <lifeless> Solarion: define manage
[05:11] <Solarion> lifeless: I have 2 branches (+ the one in SVN)--a working branch and the trunk.  Trunk is kept synchronized with the svn repo and merges in changes from the working branch, but otherwise I don't really directly access it.
[05:12] <Solarion> lifeless: the two branches are on my server, so that I can keep synchronized between workstation and laptop (and whatever else).
[05:13] <lostylost> no luck with bzr heads
[05:13] <lifeless> lostylost: you get only one head ?
[05:14] <lostylost> no I was jumping the gun
[05:14] <Solarion> lifeless: I can bzr push/pull to/from the working branch from my workstation to keep it up to date.  However, it seems that I have to be in (a branch of) the trunk branch or (a branch of) the working branch to sync between them, or to sync to/from the svn server.
[05:14] <lostylost> I think I am inluck
[05:14] <lostylost> bzr head --all shows it
[05:14] <lostylost> sweet
[05:14] <Solarion> lifeless: Thus, I either have to pull a copy of whatever branch I'm actively working on, do the changes, and push it up, or else ssh in to the server to do the operations.
[05:15] <Solarion> lifeless: Ideally, I'd like to just, say, run bzr --root=sftp://server/path operation
[05:15] <lostylost> ok so it's in there, how do  retrieve it?  it says it's a (dead) revision?
[05:15] <lifeless> lostylost: bzr merge . -r revid:THEREVISIONID
[05:16] <Solarion> lifeless: in which case, instead of looking at the current directory, bzr acts like sftp://server/path is the current working directory (or root of the branch)
[05:16] <lostylost> thank you very much lifeless, your a godsend
[05:16] <lifeless> Solarion: we don't generally do working tree operations over teh network because things like 'stat' are really not reliable, and they are needed
[05:17] <lifeless> Solarion: why don't you just have both branches on your laptop and work there
[05:17] <Solarion> lifeless: I have a workstation I work on about the same amount of the time
[05:17] <lifeless> Solarion: then whenever you feel like it bzr push to the server (e.g. when you are about to switch to another machine)
[05:17] <Solarion> I suppose that'll work
[05:17] <Solarion> still, I like the --root option idea better.  :)
[05:18] <lifeless> what I'd do is different
[05:18] <Solarion> Also, I'd like a pony.
[05:18] <Solarion> bzr --pony
[05:18] <lifeless> I'd just work on the laptop and workstation as separate branches
[05:19] <lifeless> 60% tests passed, looks like this patch is done
[05:19] <Solarion> lifeless: still not help when I need to sync the changes over to trunk.
[05:19] <Solarion> I like "micro-checkins" as my boss calls it, while he likes larger changes.
[05:20] <Solarion> having trunk helps put all of my little changes into one big one.  Keeps both of us happy.  :)
[05:20] <lifeless> Solarion: sure; so have a checkout of trunk on both laptop and workstation
[05:20] <lifeless> Solarion: then you just merge to that checkout and 'bzr commit'
[05:20] <Solarion> lifeless: then I'd have to care about keeping them synchronized.
[05:20] <lifeless> Solarion: no, bzr will manage that for you
[05:21] <Solarion> The management of it that I've seen thus far from bzr consists of telling me I need to merge the changes manually.  :(
[05:21] <lifeless> checkouts won't commit if the master is newer than the local tree; just like 'svn'
[05:21] <Solarion> anyhow, ssh'ing over to the server isn't a big deal; it's just annoying
[05:21] <lifeless> so you'll get 'cannot commit, run bzr update' if you haven't run bzr update before merging, but thats all
[05:22] <Solarion> lifeless: unless your changes + their changes require a manual merge
[05:22] <lifeless> 'bzr checkout's workflow really is designed for 'trunk' situations
[05:22] <Solarion> conflict
[05:22] <lifeless> Solarion: then you'll get a tree you can resolve the conflict it, and when you do that and ocmmit it will be all synced
[05:22] <Solarion> yeah, I ran checkout for a while, but it took a while whenever I wanted to commit.
[05:23] <Solarion> lifeless: I'd rather just not have to deal with keeping multiple branches in sync and ssh to the server.
[05:23] <lifeless> Solarion: ah, interesting
[05:23] <Solarion> or, use the --root option (in combination with --pony)  :)
[05:23] <Solarion> trunk is really just for combining commits so my boss is happy.
[05:24] <Solarion> the less annoying it is, the better
[05:24] <Solarion> though keeping multiple branches in sync is still less annoying than having to use svn
[05:26] <Solarion> interesting.  pushing the merged changes just kept my overall message, not the sub-messages.
[05:26] <Solarion> (according to svn log)
[05:27] <codeslinger> hi, pardon me for barging in. New user, quick question.   I cant get the authentication.conf file to work.  have read and re-read the docs till my eyeballs are spiing but just dont get what the problem is. can somebody please give me a hint.
[05:28] <codeslinger> Im am trying to set up automatice password so I dont have to keep typing it.  everything else is working far as I can tell
[05:28] <lifeless> Solarion: thats svn's failure to track merges AIUI
[05:29] <Solarion> svn seems to fail quite a bit
[05:29] <lifeless> Solarion: yes :)
[05:29] <Solarion> ah well, I can put it somewhere where it'll be found in the next merge.
[05:29] <Solarion> lifeless: thanks for the help, but it is bedtime for bonzo
[05:29]  * Solarion heads to bed
[05:30] <lifeless> codeslinger: I have no idea sorry; I haven't used that feature
[05:30] <dysinger> hmm I was all excited to use bzr-svn today.   However after trying it - it's unusable slow.  Am I doing something wrong?  I branched from svn.  I did a "lightweight" checkout which took a couple of minutes.  I open a file a put one line of whitespace in and committed locally.  Then I did a push parent.   It's been going 5 minutes now with 4 [05:31] <lifeless> dysinger: there is a first time startup cost which is pretty high AIUI
[05:31] <codeslinger> how many megs of files??   speed is good for me with about 40megs of files.
[05:31] <dysinger> I put one line of whitespace in a file and made a commit comment - then I am trying to get that back into sv.
[05:31] <dysinger> svn.
[05:31] <lifeless> dysinger: so you're pushing to svn:// ? from bzr?
[05:31] <dysinger> It's been twirling for 5 minutes now.
[05:32] <foom> dysinger: the first time you do "anything" it loads a bunch of stuff into a cache
[05:32] <codeslinger> lifeless -- are you saying that you type the password after every command???  or just run everything local?   I find the password prompt tedious real fast.
[05:32] <dysinger> trying to push that one commit up
[05:32] <lifeless> dysinger: like I say though, AIUI there is a first time cost where it maps a bunch of data
[05:32] <lifeless> codeslinger: I use ssh with ssh-agent
[05:32] <dysinger> didn't it map that on the way when I branched it?
[05:32] <foom> probably not since you did a lightweight branch
[05:33] <dysinger> No the test commit to svn I did on the branch I took from svn
[05:33] <lifeless> dysinger: I've seen jelmer explain this to other people;
[05:33] <lifeless> dysinger: if you allow it to finish and try again I understand it to be much much faster
[05:33] <dysinger> I branched my trunk svn project with bzr-svn, made one line of whitespace and then tried to push that back to svn
[05:33] <dysinger> lifeless - ok
[05:33] <codeslinger> lifeless -- ssh-agent -- oh, okay, I see a vague reference to it, but did not yet find/read that section.    if that works well then I guess I better give it a shot
[05:33] <foom> btw, is your home directory on a local disk?
[05:33] <dysinger> It's taken forever so it's scared me.
[05:34] <dysinger> It's never taken this long with file:// or sftp://
[05:34] <foom> i ran into the issue where it was taking *extra* forever due to it putting the cache on NFS.
[05:38] <codeslinger> could be the speed issue is related to the hybyrd interface to svn.  I create a clean repository from scratch and was satisfied with the speed.  its not a mamoth project, but it's not lightweight either.
[05:38] <dysinger> I am hoping this is just some one time cost.
[05:39] <dysinger> it's been committing my one line of whitespace for 10 minutes now.  It's churning through things like it's evaluating all 5000 commits 1st though
[05:39] <foom> it is
[05:39] <codeslinger> does anybody else have any ideas about authentication.conf ???   is there a trick to getting it to work???  maybe its a bug???
[05:43] <lifeless> spiv: ping
[05:43] <lifeless> spiv: I'd like a quick chat
[05:49] <lostylost> thanks again lifesaver
[05:49] <lostylost> lifeless
[05:49] <lifeless> lostylost: np
[05:50] <dysinger> How do I manipulate the "parent" branch - say I branched and then the parent is gone now.
[05:50] <poolie> dysinger, i believe it's set by pull --remember
[05:51] <poolie> um
[05:51] <poolie> there might be a more direct way?
[05:53] <dysinger> So let me ask another question - is there some benefit to setting up a rich root and the branching a svn repository into it a subdirectory vs just branching a svn directory somewhere else?  When I do a bzr info on both of them the both say rich-root type.
[05:53] <dysinger> "as a subdirectory"
[05:54] <codeslinger> lifeless -- Im trying to find the docs for ssh agent.  the manual refers to it in several places.  but nowhere do  I find a section on setting it up???
[05:55] <dysinger> I don't see the benefit of the creating a bzr init-repo --rich-root repostitory and then going into that directory and bzr branch http://my/svn/repo
[05:55] <dysinger> I can just  bzr branch http://my/svn/repo directly
[05:55] <dysinger> both ways I can checkout --lightweight from it.
[05:56] <dysinger> maybe I am missing something.
[05:56] <foom> you can have a heavyweight checkout for "free" inside the repo
[05:56] <foom> instead of just a lightweight one
[05:56] <dysinger> oh you mean I don't have to specify the --lightweight ?
[05:57] <foom> not only don't you have to specify it, you get all the revision data immediately there
[05:58] <codeslinger> from reading the manual, it says that the main advantage of the repro is when you have multiple branches.   Lightweight is basically for when you want just the files and nothing else.  for instance the example give is that you are publishing to a website.  otherwise heavywieght is usually what you want.
[05:59] <codeslinger> when you have multiple branches the shared repro is able to avoid duplication.  if you only have one branch you won't see any savings.
[06:00] <codeslinger> question: I have multiple projects that use some of the same files.  I can keep all of these shared files in their own directory.  what is the best way to share them amoung multiple unrelated projects?
[06:01] <Peng> You'd put them in another branch, and include them with subtrees (something akin to svn:externals). Unfortunately, that's not exactly supported yet. :P
[06:02] <Peng> s/include them/include that branch/
[06:04] <dysinger> ok Let's take the case of using a subversion "trunk" repository as the parent:  If I create a shared repo and then branch svn trunk into it as "trunk" and then I have another branch from svn called "branch-x" that I clone and then I branch locally from trunk.  You are saying that the shared repository is aware of the commits so that it doesn't duplicate data ?
[06:04] <codeslinger> its not clear to me how to do subtrees, but some of what Ive read cause me to think that it is still being developed.
[06:04] <bob2> dysinger: for branches within the repository, yes
[06:05] <dysinger> ok I see the benefit then.  Thanks.
[06:06] <dysinger> So I am going to create a shared repo with bzr init-repo --rich-root myrepo then branch a remote svn "trunk" and remote "branch-x" into the repo.  THen I can go into the repo and "checkout trunk my-topic" and make commits to that.
[06:06] <Peng> codeslinger: Yeah, subtrees are experimental.
[06:07] <bob2> well, "branch trunk my-topic"
[06:07] <dysinger> checkout is not recommended?
[06:07] <codeslinger> ok, thanks, I will avoid that for now.   any ideas where I can find the docs to config ssh agent?
[06:07] <dysinger> branch would give me a clone
[06:07] <dysinger> right?
[06:08] <bob2> well, you'd need to make a my-topic a branch in the repository, then check that out
[06:08] <codeslinger> yes, branch is a connected clone
[06:09] <dysinger> That would make 3 layers there - 1 branch svn, 1 more branch "my-topic" and then one checkout?
[06:09] <lifeless> dysinger: checkout is recomment just fine
[06:09] <bob2> three steps, yes
[06:09] <dysinger> I don't see the benefit ...  In git I clone, then branch, work, commit, merge, push etc.  Then delete the branch and move on.
[06:10] <codeslinger> the checkout is your working set of files where you make you changes. the svn branch would be your base
[06:10] <dysinger> Couldn't I just branch from svn and then branch off that for topics, commit and then push  ?
[06:10] <bob2> you can
[06:11] <dysinger> oh codeslinger says I _can_ checkout off the svn branch
[06:11]  * dysinger needs to learn the diff between branch and checkout.
[06:11] <Silktrader> Hello.
[06:11] <bob2> yes, using a repository is just an organisational/efficiency thing
[06:11] <bob2> sorry if I confused you by suggesting it
[06:11] <dysinger> It's fine - I am drinking from the firehose
[06:11] <dysinger> :)
[06:12] <dysinger> No better way to drink if you ask me.  -  just get it over with
[06:12] <Silktrader> I had a glance at Bazaar's container formats, and I see dirstate and knit ...
[06:12] <Silktrader> Is there a way to have plain files stored?
[06:12] <Peng> Silktrader: Plain files? What do you mean? Why?
[06:13] <Silktrader> I am using bzr to track changes on Word documents.
[06:13] <Silktrader> Though I would like to index them.
[06:13] <Silktrader> So I can search within those.
[06:13] <Silktrader> Right now bzr stores revisions as .packs.
[06:13] <Peng> For a mirrored bzr branch on Launchpad, would bzr+http be better than http? Does "bzr pull" or whatever LP uses perform better in some way with bzr+http?
[06:13] <dysinger> When you guys checkout from svn - I am sure some of you do in here - just to deal with other projects that use svn.  When you do that do you checkout the repository root or do you checkout individual branches, trunk and tags ?
[06:14] <Peng> FWIW, 99% of the time, LP will find no new changes.
[06:14] <Peng> Silktrader: Why do you want to index the repository instead of the working tree?
[06:14] <Silktrader> Because I may delete content from the working tree.
[06:15] <Silktrader> I have document X, which I edit and commit.
[06:15] <Silktrader> Then I reedit document X, take off stuff, recommit.
[06:15] <dysinger> Sorry to ask so many questions - I promise to help out with other noobs when I get done.
[06:15] <Silktrader> I would like to be able to search through what has been deleted, for instance.
[06:15] <Silktrader> That is - through old revisions.
[06:15] <Peng> Silktrader: Ooh, that's pretty neat.
[06:16] <bob2> dysinger: latter, doing the former on big svn repositories would be huge
[06:16] <foom> checking out the repository root is a good way to use up your whole hard drive. :)
[06:16] <dysinger> OK so you make a shared bzr repo and then checkout trunk and checkout branch-a etc.
[06:16] <codeslinger> dysinger -- okay, say you start out with the svn in the shared repository.  you leave that prestine as your base.  then you make a branch in the repository and that becomes your target for any changes.  these both are living on the server.   now you do a branch on your local computer from the branch that you made of the svn.  this thrid branch is your working set, where you make your changes.  when you do a checkout you are connecting your 
[06:16] <codeslinger> branch to the servers branch such that any commits are made immediatly to the server as well as local.  this is refered to as lock-step mode and is probably closest to how you are used to working with svn.   but you do not actually have to do a checkout, you can skip that process and work with the local branch in dristubited mode.
[06:16] <Peng> Silktrader: Anyway, bzr currently does not have a format that stores a bunch of plain files. That would be horribly inefficient.
[06:16] <Peng> Silktrader: You could always develop one if you wanted to . . . :D
[06:17] <Silktrader> Peng: I understand. But given small repos ... space efficiency is not so important, is it.
[06:17] <foom> Peng: you'd be surprised: some VCSes only store full files, no diffs.
[06:17] <Peng> Silktrader: True.
[06:17] <bob2> Peng: hardlinking identical files...
[06:17] <foom> Peng: "hard disk space is cheap" is the theory
[06:17] <bob2> you could call it a "revision library"
[06:17] <Silktrader> Foom: which ones?
[06:18] <Peng> foom: What, svn working copies (ughhh, that was a bad design decision) and git? With git, you're supposed to pack occasionally.
[06:18] <foom> Silktrader: accurev is one
[06:18] <Silktrader> Proprietary, right?
[06:18] <foom> yes
[06:18] <bob2> doesn't svn gzip pristines now?
[06:19] <Silktrader> Gzip is already decent ...
[06:19] <foom> not in the last released version...dunno about the next version
[06:19] <Silktrader> As content can be easily indexed within archives.
[06:19] <dysinger> codeslinger - If I didn't want to go that complex and keep it distributed like git - I could just create a shared repo, branch svn there and then branch again from that - commit, commit and then push back to svn.  Correct?
[06:22] <codeslinger> I dunno....  but frankly I'd be pretty nervous about it.  plenty of opportunity for bugs to byte yea in the interface/conversions to/from svn
[06:23] <dysinger> really?  so bzr-svn isn't ready for prime-time?  I have to work with others that aren't on bzr - they are on svn.
[06:23] <codeslinger> did you figure out how to get it to not ask you for a pasword?
[06:23] <dysinger> y
[06:24] <codeslinger> whats the secret???   to the password?  I've been thrashing it for a couple of hours now with no luck.
[06:24] <dysinger> I mean I would be all for fully distrubuted mode with git or bzr for me team but I have to get them to take baby-steps
[06:24] <dysinger> I just cloned (branched) from subverison with http://myuser:mypassword:server/repo
[06:25] <dysinger> I mean http://myuser:mypassword@server/repo
[06:25] <dysinger> http basic style
[06:25] <codeslinger> awww  thats too simple :-)    thanks.
[06:25] <dysinger> Maybe it doesn't remember my password though - I need to use it more to make sure.
[06:26] <dysinger> It does at least keep the username - I can see that in the bzr info
[06:26] <lifeless> foom: disk space is cheap; disk cache is not
[06:27] <lifeless> Silktrader: I suggest you index by writing a small amount of glue for your indexer
[06:27] <lifeless> Silktrader: so that it can extract all the historical versions during initial indexing
[06:28] <foom> lifeless: yeah but who ever accesses old revisions, anyways!
[06:28] <codeslinger> as fro svn, I'm a bzr noob.  I only know what Ive read in the docs so far.   but my overall impression is that bzr is still a little young.  plus just general experience says that a hybyrd interface is asking for trouble.  I'd be very conservative if I was you, last thing you need happening is corruypting either of the stores.  won't make a good impression on your team.
[06:28] <Silktrader> I do, foom. Very often.
[06:28] <Silktrader> Perhaps not when writing software.
[06:29] <Silktrader> lifeless: thanks, but can't code a plugin for the indexer ...
[06:29] <Silktrader> ... I'd rather use the filesystem and that's it.
[06:29] <lifeless> Silktrader: write it in fuse then :)
[06:29] <lifeless> Silktrader: but that said, sounds like the indexer is pretty primitive
[06:29] <Silktrader> Come on, write a fuse plugin to deal with that? :-)
[06:29] <lifeless> Silktrader: sure; expose the historical trees over fuse
[06:29] <Silktrader> Lucene, Google Search, etc.
[06:29] <foom> hey now, a fuse plugin for bzr would be nifty
[06:29] <Silktrader> They can't deal with bzr's packs.
[06:30] <foom> someone was just telling me the other day how awesome it was in ClearCase how you could just use normal unix utilities to navigate history
[06:30] <lifeless> Silktrader: they wouldn't need do; you can generate any flat namespace you like;
[06:30] <lifeless> foom: yah; I wrote a fuse plugin using pyfuse and pybaz
[06:31] <Silktrader> lifeless: It's great to be spurred to write code ... but I don't have the time nor the skill to :-)
[06:32] <Silktrader> Besides ...
[06:32] <Silktrader> I work on Windows machines ...
[06:32] <Silktrader> So no fuse I suppose.
[06:32] <codeslinger> there is a reference in the manual with pointers to an article about using word revision tracking in conjunction with bzr
[06:32] <foom> there's fuse for windows now I believe
[06:32] <Silktrader> codeslinger: searching, thanks.
[06:34] <Silktrader> codeslinger: I see a DocDiff plugin.
[06:34] <codeslinger> that could be it, I didn't read it since I dont need it.   be careful of word revisions though they are not that reliable.
[06:35] <Silktrader> They suck.
[06:35] <Silktrader> Both Word and OO.
[06:37] <codeslinger> it's hard to do it right, the complexities of the documents is huge.  I don't know what OO's track record is for revisions, but I have a lot of experience with word revisions and know that they are not something you would want to use with complex docs, as long as you stick to text with no tables or art objects you should be fine.
[06:37] <lifeless> with oo you can get diffs from bzr, using bzr to track the revisions
[06:38] <codeslinger> that sounds great.  I was guessing/hoping that OO had done it better.
[06:39] <Silktrader> lifeless: Yes. I assume OO's format is also more portable than MS.
[06:39] <Silktrader> But it still doesn't solve the searching issue ...
[06:39] <Silktrader> I should probably be looking for DMS.
[06:39] <Silktrader> Document Management Systems ...
[06:39] <Silktrader> But bzr is so simple and easy ...
[06:40] <Silktrader> Software like Alfresco and whatnot puts me off.
[06:40] <codeslinger> well, good luck.  I gotta get back to my bzr slugfest.
[06:45] <lifeless> spiv: ping
[06:45] <spiv> pong
[06:45] <lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/smart/client.py", line 77, in call_with_body_bytes_expecting_body
[06:45] <lifeless>     request = self.get_smart_medium().get_request()
[06:45] <lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/smart/client.py", line 33, in get_smart_medium
[06:45] <lifeless>     return self._shared_connection.connection
[06:45] <lifeless> AttributeError: 'FakeMedium' object has no attribute 'connection'
[06:46] <lifeless> and I'm seeing an error about read_streamed_body
[06:47] <spiv> Hmm.
[06:47] <lifeless> so I was pinging you about the fake medium error
[06:47] <lifeless> where is the voodoo to fit that in
[06:48] <spiv> lifeless: See FakeClient
[06:49] <lifeless> the second one comes from
[06:49] <lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/repository.py", line 832, in insert_data_stream
[06:49] <lifeless>     for item_key, bytes in stream:
[06:49] <lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/remote.py", line 996, in _deserialise_stream
[06:49] <spiv> lifeless: I think you want to override call_with_body_bytes_expecting_body in that.
[06:49] <lifeless>     stream = protocol.read_streamed_body()
[06:49] <lifeless> AttributeError: 'SmartClientRequestProtocolOne' object has no attribute 'read_streamed_body'
[06:49] <lifeless> ah
[06:49] <Silktrader> Well fellows, thanks for the help. Have a good day, cheers.
[06:49] <spiv> The second error is correct, in that there is intentionally no read_streamed_body on SmartClientRequestProtocolOne.  It's implemented only on SmartClientRequestProtocolOne
[06:50] <spiv> Er,
[06:50] <spiv> It's implemented only on SmartClientRequestProtocol*Two*
[06:50] <lifeless> err, ROTFL> L> L>
[06:51] <spiv> A laugh with a stutter?
[06:51] <lifeless> yah
[06:51] <lifeless> so why am I getting the old protocol?
[06:51] <spiv> You'll have to demonstrate that one in person for me sometime ;)
[06:51] <spiv> Good question.
[06:51] <lifeless> laugh repeatedly tailing off a little slowly
[06:52] <lifeless> ok, first one fixed
[06:52] <spiv> Can you give me a little more context?
[06:52] <lifeless> yes
[06:52] <lifeless> I'm testing a modified streaming revisions pull
[06:52] <lifeless> that I upload a body to
[06:53] <lifeless> that contains start_keys\nstop_keys\ncount
[06:57] <lifeless> I'll defer this till tomorrow now, too many hours working :)
[07:00] <spiv> lifeless: that's odd
[07:00] <spiv> lifeless: I don't know why you'd get a ProtocolOne there
[07:01] <lifeless> oh
[07:01] <lifeless> callwithbodybytes
[07:01] <lifeless> uses One not Two
[07:01] <lifeless> is it safe to change that ?
[07:01] <Peng> Cool, with dirstate-tags, pulling with no new revisions only downloads the format files and last-revision.
[07:01] <spiv> Oh, huh.
[07:01] <Peng> Oh, and tags.
[07:02] <Peng> With bzr+http, it still makes 24 requests.
[07:02] <spiv> lifeless: I guess so, it seems wrong that it's hard-coded either way in that class though.
[07:02] <Peng> Same as when there is 1 new revision.
[07:02] <spiv> lifeless: but it should at least be hard-coded consistently :)
[07:02] <lifeless> spiv: righto, well I'll change it in the new method I add
[07:02] <lifeless> spiv: and let you worry about consistency
[07:02] <lifeless> :)
[07:03] <spiv> lifeless: sounds good :)
[07:03] <lifeless> woo passes
[07:03]  * lifeless runs a full suite and organises food
[07:07] <Peng> Ooh! I upgraded all of my local branches recently but forgot about my remote ones!
[07:07] <Peng> Err, wait, I don't know.
[07:08] <Peng> Right, I don't want to upgrade that branch.
[07:08] <Peng> Apparently on one project still using dirstate, some of my remote branches are dirstate and some are dirstate-tags.
[07:09] <Peng> I guess it depends on whether they were created before or after I upgraded my local stuff to packs.
[07:16] <abentley> bob2: revision library?  For shame!
[07:19] <poolie> ok, out for a bit
[07:19] <poolie> good night, abentley, or morning
[07:20] <abentley> poolie: good night
[07:43] <dysinger> What does --rich-root really do ?  the help doesn't really explain it and the online manual doesn't mention it.
[07:44] <lifeless> it adds a versioned / to the disk format
[07:44] <lifeless> which is needed to handle svn branches as they are made via copies
[07:45] <dysinger> ok don't quite get that but ok
[07:45] <lifeless> it will eventually be the default format
[07:45] <dysinger> the manual just says bzr init-repo X-repo (without the rich-root).
[07:46] <dysinger> ok cause when I do a branch from a svn repo it does the rich-root by default - I can see it in the info
[07:47] <dysinger> Is the --no-trees usually used with checkout ?  And is checkout mostly used with the centralized workflow only?
[07:47] <dysinger> that seems to be the pattern in the examples in the manual
[07:48] <fullermd> dysinger: It Depends(tm)   :)
[07:48] <dysinger> heh
[07:49] <lifeless> checkout is most often a tool for centralised workflows
[07:49] <dysinger> I am just trying to figure out the best setup for working with a team that mostly uses svn.  I could init-repo and "checkout" the remote svn repo and then make branches off of that for work.  Or I could "branch" the svn repo and then make branches off of that for work.
[07:50] <lifeless> --no-trees in init-repo is used when you expect to have your working areas elsewhere yes
[07:50] <dysinger> lifeless gotcha
[07:50] <lifeless> dysinger: so there are two dimensions here
[07:50] <lifeless> 1) init-repo or not
[07:50] <lifeless> 2) checkouts or branches
[07:50] <fullermd> Well, you _can_ do it either way, or probably a dozen others.  If it were me, *I* would make a checkout of the svn branch, then branch off that.
[07:50] <dysinger> OK so --no-trees would be like git clone --bare
[07:50] <dysinger> It's for history only then.
[07:50] <dysinger> no work
[07:50] <lifeless> init-repo is *simply* for sharing .bzr/repository amongst many branches
[07:51] <fullermd> That way I could use that checkout just like it were a svn checkout; update, commit, etc.
[07:51] <lifeless> thats all
[07:51] <dysinger> checkout would be if I wanted a tracking branch
[07:51] <fullermd> And it wouldn't let me commit and diverge from upstream.
[07:51] <lifeless> so you can init-repo, then branch into the repo, and make branches from that etc
[07:51] <dysinger> where commits are immediate.
[07:51] <fullermd> Then I could merge ; commit into it when I wanted to land my other branches.
[07:51] <lifeless> or you can init-repo, and use checkouts, its all reasonable
[07:51] <fullermd> (or just edit ; commit directly in it if I just wanted to make one rev right on trunk, like if I were just using svn itself)
[07:52] <dysinger> ok I am getting it.
[07:52] <fullermd> Right.  That checkout would then explicitly always be "whatever's in svn [mod getting behind and having to 'update' of course]"
[07:52] <dysinger> There's some parallels to git (and some to svn)
[07:52] <lifeless> rule of thumb is 'if your history is large, or you will have many branches, you should use init-repo'
[07:54] <dysinger> What is --rich-root-pack all about?
[07:54] <dysinger> Does it make a diff vs --rich-root  really ?
[07:55] <fullermd> --rich-root is a variant of knits (the older repo format).  --rich-root-pack is a variant of packs (the newer repo format)
[07:56] <dysinger> should I go with the newer one? Is that where everything is headed ?  I read how you guys are using packs to speed up transfers.
[07:56] <ubotu> New bug: #183704 in bzr "bzr clean-tree should not remove .shelve directory" [Undecided,New] https://launchpad.net/bugs/183704
[07:56] <fullermd> Well, packs ARE intended to replace knits.  It's the direction we're going.  There are some reasons to use knits; compatibility with older versions of bzr, for instance.
[07:56] <fullermd> But lacking those reasons, you probably want packs.
[07:57] <dysinger> ok I have no other bzr interaction on my project
[07:57] <dysinger> (no older versions)
[07:57] <fullermd> packs are the default now, if you just 'bzr init'.
[07:57] <dysinger> oh really
[07:58] <dysinger> so I could just bzr init-repo myrepo ?
[07:58] <fullermd> Yeah, as of 1.0 [I think].  They were introduced on 0.92.
[07:58] <fullermd> Well, not if you want to use bzr-svn   ;)
[07:58] <fullermd> It needs the rich-root variant.
[07:58] <fullermd> (which isn't default)
[07:58] <dysinger> oh ok so if I want to branch off of svn I MUST use the knits format
[07:59] <fullermd> No, you need to use a rich-root capable format.  There's one of those for knits AND one for packs.
[07:59] <fullermd> --rich-root is the knit version; --rich-root-pack is the pack version.
[07:59] <dysinger> ok
[07:59] <fullermd> Unless you know a reason you want to go knit, you probably want the pack.
[08:00] <fullermd> (if the choice turns out to be wrong later, there are ways to convert yourself down, so it's not a lock-in decision)
[08:00] <fullermd> rich-root is, though, which is the main reason it's not default; you can convert data from packs into knits, (or from rich-packs into rich-knits), but you can't convert from rich to non-rich.
[08:03] <dysinger> so just so I am understanding - in order to use svn I must use a rich _variant_ which is either rich-root or rich-root-pack - either one.  Packs are the default bet are not rich right?
[08:03] <dysinger> s/bet/but
[08:03] <fullermd> Right.
[08:04] <dysinger> so I could bzr init-repo --rich-root-pack myrepo and the branch svn off into it
[08:04] <fullermd> Bingo.
[08:05] <dysinger> ok thanks for your help
[08:05] <dysinger> I am getting it.
[08:05] <dysinger> I promise I'll help others once I do
[08:05] <lifeless> you want rich-root-pack
[08:06] <dysinger> someone told be just rich-root earlier
[08:06] <dysinger> but I want to go with the newest format
[08:06] <dysinger> if I have no legacy to deal with
[08:06] <lifeless> yeah I forgot there were two variants
[08:06] <fullermd> Yeah, that might just be a finger-o; thinking 'rich root' and forgetting to append the pack.
[08:07] <dysinger> can you branch off of a  checkout ?
[08:07] <fullermd> Yep.
[08:08] <dysinger> I could see an advantage of checkout for svn and the branch off of that for work.
[08:08] <dysinger> I don't know - maybe not.
[08:08] <fullermd> I'd do it that way.
[08:08] <fullermd> That way the thing that directly touches svn acts like an svn client would; helps reduce impedance mismatches.
[08:08] <dysinger> y
[08:09] <dysinger> Especially for me - I wouldn't use that checkout for anything other than tracking the remote branch
[08:09] <dysinger> and merging into my topic branches
[08:09] <fullermd> Really, I also work that way on multi-dev bzr projects; there's a shared trunk that I checkout.  I do trivial things directly on trunk, just like I did with CVS.  And branch off that for more involved things.
[08:15] <dysinger> If make a branch and then want to push back to the parent - what's the best way to do that
[08:15] <dysinger> I can re-specify the parent in the push command but that seems a bit redundant
[08:16] <fullermd> Well, with this toplogy you wouldn't push back; you'd merge your topic branch _into_ the checkout, then commit that merge (and the commit in the checkout goes upstream)
[08:16] <dysinger> ok
[08:16] <dysinger> so it's done with merges
[08:16] <fullermd> Sorta a hierarchial setup, rather than the mesh-like setup of more 'fully distributed' workflows.
[08:17] <fullermd> Well, you _can_ do it with pushes.  But that gets you back to impedance mismatches with svn, and (IMAO, anyway) is more likely to lead to confusion.
[08:18] <dysinger> don't want to do that
[08:18] <dysinger> (mismatches)
[08:18] <dysinger> I'll just keep it straight checkout and merge/commit into it.
[08:18] <dysinger> from my branches.
[08:18] <fullermd> Yeah.  This way you have the svn side, which acts like svn.  You have your bzr side, where you do whatever you want, bzr-style.  And all interaction between them funnels through your bzr-svn checkout.
[08:19] <dysinger> excellent
[08:19] <fullermd> Seems cleaner to me  [note, though, that I've never used bzr-svn, so this is all "how it fits in my head" and from reading about other people using it]
[08:19] <dysinger> and if I want I can take one my branches and 'push' it off to a 3rd machine where I can share it with team mates distributed-style.
[08:20] <fullermd> Right.  No problemo.  You can get all wild and wooly on the bzr side.
[08:20] <dysinger> that's how I did all this with git so it makes sense
[08:20] <dysinger> git/svn
[08:21] <dysinger> I really like how bzr doesn't treat svn like a side-car-add-on
[08:21] <dysinger> It's just a transport/storage plugin
[08:21] <dysinger> git-svn is a one-off-hack
[08:21] <fullermd> That's because we don't trust svn way off to the side, where we can't smack it   ;)
[08:22] <dysinger> and the commands are different than the normal git flo
[08:22] <dysinger> flow
[08:22] <dysinger> It's sucky
[08:22] <dysinger> (but fast)
[08:23] <dysinger> I was in a svn working directory and I accedentally typed bzr st
[08:23] <dysinger> and it told me the status
[08:24] <dysinger> I was like ???
[08:24] <dysinger> so then I commit with bzr too and it worked !?
[08:24] <dysinger> that's too transparent
[08:24] <fullermd> Heh.
[08:25] <dysinger> bzr log worked - it was like it was a bzr repo
[08:25] <dysinger> then I was looking at bzr init-repo help
[08:25] <dysinger> and it has --subversion in it
[08:25] <dysinger> so bzr-svn is pretty integrated.
[08:26] <sabdfl> if you have a branch, with a few files added, and you want to split that into two branches which add different sets of files, can you do that easily with bzr?
[08:26]  * dysinger is a noob
[08:26] <fullermd> sabdfl: Mmm.  I think you'd have to sort of the files manually.  Maybe "branch ; merge --uncommitted", the rm the right files on each side?
[08:27] <dysinger> I imagine you could always make two branches from the one
[08:27] <dysinger> and just prune away until you had it like you like
[08:27] <sabdfl> fullermd: i'm worried that rm'ing the files on each side would mean the whole lot get rm'd when these land in trunk
[08:27] <fullermd> Well, I'm reading you as "bzr add'd but not committed".
[08:28] <fullermd> If they're committed files you want to rm, then yeah, that would happen.
[08:28] <dysinger> since bzr doesn't auto-commit merges though
[08:28] <fullermd> In that case, I think you'd have to backtrack to before they were added, and recreate history from that point onward in two different branches.
[08:28] <dysinger> you could merge the two branches back in
[08:28] <dysinger> but revert the removes
[08:29] <dysinger> and then commit
[08:29] <fullermd> Well, or that.  And if you edit the files in the branch you don't delete them in, it'll conflict and you can resolve it from there.
[08:29] <fullermd> That means adding to your work at merge-time.  I guess which is Right depends on how long they'll be unlanded, and how much history you'd have to rewind, and yada yada.
[09:01]  * igc dinner
[09:30] <lifeless> sabdfl: split the branch into two, delete on each side. then merge each side to the other with the following recipe:
[09:30] <lifeless> bzr OTHER; revert .; commit -m 'sync with split branch'
[09:31] <lifeless> the . is important
[09:31] <fullermd> Twisted.
[09:31] <lifeless> then you'll have two branches which think they are mutually merged (but aren't), so merging with trunk will do the right thing (well, you can test this, its late, but my head says this will work)
[09:31] <lifeless> ciao
[09:32] <lifeless> perhaps test locally first; merging both serially to a copy of trunk :)
[09:49] <sabdfl> lifeless: bummer, i started doing this the hard way, and will just finish
[09:49] <sabdfl> but have a note of the recipe and will try it next time
[09:49] <sabdfl> thanks!
[10:05] <rjek> Gah!  I hate Mac OS X.
[10:06] <rjek> I can't install bzr on it from MacPorts, because it can't fetch paramiko from any of the places it knows about.
[10:06]  * rjek wonders why Fink went out of fashion.
[11:15] <rjek> So.  Is bzr available for Mac OS X 10.4 using a package management system that actually works? :)
[11:48] <dysinger> rjek:  I just posted some instructions on the bzr-svn page about 6 hours ago which includes bzr install
[11:48] <dysinger> without macports or fink
[11:49] <dysinger> btw I think the #bzr channel peoples are soooo... awesome
[11:49] <dysinger> and the bzr developers
[11:49] <dysinger> it worsk
[11:49] <Kamping_Kaiser> is the correct capitalisation Bzr bzr or BZR?
[11:49] <dysinger> works
[11:50] <dysinger> I think it's actually bZr
[11:50] <Kamping_Kaiser> >,<
[11:50] <dysinger> :)
[11:50] <Kamping_Kaiser> :P
[11:55] <dato> Kamping_Kaiser: the correct capitalization of the software is Bazaar, and the correct capitalization of the binary is bzr
[11:55] <dato> if you'd like to use bzr to mean "Bazaar", then, well, write "bzr" :-)
[11:56] <Kamping_Kaiser> dato, so its Bazaar? (not Bazaar-ng or any of the short versions?)
[11:57] <dato> Kamping_Kaiser: yeah, Bazaar, but many people use bzr as well. Like Subversion/svn or Mercurial/hg
[11:58] <Kamping_Kaiser> dato, thanks for that
[11:58] <dato> you're welcome
[12:03] <rjek> dysinger: Sounds fun.  URL?
[12:06] <dysinger> http://bazaar-vcs.org/BzrForeignBranches/Subversion
[12:12] <rjek> dysinger: Which version is Leopard?
[12:12] <rjek> I have 10.4
[12:12] <dysinger> 10.5 is leopard but it should work all the same IMO
[12:13] <rjek> Does 10.4 ship with a version of Python that isn't too ancient?
[12:13] <dysinger> I don't know that for a fact though
[12:13] <rjek> (which I had assumed is the reason bzr is packaged more simply for 10.5 than for 10.4)
[12:13] <dysinger> open a terminal
[12:13] <rjek> What is this easy_install thing, too?
[12:14] <rjek> I have Python 2.3.5, btw.
[12:14] <dysinger> http://peak.telecommunity.com/DevCenter/EasyInstall
[12:15] <rjek> ta
[12:19] <rjek> dysinger: It appears to be doing something \o/
[12:20] <rjek> Although it appears to be having the same difficulty as MacPorts: it can't reach www.log.net to download paramiko.
[12:21] <dysinger> Should upgrade to 10.5 then! :)
[12:21] <rjek> This Mac's lucky I've not thrown it out of the window.
[12:21] <rjek> I *hate* Mac OS.
[12:22] <dysinger> Then erase it and install something better
[12:22] <rjek> Not an option, given the entire point of the exercise it to ensure something works under Mac OS :)
[12:22] <rjek> I'd be furious if I actually paid for this Mac.
[12:23] <dysinger> Something does work
[12:23] <dysinger> As I experienced today
[12:23] <dysinger> What is your pref?
[12:23] <rjek> No, I mean I'm making sure a piece of our software's portable to it.
[12:23] <dysinger> Is the hardware garbage?  That's rarely the case
[12:24] <rjek> I hate Apple hardware almost as much as I hate their OS.
[12:24] <dysinger> Oh are you a M$fanboy?
[12:24] <rjek> No
[12:24] <dysinger> Then BSD ? Linux?
[12:24] <rjek> But I can tolerate Windows for longer periods than I can Mac OS: it still ultimately annoys me.
[12:24] <rjek> All OSes annoy me: Mac OS is just top of the pile.
[12:24] <dysinger> Wow.
[12:25] <rjek> dysinger: My development environment is Linux.  Where I build Linux and Windows versions of stuff.  Mac OS stuff I have to do self-hosted given there's no good toolchain like MinGW for Linux yet.
[12:26] <dysinger> Winblows is the top of my shit pile.  That's an absolute crap-pile.
[12:27] <dysinger> rjex "I hate Apple hardware almost as much as I hate their OS."  Wow
[12:28] <dysinger> What on this green earth do you actually like?
[12:29] <rjek> I like my Thinkpad.
[12:30] <rjek> It's built like a tank, doesn't have keylegends that wear off if you look at them too much, has three mouse buttons, and wasn't over-priced.
[12:30] <dysinger> With what freedos?
[12:31] <rjek> Erm.  Ubuntu as it happens, but you've left now.
[12:32] <fullermd> I think freenode logs you off if you say 'freedos'.
[12:32] <rjek> heh
[12:33] <rjek> fullermd: Didn't kick you off. :)
[12:33] <fullermd> I'm special.  My mother always told me so.
[12:33]  * rjek grins.
[12:34]  * rjek checks out the source on Linux box, burns it onto a CD-R, and shoves it in the Mac that way.
[12:35] <fullermd> Do regular CD-R's work in a Mac, or do you have to get special multi-colored aerodynamic CD-R's?
[12:35] <rjek> Crap, I hadn't thought of that.
[12:35] <rjek> It might spit it out in disgust for being a cheap Tesco CD-R.
[14:33] <codeslinger> hi, anybody awake?
[14:33] <matkor> codeslinger: Yes, but I most likely will not be much help ;)
[14:34] <dato> abentley: I'm sorry for the format flags mess
[14:34] <abentley> No worries.
[14:34] <codeslinger> Great!!!    question:  I don't see this in the manual.  is the physical location of a branch fixed or can I arbitrarily move it to another location?
[14:34] <abentley> I could have read it more carefully, too.
[14:35] <abentley> codeslinger: You can move it anywhere you like, even mirror it to another machine.
[14:36] <codeslinger> cool!!!!!
[14:36] <abentley> If you a shared repository, you have to keep the branch inside the shared repository.
[14:36] <matkor> abentley: Even outside shared repository ?
[14:36] <abentley> matkor: ^^^
[14:37] <codeslinger> what if I move the repository too.  basically I just want to know about disk reorg and moving the entire structure, does it have any fixed path components?
[14:38] <abentley> codeslinger: If you remove the repository too, that's fine.
[14:38] <codeslinger> good. thanks.
[14:39] <abentley> Many commands remember the location you ran it against last, e.g. "pull".  Those locations tend to be fixed locations.
[14:40] <codeslinger> bind ????
[14:40] <abentley> Yes, I believe bind is one of those.
[14:40] <codeslinger> er, let me be clear.  can I fix that path with bind?
[14:40] <abentley> Yes.
[14:41] <codeslinger> great.
[14:41] <abentley> If you have a checkout, and you move the branch you're bound to, you can just do 'bind'.
[14:41] <brilliantnut> abentley: Actually, I think this is one of the problems that I'm facing.. If I have a branch or checkout bound to a shared repository. If the shared repository is no longer accessible, I can't unbind it...
[14:41] <abentley> Similarly, you can fix pull with pull --remember.
[14:41] <brilliantnut> neither was I able to bind to a different location..
[14:42] <abentley> brilliantnut: Try switch --force then, but file a bug report please.
[14:43] <abentley> But you mean "If I have a branch bound to *a branch in a shared repository*...", right?
[14:43] <abentley> Branches aren't "bound" to repositories themselves.
[14:45] <radix> why does 'unbind' even bother doing anything with the remote branch instead of just removing the association locally, out of curiosity?
[14:45] <brilliantnut> right.
[14:46] <brilliantnut> abentley: I did in fact mean a branch in a shared repository.
[14:46] <brilliantnut> atleast, I was facing that behaviour with 1.1rc1... I haven't had an opportunity to check since 1.1 ... To be honest, I thought it was expected behaviour..
[14:46] <abentley> Right, so if you have a heavyweight checkout of that branch, and you delete that checkout, "unbind" should work.  If it doesn't, it's a bug.
[14:47] <abentley> Scratch that.
[14:47] <brilliantnut> I did have a heavyweight checkout... but what do you mean by delete that checkout?
[14:47] <abentley> If you have a heavyweight checkout of that branch, and you delete that branch, "unbind" should work.  If it doesn't, it's a bug.
[14:47] <abentley> brilliantnut: thinko
[14:47] <brilliantnut> no, what if the repository isn't accessible any longer.
[14:47] <abentley> The repository for the branch?
[14:47] <brilliantnut> yeah.
[14:48] <brilliantnut> abentley: need to take a call, brb
[14:48] <abentley> Most of the information provided through a branch is stored in the repository, not the branch.
[14:48] <abentley> Everything you commit goes into the repository, not the branch.
[14:48] <abentley> The branch is just a pointer to the data you committed.
[14:49] <abentley> So if there's no repository for a branch, it cannot function.
[15:00] <codeslinger> I have a project with multiple (mostly) independant parts.  there is a client program and a public website and then the private website after you login and then the admin web site etc.  some fo the php programs are shared between all of the apps. some are only shared between the web apps.  but most files are not shared at all.  what would be the ~best~ way to organize this?
[15:03] <codeslinger> "if there is no repository for a branch it connot function"   but what if it's a heavyweight checkout?  doesn't the branch contain it's own copy of the repository?
[15:07] <brilliantnut> abentley: back. Here's the situation that I was facing:
[15:07] <brilliantnut> I have a central repository, and many branches on the central repository (specifically including a branch called HEAD)
[15:07] <brilliantnut> I have a heavy checkout of HEAD on local
[15:08] <brilliantnut> commits, pulls, pushes, merges etc. work fine.
[15:08] <brilliantnut> now the repository, (along with all the branches) is down.
[15:08] <brilliantnut> lets say that the location has been changed.
[15:09] <abentley> codeslinger: If the heavyweight checkout is created inside a shared repository, it will store data in the shared repository.
[15:09] <brilliantnut> at this point, I want to bind the checkout that I have to the new location..
[15:11] <abentley> brilliantnut: So bind NEWLOCATION ought to work.
[15:12] <abentley> No need to unbind.
[15:12] <abentley> But switch --force NEWLOCATION should also work.
[15:17] <brilliantnut> hmm. I didn't try --force
[15:17] <abentley> Switch ideally would not require force.
[15:17] <abentley> And it should at least suggest it on NotBranchError
[15:18] <abentley> Something I'd like to fix, but I've got a big queue right now...
[15:24] <codeslinger> thanks for all the help.   any suggestions on best practices for dealing with the situation of shared files between different projects?  I understand the subtrees are NYI
[15:33] <codeslinger> Error 1 Operation not permitted --  I have a respoitory on a server and a local branch.  the server-side was created initially by doing a push of a local branch.  what I did is to set up a conflict with another copy of the branch and then resolve that conflict and commit the changes. then I did a merge.   Now when I do a push -- which used to work -- I get the Error.   any odeas what I am doing wrong?
[15:34] <codeslinger> abentley are you still there?
[15:35] <rjek> He's abended!
[15:36] <abentley> codeslinger: Not off the top of my head.  Sounds like a permissions problem on the server.
[15:37] <abentley> You can get a full traceback by doing "push -Derror"
[15:38] <abentley> rjek: Unfortunately, I can't just idle in IRC.
[15:39] <abentley> I have work to do.
[15:41] <codeslinger> ok, fine, thanks, I understand....    I dont think it liked that I changed the path though....   I went back to the orgianl path and now I get  bzr: ERROR: Generic path error:  'zzzzz.fetch': Failure: unable to rename '../packs/zzzz.pack'
[15:46] <fullermd> Sounds permission-y to me.
[15:48] <codeslinger> Im logged in as root....
[15:51] <codeslinger> seems like bzr is pretty buggy.  I see plenty of high priority bugs that are pretty old.  does anybody have opinions about the actualy usability/stability of bzr.   I mean the design is pretty darn terrific, I thinks its what Ive been looking for.  bug I am concerned about the apparent level of bugginess.  and now I am just running some simple use scenarios and appear to have been hit by a substantial problem.
[15:54] <matkor> I use bzr since few month and never meet bug in it ... depends prolly what you are doing ...
[15:54] <codeslinger> hi fullermd!  are you the one who wrote the "rant" about BSD vs Linux?   I checked out your site.
[15:56] <codeslinger> matkor -- that is good to know.  what is your typical use scenario?   I've been at it for basically one day and already hit two problems.
[15:57] <fullermd> Oh, lord, and here I thought it was safe to step outside again...
[15:58] <dato> jelmer: regarding bug #180128, did I do wrong by cp'ing with svn? is there another way of doing the same with bzr-svn alone, in a way that the created branch is a cp, and I can push new changesets to it?
[15:58] <ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
[15:58] <matkor> codeslinger: what is typical use of bzr -  developing software in many places and many branches ;)
[15:58] <fullermd> I've been using bzr for...  2 years and change.  I've hit a number of bugs in that time, but pretty much all of the bug ones have since been fixed.
[15:59] <codeslinger> fullermd - you make some very good points about linux, it's exactly why I switched to gentoo.  and now trying out sabayon.
[16:01] <fullermd> I should go through that thing sometime and do some cleaning and updating.
[16:01] <fullermd> Of course, that's a subset of needing to do the same on, like, my whole webpage.
[16:01] <codeslinger> I'm am trying to figure out what I can do and should avoid with bzr.  I just tried a use scenario of creating a conflict and resolving it and somehow it is now blowing up in my face.  it may be related to the fact that I changed the location of the server path due to another bug in which the automatic password conf file is not working.
[16:04] <codeslinger> fullermd -- it was a good read.
[16:04] <fullermd> I was happy with how it turned out.
[16:09] <codeslinger> fullermd -- the thing is, that "Aunt Betsey" is not going to be willing to compile code from scratch.  she just wants something that works out of the box.
[16:13] <awilkins> codeslinger: I keep thinking about the potential for gentoo to benefit enormously from a hug distributed P2P compile system
[16:14] <awilkins> codeslinger: FOr most of the common hardware setups and use flag combos, there must already be binaries out there.
[16:15] <codeslinger> yeah, I set up distcc locally but iy was a pain to get working.  spent spent was greater than time saved.
[16:16] <awilkins> I don't update as much as I used to, my only gentoo box is a MythTV box now
[16:16] <awilkins> I used gentoo because at the time it was the only distro I could get the hardware working on ; not least because it was the easiest to get the mm-sources kernel working on
[16:17] <codeslinger> "spent spent" [16:17] <awilkins> But I found gentoo to be a great teaching distro - it really makes you learn a lot about Linux
[16:19] <codeslinger> yes, gentoo seems to combine best of most worlds.  but the "learning curve" was pretty darn steep.  so far I am liking sabayon, it's gentoo packaged to "just work" out of the box.
[16:20] <codeslinger> once I finally tamed the beast, I put gentoo on all of my servers.  debian and other distros drove me nuts with their dependancy hell.
[16:21] <awilkins> Agreed, not having to install GTK to get the ncurses version of BitTorrent is very useful
[16:22] <awilkins> This particular box doesn't even run a desktop, just MythTV in a bare X server
[16:27] <codeslinger> we are way off topic but I guess nobody is objecting....   I have seen some references in the gentoo docs to the pre-compiled binararies.  but at a quick glance it looks pretty restrictive.  so I have not pursued it. sound like you have been using it,  what is your impression?
[16:31] <awilkins> codeslinger: No, I don't use precompiled binaries, I still build from source, but not often
[16:32] <awilkins> FOr MythTV I still build from source because the ebuilds lag behind the trunk so much
[16:33] <awilkins> But I even do that less often as it gets more stable. I'd love a build that didn't use MySQL though, that thing is a piece of trash (doesn't survive a BRS reset very well)
[16:33] <codeslinger> ah, okay.   lag... yes, but over-all pretty impressive, consider php for instance. they had the updated ebuild in about 3 days.
[16:34] <awilkins> I wouldn't notice ; I don't even have a cron job running emerge --sync
[16:34] <codeslinger> i've found mysql to be pretty solid. perhaps the cause is elsewhere.
[16:34] <awilkins> codeslinger: It's probably because the box was overheating and shutting down non-gracefully
[16:35] <awilkins> This was only happening in long transcoding jobs... I've underclocked it since and it's stable even transcoding 24/7 for 3 days straight.
[16:36] <awilkins> I'd swap the CPU for a mobile variant but the motherboard is a budget model and has no VCORE support.
[16:37] <awilkins> I'm happy with it though, £43 for onboard graphics with TV-out
[16:37] <codeslinger> oh I'd never use a cron job for that.   it's jsut that I happened to be looking for the php upgrade and expected to have to install it from scratch and lo there it was already  to go.  that was one of the things that decided me to switch the servers to gentoo
[16:37] <awilkins> They're probably a lot snappier on core packages
[16:37] <codeslinger> if you've got hardware issues it is totally unfair to blame mysql for corruption.
[16:38] <awilkins> It's not exactly ACID though, is it?
[16:38] <codeslinger> I've got tables with a million plus records and mysql handled it without a hiccup.  impressed the heck out of me.
[16:40] <awilkins> I suppose I'm being a little unfair... it got really annoying for a while though, having to repair the tables every couple of days
[16:40] <awilkins> I'm more used to RDBMs like MSSQL and MySQL feels a little toy-like in comparison.
[16:40] <radix> a database _should_ be able to handle power cutoff
[16:41] <awilkins> radix: My point ; if the same thing happened to MSSQL for example, it would recover fine because the transaction log would be played back when it recovered.
[16:41] <awilkins> AFAIK, MySQL doesn't _have_ a transaction log
[16:42] <LeoNerd> MySQL doesn't usually have transactions, period
[16:42] <fullermd> Oh, heck, am I busy working through Bash MySQL day?  Crap.
[16:42] <awilkins> On the other hand, it's not exactly "enterprise" deployment, being a mythtv box. SQLite managed to be ACID though ; I'd be interested to see how easy it was to port MythTV to use that instead.
[16:43] <LeoNerd> SQLite is nice.. it lacks a lot of abilities but it's very upfront about that. "Here's what we do, here's what we don't."
[16:44] <codeslinger> mysql != toy  it's being used by some pretty big players such as the census buru and the airline reservation system.  if you think it toy because of minimal interface then try mysqladmin it is good.
[16:45] <awilkins> In any case, I've not had to repair the tables since I underclocked the CPU, so hooray.
[16:45] <LeoNerd> Er.. no... I think MySQL is a toy because of all the crazy things it does
[16:45] <awilkins> codeslinger: I'm happy enough with SQLYog on windows and phpmyadmin
[16:45] <codeslinger> transactiosn and logs are options that you turn on when desired.
[16:45] <LeoNerd> Have you seen such things as the example SELECT * FROM table WHERE col IS NULL AND col IS NOT NULL;  ?
[16:45] <LeoNerd> It returns a row :)
[16:46] <fullermd> I prefer the high-quality data validation, myself.
[16:46] <fullermd> 's all way the heck off the #bzr path, though.
[16:46]  * awilkins likes bzr but hasn't really tried shared repositories yet
[16:47] <codeslinger> yup, so I am going to say bye now.  see you around, good chating.
[16:49] <awilkins> Am I rght in thinking that if I wan't proper merge tracking converting over a old CVS repository I;m going to have to do it myself?
[16:54] <fullermd> Just reading that question gives me the twitches...
[16:56] <awilkins> It's worse, it's not even a real CVS repository, it's MKS
[16:56] <awilkins> I've already patched rcstools not to choke and die on the MKS RCS format though
[16:56] <awilkins> MKS does at least have some notion of atomic commits
[16:58] <awilkins> But it doesn't track merges and even if it did, the merges are being done here by some horrible old Java
[16:58] <awilkins> (MKS itself is some horrible old Java too)
[16:59] <awilkins> This stuff branches by copying individual files into their own "change package" folder and working on them there
[17:00] <awilkins> I'm supposed to be developing this on the back of SVN but after a few days trying bzr I'm rather enamoured of it's speed and merge support
[17:00] <awilkins> I'm fairly convinced that even if the final product is svn-driven, just using bzr for development and testing is going to increase my productivity enormously
[17:07] <fullermd> Well, I ended up using bzr because I figured svn was mature enough to look at replacing CVS with, then looked at it closely.  So using bzr instead of svn sounds perfectly reasonable to me   :)
[17:09] <awilkins> The only problem is that the Eclipse plugin is not ... mature
[17:10] <awilkins> Which is a real stumbler for the automation that my users expect. *sigh*
[17:10] <fullermd> Ah, well, I'm waiting to eclipse itself to mature so that it looks more like vi   ;>
[17:11] <awilkins> Isn't there a vim editor plugin for Eclipse?
[17:11] <brilliantnut> eclim
[17:11] <awilkins> fullermd: Are you an MD or is that something else?
[17:12] <fullermd> Oh, no, it's initials.
[17:13]  * awilkins does healthcare IT
[17:13] <fullermd> First account I had used last name and initials as the naming scheme, and it's only been a millennium since then; too little time to get aroudn to changing it.
[17:15]  * fullermd doesn't, and is glad of it.
[18:06] <krish> hi, in bzr branch http://bazaar.launchpad.net/~timepass/timepass/timepass-devel
[18:07] <krish> ~timepass is project name
[18:07] <krish> what is the next timepass for?
[18:07] <krish> or is ~timepass the name of the team
[18:09] <dato> krish: yes, the team
[18:10] <krish> then the next timepass is for?
[18:10] <krish> timepass-devel is my branch
[18:11] <krish> what does the timepass between these two mean?
[18:11] <dato> the name of the project
[18:11] <dato> (to which the branch belongs to)
[18:11] <krish> oo.  so i have to use     registrantofbranch/projectname/branchname always
[18:12] <dato> yep
[18:13] <krish> thks dato. :)  im new to bzr and its the first versioning system i m using. todays my first day. thks a lot
[18:13] <dato> you're welcome
[18:13] <LeoNerd> It's not a bzr thing - bzr doesn't care.. that's just a file path
[18:13] <dato> krish: you have to use "registrantofbranch/projectname/branchname" for *launchpad.net*
[18:13] <LeoNerd> It might have some significance to the launchpad system in particular... but... bzr cares not
[18:14] <krish> oh ok
[18:14] <krish> shall remember that :)
[18:25] <ubotu> New bug: #183831 in bzr "Internal error with soft link" [Undecided,New] https://launchpad.net/bugs/183831
[18:56] <mimir_> hey, i've got a question
[18:56] <mimir_> i've done a bzr push to a sftp URL
[18:57] <mimir_> and i only have the files "visible" at that location after i do a bzr update on the server
[18:57] <mimir_> is there a way so that on push the repo on the sftp location will update?
[18:58] <radix> mimir_: https://edge.launchpad.net/bzr-push-and-update
[18:58] <dato> mimir_: not over sftp, but if you install bzr on the remote end, you can use bzr+ssh, plus the link radix gave you
[18:59] <mimir_> thanks a lot. that's what i was looking for
[18:59] <radix> oops. I guess that plugin is ssh only
[18:59] <mimir_> i have ssh, no prob there...
[18:59] <radix> although probably that works in the majority of cases where you have sftp access :)
[19:00] <radix> it's the requirement of bzr on the server that's the strictest requirement
[19:01] <mimir_> i'm installing the plugin right now
[19:09] <krish> radix: do i need that plugin to work on launchpad too?
[19:09] <radix> krish: no, not at all
[19:09] <radix> the plugin doesn't really make sense with launchpad, you don't need working trees on the server
[19:10] <krish> hmm ok
[19:23] <mimir_> question... is there a way now to alias bzr push to execut bzr push-and-update?
[19:23] <mimir_> i'm using BzrEclipse
[19:24] <mimir_> and it only has bzr push...
[19:24] <krish> doesnt bzr has a gtk frontend?
[19:24] <krish> i m new to this.
[19:24] <brilliantnut> krish: bzr-gtk
[19:24] <krish> brilliantnut: i was suggesting mimir_
[19:25] <krish> brilliantnut: may be u can help him out. i just read that bzr has a gtk frontend
[19:25] <krish> brilliantnut: i dont even know how it looks :P
[19:27] <dato> mimir_: mmm. push-and-update now is smart, and makes "push" alone itself update the remote tree, *iff* there is one
[19:28] <dato> mimir_: so you just need to log to the remote computer once and create the tree there. you create the tree with 'bzr checkout .'
[19:29] <mimir_> dato, here is how i work: 1. create on the remote server the repo (bzr init, bzr add, bzr commit -m "initial import"). then on local machine i do a bzr branch sftp://URLHERE
[19:29] <mimir_> dato, then i work on the local branch, i do commits etc, until i'm ready to make a push back to the remote server..
[19:30] <mimir_> dato, so i want now that on push the remote does bzr update... what is the plugin mentioned doing, right?
[19:31] <dato> mimir_: yes, it will do that, as long as you push over bzr+ssh and not over sftp
[19:31] <mimir_> ah... so on push i neet to do bzr push bzr+ssh://someurl ?
[19:32] <dato> yeah
[19:32] <mimir_> dato, cool, testing it now..
[19:32] <dato> ok
[19:44] <mimir_> dato, i think i'm doing smthing wrong...
[19:44] <mimir_> dato,  bzr push bzr+ssh://science@myscienceisbetter.info/home/science/public_html/basilisk/
[19:44] <mimir_> science@myscienceisbetter.info's password:
[19:44] <mimir_> This transport does not update the working tree of: bzr+ssh://URL. See 'bzr help working-trees' for more information.
[19:44] <mimir_> No new revisions to push.
[19:45] <mimir_> ah... 1 sec..
[19:48] <mimir_> dato, nope... i still need to do bzr update on server...
[19:48] <mimir_> am i missing something?
[19:48] <dysinger> Thanks for your help yesterday gang.  I am totally on bzr/svn now.
[19:49] <beuno> mimir_, I use a cron job which runs bzr update due to permission problemas. AFAIK, bzr+ssh doesn't update the working tree, just the push-and-update plugin
[19:50] <dato> mimir_: if you see the "This transport does not update..." warning, something's gone wrong. do you see push-and-update listed if you run `bzr plugins`? (Also, the directory under plugins should be named push_and_update, it can't be push-and-update)
[19:50] <mimir_> let me check..
[19:51] <krish> bye all
[19:54] <beuno> mimir_, you have to do:  bzr push-and-update bzr+ssh://science@myscienceisbetter.info/home/science/public_html/basilisk/
[19:54] <dato> beuno: nope
[19:54] <mimir_> dato, thanks m8, it works now
[19:54] <dato> beuno: check the commit log
[19:54] <mimir_> dato, there was a problem with my push-and-update install
[19:54] <dato> mimir_: very well
[19:54] <beuno> dato, really?  aaaah, didn't know a new version was out
[19:55]  * beuno learns something new
[19:55] <mimir_> i just did bzr push-and-update and it automaticaly the sftp:// path
[19:55] <mimir_> and it did the job quite well :)
[19:56]  * mimir_ thanks dato and radix for pointing the right path :)
[19:56] <dato> you're welcome
[19:57] <beuno> that's odd, I was subscribed to the repo en launchpad, but I didn't get any notifications
[20:00] <jelmer> yay, the 20th bzr-svn bug related to unicode \o/
[20:00] <james_w> hi jelmer
[20:00] <james_w> hi dato
[20:00] <dato> hey, james_w. long time no see, I think?
[20:00] <jelmer> hey James
[20:01] <jelmer> 'evening Adeodato
[20:01] <james_w> dato: yeah, hardware troubles. All sorted now, so I should be back with the code soon.
[20:01] <dato> james_w: great
[20:01] <rjek> jelmer: On the other side, my experience with bzr-svn was almost flawless apart from my misunderstanding of what the branch file thingy was for :)
[20:01] <dato> jelmer: I'm going home now. I'll try to take a look at -pqm when I arrive.
[20:02] <jelmer> dato: Cool, thanks
[20:15] <slestak> can i bounce some bzr ideas off the room
[20:15] <slestak> i am trying to plan a vcs system for my workgroup
[20:16] <slestak> we have a shared codebae that is 75% plain text files, and 25% within binary files (more on that in a sec)
[20:17] <slestak> its the 25% that is an issue.  the 4gl we use stores the file definitions and screen definitions withing the header of the actual db datafile.
[20:18] <slestak> i think i am capable of coming up with a fuse fs kindof like sshfs that would allow regular fs-like access to thes contents of the binary files.
[20:19] <slestak> has anyone dealt with a simialr setup, versioning selected contents of a vinary file, not teh whole bin file.
[20:19] <rjek> The only occation I found myself needing fine-grained revision history over binary blobs I wrote a tool to convert the binary blobs to and from a textual format, and installed a pre-commit hook.
[20:20] <slestak> thats kindonf what i am thinking, a wrapper that will extrac the records I need, and put tehm back safely.
[20:21] <slestak> i was considering a fs-like interface so it will be familiar and transparent to any 3rd party tools that deal with bzr
[20:21] <rjek> There's no need for a FUSE hack really.  The pre-commit hook idea is also more portable in case you want to check in or out on a non-Linux box.
[20:28] <Manfre> what is the command to generate a diff of 2 revisions?
[20:29] <slestak> rjek: thanks :)
[20:29] <luks> Manfre: bzr diff -r R1:R2
[20:29] <luks> er
[20:29] <luks> that's svn :)
[20:29] <luks> bzr diff -r R1...R2
[20:30] <Manfre> thanks
[20:30] <luks> actually it's bzr diff -r R1..R2
[20:30] <luks> I should probably really try to not help anybody today :)
[20:41] <Manfre> does bzr support the auto replace variables? e.g. $LastChangedRevision:
[20:41] <Manfre> if so, can some one link me to a doc that explains it
[20:41] <luks> no
[20:42] <luks> the usual trick for build scripts is `bzr version-info`
[20:43] <rjek> it's a shame you can't really do that (AFAICT) from bzr export.
[20:55] <dysinger> Is there a way to get bzr-svn to remember your password like git-svn or just plain svn?  It's driving me nuts having to enter it all the time.
[20:56] <luks> use svn to remember the password
[20:56] <jelmer> dysinger: what transport are you using?
[20:56] <luks> then bzr-svn will use the saved password
[20:56] <dysinger> https
[20:56] <dysinger> when I branched I put https://username:password@host/url
[20:57] <dysinger> but now I have to enter my password everytime.
[20:57] <dysinger> when update/pull etc.
[20:58] <dysinger> That brings up another question.  A guy in here last night recommended that I checkout from svn instead of branch - said there was less chance for an impedance mismatch with svn.  Is that true Jelmer ?
[20:58]  * fullermd <---- guy
[20:58] <dysinger> heh
[20:58] <dysinger> hey fullermd
[20:59] <dysinger> I just wanted to check with 'the man'
[20:59] <fullermd> I _wish_ it were last night.  It's still "earlier today" for me   :|
[20:59] <dysinger> heh I am GMT-10
[20:59] <dysinger> in the center of the ocean
[20:59] <fullermd> Well, if you're going to be becalmed, you might as well have a 'net connection.
[21:00] <jelmer> dysinger: can you rephrase that last bit without using "impedance"?
[21:00]  * jelmer is not a native speaker, the only way I know impedance is related to electricity
[21:00] <fullermd> Well, that's the context I draw it from too   :]
[21:00] <dysinger> fullermd said that using checkout for an svn remote repo was better and there was less chance for problems
[21:01] <dysinger> I found that at least it seems to me checkout is better for svn because "push" to svn on a branch I made the 1st time was painfully slow.
[21:02] <fullermd> Well, that's not a checkout/push difference; that's some cache or other that had to fill.
[21:02] <dysinger> I just want to make sure I am doing "the right thing" before I settle in on a pattern of work.
[21:02] <jelmer> dysinger: Checkouts will be slow the first time as well
[21:02] <dysinger> yes checkout vs branch is about the same
[21:02] <jelmer> dysinger: checkouts are basically branches that push on commit
[21:02] <dysinger> y
[21:03] <jelmer> dysinger: They're not necessarily better than pushing, but they may match your workflow better
[21:03] <fullermd> jelmer: My operative theory is that using the checkout to interface to svn via merging in work and committing (vs. merging from svn and pushing) is interfacing to svn how svn expects to be interfaced to, and so is less likely to confuse it or you (or both).
[21:04] <fullermd> (i.e., matched impedances, no reflections)
[21:04] <dysinger> What I am hearing is that branch vs checkout makes no difference to the bzr-svn plugin -but checkout matches svn workflow better
[21:04] <AnMaster> changelog for 1.1?
[21:04] <jelmer> fullermd,dysinger: yep, that makes sense
[21:04] <dysinger> fullermd you used the word impedance again :)
[21:04]  * fullermd nods.
[21:04] <fullermd> Well, I considered using admittance instead   ;)
[21:05]  * jelmer has a some idea of what it means now :-)
[21:05] <jelmer> foss development is really good for my foreign language skills
[21:05] <fullermd> Luckily, I have a pi-network tuner right here at my elbow to resolve such mismatches   :p
[21:05] <lifeless> moin
[21:05] <dysinger> So about that svn password - is there something I can stash in .bazaar/subversion.conf or something?
[21:06] <jelmer> hey lifeless
[21:06] <jelmer> dysinger: If you force svn to authenticate once, it will cache the password
[21:07] <dysinger> hmm
[21:07] <jelmer> see the bzr-svn FAQ for details
[21:07] <dysinger> ok
[21:07] <dysinger> It's asking me for a password everytime
[21:23] <dysinger> FAQ! it doesn't work jelmer  svn info https://dysinger@xyz.com/svn works without password but then I immediately get asked for my password when doing bzr update <branch>
[21:23] <dysinger> svn password is cached
[21:23] <dysinger> bzr still asks everytime
[21:23] <jelmer> dysinger: and if you don't specify a username to svn?
[21:24] <dysinger> svn info works fine either way with no password
[21:25] <rjek> Does bzr still produce an error if you try to do something with an http:// URL that requires auth but you don't specify a username?
[21:25] <dysinger> maybe it's because I checked out the branch with bzr using the username:password@ notation
[21:27] <lifeless> dysinger: try bzr bind bettersvnurl
[21:27] <jelmer> dysinger: right, but if you specify a username to svn (using the username@ notation) it may not do any caching
[21:27] <dysinger> ok I'll try it again
[21:28] <lifeless> dysinger: that will update the url bzr has remembered
[21:28] <jml> bzr.dev seems to take an awfully long time to pull
[21:29] <rjek> jml: Lots of history.
[21:29] <rjek> Try a checkout with --lightweight instead if you're not interested in editing the source so much as simply get the latest source.
[21:29] <dysinger> that only works if you are always connected if I am correct
[21:30] <rjek> dysinger: Sure, but if you're not interested in using it for development work and only as a way to check out the latest source, you'd need to be connected anyway.
[21:30] <jml> rjek: I mean, pulling from my month-old copy
[21:30] <dysinger> oh sorry I was thinking of my repo - not bzr.dev
[21:31] <dato> jml: is your copy in knits or packs?
[21:31] <dysinger> lifeless lol oops I already deleted my repo to start over.  dogh!
[21:32] <lifeless> dysinger: heh, why delete the repo ?
[21:33] <jml> dato: format is 'dirstate', I guess that means knits
[21:33] <dysinger> Thanks to OS X I can time-machine back an hour ago and grab it.
[21:33] <lifeless> dysinger: at most delete the branch; repositories have no configuration, only raw data, so for things like cached password etc the repository is never at fault
[21:33] <dysinger> gatcha
[21:33] <lifeless> jml: 'bzr upgrade'
[21:33] <jml> lifeless: doing so now :)
[21:33] <dato> bzr upgrade --pack-0.92 to be really sure
[21:34] <dato> (in the rare case his copy didn't have packs-as-default)
[21:34] <jml> why do people say knits when bzr says dirstate?
[21:34] <dysinger> time machine is so awesome
[21:34] <dysinger> restore -> click
[21:34]  * dato thinks that part of bzr is messy, messy.
[21:35] <dato> jml: if you know the difference between brach, repository, and working tree, because dirstate is a working tree format and knits a repository format
[21:35] <lifeless> sweet
[21:35] <lifeless> hpss call w/body: 'Repository.stream_revisions_chunked', 'home/robertc/bzr.dev/' ('pqm@pqm.ubuntu.com-2'...)
[21:35] <lifeless>               172 bytes
[21:36] <jml> dato: interesting. running bzr info in the top dir of a shared repository said the format was dirstate
[21:36] <lifeless> down from > 1 MB
[21:37] <jml> dato: I'm surprised that has anything to do with working trees
[21:37] <lifeless> jml: see bug kthxbye
[21:41] <dysinger> Grrr - when I do svn info http://url.com/svn it works fine.  We I try to bind my checkout to it it fails :  Duece:trunk tim$ b bind https://url.com/svn/trunk
[21:41] <dysinger> bzr: ERROR: Invalid http response for https://url.com/svn/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[21:43] <lifeless> dysinger: try svn+https
[21:43] <dysinger> k
[21:43] <lifeless> or is it https+svn; svn first I think
[21:43] <dato> yes
[21:44] <dato> (svn+)
[21:46] <lifeless> does it work ?
[21:46] <dysinger> no
[21:46] <lifeless> jelmer: ^ ?
[21:46] <dysinger> I went into /tmp & created a new fresh repo & tried to checkout
[21:47] <dysinger> first I did an svn info https://url....
[21:47] <dysinger> then bzr checkout https://url <- fails
[21:47] <dysinger> bzr checkout svn+https://url <- fails the same
[21:47] <dysinger> that's why I added the username:password in the url last night.
[21:48] <dysinger> I get bzr: ERROR: Permission denied: ".": PROPFIND request failed on '..... everytime
[21:50] <lifeless> I don't know enough about bzr-svn to answer this sorry
[21:50] <jelmer> Sorry, I don't know eithr
[21:51] <jelmer> Subversion 1.5 and bzr-svn 0.4.6 should allow bzr to do the caching
[21:51] <dysinger> whacked ok I am going to try one of my other accounts to see what's up
[21:51] <dysinger> ok I am using bzr-svn stable but subversion 1.4.6 with patches
[21:51] <dysinger> maybe I should go trunk
[21:51] <jelmer> but the "svn info" trick has always worked for me so far
[21:52] <dysinger> ^ trunk on subversion 1.5
[22:11] <dysinger> Is trunk 1.5 subversion stable enough to use for everyday dependable development work?
[22:11] <lifeless> jelmer: %
[22:12] <jelmer> dysinger: imho, yes
[22:13] <dysinger> They don't have a branch for 1.5 yet so I imagine you just compile trunk
[22:13] <dysinger> and trunk needs no patches
[22:13] <jelmer> yep
[22:17] <dysinger> geez trunk is way easier to compile
[22:25] <dysinger> I bet the problem is this
[22:26] <dysinger> I am using os x's svn client to login
[22:26] <dysinger> but bzr is using an updated svn library
[22:26] <dysinger> that's off to the side.
[22:26] <dysinger> maybe that's it
[22:46] <lifeless> abentley: ping
[22:46] <dato> jelmer: uploaded
[22:58] <igc> morning
[22:59] <jam> igc: morning
[22:59] <igc> hi
[23:00] <jam> spiv: any recent changes to Launchpad that would make bzr+ssh start failing?
[23:01] <elmo> grr
[23:01] <lifeless> jam ping
[23:01] <spiv> jam: not that I know of
[23:01] <elmo> plstobe bzr add not being relative to cwd
[23:01] <lifeless> jam: I have an incremental patch I'd love instant-review on
[23:02] <jam> lifeless: just a sec, phone call right now
[23:02] <jam> will do after
[23:02] <lifeless> jam: will mail it then
[23:04] <lifeless> jam: so there are two unreviewed patches in this stack - the incremental one I just sent; and the smart server one that I rejected last night, but is actually good.
[23:05] <spiv> lifeless: I reviewed that a moment ago
[23:06] <lifeless> sweet
[23:06] <lifeless> its a change from  >1.2MB -> 172 bytes  :)
[23:12] <jelmer> dato: why the "sigh" about python-all-dev?
[23:15] <jelmer> dato: and thanks once again for uploading :-)
[23:18] <jam> lifeless: bb:approve
[23:20] <lifeless> thanks
[23:20]  * lifeless merges all 4
[23:22] <lifeless> jam: its release time; could be a rollout or something has just been done
[23:25]  * jam => family time
[23:31] <keithy_> Is there an install for 10.4
[23:31] <keithy_> Is there an install for Mac OS X 10.4
[23:33] <dysinger> is easy_install on Tiger ?
[23:33] <dysinger> can you open a terminal and type `which easy_install` ?
[23:33] <keithy_> nope
[23:34] <keithy_> is that what the 10.5 dmg installer uses?
[23:34] <dysinger> I think so yes
[23:34] <dysinger> I am on leopard so I just type `sudo easy_install -U paramiko pycrypto bzr`
[23:35] <keithy_> seams silly to only release for os os that is barely months old
[23:35] <keithy_> an*
[23:36] <dysinger> oh I am sure there is a way
[23:36] <dysinger> I just don't know it.
[23:36] <dysinger> It's just python
[23:36] <dysinger> code
[23:36] <dysinger> Do you have macports installed ?
[23:36] <keithy_> thats enough to make me suspicious
[23:37] <keithy_> I cant stand python
[23:37] <keithy_> yeah I am updateing macports now
[23:37] <dysinger> wow be careful
[23:37] <dysinger> :)
[23:37] <keithy_> why is that not going to work either?
[23:37] <dysinger> The heresy to say python sucks in here
[23:37] <keithy_> ih that
[23:37] <dysinger> s/the/that's
[23:38] <keithy_> well written by a guy who doesnt understand object dispatch
[23:38] <keithy_> sh, down boy
[23:38] <dysinger> Python's a perfectly fine language - I prefer ruby myself or java
[23:39] <keithy_> first language I ever write a hate sheet on
[23:39] <keithy_> but I suspect it might have been the first book I bought on it was rubbish and that coloured my view
[23:40] <keithy_> ruby's ok
[23:40] <dysinger> I just like Ruby better nowdays - java paid the bills for 10 years
[23:40] <keithy_> wow macports updated!
[23:41] <keithy_> this might be ok afterall
[23:41] <dysinger> I believe git and bzr etc are in macports
[23:42] <keithy_> ive tried mercurial, now its bzr's turn.... does it have patch queues?
[23:43] <keithy_> does it do binary diffs?
[23:44]  * dysinger just came from git & now trying bzr
[23:44] <fullermd> Ruby...  furrfu.  Crazy people, this internet thing has...
[23:44]  * awilkins is using SVK fairly actively, tried git (windows) and is liking the look of bzr so far
[23:45] <dysinger> hey easy - I didn't say python sucks.  I just said I like Ruby. :)
[23:45] <keithy_> well Smalltalk pays my bills
[23:45] <awilkins> keithy_: bzr will let you pass off to the diff tool of your choice
[23:45] <dysinger> wow - they still make smalltalk ?
[23:45] <dysinger> :)
[23:45] <keithy_> not that sort of diff
[23:45] <keithy_> when it stores in the revisions
[23:45] <fullermd> Oh, well, I said python sucks  :p
[23:45] <keithy_> does it store whole files or does it store diffs?
[23:46] <fullermd> But hey, as long as the tool works, and *I* don't have to write the language, it can be in whatever it likes.
[23:46] <dysinger> fullermd likes ???
[23:46] <fullermd> Well, except Haskell.  Gotta draw the line somewhere.
[23:47] <lifeless> keithy_: its stores both full files and diffs
[23:47] <fullermd> I dunno.  I don't actually have a language I'm agog about these days.
[23:47] <lifeless> keithy_: but chooses between them to balance time and space at each commit
[23:47] <keithy_> so if I have a 50Mb file in 4 versions
[23:47] <dysinger> I am not a fan of any language I can't read - haskell, erlang, scala etc all have totally bizarre syntax.
[23:48] <fullermd> I like C, but it's so much manual bookkeeping.  I spend my days writing PHP and it's not bad, except for the big gaping suckages.  I like perl, but it irritates me in a lot of ways...
[23:48] <lifeless> keithy_: in 1.0 or 1.1 you'll end up with 50MB gzipped + space proportional to the difference in the files, split on \n and represented as line deltas
[23:48] <fullermd> But hey, perl 6 will cure everything.  And it's right around the corner.  No, really, this time for sure.
[23:49] <keithy_> but binary fiels dont have lines
[23:49] <lifeless> keithy_: they have \n in ~1/256 characters
[23:49] <lifeless> keithy_: which is enough for the storage layer.
[23:50] <keithy_> hmm not sure if it would work on a smalltlak image, can I change the split character
[23:50] <lifeless> keithy_: but its not as efficient as something that looks for common sequences of bytes rather than fooo\n's. We know this is an issue and are looking at a new compressor in a couple of months time
[23:50] <lifeless> keithy_: no, you can't, but it will work - it round trips losslessly; the worst case is you end up with 200MB of storage.
[23:50] <keithy_> k
[23:50] <lifeless> keithy_: (and which we will be addressing by 1.4 anyhow :))
[23:51] <lifeless> folk version iso's :)
[23:54] <lifeless> keithy_: you could also use the fuse interface someone was working on to the squeak code and version that in bzr; I suspect we'd need a little work to work on the fuse tree (we need os locks which you wouldn't really have, for a couple of files), but the fuse tree could back that part to local disk; :)
[23:54] <keithy_> wow you know about that fuse interface!
[23:55] <keithy_> interesting idea
[23:56] <lifeless> it wouldn't get object state; but personally I like file-in imageless based smalltalks :)
[23:57] <keithy_> I used to use st/x myself
[23:57] <keithy_> and that did cvs versioning of classes
[23:57] <lifeless> bbiab