=== kiko is now known as kiko-afk [00:11] hi zsquareplusc, sure === chx is now known as chx_afk [01:00] Good morning. === chx_afk is now known as chx [01:10] zsquareplusc: that looks ok to me on a brief read [01:10] except it seems like you should be telling people to do init-repo in the project base directory [01:10] then init under that to make the branches [01:10] hi spiv [01:12] poolie: so its fully clear to you that i can push several branches? i was expecting to read something about shared repository but it's probably me who does not yet fully understand that [01:13] ok, with init-repo you would make a local shared repository for better efficiency (?), but that does have no impact on how the server stores them [01:15] i'm suggesting you should init-repo on the server [01:16] bzr init-repo bzr+ssh://.../project [01:16] bzr init bzr+ssh://.../project/trunk [01:19] hm ok. to late for me, i already pushed several branches :-) [01:24] spiv, sorry, i didn't get back to your review [01:24] i'll try again today === chx is now known as chx_sleeping [01:30] poolie: OMW [01:32] me too, soon [02:09] why can't a RegistryOption have a short_name? [02:10] mwhudson: good question! [02:55] mwhudson: noone has made it work ? :) [02:55] lifeless: yeah, fair enough [03:34] It seems that I usually forget this, but how to overwrite a lp revision without deleting the original branch? [03:35] push --overwrite [03:36] I thought I was thinking wrongly (that's probably why I did not thought of that flag :) ) [03:42] thank you again :) btw, is it my impression or bzr command interface needs some standardization? [03:43] e.g. some commands you need a -d ,and other you don't for the same thing [03:49] spiv: bug 406687 - where is that up to? looks like a stale report to me ... [03:49] Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687 [03:49] RenatoSilva: not really, -d isn't ever really needed, is it? [03:50] lifeless: can't recall for what command... [03:50] please do file a bug in such a situation [03:51] lifeless: pull from a bzr patch (that one generated by bzr send and that I always forget the name) [03:51] bzr pull filename ? === chx_sleeping is now known as chx [03:52] isn't it -d filename? [03:52] no [03:53] bzr pull [-d] thing ---> one you say it is a patch, other you say it is a master branch [03:53] can't recall now [03:53] have a look at bzr help pull [03:56] -d if for when . is not your branch right [03:56] *-d is [03:56] thats correct [03:56] ok thanks [03:56] spiv, should we merge https://code.edge.launchpad.net/~spiv/bzr/lockcontention-bugs/+merge/9228 [04:00] lifeless: right, it should have been marked Fix Released in both targets; fixed now. [04:04] poolie: it got stuck trying to decide if this was actually a good fix, IIRC. I think long-term we will want to pass paths like this back through the pathfilter in smart server... I'm not sure if this is a good interim step or not if that's the goal. [04:55] * spiv -> lunchb [04:55] lunch, even! [05:50] spiv, i haven't (re)read it, i just want it off my list [05:50] this might indicate some kind of lp use case [05:50] "i don't want to think about this more til something happens" [05:52] poolie: well, how about I mark that proposal as rejected, for now [05:52] poolie: it'll still be in my list of recent branches, to remind me, without cluttering the review list for everyone else. [05:52] wfm, and just put it back to an inprogress bug [05:52] Ok. [05:53] going back to your patch now [06:06] really :) [06:33] spiv: homedir +1 [06:33] well, one question [06:40] poolie: yeah, setUp/tearDown is consistent with transport Servers (even though that class isn't a Server) [06:41] poolie: it never even occurred to me as I wrote that code to write "setUp" any other way :) [06:42] poolie: I'll make them set_up and tear_down; we may as well start using the preferred naming style. [06:42] poolie: thanks for the review! [06:50] you're welcome [07:01] poolie: http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text is a subunit stream with timing data [07:04] spiv: my 2c are that I'd use setUp/tearDown because its the idiom we've used everywhere; its not a strong reason though [07:08] poolie: subunit-ls --times < text | grep blackbox | awk '{ n += $2} END{print n}' [07:16] hi all [07:16] lifeless: regarding config imports, my delete-useless-imports day is friday, couldn't do it yesterday, sorry about that [07:17] hi vila! [07:18] lifeless: the timings run#15 should be as accurate as possible, at least the noise was certainly very low [07:19] and the botnet is fully green, "Dormez bonne gens !" :D [07:42] vila, is binding the jail to the test instance really needed? [07:42] it seems a bit like unnecessary coupling to me [07:43] oh in theory yes, in practice that the easiest thing to do [07:44] Said otherwise: there are two test base classes proposed here, as you can see they are pretty trivial no you can redo your own binding even in a test method if you want [07:45] I don't consider the proposed implementation as final anyway, I just want it to be easily usable, [07:46] fair enough [07:46] And I've been able to paste fully copy/pastable examples here and there in the bug reports (cough, a bit too much may be, but well, I viewed them as part of hte experiment) [07:47] err, I meant: "In theory no (you don't have to bind the ScriptRunner to a test instance, you just need to provide a ensure_jail())" [07:56] yes, they look [08:00] anyhow, i'm going back tothat patch [08:04] vila: no need to apologise. [08:04] i meant to say, they look great [08:04] lifeless: joke :D [08:05] lifeless: thanks for the heads-up was the hidden message [08:07] lifeless: I wish we had better ways to identify useless imports... is it pyflakes that can be used for that ? [08:07] spiv: ^ [08:07] vila: it can, but lazy_imports seem to upset it [08:08] poolie: ha right, thanks [08:08] i'd like to write that import effort test sometime [08:08] probably not this afternoon though [08:09] argh, 'bzr pull' is not undoable :-( [08:13] vila: it can, and mwhudson has a branch of it on lp that understands lazy_imports [08:14] * vila . o 0 (Yet another botnet job... remaining hidden until successful) [08:16] vila: and you can hook it up to flymake in emacs [08:17] mwhudson: err, .el somewhere ? [08:17] mwhudson: we really need a wiki for that kind of tricks [08:22] ok i'm off [08:22] hi *bzr [08:23] mwhudson: and there's a similar thing for vim, now [08:23] vila: https://dev.launchpad.net/EmacsTips [08:23] spiv: yeah well, who cares about that? :) [08:24] mwhudson: :P [08:24] mwhudson: OMG, Christmas time ! [08:25] mwhudson: "unused imports and unrecognized games" is the later a typo or a joke I miss ? [08:32] hi bialix ! [08:33] bonjour mon cher vila [08:40] vila, it should be "names", not "games" [08:40] jml: ok [08:41] jml: wow, already fixed, you're quick :) [09:09] Hello, is it possible to split a bzr repo into several repositories ? [09:09] I asked this question few months ago, and I was told that there will be a new format that makes that easy [09:31] hello! I stumbled accross this error message just now: http://paste.ubuntu.com/273312/plain/ - it first says ssh can not find the hostname (a problem with my nameserver) and then a very different bzr error message [09:56] hey guys. [09:56] i have a quick question on workflow.... [09:57] there's 2 of us, well, my self on my linux machine, and my windows machine is branching from the linux machine. [09:57] spiv: ssh-homedir landed, Yes ! [09:57] as i code on linux, i do bzr add; bzr commit; and that keeps the local bzr branch updated... [09:58] NET||abuse: then you push from windows and suddenly your working tree is not up-to-date anymore ? [09:58] NET||abuse: Issue 'bzr update' [09:58] as i do design on the windows machine(flash and photoshop work mostly) i want to push up to the linux branch, so,, bzr init-repository; bzr branch ssh://me@linuxip/path/to/bzr/repo; hack hack.. bzr commit; bzr merge; bzr push??? [09:59] is that the series of events? [10:00] ahh, and after i push from windows, onl linux i do what you say, bzr update; will that overwrite any changes i make on linux if say the same file was edited on windows and checked in later than the commit occured onlinux? [10:00] do i not have to bzr merge on linux? [10:00] i ithink,, i'm confused as to the functionality of some of the commands. [10:00] bzr merge and bzr update,, what's the difference? [10:00] on windows: bzr branch bzr+ssh://you@linux/path/to/branch; cd branch; hack, hack; bzr commit -m 'blah'; bzr push [10:01] It's a plausible series of events. Not the only, but workable. [10:01] on linux: 'bzr update if you did push from windows [10:01] ok, [10:01] Totally different commands; it's like asking the difference between a motorcycle and a tree stump. [10:01] what's the difference between a motorcycle and a tree stump? [10:01] NET||abuse: It may be clearer to use a master branch where both users push though [10:01] Tree stumps are hard to change the plugs in :p [10:01] What's a stump ? [10:02] vila, yeh, i'm more used to an svn style workflow [10:02] 'update' is a command that works between a working tree and its branch. In general, it means "catch me up with changes in the branch". [10:02] mvo: thanks [10:02] mvo: kindof a known cleanup issue [10:02] i guess it's only while i'm doing flash stuff and whatnot that i branch off the linux laptop to work on it... 90% of the time i'm just hacking away on my linux machine. [10:02] 'merge' is a command between branches. In general, it means "bring over changes from that other branch" [10:02] so i just have a solo project style.. [10:03] (technically, it's between your local WT and that other branch, since it doesn't _commit_ the merge, just _prepares_ them.) [10:03] fullermd, ahh,, ok,, so on the windows machine, why would i not just do bzr update also? [10:04] * vila . o 0 (Of course the question *has* to be asked to fullermd ....) [10:04] Well, you could, but it wouldn't accomplish anything toward getting changes from the branch on your Linux machine. [10:04] vila, sorry, i don't mean to make you feel left out :) [10:05] All it would do is update the WT to the local branch (which is presumably a no-op, since the only way you get new revs into that branch is through that WT anyway) [10:05] NET||abuse: I don't :) fullermd speaks better than me :) [10:05] ;) [10:05] ahh, ok,, so a flow of how the data moves from the remote branch to the local WT is waht i was missing. [10:05] Pfft. vila just knows that when *HE* asks a question of me, he ends up spending half a day tracking test failures. [10:06] when you pull down from the remote, i wasn't sure where the changes came into, i thought they were stored in the local branch in the background and then updated into the local WT [10:06] When you 'pull', that's what happens, yes. [10:07] When you 'merge', it prepares a new commit in the WT that contains those revisions (they sort of sit in limbo until you commit them, then they get hooked in) [10:07] so a pull would just pull the remote branch to the local branch in the background, and the local WT wouldn't see the pulled updates. [10:07] No, pull updates the working tree. [10:07] arrr... [10:07] But you can't pull unless you're an ancestor of the remote tip. If you have local commits, for instance, you can't pull. [10:07] (well, you can pull --overwrite, but that throws away your local commits. Probably not what you want.) [10:08] yeh, see i'm seeing it now as there are 2 copies of the code base on the machine, a branch that lives as parth of the the working history repository in the .bzr directory and the working copy.. but i feel i'm not right in thinking that. [10:09] need to study the documentation more closely again and really try to understand the data flow behind the scenes, [10:09] spiv: That bzr+ssh ~ support does all the work on the server side, right? [10:09] * vila . o 0 (Oooh, *1* half-day ? Really ?) :-P [10:09] these code management things have always taken a while to click in my head [10:09] fullermd: AIUI (bzr+ssh) yes [10:10] fullermd: that way old clients benefit too [10:10] NET||abuse: Try this. The important unit is the Revision; a given state that you commit'd (there are other ways to create them, but that's 99.99% of them) [10:10] Yah. But new clients with old servers don't :p [10:10] (I mean, it's not much of a question... it _can't_ be done anywhere but server side, so I don't know why I asked...) [10:11] ok, i think i just need to continue using it for now.. [10:11] NET||abuse: So everything you do is in some way related to manipulating revisions (rather, moving them around, since they're immutable once created) [10:11] these concepts will slowly sink in as i see them happen. [10:11] yeh, your only creating new revisions by branching the previousrevision. that makes sense, [10:11] NET||abuse: The three bits you work with are Repositories, Branches, and Working Trees. And most of the time you don't actually work with Repositories, so you can pretend they're just a part of the Branch. [10:12] So you can think of the Repo/Branch as SVN's repo, and the Working Tree as a SVN checkout. [10:12] (except of course that on a SVN project, you need to move heaven and earth to have multiple repos talking together. And even then it's iffy.) [10:13] So, you have two Branches (and their associated Repos); one on the Linux box, and one on the Windows. [10:13] And each branch has a Working Tree. [10:14] So the question you need to answer at any given point is "What am I doing with the Revisions?" [10:14] The answer can be "making a new one", which basically means editing files in the WT, fixing old bugs and creating new ones, and then 'commit'ing them to make a new Rev. [10:15] Once that's done, you have a new Rev in that Branch (and _not_ in the other Branch, so they're now out of sync, even if they were perfectly sync'd before) [10:15] The other main answer is "copying Revs from one of these Branches to the other" [10:15] That can happen via a variety of commands, the most pertinent being merge, push, and pull. Each of those applies in a slightly different situation. [10:16] push and pull are (almost) symmetrical, it just being a question of whether you're in the source pointing at the destination, or in the destination pointed at the source. [10:16] Either of them works in the case that your source already includes everything the destination does (and presumably has new stuff on top) [10:17] e.g., you commit on the Windows Branch, then you 'push' that new rev to the Linux Branch. Or you commit in the Linux Branch, and then you go into the Windows Branch and 'pull' that new one down. [10:17] aha, ok .... just one thing, i can't for the life of me imagine how from linux i could pull from windows.. [10:18] Oh, it's possible in various ways. But you may not want to bother figuring it out, since it may not matter (after all, you can just push from Win) [10:18] is that just a network protocol access problem more than anything :) [10:18] Probably. [10:18] Clear so far? [10:18] so from your own perspective, you can treat one working copy as a master repo like i am doing, pretty successfullyl. [10:19] yeh, so far it's making sense. [10:19] OK. So that just leaves us with 'merge'. [10:19] yeh, this is the fuzzy one. [10:19] Merge is what you use when you can neither push nor pull (simplifying things). [10:19] Which is to say, that _neither_ branch is an "old version" (so to speak) of the other. [10:19] Say you commit on Windows, and then you go commit something else on Linux. [10:20] Now _each_ branch has stuff the other doesn't. So you can't pull/push either way (without losing stuff). [10:20] when there are parallel changes in both branches, the local windows one and the linux one it pulled from. [10:20] Right. So now we need a way of pulling these two heads together. Or, should we say, merging them. [10:20] aha, ok that's making a little more sense. [10:21] Since accessin Win remotely has its issues, we'll just assume you're sitting at the Win box when you go to resolve this. [10:21] yeh, ok [10:21] and merging goes straight into the local windows WT [10:21] So you'd do a "bzr merge bzr+ssh://linux/foo" (or whatever the path; it will default to the same location as 'pull' if you don't explicitly give one, so you probably don't need to give one at all) [10:21] yeh, i don't have to. :) [10:22] What that would do, is bring over that Rev (or Revs, if there are more than one you don't have locally), merge the changes in the Working Tree, and stash the actual Revs in limbo. [10:22] That gives you a chance to review the changes made, fix any conflicts, and then when you're satisfied with the merge, commit it. [10:22] What that gives you now is a new Rev, which has _two_ parents, instead of the _one_ that you normally have. [10:22] To wit; your previous local head Rev, and that head Rev you got from the other branch. [10:23] So NOW, this local branch is a superset of the remote branch, and you can 'push' without losing anything. [10:23] ok, that's pretty well explained, [10:23] OK. [10:23] So since update was brought up, let's skim that real quick [10:23] ok [10:23] Update is most useful when your Working Tree is out of date with your Branch. [10:24] That will happen in this scenario when you've made changes on Windows (whether purely local or involving merge's, doesn't matter), then you 'push' them to the Linux box. [10:24] Over remote protocols, push doesn't update the working tree. [10:24] So now your WT on Linux considers itself "based on" an older revision, which is no longer the head of the branch. [10:24] And you can't commit from that state; you can only add on to the 'end'. [10:25] So you'd need to "bzr update" on Linux to 'catch up' the WT with the branch. [10:25] When you 'pull', you generally do it from within a branch, so 'pull' will update the WT as a matter of course after it does the Branch changes. [10:25] so if i did a bzr commit on the linux WT at that point, before doing update, it would complain? [10:25] Right. Also, I think 'status' warns when the WT is pointing at an older rev. [10:25] ah, ok [10:26] Pretty much what happens with SVN if you try and change a file after somebody else commit'd to it, but without update'ing. [10:26] yeh, ok [10:26] It just happens less often in bzr, since Most Of The Time(tm), people aren't push'ing revs into your branch behind your back. [10:26] :P [10:26] The only way you get new revs is by commit'ing them, or pull/merge'ing them from elsewhere. [10:26] sneaky commit's [10:27] But in some cases, like this one, you have a branch that is both "a branch you're working in", and "a branch you're pushing into from elsewhere" [the Linux one], so new revs can show up without the WT knowing about it. [10:27] And there's nothing at all wrong with that. It just means you sometimes have to nudge the WT. [10:28] huh, that goes along way to explaining how you can merge copies of code from various different members of a team.. it is a bit more of a learning curve than svn... but i can see some plausible use cases [10:28] ... I think that's sufficient confusion :) [10:28] so one last area that's confusing me, init-repository, branch and pull? [10:29] init-repo is used to create a shared repo, that can be shared across branches. [10:29] i've seen people say you should init-repository on , for example, my windows machine, before branching. [10:29] If you 'init' a branch without one (or create a branch another way, like with 'branch'), it builds an internal repository. [10:29] The downside there is that if you have 2 or 3 or 30 branches of the same project, every branch has a full copy of the history, and most of it will naturally be duplicated. [10:30] If the branches share a repository, though, all that duplicated history only gets stored once. [10:30] So if you expect multiple branches of one project, it's better to init-repo a shared repo for them before you start. [10:30] hmm, trying to think how you'd end up with multiple branches in a project.. [10:30] But it's not a big deal. You can create a repo later and change the branch[es] you already have to use it. [10:30] Heck, I've got dozens of branches of projects around :p [10:31] oh, so you could branch for a specific feature, [10:31] It's not like SVN where that repository has some semantic meaning, or acts as a boundary. [10:31] and then have 2 or 3 branches of the same code base [10:31] The only real difference is makes is saving your disk space and I/O bandwidth. [10:31] fullermd: how do you do that? Switch a branch to using a shared-repo, that is? [10:31] Which is well worth it, to be sure. But running commands between branches works the same whether they share a repo or not. [10:31] jszakmeister: See the help for 'reconfigure' [10:32] Thanks! [10:32] ok,, so you can create a branch by bzr branch [remote branch] or bzr pull [remote branch] ?? [10:32] (this is actually a _slight_ lie, because there are some edge cases where the repo will change behavior. But they don't really matter until you get deep into stuff) [10:32] pull won't create a branch; it only updates one you already made. [10:33] That's one of the asymmetries between 'push' and 'pull'; push will create the target if it doesn't exist, pull won't. [10:33] ahh, so you don't start a fresh branch with pull ,, [10:33] Right. You basically create a branch one of two ways. [10:33] init-repo or branch? [10:33] With 'branch' (make a new copy of an existing branch to work with), and 'init' (create a new empty branch) [10:33] cool.. [10:33] init, not init-repo. init-repo just makes a shared repo for branches to use. [10:33] and from an init'd branch you could pull code from a remote branch somewhere [10:33] ahhh [10:34] With a bare Repository, you can't _do_ anything. It just exists for Branches to use behind the scenes. [10:34] hmm [10:34] that's a new concept. [10:34] Sure. You could "bzr init x ; cd x ; bzr pull http://some/where" instead of "bzr branch http://some/where x", and they'd do pretty much the same thing. [10:34] (it would be silly, but you could do it ;) [10:34] cool, ok that much makes sence. [10:34] yeh, i wouldn't bother doing it, just to make sense of some of it that helps. [10:35] Yeah. It can be a bit of a change from SVN, because in SVN the bzr concepts of Branch and Repository are sorta both crammed into the Repository. [10:35] (well, half of the Branch concept anyway. The other half doesn't really exist, and just gets faked up with other primitives. But that's details.) [10:35] you couldn't do bzr init ./blah; cd blah; bzr branch [remoterepo] ./v1; bzr branch [differentrepo] ./v2; would that be wrong? [10:36] Well... it would be weird. [10:36] (and you branch a Branch, not a Repo) [10:36] ok sorry, branches then. [10:36] What you'd end up with is three branches, one with nothing in it, and two others that happened to be below it in the filesystem. [10:36] Maybe you meant init-repo there? [10:36] hmm, ok so that'd be why you use init-repo for shared repo. [10:36] not really, just getting the difference between the 2 [10:37] Basically, everything you directly interact with is a Branch. [10:37] You commit onto a Branch, look at the log for a Branch, etc. [10:37] Repositories are basically giant buckets that Revisions get dumped into. [10:37] Branches point at a Repository and say "look in there for [these revisions], those are the ones that are part of me" [10:38] if you worked in a group and had a central master branch you all checked out of, but wanted to be able to push specific changes over to a co-worker but not he central branch, you could set up pointers to eachothers local branches? [10:38] Mostly, the only time you directly look at or interact with a Repo is when you run init-repo. [10:38] ok [10:39] Usually, you'd go the other way; tell them to pull (or merge) from your branch. [10:39] checked out? there goes my svn centric concepts again.. a master branch you all branched out of... [10:39] No, you could all checkout the master branch too. [10:39] eh? [10:40] by checkout are you making a destinction from branching from the master branch? [10:40] 'checkout' creates a Working Tree for a given branch. And usually it's used for making multiple WT's on the Branch. [10:40] Which is the same flow you have in SVN. [10:40] hmm [10:40] No, by checking it out. "bzr checkout http://some/where" [10:40] (well, probably not http, since you presumable want to be able to _write_ there, so bzr+ssh:// or something) [10:41] well, web dav will allow you to write. [10:41] but anyway. [10:41] Then you basically have one shared branch that everybody has a WT on. When you commit, everybody else needs to 'update', just like in SVN. [10:41] This is a workflow that DVCS's in general kinda shun, and nobody but bzr (TTBOMK) really first-class supports. [10:41] Me, *I* use it all the dang time, because it's really useful. [10:41] oh? [10:42] TTBOMK> [10:42] ? [10:42] To The Best Of My Knowledge [10:42] ahh, just urban dictionary'd it. [10:42] Ogod, I'm speaking urban now? [10:42] :P [10:43] By default, checkout creates what's called a "heavy" checkout, which means that it also copies down and stores the full history, just like 'branch' does. [10:43] That means that things like "bzr log" don't have to go across the network to the server. [10:44] hmm, why would it be useful? It just would prevent you from being able to ever use the WT to branch from again if you wanted to push work up from another machine, like in my case, I have 3 pc's, linux windows and a netbook, which i code on sometimes when traveling.. [10:44] With a heavy checkout, you _can_ use that checkout as a source for 'branch'. [10:44] ohhh,,, yargg.. [10:44] not sure i get the difference between that and a regular branch then. [10:45] The difference is that the Branch for that WT is the one off on the server you checked out from. [10:45] So when you 'commit', the rev goes there. When somebody else has commit'd, you get told you're out of date and to 'update' before you can commit. [10:45] It's something you might commonly use for 'trunk' branches, for instance. [10:45] so it's more like a pure svn approach for that instance. [10:45] Right. [10:45] Hey I am having problems with bzr export. http://pastie.org/621552 - I run an export but the zip it produces is 0kb... [10:46] OllieR: Dunno, sorry; I don't know much about export :( [10:46] NET||abuse: Let's invent a setup much like what I use. [10:47] haha, ok .. [10:47] NET||abuse: We have a project, project1. There's a central server with a 'trunk' branch on it, that me and the other 6 guys all work on to move this thing forward. [10:47] yeh, sure. [10:47] I'll create a shared repo at /project1 (yeah, I base everything off the root dir for examples) [10:47] So "bzr init-repo /project1" [10:48] cool, we've init'd a shared repo. great. [10:48] Now, I make a checkout of the trunk: "cd /project1 ; bzr co bzr+ssh://server/project1/trunk" [10:48] Being a heavy checkout, it copies down all that history, and stores it in the shared repo instead of internally. [10:48] right, we've got our heavy checkout of the trunk branch.. [10:48] OllieR: 'bzr version' ? What happens if you don't specify '--format zip' ? [10:48] So now I can work SVN-style by working and commit'ing and update'ing and all in /project1/trunk [10:49] And in fact, if the other 6 guys are all SVN-heads, I can basically move them to bzr with this setup, and the only difference they'll see is they run "bzr whatever" instead of "svn whatever". [10:49] They don't need to know anything about local branches or distributed whosafudge. [10:49] But I do, see. 'cuz I'm smart and stuff. [10:49] haha, cool, cause i have 5 guys in the office here all on svn, and i've broached the bzr scenario with them and they're... meh.. about it. [10:49] So I want to work on adding nobbles to it. But that's gonna take a while and break stuff while I do it. People get pissed when I break trunk, for some reason. [10:50] So, I make a new branch: "cd /project1 ; bzr branch trunk add-nobbles" [10:50] yeh, i get that too.. but my commits usually break buildbot. [10:50] Now I have trunk, still a checkout of the central trunk. Anything I do there goes straight to the central server. [10:50] But I also have add-nobbles, as an independent branch, existing nowhere but on my drive. [10:50] cool, so we've branched from our heavy checkout to another local branch but both in a shred repo. one history.. gotcha. [10:51] (and that happened fast, because 'trunk' and 'nobbles' are both using the shared repo at /project1, so it didn't have to actually _copy_ any history) [10:51] vila: http://pastie.org/621552 [10:51] So now I can go ahead and work on add-nobbles for the 9 weeks it takes me to finish it, without bothering turnk. [10:51] And without having 9 weeks of changes sitting uncommitted in a checkout, just begging for disaster. I can keep on making a few commits an hour there. [10:51] yeh, this is a scenario i really like. [10:51] Of course, trunk keeps moving ahead while this is happening too. I can still be working on fixes there and commiting them into trunk. [10:51] vila: added version output and export without --format zip. It seems it just exports an empty directory... [10:52] So every couple days, I "cd /project1/add-nobbles ; bzr merge ../trunk ; (check them over) ; bzr commit", to bring in the trunk changes. [10:52] OllieR: 'bzr ls -RV' ? [10:52] This way I don't diverge too far, and when I get conflicts, they're small and easy to fix, rather than trying to do one giant merge at the end. [10:52] Of course, this doesn't affect trunk at all. Just add-nobbles. But it means that I'm keeping up with those changes all the time. [10:53] Eventually, I finish up, and it's ready to go. So I "cd /project1/trunk ; bzr update (just to be sure) ; bzr merge ../add-nobbles ; (check) ; bzr commit" [10:53] vila: null - so does bzr export only work within a working tree [10:53] I am using it from a treeless repo [10:53] My network churns for a while, uploading all those new revs to the server, and presto; the branch is landed into trunk. [10:54] Next time everyone else 'update's, they get all those changes. [10:54] fullermd, brb, one sec, have to move some application certificate for boss... [10:54] OllieR: Could be, may be worth filing a bug [10:54] Now, a few things here; first, that last merge is _EASY_, because I've already pretty much caught all the conflicts and fixed them with the periodic merges of trunk into add-nobbles. [10:55] NET||abuse: Second, it's not just the equivalent of doing a big "diff | patch"; every single one of those hundreds of revs I put into add-nobbles is now in trunk, so if we need to track back into them for something later, they're ready and accessible. [10:55] NET||abuse: In fact, I could "rm -rf /project1/add-nobbles" now if I wanted to; everything that was in it is in trunk now. [10:56] NET||abuse: And third, all of that work was local. Nobody else even had to KNOW I was working on nobbles, and nobody needs to ever know or care that I did it in a separate branch. [10:57] NET||abuse: So 95% of your team can totally ignore branching, and just work lockstep in trunk like SVN. And the 5% willing to shoulder the extra mental load of dealing with multiple branches can reap the benefits without getting in anyone else's way. [10:57] NET||abuse: And that 95% can slowly start using branches if they want too. Maybe when you're working on something big in a branch, and want to share it with other people. [10:58] NET||abuse: The two (or 3, 4, etc) of you can share the branch among yourselves, merge'ing each other. Or put it on a 'central' server, whether the same central server as trunk, or a different central server, and all create your own 'checkout's of it. [10:58] NET||abuse: (and then your own local branch's of THAT checkout, and... *headsplode*) [10:59] vila: Yeah works from a checkout! [10:59] http://pastie.org/621552 [11:00] fullermd, back, sorry, had to move a certificate for an applicaiton. [11:00] Nothing about that in the manual [11:00] NET||abuse: NP. That's what backscroll is for :) [11:00] fullermd, :) [11:01] So you can start working just like SVN, and scale up (individually or as a team), when you're ready to handle the extra complexity and have a situation where it's worth it. [11:01] OllieR: right, you can copy that paste into a bug report (slightly edited may be) [11:01] In my work, a lot of stuff still just happens on trunk. Small bugfixes, tiny features... roughly "anything that fits in one revision", I tend to just do straight on trunk. Simpler. [11:01] The longer or more involved or more breakage-inducing it is, the bigger the advantages of making a branch for it. [11:02] I can choose on a case-by-case basis. [11:02] vila: Diff too large for email (1008 lines, the limit is 1000). [11:02] vila: You couldn't have made that 8 lines shorter? :p [11:04] fullermd, hmm, that's fascinating,, i'm going to have to digest it before i use it more broadly, but i can imagine myself doing so in time.. [11:04] fullermd: I'm trying to do that right now for a follow-up :D [11:05] NET||abuse: Sure. Pick up new bits when they're helpful. [11:05] one of the reasons i'm looking into bzr is because of launchpad, we're very happy with trac here, but,, launchpad is pretty awsome... and we'll likely setup a copy and play with it :) [11:05] so i'll have to look into migrating our svn history into bzr somehow [11:05] then connect up launchpad as a web companion to the bzr projects we work on. [11:05] For a diversion, imagine I checkout'd /project1/trunk without making a shared repo at /project1, because I'm just gonna use the checkout, not branches anyway. [11:06] But later, I suddenly decide I want to use branches. But I don't want to keep copying all the history. [11:06] yeh, that was a question that was on my mind throughout this discussion. [11:06] I can "bzr init-repo /project1" to create a repo there (empty; trunk still has its stuff internally) [11:06] Then I can "cd /project1/trunk ; bzr reconfigure --use-shared" to move the history into the shared repo, and switch trunk to using it (and throw away its internal copy) [11:07] hah, that's neat [11:07] (you can also go the other way around and "bzr reconfigure --standalone" to create an internal repo for the branch and copy the history out of the shared into it. But you don't need to do that too often.) [11:07] i was thinking bzr co /projectco; then bzr init-repo /project1; cd project1; bzr co /projectco ./trunk; [11:07] (it's also not QUITE exactly the mirror operation, for reasons we don't need to go into 'cuz you'll probably never use it) [11:08] That would probably not work so well. Having a checkout of a checkout is icky. [11:08] hmm, yeh, maybe not. [11:08] It may not work at all. It may sorta work, sometimes. I don't actually know. [11:08]