[00:07] igc, do you want to talk about benchmarking some time? [00:07] poolie: sure [00:07] you call me? [00:07] ok [00:32] Noob Q : So will bzr rewind my local commits when I rebase and then apply them again? [00:32] like git ? [00:35] Er sorry I should RTFM http://bazaar-vcs.org/Rebase [00:36] dysinger: you can do that if you want yes [00:36] what RTFM ? :) [00:36] dysinger: our community rarely uses rebase because its very bad for collaboration [00:36] Well it's useful when your team uses SVN IMO [00:37] why? [00:37] I guess because I have some of the team on SVN and some on DVCS [00:37] so the we could all just pull from each other except some people are only commiting to SVN [00:37] I still don't get what rebase does for you; just merge and commit and away you go [00:37] you don't need rebase for that at all [00:38] I guess my mind is polluted with git-svn [00:38] :) [00:38] BZR will be a fun new (hopefully simpler) experience [00:38] when someone commits to svn, you 'bzr merge' to get their stuff into your branch [00:38] when you want to commit to svn, you do 'bzr checkout svn:///' merge and commit [00:39] Git treats SVN as a whole separate add on side-car which sucks. [00:39] indeed [00:39] * AfC just read the URL about rebase above and *still* doesn't get what it's for. {sigh} [00:39] it would be extremly hard to do other with gits design [00:39] AfC: rebase is for folk that care about having a 'pretty revision graph' [00:39] I guess [00:39] AfC: more than having effective collaboration [00:40] 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] dysinger: or you can just merge. [00:40] ko [00:40] ok [00:40] So I guess yeah - why would you have rebase then ? [00:41] 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] dysinger: as I say above, rebase is about 'revision graph prettiness' [00:41] I see [00:41] some people care intensely about that; for them we have rebase ;) [00:41] 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] that would be me [00:42] 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] dysinger: well, you may find you care less with bzr's log layout :) [00:43] i am looking forward to playing with it. [00:44] 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] Should I put it somewhere for others? [00:45] dysinger: cool, edit that page and add a version for os X [00:45] K [00:50] "Bazaar-NG branch format 5" is dirstate, right? Why is it listed as "unnamed" in bzr info? [00:51] Peng: the format name reporting is bogus, there is a bug on it [00:51] Peng: format 5 with knits and dirstate is 'dirstate' [00:51] Peng: format 5 with packs is 'unnamed' [00:52] Ahhh, ok. [00:52] Yeah, I'm using packs. [00:52] Ok. [00:54] Thanks for the explanation. :) === mw is now known as mw|out [00:57] ok I updated bzr-svn wiki with the right install info for OS X [00:59] jelmer thanks for hanging in there - it's working now! I am off to play with some svn repos [01:14] dysinger, thanks! [02:11] So who's an expert on light-weight branching? [02:13] fsvo expert many people [02:13] just ask :) [02:17] So I need a plugin? https://launchpad.net/bzr-lightweight-branch [02:18] 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] I also heard you can have many branches within the same directory like Git [02:19] Maybe that would be better [02:19] create a repository (need to use init-repo --rich-root) and branch into that [02:19] er, from svn into that [02:21] So instead of branching right from svn with bzr branch svn:///..... I do it this way? [02:21] well, you make the repository, then use "bzr branch svn..." to branch into that repository [02:21] mkdir project ; cd project ; bzr init-repo --rich-root ; bzr branch svn:///some/url ./ [02:21] you can't really have multiple branches "within the same directory like Git" [02:22] 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] "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] So if I already branched off of svn directly do i have to do it again this way? [02:24] --no-trees is optional for init-repo, and means it does not include checkouts of the branches along with the branches [02:24] bob2: sure you can; bzr switch will let you do exactly that. [02:24] I thought I read you could [02:24] you should be able to branch from the existing checkout into the repository [02:24] In the bzr vs git page [02:24] foom: that was the next bit [02:24] bob2: oh okay. :) [02:24] dysinger: you can, though, quickly switch between branches in a checkout using bzr switch, like foom says [02:25] that's what I need [02:25] I don't want new IDE setup on every branch [02:25] I just want to switch between branches fast. [02:27] that's what I use switch for, works well [02:27] dysinger: if you already branched from svn into dir FOO [02:27] dysinger: then this: [02:27] bzr init --rich-root myrepo [02:27] bzr branch $FOO myrepo/svntrunk [02:27] 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] dysinger: will transfer the data into the repo [02:28] not init-repo? [02:32] 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] dysinger: we have the source code in .../project/mainline .../project/branch1 .../project/branh2, etc [02:33] dysinger: where .../project is created with `bzr init-repository` [02:33] bob2: oh yeah, I meant to type init-repo [02:33] dysinger: and the first branch was `bzr init mainline` [02:34] AFC: lemme guess - symlinks? [02:34] dysinger: all subsequent branches were, of course, created with the `bzr branch` aka `bzr clone` command [02:34] dysinger: yes, that's where I'm heading [02:34] dysinger: [02:34] OK [02:34] I like the switch option - I'll try that. [02:34] dysinger: then (this is Eclipse, but whatever), in [02:34] I am using eclipse too [02:35] Eclipse's ~/workspace we have [02:35] ~/workspace/projectname ->.../project/whicheverbranch [02:35] 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] and we just move the symlink. [02:36] ok thanks AfC [02:36] You don't need maven, but whatever. [02:36] I Do - but that's not related to this. [02:37] So do I need the --rich-root to work with switch ? [02:38] Does the lightweight branching occur automatically when you are within a rich root ? [02:38] 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] 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] Heh yeah - I am just coming over from Git so I am wanting that switch thing [02:40] dysinger: no, lightweight always requires the option [02:40] abentley: did I mention your name? Was a talking to you? Did I say data loss? [02:40] lol! [02:40] whoa [02:41] AfC: No, though you hinted at something to do with the bzrtools incarnation. [02:41] 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] dysinger: yes, just push [02:41] AfC: But in general, I feel free to join in conversations on public fora like IRC. [02:42] dysinger: or simply bind/do a a checkout from svn (using bzr checkout) again. [02:42] dysinger: the shared repository will mean that only new data is copied, so it will be nice and fast [02:42] 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] ok [02:42] Just getting my feet wet today [02:43] 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] dysinger: yeah, so just try stuff a bit. [02:43] 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] 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] dysinger: no [02:44] 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] 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] dysinger: sweet. [02:45] dysinger: guess what I'm saying is that you can keep at the experimentation for sure (at least on the Bazaar side) [02:45] dysinger: and if you have access to create dummy repos on the svn side you're really set [02:45] 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] dysinger: you don't have to; init-repo and you're done [02:46] The other guys will want to know: how large is large? [02:46] [The Bazaar hackers, of which I am not one, are especially interested in Bazaar performance and usability on huge projects] [02:46] It's probably not large by your guys standards sorry. Only about 5000 commits but it's about 500MB [02:47] The svn repo is 500MB, a clean checkout is 500MB, or the release tarball is 500MB? [02:47] spiv/abentley if you feel like doing a review SearchResult would love one [02:47] Sorry, I have to go rock out. [02:48] lifeless: ok, I'll take a look sometime this afternoon [02:48] abentley: enjoy! [02:49] spiv: thanks; I have fetch converted to use SearchResult now [02:49] making sure all tests pass and that branch will go up; then onto hpss integration [02:49] AfC: unfortunately it's still really bad. :P [02:50] but at least it's gone from really *really* bad to only really bad. :) [02:50] foom: progress! :) [02:51] Abstractly, I wonder where the break point is. Number of revisions? Size of repository? Size of code:revision ratio? [02:52] lifeless: sweet [02:52] 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] from my understanding, the current speed issues are related to loading the index, which I guess is related to number of revisions [02:53] dysinger: erm, no I'm wrong [02:53] but I don't actually know, all I know is that it's still pretty slow. :) [02:53] dysinger: its the same as 'bzr cbranch' which is a bzrtools plugin, AFAICT [02:53] (for a 60krev repo) [02:53] foom: speed issues in what operations? [02:54] say, log. [02:54] thats due to log doing a global sort on the revisions [02:55] (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] and yes index speed matters there; the current indices are good at partial loads but not so hot at full loads [02:55] 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] dysinger: we're a friendly lot :] [02:57] 50% done no failures [03:18] * AfC goes for coffee. dysinger, I hope bzr goes well for you. Good luck. [03:19] patch sent [03:27] spiv: ping [03:27] spiv: what is the current verb for 'pull revisions' that I should be replacing ? [03:29] spiv: and why are there two verbs for it ? SmartServerRepositoryStreamKnitDataForRevisions [03:30] lifeless: there's two, because one buffers everything, and the other sends the response in chunks [03:30] I see two for the same request object [03:31] Oh, ugh, I see. [03:31] I wonder how that happened... [03:31] Repository.stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions and Repository.chunked_stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions [03:31] I iz confused [03:32] stream_knit_data_for_revisions is the original, buffering one. [03:32] ok [03:32] is there one that is not in a release yet ? [03:32] stream_revisions_chunked is the right verb for the better, chunking one. [03:34] spiv: is stream_revisions_chunked in 1.1 ? [03:34] chunked_stream_knit_data_for_revisions should not exist. [03:34] stream_revisions_chunked has not been in a release. [03:34] (and neither has chunked_stream_knit_data_for_revisions, thankfully) [03:34] k [03:34] I'll delete one and alter the other [03:34] lifeless: thanks [03:34] lifeless: and thanks for spotting it! [03:40] can bazaar version symbolic links? [03:40] how do I tell bzr to use an SSH key while doing bzr push bzr+ssh? [03:45] looks like bazaar can version symbolic links :) [03:45] aya [03:45] yay even :) [03:45] Manfre: just does it for me [03:46] i'm on windows [03:46] ah, dunno then [03:47] http://bazaar-vcs.org/Bzr_and_SSH [03:53] thanks [03:56] cool...it's working [04:05] i successfully pushed a branch up to launchpad [04:12] spiv: I'm running more and more into 'RemoteRepository has duplicate code cause its not a subclass' [04:42] 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] lostylost: there should not be, but we recommend that bzr servers run the latest release for best performance [04:43] that makes sense [04:43] I have had a few errors with bzr lately and it's getting me nervous [04:44] lostylost: what sort of errors? [04:45] 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] I can't recall exactly what it said [04:45] lostylost: your ~/.bzr.log may still have the error in it [04:46] something about to check the .bzr/checkout/pending-deletes [04:46] anyway, it said to delete the ones in there, I foolishly manually deleted them thinking everything would still be in the repo [04:46] somehow I lost a whole revision [04:47] Check the bzr log hey [04:47] I would like to understand what happened for next time [04:49] all that was in the directory was files with numerical names... [04:54] 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] cheers [04:55] 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] that is the error message I got [04:56] I just deleted all the stuff in there, thinking it was "temporary" working directory stuff [04:56] its things that are to be deleted [04:56] during the application of a merge/update/pull [04:56] so if I actually deleted them they wouldn't have been then? [04:56] ? [04:57] or are they all moved there temporarily? [04:57] hrmm [04:57] just the actual working tree files? [04:57] how do files end up there rather than just conflicting? [04:57] how come a whole local commit disappeared, along with it's message? [04:58] I shouldn't have been so rash, damn it :( [04:59] bob2: it was an "ERROR:" [05:00] lostylost: the update should have left your local commit as a pending merge [05:00] lostylost: the bug that caused the update to fail probably left the tree unupdated; the commit is still in your repository [05:00] I don't see it by running bzr log --forward [05:01] I have only 19, should be 20 [05:01] lostylost: if you install the bzr heads plugin, you can do 'bzr heads' to find it [05:01] thank you! [05:01] hope yet [05:02] so, when you merge, you merge into the working directory? [05:02] you can't merge up? [05:02] merge doesn't commit, so no [05:03] merge doesn't commit? [05:03] merge merges changes into your working tree [05:03] merge generates a tree with the combination of two existing commits [05:03] this gives you the ability to review what you are merging [05:04] and then do 'bzr commit' to save it [05:05] right [05:05] that makes sense. [05:05] I really like that the log has all of the previous logs in it. [05:06] do git hg etc do the nested log thing? [05:06] no idea [05:06] I found bzr and it was tasty crack, so here I am. [05:08] bob2: hg doesn't [05:08] bob2: AFAIR git doesn't [05:08] how does one manage a remote bzr branch? [05:09] (without logging in, cd'ing to the dir, and then running commands there) [05:10] 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] push to it and/or checking it out and commiting to it [05:10] :( [05:10] Solarion: define manage [05:11] 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] lifeless: the two branches are on my server, so that I can keep synchronized between workstation and laptop (and whatever else). [05:13] no luck with bzr heads [05:13] lostylost: you get only one head ? [05:14] no I was jumping the gun [05:14] 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] I think I am inluck [05:14] bzr head --all shows it [05:14] sweet [05:14] 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] lifeless: Ideally, I'd like to just, say, run bzr --root=sftp://server/path operation [05:15] ok so it's in there, how do retrieve it? it says it's a (dead) revision? [05:15] lostylost: bzr merge . -r revid:THEREVISIONID [05:16] 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] thank you very much lifeless, your a godsend [05:16] 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] Solarion: why don't you just have both branches on your laptop and work there [05:17] lifeless: I have a workstation I work on about the same amount of the time [05:17] 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] I suppose that'll work [05:17] still, I like the --root option idea better. :) [05:18] what I'd do is different [05:18] Also, I'd like a pony. [05:18] bzr --pony [05:18] I'd just work on the laptop and workstation as separate branches [05:19] 60% tests passed, looks like this patch is done [05:19] lifeless: still not help when I need to sync the changes over to trunk. [05:19] I like "micro-checkins" as my boss calls it, while he likes larger changes. [05:20] having trunk helps put all of my little changes into one big one. Keeps both of us happy. :) [05:20] Solarion: sure; so have a checkout of trunk on both laptop and workstation [05:20] Solarion: then you just merge to that checkout and 'bzr commit' [05:20] lifeless: then I'd have to care about keeping them synchronized. [05:20] Solarion: no, bzr will manage that for you [05:21] 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] checkouts won't commit if the master is newer than the local tree; just like 'svn' [05:21] anyhow, ssh'ing over to the server isn't a big deal; it's just annoying [05:21] so you'll get 'cannot commit, run bzr update' if you haven't run bzr update before merging, but thats all [05:22] lifeless: unless your changes + their changes require a manual merge [05:22] 'bzr checkout's workflow really is designed for 'trunk' situations [05:22] conflict [05:22] 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] yeah, I ran checkout for a while, but it took a while whenever I wanted to commit. [05:23] lifeless: I'd rather just not have to deal with keeping multiple branches in sync and ssh to the server. [05:23] Solarion: ah, interesting [05:23] or, use the --root option (in combination with --pony) :) [05:23] trunk is really just for combining commits so my boss is happy. [05:24] the less annoying it is, the better [05:24] though keeping multiple branches in sync is still less annoying than having to use svn [05:26] interesting. pushing the merged changes just kept my overall message, not the sub-messages. [05:26] (according to svn log) [05:27] 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] 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] Solarion: thats svn's failure to track merges AIUI [05:29] svn seems to fail quite a bit [05:29] Solarion: yes :) [05:29] ah well, I can put it somewhere where it'll be found in the next merge. [05:29] lifeless: thanks for the help, but it is bedtime for bonzo [05:29] * Solarion heads to bed [05:30] codeslinger: I have no idea sorry; I haven't used that feature [05:30] 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] dysinger: there is a first time startup cost which is pretty high AIUI [05:31] how many megs of files?? speed is good for me with about 40megs of files. [05:31] 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] svn. [05:31] dysinger: so you're pushing to svn:// ? from bzr? [05:31] It's been twirling for 5 minutes now. [05:32] dysinger: the first time you do "anything" it loads a bunch of stuff into a cache [05:32] 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] trying to push that one commit up [05:32] dysinger: like I say though, AIUI there is a first time cost where it maps a bunch of data [05:32] codeslinger: I use ssh with ssh-agent [05:32] didn't it map that on the way when I branched it? [05:32] probably not since you did a lightweight branch [05:33] No the test commit to svn I did on the branch I took from svn [05:33] dysinger: I've seen jelmer explain this to other people; [05:33] dysinger: if you allow it to finish and try again I understand it to be much much faster [05:33] 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] lifeless - ok [05:33] 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] btw, is your home directory on a local disk? [05:33] It's taken forever so it's scared me. [05:34] It's never taken this long with file:// or sftp:// [05:34] i ran into the issue where it was taking *extra* forever due to it putting the cache on NFS. [05:38] 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] I am hoping this is just some one time cost. [05:39] 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] it is [05:39] does anybody else have any ideas about authentication.conf ??? is there a trick to getting it to work??? maybe its a bug??? [05:43] spiv: ping [05:43] spiv: I'd like a quick chat [05:49] thanks again lifesaver [05:49] lifeless [05:49] lostylost: np [05:50] How do I manipulate the "parent" branch - say I branched and then the parent is gone now. [05:50] dysinger, i believe it's set by pull --remember [05:51] um [05:51] there might be a more direct way? [05:53] 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] "as a subdirectory" [05:54] 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] 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] I can just bzr branch http://my/svn/repo directly [05:55] both ways I can checkout --lightweight from it. [05:56] maybe I am missing something. [05:56] you can have a heavyweight checkout for "free" inside the repo [05:56] instead of just a lightweight one [05:56] oh you mean I don't have to specify the --lightweight ? [05:57] not only don't you have to specify it, you get all the revision data immediately there [05:58] 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] 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] 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] 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] s/include them/include that branch/ [06:04] 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] 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] dysinger: for branches within the repository, yes [06:05] ok I see the benefit then. Thanks. [06:06] 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] codeslinger: Yeah, subtrees are experimental. [06:07] well, "branch trunk my-topic" [06:07] checkout is not recommended? [06:07] ok, thanks, I will avoid that for now. any ideas where I can find the docs to config ssh agent? [06:07] branch would give me a clone [06:07] right? [06:08] well, you'd need to make a my-topic a branch in the repository, then check that out [06:08] yes, branch is a connected clone [06:09] That would make 3 layers there - 1 branch svn, 1 more branch "my-topic" and then one checkout? [06:09] dysinger: checkout is recomment just fine [06:09] three steps, yes [06:09] 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] the checkout is your working set of files where you make you changes. the svn branch would be your base [06:10] Couldn't I just branch from svn and then branch off that for topics, commit and then push ? [06:10] you can [06:11] oh codeslinger says I _can_ checkout off the svn branch [06:11] * dysinger needs to learn the diff between branch and checkout. [06:11] Hello. [06:11] yes, using a repository is just an organisational/efficiency thing [06:11] sorry if I confused you by suggesting it [06:11]