[00:33] sven_oostenbrink: Sounds reasonable enough. [00:36] fullermd: I do have one doubt though.. [00:37] fullermd: 1) I'd like to use ssh based protocols for this [00:37] fullermd: so probably I'll use ssh+bzr:// right? [00:38] bzr+ssh, yeah. [00:38] fullermd: Thing is, AFAIU, there will be one .bzr directory on that server which will be the trunk repo, right? [00:39] The trunk _branch_, yes. It may have the repo as well, or you may have that off in another .bzr/. [00:39] fullermd: How can I do the merge then? Because, say, if I would be doing the merges for all 3 persons.. That would mean that on the server itself, Id have to BZR merge the changes from me, and the 2 other persons.. But then security comes into play, bzr somehow needs to get these changes from the other users... [00:40] again, AFAIU, the other users will have local branches, so they'll commit there.. I can then go to that trunk branch and pull in their changes, right? [00:40] am I making any sense here? :) [00:41] That would be one way, yes. You're essentially acting as a human gatekeeper, so all commits to that central branch will be done by you. [00:41] So, you'd just own it. [00:41] fullermd: if I, user "sven" want to access the changes from the other users, I could pull in those changes.. but that means there must be a user "sven" available on the machines of these persons, right? and that user sven should have read access to the BZR repo of those persons.. right? [00:42] fullermd: yeah, I'd like to be the only one who can tree merge, to assure that the tree stays stable.. [00:42] Well, it means you need to access them _somehow_. [00:42] The thing is, I see security being a barrier here.. [00:42] You could have ssh on all their boxes (and that user be allowed to read their branches), is one way. [00:43] They could publish them via http:// or bzr:// from their boxes. They could have their own accounts on the central server that they push up to, then you merge from there. [00:43] fullermd: so.. [00:43] They could send you merge directives via mail. [00:44] fullermd: I have the trunk.. from there i create branches A, B, C (Im A, the other two developers are B and C).. Then each of A, B and C branch from their server branch (Im counting 7 branches now).. they work locally.. wheneverthey have somehting, they push / merge to their server branch.. and I merge their server branches into the trunk branch.. [00:44] fullermd: that makes sense? [00:45] Well, it works. Why make the A B C branches, instead of just letting everybody branch off the trnk? [00:45] fullermd: I've seen the send by email option.. Though it sounds interresting, its not something I'd pick at first sight.. dunno, somehow it seems.. not pretty :) [00:45] It seems an unnecessary indirection. And it will make it much harder for them to pick up change from trunk. [00:45] fullermd: so they branch directly from the trunk.. Meaning they'll have the branch locally on their computer, right? [00:46] Yeah, it would actually require that I send them trunk changes.. not a nice option.. [00:46] fullermd: I could let them branch directly to the trunk, but that would require the trunk to be on a location where A, B and C have write rights, correct? [00:46] Yeah, making the copy of trunk for each of them on the server and having them go from there isn't necessary, unless for some reason you don't want them even having read on trnk. [00:46] But that sounds like way too much trouble all around. [00:47] No, they only need read to branch from it. [00:47] (you may still want to branch trunk yourself into shared repos for each of them on the server, just to prime it with the existing revs and save them some upload, but that's unrelated) [00:47] fullermd: but if they want to merge to the trunk directly, they need write access there, right? [00:48] Yes. [00:48] fullermd: another question.. what if I don't want a central server for the trunk repo, I want to use my own laptop.. [00:48] But you could give them _read_ on it, they branch from it, and pull/merge later changes made from it, and only you have _write_ and gatekeeper it. [00:49] Well, remember that 'trunk' is a social question, not a technical one. On a technical level, all you have are a bunch of branches spread out over the world. [00:49] fullermd: interresting problem that THEN shows up is that my laptop doesnt have a static IP.. How can I fix that? can they just push to an IP that I give them? Will BZR know that its my laptop even though the IP is different? [00:49] Treating one of them specially in various ways is just up to how you want to arrange it. [00:49] A floating laptop has the property that, generally, only you can do stuff straight on it. So to have the 'trunk' there means that, generally, nobody else can even get at it to pull down new changes from it. [00:50] fullermd: yeah, I understand that part (thank god... gotta hate SVN by now, hehehe) [00:50] So generally you want a 'trunk' branch to be somewhere always connected and reasonably stable. [00:50] Of course, you CAN develop without a trunk at all. It's just tough to scale. [00:50] fullermd: well, it needs to scale.. I was thinking, BZR being a DVCS, that it might not need a central place for all changes [00:51] It doesn't, but having a specific point of reference is, if not necessary, at least highly desirable in most development. [00:51] sven_oostenbrink: scaling is a human problem, tech wise we scale out [00:52] fullermd: lifeless: Gottit [00:53] fullermd: so Im pushing my just newly created BZR branch to the central server.. since there is nothing there, it will appear there as a new branch, right? [00:53] Yes. [00:54] fullermd: the central server also requires BZR to be installed, right? [00:56] If you want to use bzr+ssh or ever work with the branch directly on the server, yes. [00:56] fullermd: whats the difference then, practically speaking, between sftp:// and bzr+ssh:// [00:56] You CAN use it simply as a dumb server via sftp or the like. But if you can avoid it, you don't want to. [00:57] bzr+ssh is bzr talking to bzr. sftp is bzr talking to a quirky and very slow filesystem. [00:57] fullermd: Im avoiding it as we speak, installing bzr now :) but whats the difference anyway? just to know.. [00:57] fullermd: as in, bzr+ssh is way faster than sftp... [00:57] both are secure anyway so.. [00:57] sven_oostenbrink: server side operations [00:58] sven_oostenbrink: e.g. to consolidate two files over sftp = 'read file a, read file b, write file c, delete a, delete b' [00:58] over bzr+ssh, we send a single command [00:58] fullermd: another thing.. Im about to up 40.000 files.. if the connection drops out half way, is there a "resume" option, or woud I have to start from 0 again? [00:58] and don't have to copy all the data over the network in both directions [00:58] lifeless: understood [01:01] Well, you send revisions, not files. [01:01] I think if you're pushing a bunch of revs into an existing repository, they checkpoint every so often, so you wouldn't lose them all on a connection drop. [01:01] nope [01:01] But an initial checking is just one rev anyway, so it wouldn't. [01:01] fullermd: so this first 40.000 files revision should pass without problem, or it will fail? [01:01] its atomic, all or nothing. [01:02] in that case I better pray my new 3G network card will hold out.. [01:02] I had MANY problems with SVK in that aspect.. one network hickup, and I could start all over on large merges.. [01:02] Well, in consolation, any future revs should be pretty small. [01:03] fullermd: yeah, I know.. its just that Im in a datacenter now, all local.. but I have to leave in about 10 mins, and I still am updating the central server.. so I gotta do the first commit over my 3G card instead of over a 1Gbit network.. :) [01:04] Well, if you ssh'd over SCTP, you could make it a portable session, and relocate it to the new IP on 3G when you need to leave :p [01:04] But if you can't move it across a gigabit network in 10 minutes, you probably shouldn't even try on 3G at all... [01:07] fullermd: I can do it over 1Gbit in under a minute, sure, but the server isn;'t ready yet for another 30 mins.. there's the prob.. [01:07] fullermd: lifeless: Thanks lots to both, I'll start messing arounhd tonight to see how it will work.. [01:07] laters! [01:09] I should hope so. A minute of gigabit time is about 7 gig. That's a pretty sizable branch :p [04:51] statik: do you know about package branches [04:52] statik: lp:~statik/ubuntu/lucid/bzr-explorer/ppa would be a better branch to use ;) [10:41] I added a key to launchpad but I haven't configure ssh to search for that key. How come that bzr co lp:foobar does not complain? === raimue is now known as Raim [11:51] I have a branch from a mirrored branch in lp, and I now want to host it in lp, what should I do, branch it and then push it in the new location? thanks [11:52] should I unbind it first or something? [14:48] alefteris: Yes, push it to a new location on LP. [14:48] alefteris: (You can even rename or delete your old branch so you can push it to the same URL. Bug and suscriber associatiosn will still be attached to the old branch, though.) [14:49] alefteris: Ah. never mind. [14:49] Peng, thanks, that's what I did :) [14:50] :) [14:56] Is it possible to pull from multiple sources with bzr? [14:56] For instance, I'm working in centralised mode on a project, which is a fork of drupal. I'd like to be able to keep merging in remote changes from drupal, but make my own changes and keep pushing those to my own repo [15:13] anyone? [15:15] You can "bzr pull" or "bzr merge" from any URL you want to.. [15:15] hm [15:15] After merging, bzr told me "working tree is out of date, run 'bzr update'" and when I did, it started calling out lots of conflicts [15:15] Nothing had changed in the upstream branch [15:15] If I ignore the message, it works [15:16] What is a "submit branch"? [15:17] sjamaan: The branch "bzr send" defaults to submitting against. [15:18] ok, but if I just bzr push or commit in bound mode, it will push the other branch? [15:18] push to* [15:18] "push" will push to your default push branch by default. You can supply an URL/path to push wherever you want to. [15:18] * Peng has to go -- bye! [15:18] thanks for the info. bye! [15:20] Is it possible to create a standalone branch without working tree, or is that only possible within a repository? [15:31] sjamaan: Sure, it's possible. "bzr branch --no-tree ...", or "bzr branch ...; cd ...; bzr remove-tree". [15:31] * Peng goes away again. [15:32] What about new branches? when using init [15:33] I tried "bzr init --no-tree foo" but that gives me an error "no such option: --no-tree" [15:35] If you type in " bzr help init-repo" it will give you the options you need. [15:35] I believe it's --no-trees with the 's' on the end [15:35] rubbs: I know it works when using a repository. I asked about standalone branches [15:35] oh sorry. came in too late [15:35] ah, I see [15:35] No prob :) [15:37] Well, I'm unsure how to do it at init time, but you can remove the tree using bzr remove-tree [15:37] you could also try the command bzr init --no-trees [15:37] no-trees doesn't work either, but remove-tree sounds like a good idea [15:38] It would be useful if init could do that, though [15:39] Just curious, why would you want a stand alone branch without a tree? [15:40] You could create a treeless repo and push your updates right to the root of the repo.. I've done that by accident before. [15:40] you would just have to think of the treeless repo as your branch location without a tree [15:41] For centralised mode, I don't need a full working copy on the server [15:41] Then I would suggest you do a repo. Even if there is only one branch on the server you would get the functionality you want. [15:42] aye [15:42] I'm doing that now, but I thought it seemed a bit overkill [15:42] (I have only one branch) [15:42] Of course, I could multiple entirely unrelated branches in one repo [15:43] But that's a bit weird too [15:43] But that is more common than you might think [15:44] hm [15:45] I'm not an expert on the internals of bzr, but AFAIK creating a treeless repo doesn't have a whole lot more overhead than a branch anyway. [15:45] I didn't think so. I was referring to cognitive overhead :) [15:45] haha. fair enough :) === sdboyer_ is now known as sdboyer [16:19] how do I get bzrlib? [16:20] It's part of bzr [16:20] If you have bzr, you have bzrlib [16:22] hm. well i installed the os x bzr and "import bzrlib" fails. Maybe I need to change my python path. [16:22] I don't know about osx, but I have to explicitly set my pythonpath on win32 [16:23] How do I find out more about loggerhead? read the source? I don't find any docs on launchpad [16:52] Can you merge a branch into a directory of another branch? [17:13] Meths: I guess you can "bzr mv" + "bzr merge" [17:18] Yeah, or just create the subdir in the branch anyway I suppose. Thanks. [17:23] Meths: "bzr join". [17:23] mindlace: Ehh. What do you want to know? [17:25] Peng: Aha, just the job, thanks. [17:28] Meths: It should handle merging nicely, too. :) [17:28] yeah, looks like it from the help description === Adys_ is now known as Adys [21:36] I have a format:unnamed repository and a "Packs containing knits without subtree support" repository on Launchpad, is there any way I can push my commits to Launchpad? It's giving me an error. [21:36] I have so much grief over different formats, for some reason [21:40] mdke: show us the error [21:40] [surely thats a reflex by now, to give details?] [22:05] lifeless: yes, sorry - it's quite a standard error. http://paste.ubuntu.com/306229/ [22:34] This is weird... http://whybzrisbetterthanx.github.com/ [22:35] Weird? [22:35] It's on github, what'd you expect? ;) [22:36] good point [22:36] I was trying to find a nice link that explains what makes bzr great [22:37] Personally, I like bzr because it's so friendly and provides a smooth transition from svn [22:37] mdke: it means that the bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/help.ubuntu.com branch - the development focus - has been upgraded [22:37] mdke: probably to 2a [22:37] hg is just as friendly, but it has no centralised development mode for those who want it, and it also doesn't support empty directories or proper renaming [22:37] lifeless: so it's my repository that's behind, not Launchpad? [22:38] yes [22:38] ok, I'll try an upgrade [22:38] mdke: one sec [22:38] bzr info nosmart+lp:~ubuntu-core-doc/ubuntu-docs/help.ubuntu.com/ -v [22:38] ^ thats a useful diagnostic to do (I'm running it now) [22:39] mdke: what do you see when you run that command? [22:39] lifeless: http://paste.ubuntu.com/306246/ [22:40] mdke: and what does 'bzr info -v' show, run from ~/ubuntu-docs/help.ubuntu.com [22:41] lifeless: http://paste.ubuntu.com/306249/ [22:42] mdke: note the 'repository' line in both cases [22:42] mdke: as it happens, launchpad is missing rich root support [22:42] but your local repo has it [22:42] right [22:42] so you either need to redo your work in a non-rich-root repo [22:43] or get the ubuntu-docs stuff upgraded [22:43] ouch [22:43] I'd suggest upgrading everything to 2a, its a lot faster and smaller [22:43] is my local repo 2a? [22:43] no, its rich-root-packs [22:43] I get rather confused with all the formats [22:43] which is the same as pack-0.92 with a little extra metadata [22:43] mdke: we know :( [22:44] you mean that others are confused too? [22:44] its a confusing situation that we permitted to come about [22:44] multiple dimensions [22:44] different conversion rules [22:45] ok, so the plan is to settle things down in the future? [22:45] oh yes [22:45] good stuff [22:45] 2a is the first step of the settle down [22:45] there are no flavours with 2a, its just '2a' [22:45] you can convert to it from any of our older formats [22:46] ok [22:46] ok, I'd better redo my work in a branch without a repo [22:47] lifeless: thanks for the help [22:47] lifeless: actually one last question [22:47] lifeless: I don't suppose there is a quicker way to redo the work without actually manually copying files or doing a diff? [22:55] bzr diff > foo.patch; patch -p1 < foo.patch P [22:55] verterok: hi [22:56] lifeless: yeah, I'm doing that with separate diffs for each revision. Thanks again