| === kiko is now known as kiko-afk | ||
| poolie | hi zsquareplusc, sure | 00:11 |
|---|---|---|
| === chx is now known as chx_afk | ||
| spiv | Good morning. | 01:00 |
| === chx_afk is now known as chx | ||
| poolie | zsquareplusc: that looks ok to me on a brief read | 01:10 |
| poolie | except it seems like you should be telling people to do init-repo in the project base directory | 01:10 |
| poolie | then init under that to make the branches | 01:10 |
| poolie | hi spiv | 01:10 |
| zsquareplusc | 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:12 |
| zsquareplusc | 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:13 |
| poolie | i'm suggesting you should init-repo on the server | 01:15 |
| poolie | bzr init-repo bzr+ssh://.../project | 01:16 |
| poolie | bzr init bzr+ssh://.../project/trunk | 01:16 |
| zsquareplusc | hm ok. to late for me, i already pushed several branches :-) | 01:19 |
| poolie | spiv, sorry, i didn't get back to your review | 01:24 |
| poolie | i'll try again today | 01:24 |
| === chx is now known as chx_sleeping | ||
| lifeless | poolie: OMW | 01:30 |
| poolie | me too, soon | 01:32 |
| mwhudson | why can't a RegistryOption have a short_name? | 02:09 |
| spiv | mwhudson: good question! | 02:10 |
| lifeless | mwhudson: noone has made it work ? :) | 02:55 |
| mwhudson | lifeless: yeah, fair enough | 02:55 |
| RenatoSilva | It seems that I usually forget this, but how to overwrite a lp revision without deleting the original branch? | 03:34 |
| lifeless | push --overwrite | 03:35 |
| RenatoSilva | I thought I was thinking wrongly (that's probably why I did not thought of that flag :) ) | 03:36 |
| RenatoSilva | thank you again :) btw, is it my impression or bzr command interface needs some standardization? | 03:42 |
| RenatoSilva | e.g. some commands you need a -d ,and other you don't for the same thing | 03:43 |
| lifeless | spiv: bug 406687 - where is that up to? looks like a stale report to me ... | 03:49 |
| ubottu | Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687 | 03:49 |
| lifeless | RenatoSilva: not really, -d isn't ever really needed, is it? | 03:49 |
| RenatoSilva | lifeless: can't recall for what command... | 03:50 |
| lifeless | please do file a bug in such a situation | 03:50 |
| RenatoSilva | lifeless: pull from a bzr patch (that one generated by bzr send and that I always forget the name) | 03:51 |
| lifeless | bzr pull filename ? | 03:51 |
| === chx_sleeping is now known as chx | ||
| RenatoSilva | isn't it -d filename? | 03:52 |
| lifeless | no | 03:52 |
| RenatoSilva | bzr pull [-d] thing ---> one you say it is a patch, other you say it is a master branch | 03:53 |
| RenatoSilva | can't recall now | 03:53 |
| lifeless | have a look at bzr help pull | 03:53 |
| RenatoSilva | -d if for when . is not your branch right | 03:56 |
| RenatoSilva | *-d is | 03:56 |
| lifeless | thats correct | 03:56 |
| RenatoSilva | ok thanks | 03:56 |
| poolie | spiv, should we merge https://code.edge.launchpad.net/~spiv/bzr/lockcontention-bugs/+merge/9228 | 03:56 |
| spiv | lifeless: right, it should have been marked Fix Released in both targets; fixed now. | 04:00 |
| spiv | 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:04 |
| * spiv -> lunchb | 04:55 | |
| spiv | lunch, even! | 04:55 |
| poolie | spiv, i haven't (re)read it, i just want it off my list | 05:50 |
| poolie | this might indicate some kind of lp use case | 05:50 |
| poolie | "i don't want to think about this more til something happens" | 05:50 |
| spiv | poolie: well, how about I mark that proposal as rejected, for now | 05:52 |
| spiv | poolie: it'll still be in my list of recent branches, to remind me, without cluttering the review list for everyone else. | 05:52 |
| poolie | wfm, and just put it back to an inprogress bug | 05:52 |
| spiv | Ok. | 05:52 |
| poolie | going back to your patch now | 05:53 |
| poolie | really :) | 06:06 |
| poolie | spiv: homedir +1 | 06:33 |
| poolie | well, one question | 06:33 |
| spiv | poolie: yeah, setUp/tearDown is consistent with transport Servers (even though that class isn't a Server) | 06:40 |
| spiv | poolie: it never even occurred to me as I wrote that code to write "setUp" any other way :) | 06:41 |
| spiv | poolie: I'll make them set_up and tear_down; we may as well start using the preferred naming style. | 06:42 |
| spiv | poolie: thanks for the review! | 06:42 |
| poolie | you're welcome | 06:50 |
| lifeless | 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:01 |
| lifeless | 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:04 |
| lifeless | poolie: subunit-ls --times < text | grep blackbox | awk '{ n += $2} END{print n}' | 07:08 |
| vila | hi all | 07:16 |
| vila | lifeless: regarding config imports, my delete-useless-imports day is friday, couldn't do it yesterday, sorry about that | 07:16 |
| poolie | hi vila! | 07:17 |
| vila | lifeless: the timings run#15 should be as accurate as possible, at least the noise was certainly very low | 07:18 |
| vila | and the botnet is fully green, "Dormez bonne gens !" :D | 07:19 |
| poolie | vila, is binding the jail to the test instance really needed? | 07:42 |
| poolie | it seems a bit like unnecessary coupling to me | 07:42 |
| vila | oh in theory yes, in practice that the easiest thing to do | 07:43 |
| vila | 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:44 |
| vila | I don't consider the proposed implementation as final anyway, I just want it to be easily usable, | 07:45 |
| poolie | fair enough | 07:46 |
| vila | 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:46 |
| vila | 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:47 |
| poolie | yes, they look | 07:56 |
| poolie | anyhow, i'm going back tothat patch | 08:00 |
| lifeless | vila: no need to apologise. | 08:04 |
| poolie | i meant to say, they look great | 08:04 |
| vila | lifeless: joke :D | 08:04 |
| vila | lifeless: thanks for the heads-up was the hidden message | 08:05 |
| vila | lifeless: I wish we had better ways to identify useless imports... is it pyflakes that can be used for that ? | 08:07 |
| vila | spiv: ^ | 08:07 |
| poolie | vila: it can, but lazy_imports seem to upset it | 08:07 |
| vila | poolie: ha right, thanks | 08:08 |
| poolie | i'd like to write that import effort test sometime | 08:08 |
| poolie | probably not this afternoon though | 08:08 |
| vila | argh, 'bzr pull' is not undoable :-( | 08:09 |
| spiv | vila: it can, and mwhudson has a branch of it on lp that understands lazy_imports | 08:13 |
| * vila . o 0 (Yet another botnet job... remaining hidden until successful) | 08:14 | |
| mwhudson | vila: and you can hook it up to flymake in emacs | 08:16 |
| vila | mwhudson: err, .el somewhere ? | 08:17 |
| vila | mwhudson: we really need a wiki for that kind of tricks | 08:17 |
| poolie | ok i'm off | 08:22 |
| bialix | hi *bzr | 08:22 |
| spiv | mwhudson: and there's a similar thing for vim, now | 08:23 |
| mwhudson | vila: https://dev.launchpad.net/EmacsTips | 08:23 |
| mwhudson | spiv: yeah well, who cares about that? :) | 08:23 |
| spiv | mwhudson: :P | 08:24 |
| vila | mwhudson: OMG, Christmas time ! | 08:24 |
| vila | mwhudson: "unused imports and unrecognized games" is the later a typo or a joke I miss ? | 08:25 |
| vila | hi bialix ! | 08:32 |
| bialix | bonjour mon cher vila | 08:33 |
| jml | vila, it should be "names", not "games" | 08:40 |
| vila | jml: ok | 08:40 |
| vila | jml: wow, already fixed, you're quick :) | 08:41 |
| AnAnt | Hello, is it possible to split a bzr repo into several repositories ? | 09:09 |
| AnAnt | I asked this question few months ago, and I was told that there will be a new format that makes that easy | 09:09 |
| mvo | 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:31 |
| NET||abuse | hey guys. | 09:56 |
| NET||abuse | i have a quick question on workflow.... | 09:56 |
| NET||abuse | there's 2 of us, well, my self on my linux machine, and my windows machine is branching from the linux machine. | 09:57 |
| vila | spiv: ssh-homedir landed, Yes ! | 09:57 |
| NET||abuse | as i code on linux, i do bzr add; bzr commit; and that keeps the local bzr branch updated... | 09:57 |
| vila | NET||abuse: then you push from windows and suddenly your working tree is not up-to-date anymore ? | 09:58 |
| vila | NET||abuse: Issue 'bzr update' | 09:58 |
| NET||abuse | 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:58 |
| NET||abuse | is that the series of events? | 09:59 |
| NET||abuse | 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 |
| NET||abuse | do i not have to bzr merge on linux? | 10:00 |
| NET||abuse | i ithink,, i'm confused as to the functionality of some of the commands. | 10:00 |
| NET||abuse | bzr merge and bzr update,, what's the difference? | 10:00 |
| vila | on windows: bzr branch bzr+ssh://you@linux/path/to/branch; cd branch; hack, hack; bzr commit -m 'blah'; bzr push | 10:00 |
| fullermd | It's a plausible series of events. Not the only, but workable. | 10:01 |
| vila | on linux: 'bzr update if you did push from windows | 10:01 |
| NET||abuse | ok, | 10:01 |
| fullermd | Totally different commands; it's like asking the difference between a motorcycle and a tree stump. | 10:01 |
| NET||abuse | what's the difference between a motorcycle and a tree stump? | 10:01 |
| vila | NET||abuse: It may be clearer to use a master branch where both users push though | 10:01 |
| fullermd | Tree stumps are hard to change the plugs in :p | 10:01 |
| vila | What's a stump ? | 10:01 |
| NET||abuse | vila, yeh, i'm more used to an svn style workflow | 10:02 |
| fullermd | '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 |
| lifeless | mvo: thanks | 10:02 |
| lifeless | mvo: kindof a known cleanup issue | 10:02 |
| NET||abuse | 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 |
| fullermd | 'merge' is a command between branches. In general, it means "bring over changes from that other branch" | 10:02 |
| NET||abuse | so i just have a solo project style.. | 10:02 |
| fullermd | (technically, it's between your local WT and that other branch, since it doesn't _commit_ the merge, just _prepares_ them.) | 10:03 |
| NET||abuse | fullermd, ahh,, ok,, so on the windows machine, why would i not just do bzr update also? | 10:03 |
| * vila . o 0 (Of course the question *has* to be asked to fullermd ....) | 10:04 | |
| fullermd | Well, you could, but it wouldn't accomplish anything toward getting changes from the branch on your Linux machine. | 10:04 |
| NET||abuse | vila, sorry, i don't mean to make you feel left out :) | 10:04 |
| fullermd | 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 |
| vila | NET||abuse: I don't :) fullermd speaks better than me :) | 10:05 |
| NET||abuse | ;) | 10:05 |
| NET||abuse | 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 |
| fullermd | Pfft. vila just knows that when *HE* asks a question of me, he ends up spending half a day tracking test failures. | 10:05 |
| NET||abuse | 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 |
| fullermd | When you 'pull', that's what happens, yes. | 10:06 |
| fullermd | 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 |
| NET||abuse | 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 |
| fullermd | No, pull updates the working tree. | 10:07 |
| NET||abuse | arrr... | 10:07 |
| fullermd | 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 |
| fullermd | (well, you can pull --overwrite, but that throws away your local commits. Probably not what you want.) | 10:07 |
| NET||abuse | 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:08 |
| NET||abuse | need to study the documentation more closely again and really try to understand the data flow behind the scenes, | 10:09 |
| fullermd | 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 | |
| NET||abuse | these code management things have always taken a while to click in my head | 10:09 |
| vila | fullermd: AIUI (bzr+ssh) yes | 10:09 |
| vila | fullermd: that way old clients benefit too | 10:10 |
| fullermd | 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 |
| fullermd | Yah. But new clients with old servers don't :p | 10:10 |
| fullermd | (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:10 |
| NET||abuse | ok, i think i just need to continue using it for now.. | 10:11 |
| fullermd | 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 |
| NET||abuse | these concepts will slowly sink in as i see them happen. | 10:11 |
| NET||abuse | yeh, your only creating new revisions by branching the previousrevision. that makes sense, | 10:11 |
| fullermd | 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:11 |
| fullermd | So you can think of the Repo/Branch as SVN's repo, and the Working Tree as a SVN checkout. | 10:12 |
| fullermd | (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:12 |
| fullermd | So, you have two Branches (and their associated Repos); one on the Linux box, and one on the Windows. | 10:13 |
| fullermd | And each branch has a Working Tree. | 10:13 |
| fullermd | So the question you need to answer at any given point is "What am I doing with the Revisions?" | 10:14 |
| fullermd | 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:14 |
| fullermd | 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 |
| fullermd | The other main answer is "copying Revs from one of these Branches to the other" | 10:15 |
| fullermd | 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:15 |
| fullermd | 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 |
| fullermd | Either of them works in the case that your source already includes everything the destination does (and presumably has new stuff on top) | 10:16 |
| fullermd | 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 |
| NET||abuse | aha, ok .... just one thing, i can't for the life of me imagine how from linux i could pull from windows.. | 10:17 |
| fullermd | 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 |
| NET||abuse | is that just a network protocol access problem more than anything :) | 10:18 |
| fullermd | Probably. | 10:18 |
| fullermd | Clear so far? | 10:18 |
| NET||abuse | so from your own perspective, you can treat one working copy as a master repo like i am doing, pretty successfullyl. | 10:18 |
| NET||abuse | yeh, so far it's making sense. | 10:19 |
| fullermd | OK. So that just leaves us with 'merge'. | 10:19 |
| NET||abuse | yeh, this is the fuzzy one. | 10:19 |
| fullermd | Merge is what you use when you can neither push nor pull (simplifying things). | 10:19 |
| fullermd | Which is to say, that _neither_ branch is an "old version" (so to speak) of the other. | 10:19 |
| fullermd | Say you commit on Windows, and then you go commit something else on Linux. | 10:19 |
| fullermd | Now _each_ branch has stuff the other doesn't. So you can't pull/push either way (without losing stuff). | 10:20 |
| NET||abuse | when there are parallel changes in both branches, the local windows one and the linux one it pulled from. | 10:20 |
| fullermd | Right. So now we need a way of pulling these two heads together. Or, should we say, merging them. | 10:20 |
| NET||abuse | aha, ok that's making a little more sense. | 10:20 |
| fullermd | 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 |
| NET||abuse | yeh, ok | 10:21 |
| NET||abuse | and merging goes straight into the local windows WT | 10:21 |
| fullermd | 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 |
| NET||abuse | yeh, i don't have to. :) | 10:21 |
| fullermd | 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 |
| fullermd | 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 |
| fullermd | What that gives you now is a new Rev, which has _two_ parents, instead of the _one_ that you normally have. | 10:22 |
| fullermd | To wit; your previous local head Rev, and that head Rev you got from the other branch. | 10:22 |
| fullermd | So NOW, this local branch is a superset of the remote branch, and you can 'push' without losing anything. | 10:23 |
| NET||abuse | ok, that's pretty well explained, | 10:23 |
| fullermd | OK. | 10:23 |
| fullermd | So since update was brought up, let's skim that real quick | 10:23 |
| NET||abuse | ok | 10:23 |
| fullermd | Update is most useful when your Working Tree is out of date with your Branch. | 10:23 |
| fullermd | 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 |
| fullermd | Over remote protocols, push doesn't update the working tree. | 10:24 |
| fullermd | So now your WT on Linux considers itself "based on" an older revision, which is no longer the head of the branch. | 10:24 |
| fullermd | And you can't commit from that state; you can only add on to the 'end'. | 10:24 |
| fullermd | So you'd need to "bzr update" on Linux to 'catch up' the WT with the branch. | 10:25 |
| fullermd | 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 |
| NET||abuse | so if i did a bzr commit on the linux WT at that point, before doing update, it would complain? | 10:25 |
| fullermd | Right. Also, I think 'status' warns when the WT is pointing at an older rev. | 10:25 |
| NET||abuse | ah, ok | 10:25 |
| fullermd | 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 |
| NET||abuse | yeh, ok | 10:26 |
| fullermd | 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 |
| NET||abuse | :P | 10:26 |
| fullermd | The only way you get new revs is by commit'ing them, or pull/merge'ing them from elsewhere. | 10:26 |
| NET||abuse | sneaky commit's | 10:26 |
| fullermd | 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 |
| fullermd | And there's nothing at all wrong with that. It just means you sometimes have to nudge the WT. | 10:27 |
| NET||abuse | 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 |
| fullermd | ... I think that's sufficient confusion :) | 10:28 |
| NET||abuse | so one last area that's confusing me, init-repository, branch and pull? | 10:28 |
| fullermd | init-repo is used to create a shared repo, that can be shared across branches. | 10:29 |
| NET||abuse | i've seen people say you should init-repository on , for example, my windows machine, before branching. | 10:29 |
| fullermd | If you 'init' a branch without one (or create a branch another way, like with 'branch'), it builds an internal repository. | 10:29 |
| fullermd | 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:29 |
| fullermd | If the branches share a repository, though, all that duplicated history only gets stored once. | 10:30 |
| fullermd | 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 |
| NET||abuse | hmm, trying to think how you'd end up with multiple branches in a project.. | 10:30 |
| fullermd | 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 |
| fullermd | Heck, I've got dozens of branches of projects around :p | 10:30 |
| NET||abuse | oh, so you could branch for a specific feature, | 10:31 |
| fullermd | It's not like SVN where that repository has some semantic meaning, or acts as a boundary. | 10:31 |
| NET||abuse | and then have 2 or 3 branches of the same code base | 10:31 |
| fullermd | The only real difference is makes is saving your disk space and I/O bandwidth. | 10:31 |
| jszakmeister | fullermd: how do you do that? Switch a branch to using a shared-repo, that is? | 10:31 |
| fullermd | 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 |
| fullermd | jszakmeister: See the help for 'reconfigure' | 10:31 |
| jszakmeister | Thanks! | 10:32 |
| NET||abuse | ok,, so you can create a branch by bzr branch [remote branch] or bzr pull [remote branch] ?? | 10:32 |
| fullermd | (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 |
| fullermd | pull won't create a branch; it only updates one you already made. | 10:32 |
| fullermd | 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 |
| NET||abuse | ahh, so you don't start a fresh branch with pull ,, | 10:33 |
| fullermd | Right. You basically create a branch one of two ways. | 10:33 |
| NET||abuse | init-repo or branch? | 10:33 |
| fullermd | With 'branch' (make a new copy of an existing branch to work with), and 'init' (create a new empty branch) | 10:33 |
| NET||abuse | cool.. | 10:33 |
| fullermd | init, not init-repo. init-repo just makes a shared repo for branches to use. | 10:33 |
| NET||abuse | and from an init'd branch you could pull code from a remote branch somewhere | 10:33 |
| NET||abuse | ahhh | 10:33 |
| fullermd | With a bare Repository, you can't _do_ anything. It just exists for Branches to use behind the scenes. | 10:34 |
| NET||abuse | hmm | 10:34 |
| NET||abuse | that's a new concept. | 10:34 |
| fullermd | 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 |
| fullermd | (it would be silly, but you could do it ;) | 10:34 |
| NET||abuse | cool, ok that much makes sence. | 10:34 |
| NET||abuse | yeh, i wouldn't bother doing it, just to make sense of some of it that helps. | 10:34 |
| fullermd | 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 |
| fullermd | (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 |
| NET||abuse | you couldn't do bzr init ./blah; cd blah; bzr branch [remoterepo] ./v1; bzr branch [differentrepo] ./v2; would that be wrong? | 10:35 |
| fullermd | Well... it would be weird. | 10:36 |
| fullermd | (and you branch a Branch, not a Repo) | 10:36 |
| NET||abuse | ok sorry, branches then. | 10:36 |
| fullermd | 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 |
| fullermd | Maybe you meant init-repo there? | 10:36 |
| NET||abuse | hmm, ok so that'd be why you use init-repo for shared repo. | 10:36 |
| NET||abuse | not really, just getting the difference between the 2 | 10:36 |
| fullermd | Basically, everything you directly interact with is a Branch. | 10:37 |
| fullermd | You commit onto a Branch, look at the log for a Branch, etc. | 10:37 |
| fullermd | Repositories are basically giant buckets that Revisions get dumped into. | 10:37 |
| fullermd | Branches point at a Repository and say "look in there for [these revisions], those are the ones that are part of me" | 10:37 |
| NET||abuse | 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 |
| fullermd | Mostly, the only time you directly look at or interact with a Repo is when you run init-repo. | 10:38 |
| NET||abuse | ok | 10:38 |
| fullermd | Usually, you'd go the other way; tell them to pull (or merge) from your branch. | 10:39 |
| NET||abuse | checked out? there goes my svn centric concepts again.. a master branch you all branched out of... | 10:39 |
| fullermd | No, you could all checkout the master branch too. | 10:39 |
| NET||abuse | eh? | 10:39 |
| NET||abuse | by checkout are you making a destinction from branching from the master branch? | 10:40 |
| fullermd | 'checkout' creates a Working Tree for a given branch. And usually it's used for making multiple WT's on the Branch. | 10:40 |
| fullermd | Which is the same flow you have in SVN. | 10:40 |
| NET||abuse | hmm | 10:40 |
| fullermd | No, by checking it out. "bzr checkout http://some/where" | 10:40 |
| fullermd | (well, probably not http, since you presumable want to be able to _write_ there, so bzr+ssh:// or something) | 10:40 |
| NET||abuse | well, web dav will allow you to write. | 10:41 |
| NET||abuse | but anyway. | 10:41 |
| fullermd | 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 |
| fullermd | This is a workflow that DVCS's in general kinda shun, and nobody but bzr (TTBOMK) really first-class supports. | 10:41 |
| fullermd | Me, *I* use it all the dang time, because it's really useful. | 10:41 |
| NET||abuse | oh? | 10:41 |
| NET||abuse | TTBOMK> | 10:42 |
| NET||abuse | ? | 10:42 |
| fullermd | To The Best Of My Knowledge | 10:42 |
| NET||abuse | ahh, just urban dictionary'd it. | 10:42 |
| fullermd | Ogod, I'm speaking urban now? | 10:42 |
| NET||abuse | :P | 10:42 |
| fullermd | 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 |
| fullermd | That means that things like "bzr log" don't have to go across the network to the server. | 10:43 |
| NET||abuse | 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 |
| fullermd | With a heavy checkout, you _can_ use that checkout as a source for 'branch'. | 10:44 |
| NET||abuse | ohhh,,, yargg.. | 10:44 |
| NET||abuse | not sure i get the difference between that and a regular branch then. | 10:44 |
| fullermd | The difference is that the Branch for that WT is the one off on the server you checked out from. | 10:45 |
| fullermd | 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 |
| fullermd | It's something you might commonly use for 'trunk' branches, for instance. | 10:45 |
| NET||abuse | so it's more like a pure svn approach for that instance. | 10:45 |
| fullermd | Right. | 10:45 |
| OllieR | Hey I am having problems with bzr export. http://pastie.org/621552 - I run an export but the zip it produces is 0kb... | 10:45 |
| fullermd | OllieR: Dunno, sorry; I don't know much about export :( | 10:46 |
| fullermd | NET||abuse: Let's invent a setup much like what I use. | 10:46 |
| NET||abuse | haha, ok .. | 10:47 |
| fullermd | 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 |
| NET||abuse | yeh, sure. | 10:47 |
| fullermd | I'll create a shared repo at /project1 (yeah, I base everything off the root dir for examples) | 10:47 |
| fullermd | So "bzr init-repo /project1" | 10:47 |
| NET||abuse | cool, we've init'd a shared repo. great. | 10:48 |
| fullermd | Now, I make a checkout of the trunk: "cd /project1 ; bzr co bzr+ssh://server/project1/trunk" | 10:48 |
| fullermd | Being a heavy checkout, it copies down all that history, and stores it in the shared repo instead of internally. | 10:48 |
| NET||abuse | right, we've got our heavy checkout of the trunk branch.. | 10:48 |
| vila | OllieR: 'bzr version' ? What happens if you don't specify '--format zip' ? | 10:48 |
| fullermd | So now I can work SVN-style by working and commit'ing and update'ing and all in /project1/trunk | 10:48 |
| fullermd | 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 |
| fullermd | They don't need to know anything about local branches or distributed whosafudge. | 10:49 |
| fullermd | But I do, see. 'cuz I'm smart and stuff. | 10:49 |
| NET||abuse | 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 |
| fullermd | 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:49 |
| fullermd | So, I make a new branch: "cd /project1 ; bzr branch trunk add-nobbles" | 10:50 |
| NET||abuse | yeh, i get that too.. but my commits usually break buildbot. | 10:50 |
| fullermd | Now I have trunk, still a checkout of the central trunk. Anything I do there goes straight to the central server. | 10:50 |
| fullermd | But I also have add-nobbles, as an independent branch, existing nowhere but on my drive. | 10:50 |
| NET||abuse | cool, so we've branched from our heavy checkout to another local branch but both in a shred repo. one history.. gotcha. | 10:50 |
| fullermd | (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 |
| OllieR | vila: http://pastie.org/621552 | 10:51 |
| fullermd | 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 |
| fullermd | 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 |
| NET||abuse | yeh, this is a scenario i really like. | 10:51 |
| fullermd | 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 |
| OllieR | vila: added version output and export without --format zip. It seems it just exports an empty directory... | 10:51 |
| fullermd | 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 |
| vila | OllieR: 'bzr ls -RV' ? | 10:52 |
| fullermd | 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 |
| fullermd | 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:52 |
| fullermd | 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 |
| OllieR | vila: null - so does bzr export only work within a working tree | 10:53 |
| OllieR | I am using it from a treeless repo | 10:53 |
| fullermd | My network churns for a while, uploading all those new revs to the server, and presto; the branch is landed into trunk. | 10:53 |
| fullermd | Next time everyone else 'update's, they get all those changes. | 10:54 |
| NET||abuse | fullermd, brb, one sec, have to move some application certificate for boss... | 10:54 |
| vila | OllieR: Could be, may be worth filing a bug | 10:54 |
| fullermd | 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:54 |
| fullermd | 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 |
| fullermd | 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:55 |
| fullermd | 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:56 |
| fullermd | 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 |
| fullermd | 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:57 |
| fullermd | 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 |
| fullermd | NET||abuse: (and then your own local branch's of THAT checkout, and... *headsplode*) | 10:58 |
| OllieR | vila: Yeah works from a checkout! | 10:59 |
| OllieR | http://pastie.org/621552 | 10:59 |
| NET||abuse | fullermd, back, sorry, had to move a certificate for an applicaiton. | 11:00 |
| OllieR | Nothing about that in the manual | 11:00 |
| fullermd | NET||abuse: NP. That's what backscroll is for :) | 11:00 |
| NET||abuse | fullermd, :) | 11:00 |
| fullermd | 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 |
| vila | OllieR: right, you can copy that paste into a bug report (slightly edited may be) | 11:01 |
| fullermd | 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 |
| fullermd | The longer or more involved or more breakage-inducing it is, the bigger the advantages of making a branch for it. | 11:01 |
| fullermd | I can choose on a case-by-case basis. | 11:02 |
| fullermd | vila: Diff too large for email (1008 lines, the limit is 1000). | 11:02 |
| fullermd | vila: You couldn't have made that 8 lines shorter? :p | 11:02 |
| NET||abuse | 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 |
| vila | fullermd: I'm trying to do that right now for a follow-up :D | 11:04 |
| fullermd | NET||abuse: Sure. Pick up new bits when they're helpful. | 11:05 |
| NET||abuse | 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 |
| NET||abuse | so i'll have to look into migrating our svn history into bzr somehow | 11:05 |
| NET||abuse | then connect up launchpad as a web companion to the bzr projects we work on. | 11:05 |
| fullermd | 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:05 |
| fullermd | But later, I suddenly decide I want to use branches. But I don't want to keep copying all the history. | 11:06 |
| NET||abuse | yeh, that was a question that was on my mind throughout this discussion. | 11:06 |
| fullermd | I can "bzr init-repo /project1" to create a repo there (empty; trunk still has its stuff internally) | 11:06 |
| fullermd | 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:06 |
| NET||abuse | hah, that's neat | 11:07 |
| fullermd | (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 |
| NET||abuse | i was thinking bzr co /projectco; then bzr init-repo /project1; cd project1; bzr co /projectco ./trunk; | 11:07 |
| fullermd | (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:07 |
| fullermd | That would probably not work so well. Having a checkout of a checkout is icky. | 11:08 |
| NET||abuse | hmm, yeh, maybe not. | 11:08 |
| fullermd | It may not work at all. It may sorta work, sometimes. I don't actually know. | 11:08 |
| fullermd | With straight branches it's easier, since they stand by themselves. | 11:08 |
| NET||abuse | you'd have to redirect the parent / target repo of the second checkout back to the main repo. | 11:08 |
| NET||abuse | or main trunk. | 11:08 |
| fullermd | (before reconfigure grew those options, using 'branch' into and out of a repo to move things in/out was SOP) | 11:09 |
| NET||abuse | aha, ok... | 11:09 |
| NET||abuse | wow, brain melt..... in a good way though. | 11:09 |
| fullermd | Now, if you already had the [heavy] checkout at /projectco, and didn't want to re-transfer all the data across the network, I'd do something like this: | 11:09 |
| fullermd | bzr init-repo /project1 ; bzr branch /projectco /project1/tmp (just to 'prime' the repo) ; rm -rf /project1/tmp (cleanup) ; bzr co bzr+ssh://server/project1/trunk /project1/trunk" | 11:10 |
| fullermd | Since that temporary 'branch' primed the repo with all the revisions, that last checkout didn't have to transfer much of anything; just check that we already had everything. | 11:10 |
| NET||abuse | well you could do bzr init-repo project1; mv projectco ./project1/; cd project1; bzr reconfigure --use-shared; no? | 11:10 |
| NET||abuse | arrg, cd project/projectco; sorry | 11:10 |
| fullermd | That would also work, yep. | 11:11 |
| NET||abuse | meh,, ,missed the 1 in project1 also... | 11:11 |
| NET||abuse | cool though. | 11:11 |
| fullermd | And if you decide "hey, that should be called 'trunk', not 'projectco'", you could also "cd /project1 ; mv projectco trunk" | 11:11 |
| fullermd | (mv, not bzr mv, note) | 11:11 |
| NET||abuse | ah, handy | 11:11 |
| NET||abuse | yeh, of course. | 11:11 |
| fullermd | As long as the branch stays _inside_ the repo, you can move it around to anything you want. | 11:11 |
| NET||abuse | same as svn, using mv subcommand is only for moving items inside WT | 11:12 |
| fullermd | If you mv it outside the repo, though, it'll start weeping the first time you do something that makes it look for a rev. | 11:12 |
| NET||abuse | oh really. | 11:12 |
| NET||abuse | that's interesting. | 11:12 |
| fullermd | Yah. 'cuz it'll start looking for its repo, and... umm.... where'd it go? | 11:12 |
| fullermd | (that's one of the main cases you use reconfigure --standalone; to prepare for mv'ing it out of the repo) | 11:13 |
| NET||abuse | so you can move it into the shared repo. reconfigure to --use-shared and after that just mv ./projectco ./#trunk | 11:13 |
| NET||abuse | etc etc.. as much as you like, and it's still tied the the shared repo. | 11:13 |
| fullermd | Right. A branch finds it shared repo implicitly, by looking at .., then ../../, then ../../../, etc. | 11:13 |
| NET||abuse | ahh, that's very simplistic, but good i suppose. | 11:13 |
| fullermd | So you could mv it to /project1/foo/bar/baz/quux/trunk if you wanted. | 11:13 |
| NET||abuse | good tune. La Noy | 11:14 |
| fullermd | So you can mv the branch around inside the repo, or even mv the repo around as a whole. As long as the branches stay 'under' the repo, everything's cool. | 11:14 |
| NET||abuse | arrg,, La Noyée | 11:14 |
| NET||abuse | that's nice .. i like this shared repo idea.. | 11:14 |
| fullermd | A thing to note here, too, is that shared repos are entirely local. | 11:14 |
| NET||abuse | really handy for tying branches of related work together. | 11:15 |
| fullermd | Imagine you have the trunk and 2 feature branches in a shared repo on the central server. | 11:15 |
| fullermd | /project1/trunk, /project1/feat1, /project1/feat2 (/project1 being a shared repo) | 11:15 |
| fullermd | You could have co's of each of them in a shared repo at /myproject1 on your box. | 11:15 |
| fullermd | Or you could have co's of them in /myproject1 _without_ a shared repo, each having its own copy of the history. | 11:15 |
| NET||abuse | they are totally ignorant of eachothers shared repos' | 11:15 |
| fullermd | Or have trunk at /myproject1, and feat1 and feat2 in a repo at /myproject1features. | 11:16 |
| NET||abuse | gotcha,, yeh, that makes sense. | 11:16 |
| fullermd | Right. This is an aspect of "Repositories aren't semantic". Everybody's setup can be different. | 11:16 |
| NET||abuse | not bad, not bad. | 11:16 |
| fullermd | The only thing you ever directly look at is a Branch. | 11:16 |
| NET||abuse | yeh, i get that concept now.. | 11:17 |
| fullermd | (now, a downside of this is that we don't currently have something like "mirror-repo", or "pull-repo", to mirror/update the whole set of branches) | 11:17 |
| OllieR | vila: many thanks for your time - https://bugs.launchpad.net/bzr/+bug/432385 | 11:17 |
| ubottu | Launchpad bug 432385 in bzr "BZR export from a treeless repository outputs an empty file/dir" [Undecided,New] | 11:17 |
| fullermd | Doesn't necessarily mean we _can't_, but it's more involved. Some future work is looking in that direction. | 11:17 |
| vila | OllieR: thanks for filing that bug ! | 11:18 |
| fullermd | But one reason we've gotten by this far without it is that you often don't need it, so... | 11:18 |
| OllieR | vila: np | 11:18 |
| NET||abuse | fullermd: couldn't you just cp the shared repo, | 11:18 |
| * fullermd of course uses 'we' to mean 'somebody competent, not me' :p | 11:18 | |
| NET||abuse | you don't need a specific mirror command, | 11:18 |
| fullermd | Sure. You could tar it up and move it around, or rsync it, or whatever. | 11:18 |
| NET||abuse | so that's a simple way to mirror the repo. | 11:19 |
| fullermd | Gets more expensive than it has to be for updates though. | 11:19 |
| fullermd | (and of course you can't mirror just a subset that way) | 11:19 |
| NET||abuse | ok, but in situation where you only have http access to the repo, you may not have permissions to edit, so you may want to mirror the code base to fork the project or something. | 11:20 |
| fullermd | Right. You'd generally use 'branch' rather than 'checkout' for that. | 11:20 |
| NET||abuse | especially if you still want to pull the downstream updates back from the master project. | 11:20 |
| NET||abuse | yeh, | 11:20 |
| NET||abuse | upstream, downstream... umm which ever way that indicates.... | 11:21 |
| fullermd | Then you could just "bzr branch http://where/ever upstream", and never do anything in that upstream branch except 'pull' updates, and use it as a source for 'merge'ing them into your codebase. | 11:21 |
| NET||abuse | so still reaching for a real reason you'd need pull-repo | 11:21 |
| fullermd | (never doing any merge's or push's into it, or committing, or etc) | 11:21 |
| fullermd | It would be a lot more efficient for updating it than rsync and friends, for one. | 11:22 |
| NET||abuse | well, you may want to pull-repo if say you have multiple branches for an app that's acorss say, different hardware architectures or something? | 11:22 |
| fullermd | For another, you might want all the branches in that repo in a repo locally, but ALSO have your own local branches in that same repo (sharing the storage) | 11:22 |
| fullermd | Yeah, there are a number of good reasons for it. Just takes some planning in a VCS that's Branch-oriented like bzr. | 11:22 |
| NET||abuse | ok, cool. | 11:23 |
| NET||abuse | bleugh... my brain is full i think | 11:23 |
| fullermd | My work here is done :) | 11:23 |
| NET||abuse | ;) | 11:23 |
| NET||abuse | hehe. | 11:23 |
| SamB_XP_ | well, pull-repo would be pretty useful if you had, say, an svn-import that you wanted mirrored without actually using bzr-svn on the mirroring system ... | 11:23 |
| NET||abuse | well thank you.. i owe you beer if ever we meet ;) | 11:23 |
| fullermd | Yay, positive karma. Now I can blow it on telling bad jokes to vila! | 11:24 |
| NET||abuse | lol... | 11:24 |
| NET||abuse | you coming to ireland and going to ossbarcamp tomorrow? | 11:24 |
| SamB_XP_ | it's kinda funny that bzr can pull every branch from a typical svn repository, but not from it's own native format ;-) | 11:24 |
| fullermd | Oh, no. I hate travelling. I don't even like going across town. | 11:25 |
| SamB_XP_ | how big a town ? | 11:25 |
| SamB_XP_ | and is there any public transit ? | 11:25 |
| fullermd | Bigger than my front lawn, so obviously way too big to bother crossing. | 11:25 |
| SamB_XP_ | wow you are hecka-lazy | 11:25 |
| NET||abuse | haha, doh. | 11:25 |
| fullermd | Pfft. I'm a 'Merican. We don't do public transit :p | 11:26 |
| NET||abuse | lol..... | 11:26 |
| NET||abuse | i don't drive, i live on trams trains and buses | 11:26 |
| fullermd | I go out every morning and crank my truck up, to let it idle for a few hours and make sure there's enough CO2 in the air. | 11:26 |
| SamB_XP_ | fullermd: that doesn't stop me! | 11:26 |
| SamB_XP_ | it depends on where you live, I guess | 11:26 |
| NET||abuse | well, ireland, lotsa public transport here. | 11:27 |
| SamB_XP_ | so, like, what part of stupidville are you from ? | 11:27 |
| fullermd | Yeah, if you live in a real City, it's much more of an option. | 11:27 |
| NET||abuse | it's functional but badly managed.. | 11:27 |
| fullermd | You're happier not knowing :p | 11:27 |
| SamB_XP_ | oh, the bible belt then ? | 11:27 |
| fullermd | *I*'m happier not knowing... | 11:27 |
| SamB_XP_ | I'm a christian and I still think they're pretty crazy out there ... | 11:27 |
| fullermd | Yeah, and I'm atheist, so imagine the fun I get. | 11:28 |
| NET||abuse | do you live less than a 4 hours drive to a body of water | 11:28 |
| fullermd | Luckily, I'm a grumpy misanthrope, so it doesn't get me down :) | 11:28 |
| fullermd | I live less than a 4 minute WALK from a reasonably sized body of water. | 11:28 |
| NET||abuse | ahha, so you do leave your garden. | 11:29 |
| fullermd | I didn't say I GO there. Just that it's in spitting distance :p | 11:29 |
| SamB_XP_ | fullermd: how do you know it's not in his garden? | 11:29 |
| NET||abuse | is it an indoor swimming pool? | 11:29 |
| fullermd | 33k acre reservoir. | 11:29 |
| NET||abuse | ah hwell. | 11:29 |
| SamB_XP_ | hehehe | 11:29 |
| SamB_XP_ | piss in it ;-P | 11:29 |
| NET||abuse | i like ireland, ther's no where that's more than an hour drive from a beach. | 11:29 |
| fullermd | It's probably about 3 hours to the ocean. | 11:31 |
| fullermd | (but, yuck. Sand, and hot, and crappy bandwidth. Who'd want that?) | 11:31 |
| NET||abuse | and i'm only 20 minutes from the ocean here.. which is nice, and that's only cause i gotta drive along the coast to get away from the city ocean front. | 11:31 |
| NET||abuse | yeh, not a fan of sand,, never said it was hot... | 11:32 |
| NET||abuse | but i can get 3g on the beach. | 11:32 |
| fullermd | Plenty of hot here. I can ship some too you if you'd like... | 11:32 |
| NET||abuse | hehe, | 11:32 |
| fullermd | Round here, we have two seasons; summer, and January 15th. | 11:33 |
| NET||abuse | will you take some of our rain? | 11:33 |
| fullermd | My lawn could probably use it... 'course, then I'd have to mow it. | 11:33 |
| NET||abuse | we have a saying in dublin.. when you look south, if you can;t see the wicklow mountains, it's raining... if you can see the mountains.. it's about to rain. | 11:33 |
| spiv | fullermd: yes, totally server-side. Read the NEWS entry ;) | 11:59 |
| === AnAnt_ is now known as AnAnt | ||
| NET||abuse | fullermd, hmm, just thinking about how to push releases up to a web server now.. | 12:06 |
| NET||abuse | fullermd, i saw someone before mention a way to just do a push to an alias that is a branch on a web server, which has a hook of somesort that just pushes the updates straight out to a web directory. | 12:07 |
| fullermd | Ah, now you're wandering off from the stuff I touch. I don't use my VCS as a deployment mechanism. | 12:09 |
| fullermd | There's a bzr-upload plugin that does some things to push up just the working files (no history). | 12:09 |
| fullermd | If you have bzr on the server, you can make it a branch that you use 'update' to keep up to date with pushes, possibly semi-automated in various ways. | 12:09 |
| fullermd | (you could setup a cron job to fire it every so often. There's a push-and-update plugin which basically does a "ssh server bzr update" after each push. Probably other choices...) | 12:10 |
| === AnAnt_ is now known as AnAnt | ||
| OllieR | fullermd: "I don't use my VCS as a deployment mechanism." - what do you use out of interest? | 12:32 |
| fullermd | install(1) | 12:32 |
| === mrevell is now known as mrevell-lunch | ||
| siliconmeadow | I can't seem to find any books on Bazaar - are there any? | 13:35 |
| * siliconmeadow notices a lot of drupalers here... | 13:35 | |
| vila | siliconmeadow: not yet but some are in the works AFAIK | 13:36 |
| siliconmeadow | thank vila :-) | 13:36 |
| siliconmeadow | ^thanks | 13:36 |
| === mrevell-lunch is now known as mrevell | ||
| vila | good morning jam.sig ! :D | 14:53 |
| jam | morning vila | 14:53 |
| fullermd | Who? I can't see him in my clone... | 14:53 |
| james_w | bzr's gone crazy for me today | 14:53 |
| vila | jam: sorry about that mail, I overreacted, that bug drove me a bit nuts to say the truth :) | 14:54 |
| fullermd | It WHAT?! It told me *I* was the only one! | 14:54 |
| james_w | heh | 14:54 |
| james_w | UnexpectedInventoryFormat: Invalid format version '5' | 14:54 |
| james_w | anyone know what that could be? | 14:54 |
| vila | make ? | 14:54 |
| vila | I'm pretty sure we've seen that one recently | 14:55 |
| james_w | I've done make | 14:55 |
| vila | ubottu: UnexpectedInventoryFormat: Invalid format version '5' | 14:55 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 14:55 |
| james_w | I pulled across the API version change for the first time today | 14:55 |
| james_w | so I'm now trying to remove the page of warnings every time I invoke bzr | 14:56 |
| fullermd | loom? | 14:56 |
| james_w | that's from trying to pull bzr-svn | 14:56 |
| james_w | lp:~jelmer/bzr-svn/0.6/ | 14:56 |
| * james_w tries lp:bzr-svn instead | 14:57 | |
| james_w | same | 14:57 |
| awilkins | ubottu: dance | 14:57 |
| ubottu | Sorry, I don't know anything about dance | 14:57 |
| vila | james_w: in a clean branch ? | 15:00 |
| james_w | the other issue is that I can't update a checkout | 15:00 |
| james_w | vila: no, pulling in to my existing branch | 15:00 |
| james_w | a new branch works fine | 15:02 |
| vila | Did jelmer upgrade bzr-svn to 2a ? | 15:03 |
| vila | or did you upgrade your local branches to 2a ? | 15:03 |
| james_w | I'm rich-root-pack locally | 15:03 |
| james_w | the remote is | 15:03 |
| james_w | Branch format: Branch format 7 | 15:03 |
| james_w | Repository format: Development repository format - rich roots, group compression and chk inventories | 15:03 |
| vila | james_w: file a bug, I can't remember the details, sorry :-/ | 15:04 |
| vila | james_w: you can work with the new branch or are you blocked ? | 15:05 |
| james_w | I've just deactivated the plugin | 15:05 |
| james_w | I rarely need it, and I can always blow it away and pull | 15:05 |
| vila | huh ? Yo mean it's a bzr-svn issue ? | 15:05 |
| vila | huh ? You mean it's a bzr-svn issue ? | 15:05 |
| awilkins | I think it's an issue with his branch of bzr-svn | 15:06 |
| james_w | I deactivated bzr-svn so that I don't get the API version warning | 15:06 |
| james_w | I was trying to pull to get rid of that, but deactivating it is as good right now | 15:06 |
| vila | james_w: ok | 15:07 |
| jam | vila: don't worry about the email. It isn't a great method to convey humor/sarcasm, so it was easy to misinterpret what I originally said. | 15:32 |
| vila | jam: ok, but you were right, adding a test is needed :) Especially since I'm not sure neither of us is fully right about some bug details | 15:34 |
| vila | concretely, you said the file name can end in .sig.gz, but the SigStore don't do that | 15:34 |
| vila | and it goes both ways about conveying humor, I failed to explain what we did with fullermd to become confident we fixed it without breaking something else (granted, that was under the assumption that sigs were tested somewhere, which I'm less sure about now :-/) | 15:36 |
| fullermd | I must say, I find it humerous that after all the work that's gone into dealing with the most insane sort of charset and unicode weirdnesses, I managed to utterly trash the test suite by use of a hostname consisting of 7-bit ASCII all-lower-case alphabetics. | 15:39 |
| vila | jam: hmm, looking at the code right now, endswith is enough since it comes after a splitext that takes care of the optional final '.gz' so I think all is needed is a test, but if we don't have enough sig tests... it will be weak | 15:40 |
| jam | vila: I'm ok with being a bit weak on weave formats .. :) | 15:40 |
| vila | jam: LOL | 15:40 |
| fullermd | If they were tested too well, people might start using them... | 15:41 |
| vila | fullermd: that's karma for you ! When I met my gf 20 years ago, we argue about whether using accented letters in *comments* was a good idea | 15:41 |
| vila | fullermd: the truth is we had troubles converting from Unix to DOS because some accented 'e' were transformed in CR along the way... | 15:42 |
| fullermd | Those cross-platform relationships never work out... | 15:42 |
| vila | fullermd: I quickly switch to rwiting my comments in american to get rid of the problem.... and never came back :) | 15:42 |
| vila | never get rid of the gf though... | 15:43 |
| fullermd | Well, obviously you HAVE to keep her now. It would take too long to train yourself back into using the accents. | 15:43 |
| fullermd | vila: Re revspecs: It doesn't. The changes don't really make it any easier or harder to hack in the change... | 15:47 |
| vila | Not easier ? I'm a bit surprised... | 15:48 |
| vila | At least better localized no ? | 15:48 |
| fullermd | Not really. It always treated revnos directly in the main code path. | 15:52 |
| fullermd | This would just be also checking for "r[numeric]" as well as "[numeric]", stripping and trying. | 15:53 |
| vila | Yes, but your change should make it easier to address that bug no ? | 15:53 |
| vila | Should be a one-liner there | 15:54 |
| vila | (not counting tests of course :) | 15:54 |
| fullermd | No, it would just be the same change in a different place, AFAICS. | 15:54 |
| vila | ok | 15:54 |
| === EdwinGrubbs is now known as Edwin-afk | ||
| vila | red-button-alarm: bug #432390 | 16:16 |
| ubottu | Launchpad bug 432390 in bzr "beta-ppa fails to build 2.0rc2" [Critical,Confirmed] https://launchpad.net/bugs/432390 | 16:17 |
| vila | james_w: does that have an influence on bringing 2.0 into karmic ? (I don't think so, but better checking) | 16:20 |
| james_w | fixing now | 16:21 |
| james_w | it's an error because some paths changed but the packaging didn't change to accomodate | 16:21 |
| vila | james_w: sorry about that :-/ A whole week has passed >-/ | 16:22 |
| james_w | np | 16:23 |
| james_w | uploaded | 16:27 |
| bialix | james_w: hello | 16:36 |
| bialix | james_w: I don't remember I've received your confirmation about uploading qbzr 0.14.2 to karmic, maybe I'm missing your mail? | 16:37 |
| james_w | bialix: yeah, sorry, haven't got round to it yet | 16:40 |
| james_w | I still plan to | 16:41 |
| === davidstrauss__ is now known as davidstrauss | ||
| bialix | james_w: ok | 16:44 |
| james_w | ah, I can't upload to bzr-beta-ppa | 16:44 |
| james_w | vila: you are an admin of that team, would you add me? | 16:44 |
| idnar | I'm converting a darcs repository to bzr using darcs-fast-export / bzr fast-import; the original repository is about 131MB, the import has been running for around 3.5 hours now and has so far produced a 27GB bzr repository | 16:45 |
| idnar | can I expect that size to be reduced in some way once the import is complete? | 16:45 |
| james_w | wow | 16:45 |
| james_w | an increase like that suggests to me it's not a case of "more stuff that will be cleaned up at the end", but instead a bug in the conversion process | 16:46 |
| vila | james_w: me ? Forst news :-) Which user do you want ? The regular one or the daily debs one ? | 16:46 |
| bialix | anybody help? what is English word for append to the beginning? "prepend" seems wrong... | 16:46 |
| james_w | vila: james-w please | 16:46 |
| james_w | bialix: that is the correct word | 16:46 |
| vila | james_w: done | 16:46 |
| james_w | thanks | 16:47 |
| awilkins | prefix also would work | 16:47 |
| awilkins | Maybe | 16:47 |
| idnar | that 27GB is almost entirely composed of a single file in .bzr/repository/upload | 16:47 |
| bialix | james_w: strange... spellchecker is sutmbled | 16:47 |
| idnar | I don't really know anything about the internal repository structure, so I'm not sure what's what | 16:47 |
| james_w | idnar: that means everything is going in to one pack file | 16:47 |
| james_w | which is rather odd I would say | 16:48 |
| idnar | the conversion rate has been steadily going downwards throughout the conversion process, but that may be because it's reaching the limits of the physical memory on this box | 16:48 |
| * bialix mutters: esr's jargon file has "prepend", ok, go on | 16:49 | |
| idnar | but it's nearly finished, so I guess I'll just let it finish and see whether the result is garbage or not | 16:49 |
| * vila mutters to bialix, go on, prepend is ok ;) | 16:50 | |
| james_w | idnar: that's probably the best thing if it is nearly finished | 16:50 |
| idnar | I previously tried this with an older version of darcs-fast-export, which took about 10 minutes to get halfway through the conversion before it bombed out with an exception | 16:51 |
| vila | idnar: 'bzr info -v' as soon as it finish, then 'bzr check', and be ready to tell your story in a bug report :) | 16:51 |
| idnar | so this is incredibly slow by comparison; I probably would have killed it a long while back if I'd been around to notice | 16:51 |
| * vila . o 0 (Tell your tale ? Too obvious for native speakers ? ) | 16:52 | |
| vila | idnar: this is abnormally slow but killing it now would be losing the opportunity to understand why it's slow | 16:52 |
| idnar | I was using bzr-fastimport from bzr, but I didn't realise darcs-fast-export had been merged into that project, so I was using some older version of darcs-fast-export that I had lying around | 16:53 |
| vila | idnar: that slowness itself is worth a bug, that's why I give you upfront the commands to use to put their results in the bug report :) Also, your .bzr.log file may contain useful hints about what happened so keep it handy | 16:53 |
| idnar | *nod* | 16:54 |
| idnar | I was just looking at .bzr.log, but it just has the same output I saw in the terminal where I was running it, which just consists of the progress reports | 16:55 |
| rocky | is there anyway to tell bzr to forget a push location for a branch? (without using --remember to remember a new location) | 16:55 |
| idnar | it claims to have "finished" now, but it's thrashing around doing something or other (might just be process termination, it's at around 80% of physical memory now) | 16:56 |
| vila | rocky: short of editing branch.conf, no | 16:57 |
| rocky | k | 16:58 |
| dsuch | hmm would someone please direct me to any blog/mail discussion where emulating 'svn lock | 16:58 |
| dsuch | ' has been discussed to death already? | 16:59 |
| vila | dsuch: you mean a centralized lock in a distributed environment ? | 16:59 |
| idnar | hmm, I suspect I'm going to run out of memory here shortly | 16:59 |
| dsuch | yea | 16:59 |
| dsuch | anything that resembles it, bonus points for not using a lightweight checkout | 17:00 |
| dsuch | we have this 'awesome' tool at work and we really really need to serialize access to it | 17:00 |
| vila | dsuch: no solution today, no precise pointer for the discussion, but Russel Winder was involved IIRC | 17:00 |
| vila | or was it Nicholas Allen... | 17:01 |
| dsuch | okay, will google for that names | 17:01 |
| dsuch | thanks vila | 17:01 |
| vila | dsuch: I think one the latest tricks proposed was to rename the file fileis-locked-by-dsuch and commit that | 17:02 |
| dsuch | and to rename it back to the original name when done with changes? | 17:03 |
| vila | gross of course, but there is no such thing as centralized locks in distributed environments... | 17:03 |
| dsuch | yea I know | 17:03 |
| dsuch | that's why I'm saying 'emulating' | 17:03 |
| vila | On the other hand, if you believe in that, I have a bridge you may be interested in :) | 17:03 |
| vila | dsuch: sure | 17:03 |
| dsuch | a bridge? | 17:03 |
| vila | A tower ? | 17:04 |
| dsuch | a rook! | 17:04 |
| vila | fullermd: is that a bridge or a tower ? | 17:04 |
| james_w | oh, I haven't fixed it | 17:05 |
| james_w | this is weird | 17:05 |
| dsuch | vila: the trick won't work here though, the file in question is required by the tool and it needs to be foo, can't be dsuch-foo-copy and it's a proprietaru software we can't do much with | 17:05 |
| dsuch | vila: what kind of bridge anyway? | 17:06 |
| vila | dsuch: A tower, I can sell you the Eiffel tower if you're interested | 17:06 |
| dsuch | ah sure | 17:06 |
| dsuch | that sounds interesting | 17:06 |
| vila | dsuch: "proprietaru software we can't do much with" hmm, any free software alternative instead ? :D | 17:07 |
| Tak | is there a package deal with the arc de triomphe? | 17:08 |
| vila | dsuch: seriously, you have binary files that can me modified in parallel ? | 17:08 |
| dsuch | there is one, but it's been abandoned for some time | 17:08 |
| vila | Tak: sure, some price | 17:08 |
| dsuch | no, it's not binary but it produces incomprehensible XML, extremely hard to merge it | 17:09 |
| dsuch | vila: I thought you were talking about some new alternative svn-to-bzr 'bridge' ;-) | 17:09 |
| vila | dsuch: ouch, sorry :-) | 17:10 |
| vila | dsuch: do you really need to put it under version control if you can't understand it then ? | 17:10 |
| dsuch | I don't need to understand the underlying format, just the output it produces :) | 17:11 |
| vila | let me rephrase, why do you need a lock ? | 17:11 |
| dsuch | there are about 20-30 people possibly interested in modifying it, the tool chose to store all its data in XML, | 17:13 |
| dsuch | and when people are applying changes in parallel it's quite to merge the changes, | 17:13 |
| dsuch | quite *hard I mean | 17:13 |
| vila | quite hard or impossible ? Still needed or refused now because it's too much work ? | 17:14 |
| dsuch | besides, the very process of producing the output is under the control of one person (and it ought to be like that), | 17:15 |
| dsuch | too much work | 17:15 |
| vila | but other people still need to be able to read it right ? | 17:15 |
| dsuch | we'd rather focus on the real stuff not on grokking the XML, it's a completely unneeded knowledge | 17:15 |
| dsuch | yea | 17:16 |
| vila | So your use case is a bit simpler... | 17:16 |
| vila | but only a tiny bit | 17:16 |
| dsuch | mhm? | 17:16 |
| dsuch | you think so? | 17:16 |
| vila | You should be able to hack around a solution with a commit hook and one master file replicated on a read-only file | 17:17 |
| vila | Then the hook checks that only one people can modify the master and copy it to the read-only one, all other attempts to modify the read-only one should be refused | 17:18 |
| vila | Still quite hackish since that means people modifying the "read-only" version will need to revert it before getting the new changes :-/ | 17:19 |
| dsuch | not to mention that it's currently way above what I know about bzr :) | 17:19 |
| GaryvdM | Hmmm selftest --coverage seems to only show the coverage of the first test run on windows. | 17:20 |
| idnar | hrm, well that was exciting | 17:20 |
| dsuch | you said I needed a commit hook, you mean a push hook, right? | 17:20 |
| idnar | I nearly ran out of memory, but it managed to get far enough to explode with an exception | 17:20 |
| idnar | guess I'll file that bug report now | 17:20 |
| vila | idnar: too bad :-/ | 17:21 |
| dsuch | because I still would want to be able to hack on it and commit locally | 17:21 |
| bialix | GaryvdM: hello | 17:21 |
| idnar | oh, hmm, it deleted the data too, I guess | 17:21 |
| idnar | so that doesn't help much | 17:21 |
| vila | dsuch: push time is too late, you'll run into conflicts at merge time and will need to find a way to always revert to the "right" version (come to think of it, that may be easier: no code to write :) | 17:22 |
| vila | dsuch: oooh, you want to commit it anyway... but then you don't want a lock ! | 17:22 |
| idnar | bleh | 17:22 |
| vila | idnar: report it anyway ! | 17:22 |
| idnar | the exception traceback occurred in an error handling path, masking the real exception | 17:23 |
| dsuch | vila: I'd like to commit to it /locally/ and then push it to the central place | 17:23 |
| vila | idnar: I'm not up-to-date about fast-import, others may know better | 17:23 |
| bialix | heh | 17:23 |
| dsuch | vila: and to make sure no one has introduced any changes in the time I was working with it | 17:24 |
| vila | dsuch: and you expect the lock to occurs how and when then ? | 17:24 |
| * bialix trying one more time | 17:24 | |
| bialix | GaryvdM: hello | 17:25 |
| GaryvdM | hi | 17:25 |
| bialix | how's you? | 17:25 |
| dsuch | vila: not saying it needs to be a lock, but right now, with SVN, I'm able to get the lock, work on it (no local commits unfortunately), then commit it to the repo | 17:25 |
| bialix | GaryvdM: I've almost released 0.14.2 | 17:25 |
| bialix | rats | 17:25 |
| vila | dsuch: If you're the one modifying it (and the 20-30 others are using it) AND you're the one managing the trunk THEN all you have to do is ensure that nobody else than you modifies it, | 17:25 |
| dsuch | vila: right | 17:25 |
| vila | OR if you realized someone modified it anyway, push your own version on top of theirs | 17:26 |
| * bialix wonder what client Gary used | 17:26 | |
| vila | i.e. no lock but monitoring the changes :) | 17:26 |
| jam | dsuch: note that fundamentally even svn locks aren't what you want | 17:27 |
| dsuch | eh | 17:27 |
| jam | because you don't find out that someone has the lock until you *commit* it. | 17:27 |
| jam | which is too late | 17:27 |
| dsuch | vila: and merge manually? | 17:27 |
| dsuch | jam: not really, I know it when I try to get a lock | 17:27 |
| jam | unless, I guess, people are disciplined enough to take the locks out first | 17:27 |
| dsuch | yep | 17:27 |
| jam | but in that case, there is some easy plugin-ish things that you could od | 17:27 |
| vila | dsuch: you decide, you can refuse to merge and just keep your version and erased the OTHER's changes | 17:27 |
| james_w | vila: I'm too stupid to figure out how to fix that build failure right now, and have to head out to meet someone | 17:28 |
| james_w | I will try and fix it over the weekend or something | 17:28 |
| vila | james_w: thanks a lot | 17:29 |
| jam | dsuch: so *I* would hack together a "bzr lock-file" plugin that would write a file on the central target location | 17:29 |
| jam | that says what files are currently locked | 17:29 |
| jam | I'm happy to discuss the shape of something like that | 17:29 |
| jam | for example, is this using a checkout (heavy or light) | 17:29 |
| jam | a preferred submit branch | 17:29 |
| jam | etc | 17:29 |
| idnar | reported as bug #432586 if anyone is following along | 17:29 |
| ubottu | Launchpad bug 432586 in bzr-fastimport "darcs -> bzr import extremely slow before failing" [Undecided,New] https://launchpad.net/bugs/432586 | 17:29 |
| dsuch | well I'll be happy to test it when you create it :) | 17:29 |
| jam | the locations of the locks could be put somewhere hard-coded | 17:30 |
| jam | or could be per project, etc | 17:30 |
| james_w | idnar: did you pipe darcs-fast-export to a file, or directly in to bzr? | 17:30 |
| dsuch | but I completely don't know anything about bzr internals, I took a peek at the code when it was at 0.0.0.8 I think :) | 17:30 |
| jam | dsuch: can you give more information about how your work is laid out? | 17:30 |
| jam | what branches people use, where things are stored, etc? | 17:30 |
| dsuch | but now I can see it's somewhat larger | 17:31 |
| dsuch | er, but we don't use bzr right now | 17:31 |
| idnar | james_w: I piped it | 17:31 |
| idnar | er | 17:31 |
| idnar | james_w: I piped it in over stdin | 17:31 |
| vila | idnar: now that you know that your PC didn't die... | 17:32 |
| james_w | idnar: is this a public repository? | 17:32 |
| vila | idnar: you should retry with the latest bzr and bzr-fast-import versions | 17:32 |
| james_w | idnar: piping to a file and getting the size of that file could be interesting | 17:32 |
| dsuch | jam: we're using SVN and we're evaluating the alternatives (a colleague is looking at git) | 17:32 |
| james_w | if it's 300GB then that might indicate the problem is in the export | 17:33 |
| idnar | james_w: I'm trying that now | 17:33 |
| james_w | thanks | 17:33 |
| jam | dsuch: so you don't actually have a layout yet | 17:33 |
| bialix | garyvdm: hi again | 17:33 |
| idnar | 3.3GB so far, but that's uncompressed | 17:33 |
| garyvdm | Hi bialix | 17:33 |
| dsuch | jam: no bzr layout, no | 17:33 |
| bialix | how's you? | 17:33 |
| jam | idnar: so it is expected that the fast-export => fast-import process is going to generate some large intermediate steps | 17:33 |
| bialix | garyvdm: can we finish qbzr 0.14.2 this weekend? | 17:33 |
| jam | idnar: you did 'fast-export > to_file.fi" first? | 17:34 |
| bialix | garyvdm: don't disconnect please please please | 17:34 |
| garyvdm | bialix: What needs to be done? | 17:34 |
| jam | Is that your 27GB file? | 17:34 |
| idnar | jam: no, the failed attempt was piping darcs-fast-export into bzr fast-import - | 17:34 |
| jam | idnar: so first off, I don't recommend piping | 17:34 |
| jam | I recommend redirecting to a file | 17:34 |
| jam | and then loading from there | 17:34 |
| idnar | the 27GB was a single pack file in the repository which got deleted along with everything else when it failed | 17:34 |
| bialix | garyvdm: PPA | 17:34 |
| garyvdm | bialix: ok | 17:34 |
| idnar | I'm trying that now | 17:35 |
| garyvdm | bialix: ubuntu karmic? | 17:35 |
| jam | dsuch: so there are lots of potential issues | 17:35 |
| jam | for example, how should locks be coordinated between branches? | 17:35 |
| bialix | garyvdm: karmic, yes. james_w promised to help, but not yet | 17:35 |
| jam | do you want anyone working on any branch to (cooperatively) block someone working on another branch? | 17:36 |
| garyvdm | Ok | 17:36 |
| jam | (equivalent in SVN is that you lock branches/*/file/foo trunk/file/foo, for example) | 17:36 |
| bialix | james_w: can you coordinate with Gary? | 17:36 |
| idnar | some brief mental gymnastics suggests that 27GB might not be unreasonable for the size of the uncompressed export file | 17:36 |
| jam | or just always lock trunk/file/foo | 17:36 |
| dsuch | jam: in my use case, they shouldn't, there's only one file (a directory, really) that needs to be locked upon starting the work | 17:36 |
| dsuch | jam: and right now, it's always in trunk | 17:36 |
| bialix | garyvdm: ok, so I'll build installer soon | 17:37 |
| bialix | garyvdm: and will do announce after PPA | 17:37 |
| jam | dsuch: but if you aren't using checkouts, then presumably you *want* people to be working in separate branches | 17:37 |
| dsuch | mhm, I think I do | 17:37 |
| garyvdm | bialix: I'll only be able to get to it on sunday. | 17:37 |
| bialix | garyvdm: ok for me | 17:38 |
| jam | dsuch: so if you take out a directory lock, does that lock all files underneath? | 17:38 |
| dsuch | it does | 17:38 |
| garyvdm | bialix: going to SFD tommorrow, and then to my Dads | 17:38 |
| jam | dsuch: so if people are working on independent branches, then you want to be blocking *across* branches when they go to commit | 17:38 |
| bialix | garyvdm: what is SFD | 17:38 |
| garyvdm | It's my birthday tommorow :-) | 17:39 |
| bialix | garyvdm: ? | 17:39 |
| garyvdm | Software Freedom Day. | 17:39 |
| dsuch | but we also learnt that *sometimes* we can get a lock on the master file only, sometimes it works | 17:39 |
| bialix | garyvdm: congrat | 17:39 |
| bialix | so, see ya later | 17:39 |
| dsuch | jam: oh sure, if people are generally going to work in their own branches then I'd like the lock to be kept across them | 17:39 |
| bialix | bya all | 17:40 |
| dsuch | jam: which seems to be kind of impossible in general case | 17:40 |
| bialix | .me means bye | 17:40 |
| garyvdm | bialix: http://softwarefreedomday.org/teams/africa/SouthAfrica/Pretoria | 17:40 |
| dsuch | jam: but hey, who am I to tell you what's possible :) | 17:41 |
| bialix | garyvdm: looks cool | 17:41 |
| idnar | hmm, I should probably attempt this on a faster system | 17:43 |
| jam | dsuch: so basically you just configure a central location where the locks are stored | 17:45 |
| dsuch | aha | 17:45 |
| dsuch | I understand you're thinking aloud of some not yet written feature? | 17:46 |
| jam | dsuch: well, being written as we chat :) | 17:46 |
| dsuch | heh | 17:46 |
| dsuch | want me to grab it from somewhere? | 17:47 |
| jam | dsuch: given that it doesn't really exist as of yet, I'll let you know when I get somewhere | 17:47 |
| jam | most likely I'll put it up as lp:~jameinel/+junk/file-locking | 17:47 |
| jam | to eventually become lp:bzr-file-locking | 17:47 |
| dsuch | heh that's what I meant :) | 17:47 |
| jam | or something along those lines | 17:47 |
| phinze | jam: back from canada? :) | 17:49 |
| === deryck is now known as deryck[lunch] | ||
| garyvdm | vila: When you said that NEWS entries must be sorted alphabetical, is that the actual text in the entry ? | 17:50 |
| vila | garyvdm: yes | 17:51 |
| garyvdm | thanks. | 17:51 |
| jam | phinze: yep | 18:04 |
| jam | garyvdm: yeah, it makes for really weird reading | 18:05 |
| jam | for it makes reading really weird yeah, | 18:05 |
| jam | :) | 18:05 |
| jam | Odd that the sorted version is still rather readable | 18:05 |
| garyvdm | jam: lol | 18:06 |
| jam | garyvdm: but yeah, within any given section (like Bugs) we sort by the first words of the sentence | 18:06 |
| jam | it isn't a great system, but it has reduced the amount of spurious conflicts (a little bit) | 18:06 |
| garyvdm | bye all | 18:09 |
| RenatoSilva | bzr+ssh is just ssh actually, right? | 18:10 |
| awilkins | RenatoSilva: No, it speaks the HPSS protocol across the SSH to an instance of bzr at the other end | 18:10 |
| awilkins | RenatoSilva: If you want "just ssh" you want sftp | 18:10 |
| jam | dsuch: I'll probably be offline for some of the afternoon, but I'll let you know where I get to. | 18:10 |
| jam | its an interesting problem that has been brought up before | 18:11 |
| dsuch | sure, thanks anyway jam | 18:12 |
| dsuch | it's not that we need to migrate right now | 18:12 |
| jam | dsuch: sure, mostly you just brought up the idea | 18:14 |
| jam | of course, there are *tons* of complications, so I'm trying to figure out how much to implement | 18:14 |
| jam | for example, if I lock "dir/" | 18:14 |
| jam | and you rename "dir/foo => otherdir/foo" | 18:14 |
| jam | should "foo" stay locked? | 18:15 |
| dsuch | remember that it doesn't need to solve all people's use cases | 18:15 |
| jam | what about if I add "dir/bar", should that fall under the lock | 18:15 |
| jam | etc | 18:15 |
| RenatoSilva | awilkins: the SSH protocol is not related only to os shells, right? | 18:15 |
| RenatoSilva | awilkins: so on the server I can put bzr and send bzr commands instead of shell commands, right? | 18:16 |
| dsuch | jam: if it helps, 1) yes, it should stay locked in my case 2) adding a file when 'dir' is under the lock shouldn't be possible | 18:16 |
| RenatoSilva | awilkins: is the HPSS a proprietary protocol of bzr? | 18:16 |
| awilkins | RenatoSilva: Yes (not sure I got the acronym right either) | 18:17 |
| RenatoSilva | awilkins: yes for which question ? :) | 18:18 |
| awilkins | Yes, it's the bzr network protocol | 18:18 |
| RenatoSilva | ah ok, thanks | 18:19 |
| RenatoSilva | now I got why it is called bzr+ssh | 18:19 |
| jam | dsuch: should it fail to 'add' or should it fail to take a lock on the dir? | 18:19 |
| awilkins | RenatoSilva: you can do bzr:// on it's own, but it's got no security of it's own | 18:20 |
| RenatoSilva | it's ssh, but not over the ssh port, which is for shell | 18:20 |
| awilkins | RenatoSilva: Yes, it's over the ssh port | 18:20 |
| RenatoSilva | 22? oh | 18:20 |
| LarstiQ | RenatoSilva: ssh is the transport, bzr is on top of that | 18:21 |
| awilkins | RenatoSilva: All ssh does is tunnel traffic to an instance of the shell at the remote end (bash, csh, whatever) | 18:21 |
| LarstiQ | RenatoSilva: what it does is set up a ssh connection, start bzr on the other side, and then talk bzr across the ssh connection | 18:21 |
| awilkins | bzr+ssh tunnels traffic to an instance of bzr | 18:21 |
| RenatoSilva | awilkins: All ssh does is tunnel traffic to an instance of the shell at the remote end (bash, csh, whatever) ----> and in this case the "shell" is bzr | 18:22 |
| awilkins | RenatoSilva: pretty much, yes. Part of the ssh protocol is you specify what you want to run, and if you don't, it uses the default shell configured for the remote user | 18:23 |
| jam | dsuch: also, how do you want to handle the unlock process | 18:24 |
| jam | how do we know if a given user has the right to unlock it? | 18:24 |
| jam | Is it just on-your-honor? | 18:24 |
| jam | Do we check the username first | 18:24 |
| jam | and if that fails, allow them to 'break' the lock? | 18:24 |
| jam | etc | 18:24 |
| RenatoSilva | <LarstiQ> RenatoSilva: what it does is set up a ssh connection, start bzr on the other side, and then talk bzr across the ssh connection --> how about the mentioned HPSS? The way you say is like the talk are just bzr shell commands... | 18:24 |
| jam | dsuch: and if I have 'foo/bar' locked, can you take a lock out on 'foo'? | 18:25 |
| RenatoSilva | LarstiQ: sorry I think I misunderstood you | 18:26 |
| dsuch | jam: you mean forcibly? | 18:28 |
| jam | dsuch: so for example | 18:28 |
| jam | you take out a write lock | 18:28 |
| awilkins | RenatoSilva: It talks the server protocol ; the server is the remote instance of bzr. It's equivalent to running `bzr serve --directory=/ --allow-writes` | 18:28 |
| jam | then I should be able to see that | 18:29 |
| jam | can I break your lock? | 18:29 |
| jam | if I just do "unlock" does it do it automatically? | 18:29 |
| dsuch | yes, you can | 18:29 |
| jam | does it check the user? | 18:29 |
| jam | or do you expect something stronger than that | 18:29 |
| dsuch | currently it doesn't | 18:29 |
| dsuch | we're a small team so if someone does it I can always get him on the phone and ask why she did that | 18:30 |
| dsuch | eh, *her :) | 18:30 |
| RenatoSilva | awilkins: ok thanks | 18:30 |
| jam | dsuch: well, do you want logging of how locks have transitioned, then? | 18:30 |
| dsuch | jam: everyone has equal rights here, so everyone can steal any lock | 18:30 |
| jam | (see why this doesn't just exist :) | 18:30 |
| dsuch | Yea, lots of questions. | 18:31 |
| awilkins | In SVN, locks are more of a warning... you can ignore them (reset the write bit), and steal them | 18:31 |
| RenatoSilva | thanks | 18:31 |
| awilkins | They were pretty much an afterthought in the design too - I would guess because people who were used to Visual Sourcesafe and the like wanted them | 18:31 |
| dsuch | jam: a log could be handy for answering the who-stole-my-lock kind of questions | 18:32 |
| awilkins | SVN logs it | 18:32 |
| awilkins | When you steal a lock you have the opportunity to provide an explanation | 18:32 |
| dsuch | yea | 18:32 |
| awilkins | AFAIK there are still some bugs about locks not being renamed along with their files in the repository | 18:33 |
| awilkins | I had to write some admin scripts to purge dead locks | 18:33 |
| jam | awilkins: files are never renamed, they are copied :) | 18:33 |
| dsuch | what a great last words :) | 18:34 |
| awilkins | The problem with locks is magnified by the DVCS model if you ask me | 18:34 |
| awilkins | It's not so great in SVN ; but it works where you are working on the same branch and have files that are (eg) Visio diagrams, etc, binaries that don't merge well | 18:35 |
| awilkins | But SVN was designed for edit / merge work cycles not lock / edit / commit like VSS | 18:35 |
| dsuch | *nod* but then again, the case we were discussing involves a human gatekeeper who really needs to be sure he's using the latest version, not modified by anyone | 18:35 |
| awilkins | dsuch: Which is difficult when there are branches that the server doesn't even know about | 18:36 |
| dsuch | right | 18:36 |
| awilkins | dsuch: I suppose you could have a "lock server" feature that keeps a map of lock : file-id | 18:37 |
| dsuch | I think that's what jam is thinking of | 18:37 |
| awilkins | I should refrain from joining in, my head is full of bursting/bucket tries, I need to work out how to splat them into a filesystem | 18:39 |
| === deryck[lunch] is now known as deryck | ||
| Naoki | Hi | 19:16 |
| Naoki | Some Japanese Documents in here: lp:bzr-doc-ja | 19:17 |
| === awmcclain_ is now known as awmcclain | ||
| phinze | level -JOINS -PARTS -QUITS | 20:34 |
| === pwolanin is now known as pwolanin|afk | ||
| idnar | bleh, hit 45GB on this export and ran out of space | 22:08 |
| * idnar throws in a gzip | 22:08 | |
| === abentley1 is now known as abentley | ||
| === Toksyury1l is now known as Toksyuryel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!