[00:00] I just like avoiding duplication of effort *before* that effort happens ;) [00:01] I think long term we would like to have i18n and l10n in core, we just have to find out if we can do it without suddenly doubling our startup overhead [00:01] which is already too high [00:01] markh: I don't think we have no interest, but we don't have enough to do it ourselves right now. [00:01] my rough testing here [00:02] shows that it may not cost as much as I was originally worried [00:04] poolie: call time? [00:04] good point! [00:04] wouldn't you try and only gettext() things as they are displayed? Even the import could be delayed. Regardless though, it sounds like the approach I need to take is let qbzr do what it does, and hope bzr can reuse some of it when it gets to the point it cares enough about l10n to apply resources? [00:04] spiv, call [00:05] markh: well, in traditional C code, I'm pretty sure you sprinkle _() liberally throughout your code [00:05] rather than just at the point of display [00:06] jam: lucky we aren't writing traditional C code ;) [00:06] personally, I think gettext was invented by people who thought considering l10n *before* coding was for wimps ;) [00:11] jam: you probably know the context of this from the qbzr mailing list. Should qbzr treat localization of the identical options it shares with bzr in isolation? I understand there are issues so the answer may be "sorry, we don't have the resources to care about that now, just go for it"... [00:17] that's probably a reasonable answer [00:45] * markh will one day learn to accept a simple answer... :) [00:46] another option would be for bzr to adopt localizations - but not attempt to use them at runtime. The doc generation process could though, and it would offer a single entry point for projects like qbzr to not only source l10ns from, but to contribute them to. [00:47] then later, bzr could adopt them at runtime if it can work out how to without costing too much perf [00:47] am I just making things hard on myself? [00:49] that could be good [00:50] Making things hard on himself? :) [00:54] I get this warning when pulling old branch (using bzr 1.5): Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) [00:54] this is from launchpad, what am I doing wrong? [00:55] johan: using bzr 1.5 [00:55] if you upgrade to 1.6 it will go away [00:55] (the message from the client is a bit misleading, yes) [00:56] mwhudson: sure, will do, thanks [00:57] mwhudson, beuno: btw, great work on loggerhead. 1.6 is really nifty [00:57] it's getting there :) [00:57] works fine here [00:58] except that I couldn't quite figure out how to configure user-dirs properly [00:58] it's still too slow, uses too much memory [00:58] (but you probably won't notice unless you're us) [00:59] ah yes, the user dirs thing is a strange beasty [00:59] it's not instant, but /much/ faster than before [00:59] * mwhudson afk for a bit [01:29] biab === kiko is now known as kiko-zzz [02:00] poolie: hi, sorry I missed the call. Today I'm going to try land most of my patches that are approved in bundle buggy. === spiv_ is now known as spiv [02:31] mwhudson: ping? [02:31] Peng_: hi [02:31] Hi! [02:33] mwhudson: I'm being impatient, but can you confirm my issues in https://bugs.edge.launchpad.net/loggerhead/+bug/268867/comments/2 ? I might have just broken my LH setup or something. [02:33] Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New] [02:33] Peng_: i can easily believe [02:33] it [02:34] Peng_: whenever i think about url generation in loggerhead i just want to cry :/ [02:34] Heh. [02:35] I've backed out breadcrumbs from my copy of LH due to that bug, but it's starting make it hard to keep merging the trunk. [02:38] Peng_: care to help me configure apache locally to reproduce? [02:38] I run Lighttpd. :P [02:39] bah [02:41] I dunno. I run a pretty basic mod_proxy setup. [02:44] ah, ok, can reprp [02:44] *o [02:47] * mwhudson stabs simpleTALES [02:48] Oh, good (or not). [02:48] well, it's just so fun to debug [02:49] WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: 'int' object is not callable [02:49] a traceback would be nice === jamesh_ is now known as jamesh [02:56] uh [02:56] does this stuff work at all? [02:58] What? [02:58] Is it just me, or does serve-branches not use loggerhead.trace.setup_logging()? [03:01] Peng_: breadcrumbs [03:02] mwhudson: When I filed bug 268867, they seemed fine, aside from that bug. [03:02] Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New] https://launchpad.net/bugs/268867 [03:02] I run a stripped-down version of serve-branches. Stop improving it, guys, it's getting hard to hack it all out. :( [03:05] Peng_: can you try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs ? [03:05] (when it gets there) [03:05] OK [03:08] Peng_: try now [03:09] Yeah [03:09] Argh, that's based on the tip. I still haven't merged that. [03:10] * Peng_ 's head spins [03:10] Peng_: what changes do you have from tip? [03:10] mwhudson: Mainly my stripped-down version of serve-branches. [03:11] Peng_: what does serve-branches do that you don't want it to, by default? [03:14] mwhudson: I started when it was still new and very simple. I occasionally added something (sys.path, different logging, etc.), and whenever you added a feature I didn't need (--port or something), I didn't merge it, so now my script is kind of a mess. [03:14] i see [03:15] i guess it would be easier for you to call your script something else :) [03:15] :) [03:15] Heh. [03:15] Hmm, that's not a bad idea. === Peng__ is now known as Peng [03:19] Packet loss to your server is a good excuse not to work on LH, right? :P [03:27] heh heh [03:48] Wait, I only needed to change like 2 lines in serve-branches. Thank you, "bzr diff". [03:50] mwhudson: Err, now I just got a traceback. [03:50] Peng_: darn [03:50] Hold on [03:50] Peng_: pastebin? [03:51] Damn, I forgot about Paste not logging exceptions. [03:51] Which the new serve-branches code I didn't merge may have fixed. [03:52] mwhudson: It was when I visited the root page. Here's the tail of the traceback, fwiw. http://paste.pocoo.org/show/86566/ [03:53] oh ffs [03:54] mwhudson: What's wrong with breadcrumbs? [03:54] They attract roaches. [03:54] And housecats! [03:56] well housecats aren't so bad. [03:56] except the vet bills. [03:56] Peng_: try pulling rev 228 [03:56] Hold on [03:57] mwhudson: Of which rbanch? [03:57] uh [03:57] fix-breadcrumbs? I don't see a new revision [03:57] bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs rev 229 [03:57] it'll be there in a minute [03:57] Yeah, there iti s [03:57] you want 229 though, 228 is trivially broken [03:58] Oh. [04:00] Hey, no instant explosion! [04:01] mwhudson: Seems to work perfectly (testing only the root and a /changes page) [04:01] Peng_: good good [04:01] (Aside from how the links don't end in a /, but that's only a minor inefficiency, not a real issue.) [04:03] mwhudson: Thank you! :) [04:04] i guess i'll merge to trunk then [04:04] :) [04:13] mwhudson: Not that it really matters, but do you mind if I add the fix-breadcrumbs branch to the list of related branches on the bug? [04:14] Peng: nope [04:15] Thanks again for fixing this. :) [04:17] np [04:17] mwhudson: Hmm... I have errors with that branch. [04:18] http://localhost/bzrpackagedb/fedora-packagedb-devel [04:18] abadger1999: that's not a very useful url :) [04:18] There should be a "/" between bzr and packagedb [04:18] heh. yeah. [04:20] mwhudson: server.webpath = 'http://localhost/bzr/' [04:20] And... I'm using my mod_wsgi script rather than serve-branches. [04:21] abadger1999: ah, what happens if you don't have the slash on the end of the webpath? [04:21] well, nothing i guess [04:21] * mwhudson hates urls [04:21] mwhudson: I get the same error. [04:21] well not error. Same url. [04:22] yeah, sorry, that was daft [04:22] abadger1999: where do you get it? [04:22] Those are the links on the front page. [04:22] So that's one of my branches [04:22] The branches are autoconfigured. [04:22] auto_publish_folder = '/bzr/packagedb/' [04:23] abadger1999: um, is this new with this branch? [04:23] mwhudson: yeah. I wrote the breadcrumb patch that was merged at revno 224. [04:23] mwhudson: It worked at that point. [04:24] Actually... Let me just make sure I didn't have any other patches in my mod_wsgi branch that have bearing on this. [04:26] yeah, rev 227 _really_ shouldn't have changed the browse view at all [04:26] mwhudson: My browse.pt has: yours doesn't have the '/' [04:26] the first one? [04:26] hm [04:27] abadger1999: is this a change you made? [04:27] I think I must have added that specifically for the mod_wsgi stuff. [04:27] I just confused the browse.pt and breadcrumbs.pt changes. [04:31] * mwhudson grumps [04:32] it seems that all calls but that one to static_url have '/' as path[0] [04:32] so i may as well change that one [04:33] mwhudson: Cool. Have you looked at my mod_wsgi branch? [04:33] abadger1999: no [04:33] * mwhudson looks [04:34] mwhudson: https://code.launchpad.net/~toshio/loggerhead/mod_wsgi [04:36] abadger1999: do you know how unicode ends up in SCRIPT_NAME ? [04:36] mwhudson: Well, mod_wsgi and paste both put it there. [04:37] mwhudson: I'm talking to the mod_wsgi upstream right now... it might be part of the wsgi spec [04:38] ok [04:38] "HTTP does not directly support Unicode, and neither does this interface. All encoding/decoding must be handled by the application; all strings passed to or from the server must be standard Python byte strings, not Unicode objects. The result of using a Unicode object where a string object is required, is undefined." [04:38] (from pep 333) [04:39] yeah. [04:39] but whatever [04:39] abadger1999: i think on trunk, you should be able to call loggerhead.trace.something rather than copy/paste the logging config [04:39] (in loggerhead.wsgi) [04:40] That would be nice. [04:40] and in general it would be nice for start-loggerhead and loggerhead.wsgi to share slightly more code [04:40] looks fine in other respects though [04:41] mwhudson: Sure. Do you want the code moved into loggerhead and the two scripts just call them? [04:41] Or just to use the same code? [04:41] abadger1999: i think that would be great [04:41] Cool. [04:41] (the former) [05:20] If I create a central/shared repository (bzr init-repo) over an existing file structure, what will that do? Will it change any of the files? Will it automatically include all of them in the repository? [05:20] No, it won't change any existing stuff. [05:21] It'll only affect new branches. [05:21] Can those files be edited directly? [05:21] Which files? [05:21] Lemme explain the situation and give some background [05:22] our web team here has been maintaining the large (university) website using one SFTP user [05:22] all developers use that same user to upload changes to the server [05:22] which means that conflicts occur, and no one know who did what or when [05:22] I would like to switch development over to Bazaar [05:23] so... would it be best to init-repo right over the htdocs, or should I put it in a separate location? [05:23] OK, so that's not _quite_ the right question. [05:23] I would prefer that each developer be able to use their own username to commit changes [05:23] Repos (init-repo) don't contain files; you don't work in repos. Branches (init) do. [05:23] lifeless: ping [05:23] instead of the master username [05:24] ah, OK [05:24] Repos are used to share storage among related branches. We can ignore them for now. [05:24] james_w: I don't suppose you have insomnia? [05:25] GPH-Laptop: The branch itself is the unit you work with; all the files are in there, that's where you edit, where you commit, etc. [05:25] right [05:25] GPH-Laptop: So, the question is, what are the boundaries of the branch? Is the entire site one monolithic entity, or are there multiple pieces in it that are rather independent? [05:26] That's a question both of structure (how does it all fit together?), and of development (are there separate maintainer teams for different pieces?). [05:26] I'm not sure... I think it's kind of a mixture... the web team has access to everything, but users also have their own ~homedirectory/ [05:26] but those personal directories need not be included [05:26] Well, those aren't in htdocs, right? They're off in userdirs. [05:27] true, yeah [05:27] but there are a lot of symlinks to custom dirs [05:27] that might not quite map to a specific user [05:27] but nonetheless act like a userdir [05:27] I think [05:27] Well, that probably doesn't matter. bzr won't walk _through_ the symlinks, though it could version the symlinks themselves. [05:27] OK [05:27] (you can choose to ignore and not version them of course) [05:27] right [05:28] Presumably they're somewhat peripheral; they're not necessary bits of the site proper, they're just other things that happen to be under the same base. [05:28] yeah [05:28] not something that would be actively developed [05:29] So, as a first approximation, "everything under htdocs that's part of the actual site" would be the bounds of the branch you want to create. [05:29] right [05:29] sounds good [05:29] Which may just be everything there, then eventually drop things like symlinks as you figure you don't need them, or may be more careful up-front deciding. [05:30] One thing to remember is that once something's committed, it will always be in the history. That could matter for two reasons; information security, and storage/transfer resources. [05:30] right [05:30] On the one hand, if you commit a file with passwords in it, even if you later delete it it'll always be in the history. [05:30] On the other, if you accidentally commit that directory of DVD ISO's... well, your branch is gonna be Zarking Huge(tm) forever, and take ages to download. [05:30] right [05:31] no way to delete that stuff? [05:31] Well, yes and no. [05:31] It's permanently part of that history; there's no way to go back to a revision and take out parts of it. [05:31] why does TransportConfig.set_option() take value, name rather than name, value? [05:31] You could create a new history from scratch, that's pretty much like the old one EXCEPT without those pieces. [05:31] But that's a new history; you can't merge from the old stuff into it, everybody has to re-download from scratch, etc. [05:31] oh, wow, no file-by-file? [05:31] Right. Revisions are the whole tree. [05:31] right [05:32] gotta remember that [05:32] Now, things like symlinks that are neither sensitive nor huge, that get committed but you don't really want and eventually delete, are still 'clutter' in the repo in a way, but probably don't much matter. [05:33] hmm [05:33] So you have to look at just what your situation is to figure out how painstaking you want to be about setting up things initially. [05:34] It doesn't sound like you have much worry there, though I've seen some big files hiding around web dirs long after their purpose (if any) had vanished. Ultra-high-res images, tarballs, blah blah blah. [05:34] Somebody needed somewhere to stick that MPEG to send to their friend, 6 years ago, and forgot about. [05:34] heh [05:34] yeah [05:34] hmm [05:35] At the moment, you have no history to preserve at all. So, if a week from now you find out there's a buncha big stuff there you didn't really want, it may not be a big loss to just throw away the bzr metadata and re-start from scratch. [05:35] Throwing away history like that makes ME twitch, of course. But a lot of people are less obsessive than I am :) [05:35] is the repo compressed in any way? [05:35] I'm probably more on your side of that line ;) [05:36] but I don't know how the rest of the web team is [05:36] I just joined it [05:36] Yes, changes are stored as deltas rather than as continaul full-texts. And there's gzip compression of the whole repo. [05:36] oh, OK [05:36] good [05:36] Future formats will probably feature much better compression, especially for binary files. [05:37] As current VCS's go, the current bzr formats are a little on the large side for the history. But that doesn't sound like it will be a big deal for you. [05:37] OK [05:37] I tried to find something that fit what we needed... Git and Mercury didn't seem to cut it [05:38] the problem is, there aren't any good Mac OS X GUI clients [05:38] and we could really use that [05:39] Where did git and hg fall short? [05:39] I forget... just at places that I consider important... I think they just did things differently than I would prefer [05:40] Why? Would you recommend one of those instead? [05:40] Well, if I did, I'd be in #hg or #git rather than #bzr :) [05:40] That's what I figured [05:40] Partly, I'm just curious. [05:40] Yeah, I don't remember [05:40] it was probably things we won't even wind up using [05:40] And partly, despite a lot of higher-level differences the base models among the three are very similar. [05:41] but I'm a kind of guy who thinks CVS does some things better than SVN [05:41] like tags and branches and stuff [05:41] SVN does tags and branches? ;) [05:41] exactly [05:42] I used CVS for many years. I moved to bzr after I decided SVN was mature enough to consider, and actually _looked_ at it. [05:42] heh [05:42] Wikipedia's got a nice comparison [05:43] GPH-Laptop: Tags I agree with you, branches not so much. [05:43] abadger1999: Maybe not in the sense of merging [05:43] True. svn has branching but merging was not fun. [05:44] Of course, CVS by its nature allows things that none of the modern VCS's do. [05:44] either way, Bazaar looks to be a good choice [05:44] and I'd like to implement it ASAP ;) [05:44] Always a good plan :) [05:44] I just had to deal with a editing conflict [05:44] which is not good over SFTP [05:44] Now, here's the last sticky question; what's your deployment plan? [05:44] (deploying the website, that is, not bzr) [05:45] oh [05:45] well [05:45] When you 'bzr push' (or whatever workflow method you use) the changes up to your central site, it'll push the repo stuff with the history and all, but it doesn't do anything with the checked-out working files. [05:45] we actually have two different websites... htdocs-dev operates on :8888, htdocs is live at :80 [05:45] So you need some way to actually update the files the webserver sees. [05:46] So they can't be the same files? [05:46] Well, they never ARE the same files, much like the RCS files in a CVS repo aren't the same files as the working files in your checkout. [05:46] true [05:47] You can't point Apache at a CVS repo and have the files served (at least, not without horribly evil mod_whatever we'll pretend doesn't exist) [05:47] lol [05:47] OK, so they'll need to be pushed live either way [05:47] It's analogous with bzr; commands like "bzr push" shove around the 'repo', not working copies. [05:47] Right. There are a number of possible routes, but which is best depends on your case. [05:48] For me, I'm a *nix guy, and I work with servers I can login to. So MY deployment scheme is a set of Makefile's, and I deploy via "make install". [05:48] oh [05:48] I was thinking cron [05:48] For devs that need a Mac GUI client, this is obviously not so hot a choice :) [05:48] yeah [05:48] cron is an option; just have a checkout where Apache looks for the site, and "bzr up" every 12 hours or something. [05:49] yeah [05:49] (don't forget the bzr-update-after-push plugin) [05:49] That could be supplemented by a carefully-crafted secure page with a "click here to force update". [05:49] oooh [05:49] OK, now we're getting fancy [05:49] let's get the thing set up first :P [05:49] As bob2 said, there's a push-and-update or something plugin, which makes the push ssh into the server and run 'bzr up' every time you push. [05:50] Though that means that the branch you're pushing into would have to be the one sitting where Apache looks, which may not be your best choice. [05:50] There's also a "bzr upload" plugin, which deploys/updates working files via sftp (or probably other transports) out of your local working dir. [05:51] The conceptually simplest is probably the first; having a checkout where the live site points, and updating that (via cron, via manual, via whatever) at the appropriate interval. [05:51] OK [05:51] so first I set up a repository outside of htdocs [05:51] ? [05:52] Doing that (or any other thing where the live site is an actual bzr branch), I'd be sure to take pains to block off access to the .bzr directory, just on GP. [05:52] I'd play with it locally first. Copy down all the files (or take a copy of the ones you already have), and setup a branch. [05:52] aren't dot-prefix files automatically off-limits? [05:52] A thing to realize is that the location of and relationship between branches are MUCH more fluid than in CVSVN. [05:53] Not in any server I've ever worked with.... Apache blocks and reserves .ht*, but no other dotfiles. [05:53] oh, OK [05:53] well, what if I set up everything on the server, but outside the realm of the public website [05:54] and basically pretend like I'm committing to the website [05:54] ? [05:54] Here's what I would suggest. [05:55] 1) First setup a branch locally and play with it a while, to get used to actually _using_ bzr. If you've already got CVSVN background, you'll have all the general knowledge, so just a little while of fiddling should get you used to the minor differences. [05:56] 2) Once you're comfortable with that (and assuming you haven't trashed your branch ;), setup a "central" branch on the server (probably somewhere other than the web root), and reconfig your local branch to be a checkout of it. [05:56] Up to this point, you're the only one using bzr, so you'll have to take care to bring in any changes from the live site. [05:56] Then, 3) strongarm your associates into making their own checkouts and working from them. [05:56] heh [05:56] (up to here, you're still _deploying_ the files however you're doing it already; FTP or rsync or whatever) [05:57] yeah [05:57] Then 4) choose the deployment strategy; making the live site a checkout, etc. [05:57] OK [05:57] Now, note that you're actually _using_ bzr pretty much like CVSVN here; there's one central branch that everybody checks out. [05:58] the problem I'm having in my head is the terminology, e.g. the difference between a branch and a repository, etc. [05:58] The native support for that workflow is, IMO, one of the *BIG* things bzr brings to the table than the other DVCSen don't. They tend to undervalue its real use. [05:58] Gimme a sec to finish off this email, then we can chat about that. [05:58] ok [05:59] There. Darn clients... [05:59] heh [05:59] So, in CVS, you essentially have two pieces. You have the repo, where all the history and metadata and whatnot is stored, and the checkout, where you actually work on files. [06:00] yup [06:00] Branches are implicit, and essentially properties of certain revision numbers. [06:00] SVN is similar, except worse in making branches social constructs of various paths within the repo. *shudder* [06:00] heh [06:00] In both cases, you actually check out [some subset of] the repository. [06:01] In bzr, things are a bit different. The checkout is still pretty much the same; it's where you work on files. [06:01] The repository is basically a big bucket, into which every revision goes. There's no order or sorting per se; it's just a big storage box. [06:01] You can't "check out" a repository; the concept is just without meaning. [06:02] There's a third entity, which is the branch. It's an explicit construct, rather than being implicit like in CVS or SVN (in their own different ways) [06:02] A branch is what says "THIS is the current revision", basically speaking. [06:02] Each revision points to another rev (or 2 revs, or 3 revs, or no revs in the case of initial revisions) and says "That's my parent. [06:02] thumper: pong, but leaving poolies soon, topic ? [06:03] So essentially, a branch describes WHICH revisions are important for a particular line of development. [06:03] I see... and these revisions are the who repository, not just specific files, right? [06:03] The branch doesn't actually HAVE them; it just says which you care about. You reach into the bucket of the repository to fish out the revs you want at any given time. [06:03] Right. [06:04] In the "default" case, where you run "bzr init", then add files and work on them, all 3 pieces (checkout, branch, repository) are sort of colocated, right there where you're working. [06:04] When you use init-repo, then make branches inside that repo, you've got 2 pieces (checkout and branch) colocated, with the repository being a step up. And that repository is then shared by multiple branches. [06:05] And you can have other cases where all 3 pieces are in different places. [06:05] But in most ways, it doesn't matter which way things are setup; everything works the same. [06:05] OK, this is the part where I lose you, hang on [06:06] OK. [06:06] what do you mean when you say "colocated"? the same directory? [06:06] Right. [06:06] so what does init-repo do? [06:06] (well, technically, the checkout metafiles are in .bzr/checkout/, the branch in .bzr/branch/, and the repo in .bzr/repository/, but...) [06:06] :P [06:06] init-repo creates a shared repository, which is a repo that multiple branches can refer to. [06:06] Take your site. Let's presume it's big, and has a lot of history. [06:07] Enough that the whole history is a hundred megs. [06:07] Anytime you make a new branch, the whole history is in each place, so if you "bzr branch trunk fixlinks" to make a branch to fix some links in, you eat up another hundred megs of disk space. [06:07] (to say nothing of eating 200 megs of I/O, or worse, a hundred megs of network) [06:08] Obviously, this doesn't scale well. [06:08] right [06:08] In CVSVN, there's only one copy of the history, ever; on the central server. [06:08] This means that access the history can be slow, or even impossible if you're disconnected from the network (or it is) [06:08] So with the distributed systems, everybody has a copy of the history locally. [06:09] Which wouldn't be so bad, really, if you only had to deal with ONE copy of the history, rather than one per branch. [06:09] Enter, the shared repository. [06:09] Because remember, branches don't actually hold the history; the repository does. So you _need_ one copy per repository. [06:09] You can thus share one copy of the history across multiple branches, IF the branches share one repository, rather than each having their own. [06:10] We often say "repository" when we MEAN "shared repository", and so we say things like "you don't need a repository" [06:10] Of course, every branch needs a repository, but it can be either private ("standalone branch"), or shared among multiple branches (which is what init-repo does for you) [06:11] The important thing (as mentioned in the separate of the 3 pieces earlier) is that the existence of a shared repository doesn't change any of the semantics of working on the branches. [06:11] It just saves space (and time, since there's less data to shuffle around in various operations) [06:11] So, for instance, let's say we're both working on this site, and we each have 3 branches. [06:12] Let's say they're the same 3, for simplicity. trunk, fixlinks, and newimages. [06:12] We've got a central server, with a shared repo in /repo, and the branches inside that repo: /repo/trunk, /repo/fixlinks, and /repo/newimages. [06:12] So on the server, there's one repository in /repo full of all that history, which is probably mostly the same. The branches have diverged a bit, but most of their history is still common. [06:13] So instead of taking up 3*N space, it just takes up N+. [06:13] Now you've got a repo in ~/website, with the 3 branches checked out in it: ~/repo/trunk, ~/repo/fixlinks, ~/repo/newimages [06:13] Er, ~/website/, not ~/repo/ in all those cases. [06:13] ight [06:13] Now I've got all 3 checked out too: ~/website/trunk, ~/website/fixlinks, etc. [06:14] BUT, for whatever reason, I *DON'T* have a shared repo in ~/website/ [06:14] So on MY machine, each of those branches has their own (internal) repo, so I have 3 full copies of the history. [06:14] Rather stupid on my part. [06:14] heh [06:14] But it doesn't have any impact on how I work with you, or with the central server. [06:14] Any operation that we'd need to refer to each other with, like merging or pulling, just points at a branch. Finding the repository for that branch is handled entirely internally. [06:15] on the central server? [06:15] On any place. [06:15] ok [06:15] It's distributed remember; a central server is a VERY handy social construct, but it's not a technical one in distributed systems. Any branch is equal technically. [06:15] ok [06:16] so what is the difference between my files and your files? [06:16] If I create a repo in ~/website/ later on, it doesn't affect those existing branches. [06:16] But I can explicitly convert them to using a repo, and so regain all that space. [06:16] So the important points here are (a) [shared] repo layouts (or even usage) don't have to be consistent across a project; they're purely local constructs [06:17] And (b) your choice of laying out or using shared repos isn't permanent; you can change it around anytime, with very little work. [06:17] so the shared repo is for me and my multiple branches? [06:17] Essentially, the difference between my files and your files is... well, my files are my files, and your files are your files :) [06:17] Right. A shared repo only has meaning where it is; it doesn't affect anything outside. [06:18] I think I'm having trouble letter go of the central server [06:18] All commands work on and between _branches_, not repos (not quite true, but close enough). [06:18] letting [06:18] You never checkout a repo, or branch a repo, or commit into a repo; you do things on branches. [06:18] Sure. And you shouldn't necessarily; most of my work has a central server. But that's because I _choose_ one location to be central. [06:18] one shared repo [06:19] It becomes central because I treat it as central; I push all my revs up there, and other people push their revs up there, and we agree that that's the "master", "authoritative" copy. [06:19] But there's no technical different; no separate setup, no special "I am master" flag. [06:19] so, in my case, a shared repo on the server [06:19] If you're going to have multiple branches (even possibly in the future), yes, a shared repo. [06:20] But you don't need to; if all you'll ever have there is trunk, you could just make it a standalone branch. [06:20] would be the "central" location [06:20] I think we'll be needing multiple branches [06:20] * fullermd nods. [06:20] Probably a good idea to plan for that, even if it doesn't ever come about. [06:20] OK, so the server has the one central shared repo [06:20] now how do the branches work? [06:21] are they on the server, or local, or what? [06:21] So, going back to my 4 steps earlier, in (1) you create a standalone branch locally to fiddle with, and then in (2) push it up to becoming a repository branch in the shared repo in the server. [06:21] Both. [06:21] Let's take the example of bzr itself. It's developed in bzr. [06:21] I keep a local mirror of the bzr development. [06:22] I did that via "bzr branch http://bazaar-vcs.org/bzr/bzr.dev/", which is where that branch is available. [06:22] And every few days, I do a "bzr pull" to keep it updated. [06:22] Sorta like using cvsup to mirror a CVS repo. [06:22] yeah... I used GUI for CVS, too :P [06:22] Now, _conceptually_, to me, that's just a mirror. I don't do local development. It's not, to me, a "new branch". It's just a copy of the main one. [06:23] But technically, in bzr terms, it IS a new branch. It's a new branch that HAPPENS to never get anything in it that isn't copied from somewhere else, but that's just happenstance. [06:23] So right off, there are 2 branches of bzr in the world; the one on bazaar-vcs.org, and the one on my hard drive. [06:24] In technical terms, there's no reason to prefer one over the other for being the "real" bzr, or the "master" bzr. It's a social decision. [06:24] In your case, you'll have a branch of the site on server:/repo/trunk/, and a branch on workstation:~/website/trunk/. [06:24] (assume you do a 'branch', not a 'checkout', which you probably won't, but for the purposes of this discussion...) [06:25] You'll work in ~/website/trunk/, and make commits. They're sitting there, nowhere else. You'll push those revs up to the server:/repo/trunk/ when it seems appropriate to you. And you'll pull new revs from there that other people push up there. [06:26] so I commit locally first, and then push the commits to the server later? [06:26] By and large, using checkouts will be easier; those will act pretty much like you'd expect from CVSVN. You commit, it goes to the repo on the server. You try to commit and you're out of date, you have to 'update' then commit. [06:26] oh, ok [06:26] If you're working in a branch rather than a checkout, yes. [06:26] (This is also a lie; checkouts support commit --local. But until you've a pretty deep understanding of bzr and just what it does, you'd be well advised to forget about it) [06:27] consider it done [06:27] ;) [06:27] The basic commands are what you expect from CVS. Commit is bzr commit or bzr ci, update is bzr up, checkout is bzr co, diff is bzr diff, stat (which doesn't exist in CVS, irritatingly) is bzr stat, etc. [06:28] The extra commands come when you deal with multiple branches and moving stuff between them. [06:28] OK, well, we're in the process of moving from PHP4 to PHP5 [06:28] push and pull are sorta like mirroring commands; make {that branch there, this branch here} an up-to-date copy of {this branch here, that branch there} [06:28] but they need to be independent of each other [06:28] so that would be branches, no? [06:28] merge is used to merge together changes from another branch into one you're working on locally. [06:28] Right. [06:29] So, let's pretend that you're the only one doing the 4->5 conversion. [06:29] The other half dozen people are just continuing to work on the existing site. [06:29] There's a server:/repo/trunk/ branch that's used for that. [06:29] And you've got a checkout of it in ~/site/trunk/ [06:29] (and so does everybody else of course) [06:29] You work with this just like you'd work with CVS. [06:30] Now, you want to go work on the 4->5 conversion. Nobody else is involved, so you decide not to bother putting a new branch on the server. [06:30] Instead, you just make a branch locally. You do something like "cd ~/site ; bzr branch trunk php5" [06:30] Now you've got a new branch in ~/site/php5/ to do that work. [06:31] You work for a week or two, getting a bunch of it done. Meanwhile other people are still making changes to the live site, so obviously you need to work those in too, or your conversion will be a conversion of an old version of the site, which isn't much help. [06:31] So you keep your trunk copy updated: cd ~/site/trunk/ ; bzr up [06:31] (and you may still do some work on trunk too; who knows) [06:32] And every so often, you merge those changes into your ongoing PHP5 work: cd ~/site/php5/ ; bzr merge ../trunk [06:32] This merges them in and prepares the merge commit, though it doesn't actually commit it. This gives you a chance to resolve any conflicts, and generally look things over, before you "bzr ci" to commit the merge. [06:32] Rinse, repeat; this process goes on for about 20 freakin' years, until you finally get done the conversion. [06:33] Then when that's done, it's time to take it live. So you go the other way around: cd ~/site/trunk/ ; bzr merge ../php5 (review and commit) [06:33] And now the branch is landed, you take it live, receive worldwide adulation. Riches, power, beautiful women throwing themselves at your feet, etc. [06:33] lol [06:33] There's a few things to notice here. [06:34] 1) Since bzr actually has merge tracking, there's no magic about all those merges from trunk into php5 you did along the way. You just do 'bzr merge', and it brings in the new stuff. No remembering what you've merged before, no re-re-re-resolving old conflicts, etc. [06:34] You can do it as often as you want. Do it every day at 4:30 pm, and each merge will make very little change; and when it DOES conflict, it'll conflict in code you were just working on, so it's easy to fix. [06:35] bzr has very smart merge algorithms, but the biggest thing that makes merging easy is making a lot of small merges all through the process, rather than one giant merge at the end. [06:35] 2) This php5 branch you did all this work in, never existed on the server. It only ever exists on your local drive. [06:35] 3) Once you've done the merge into trunk at the end, all those revisions are in the trunk branch too. So you could rm -rf php5, and you still have that entire detailed history in trunk if you ever need to go back to it. [06:36] And as a consequence of (2), 4) Nobody needs to even know you've done any of this until it's landed. So you don't need to get buy-in to the idea ahead of time; only when it's ready. [06:37] (which isn't to say that working in a corner on codebombs is a good idea; just that the barriers are social, not technical) [06:37] Now, let's back up a little, and pretend you're partway done. [06:37] And you have to go on vacation. Luckily, I'm also working on this site, and I can do PHP stuff, so I can take it over and finish it for you. [06:37] I do that by making my own branch of your php5 branch in my ~/site/php5/. [06:38] (how I get to your branch is an open question, but irrelevant; somehow you give me access to be able to read those files) [06:38] My branch has a full copy of all your history of course. So I pick up where you left off, doing my own merges from trunk occasionally. [06:38] Eventually I finish, then *I* merge it into trunk and land the changes, and *I* get the riches and fame. You come back from vacation to find yourself my handservant. [06:39] lol [06:39] thanks a lot [06:39] Again, the php5 branch never existed on the server. You've still got an old, outdated copy of it on your hard drive. I've got the new, latest copy on mine. [06:39] Both of us can rm -rf them now if we want. Or you could 'pull' mine, so that yours is up to date, then rm it. Or keep it around for a while, just in case. Doesn't matter. [06:39] But let's back up and assume that you're not going on vacation, but you decide you need some help with it; it's too much for one person to do on their own. [06:40] So you again come bother me, and nag me into helping. I get my copy from your machine into ~/php5/, and go on working. [06:40] Of course, we can't just each go off our separate ways; we have to stay in sync. [06:41] So, much like merging trunk, every so often I would "bzr merge bzr+ssh://GPH-Laptop/home/gph/site/php5/" (or however I access it) to merge in your changes since last time I synced. [06:41] And you would do the same in reverse; merge my changes back. [06:41] This means that if, say, I do my daily merge of trunk, and then afterward you do your daily merge of my changes, you get all the stuff from trunk and don't have to merge it yourself. [06:41] Of course, you COULD just go ahead and "bzr merge ../trunk", but you may get the answer "Nothing to do" if nothing new has shown up since I merged. [06:42] And otherwise the process goes on until we decide that we're done, then I sneak down to the machineroom and pull out your ethernet cable so that I can be the one that merges it into trunk, adulation, women, etc. [06:42] mwhudson: I have good news and bad news. [06:42] But wait; that's a little annoying, us having to merge back and forth. [06:42] abadger1999: tell me the good news now and the bad news tomorrow? :) [06:43] lifeless: sorry, fixed the problem anyway [06:43] And if there were *3* of us working on it, it would be even worse; we'd have more complicated merging to do. It can work just fine of course, but it's more mental overhead to keep track of what's going on. [06:43] Good news is I'm testing the combined mod_wsgi paste.httpserver stuff and it works for mod_wsgi. [06:43] And what about 4 people, or 5, or 50? Eeek. [06:43] mwhudson: bad news has to do with breadcrumbs :-( [06:44] So instead of my branch'ing from your branch, what you do instead is that you push your php5 branch up to the server, so now we have server:/repo/php5 alongside server:/repo/trunk [06:44] abadger1999: argh [06:44] Then you convert your branch from being an independent branch, to being a checkout of server:/repo/php5. And I check it out locally. [06:44] abadger1999: can you file bug reports? i'm really too fried to think hard about this stuff now :/ [06:44] Then we both work on it pretty much like we work on trunk; we just commit, and update to get changes from anybody else working on it. Somebody every once in a while merges trunk and commits it, and we all get that in our update's. [06:44] mwhudson: No problem. [06:45] And when it's ready, anybody can update (to be sure they're up to date), then merge it into trunk and steal all our fame. [06:45] mwhudson: If I understood simpleTAL better I'd do a better job of debugging :-( [06:45] GPH-Laptop: The thing to notice here is that ALL of these ways are valid, and ALL of them are appropriate in certain cases. Almost any of these workflows CAN be used at almost any time, but different ones are optimal for different uses. [06:46] right [06:46] but, by spelling it out for me, it helps me wrap my head around it [06:46] GPH-Laptop: The second thing to notice is that just because we START with one workflow (you having a local php5 branch, us both having local copies with sync to each other), doesn't mean we're stuck with that workflow forever. [06:46] We can easily decide "Wait, it's too much work us both having independent local branches; let's make a central php5 branch and work there" [06:46] And converting over to working that way is very, very easy. [06:47] (and going the other way too, from one central branch to 2 independant local ones, would be easy too, if for some reason we wanted to switch) [06:48] So just because you're doing a "central" workflow for one bit (trunk), doesn't mean you can't get all funky distributed with other branches. And just because you're all funky distributed with a branch, doesn't mean you can't easily switch it over to centralized. [06:48] So, if we had the central php5 branch... would our local files be a branch or a checkout? [06:48] So you have a lot of freedom to tailor the workflow to the needs of the moment, AND to the needs of given developers. [06:48] They COULD be either; I could have my php5 be separate, and treat the central branch like I treated yours, as something to merge from. [06:49] Or I could make it a checkout, and work straight-line in it. [06:49] so a branch is pretty much a middle man? [06:49] a local branch, that is [06:49] And if I had write access to your ~/site/ somehow, I could checkout YOUR ~/site/php5 too, instead of branch'ing it. [06:49] Hm. I'm not sure I'd phrase it that way. [06:49] alright, nevermind then [06:49] A branch is the thing you work on, via a checkout. [06:50] now, if you did check out my stuff, too, could you still merge the two? [06:50] two checkouts [06:50] (which checkout COULD just be colocated with the branch, in simple cases) [06:51] Well, technically, you merge branches, not checkouts. But you do all the work in a checkout. [06:51] Let's take the case where there's trunk and php5 on the server, and I've checked out both. [06:51] When I cd ~/site/trunk ; bzr merge ../php5 [06:51] What I'm DOING is actually merging the php5 branch into the trunk branch, and preparing the merge to be committed. [06:51] Of course, I just refer to my checkout, not to the actual branch. But bzr just uses the checkout to find the branch to get the revs to merge (which come from the repository) [06:52] So it sorta steps down through all 3 pieces to get what it needs. [06:52] so... commit is 2 steps in a branch, 1 step in a checkout, and merge is 1 step in a branch and 2 steps in a checkout? [06:53] relative to the central repositor [06:53] y [06:53] or branch [06:53] or whatever [06:53] the central server [06:53] Mmm. I'm not sure that phrasing means much... [06:53] When you commit, the process goes something like: [06:53] 1) Get the current state of everything from the checkout [06:53] 2) Get the previous revision (which is at the moment the latest) from the branch (slight lie, but close enough) [06:54] 3) Create a new revision, with that previous one as its parent, containing the new files (stored as a set of diffs for compression, but conceptually a snapshot of the whole tree) [06:54] 4) Stuff that revision in the repository (wherever that might be for this particular case) [06:54] 5) Update the branch to tell it "Your head revision is now " [06:54] (this glosses over details, and skips some others, but it's close enough for understanding) [06:56] Merge works somewhat crossing levels. [06:56] On one level, it's just as if you'd made changes to the files manually; it just does it for you. [06:56] But on another level, it queues up the revisions you're trying to merge, so they become part of the history. [06:56] On a normal commit, the revision you create has one "parent"; it's the revision you start from. [06:56] On a merge, though, the revision has TWO parents; the first is as above; the one you started working from in your checkout. [06:57] The second, though, is the head of the revisions you merged. That's what makes merges special; it points back along BOTH lines of development. [06:57] hmm... OK [06:57] I think I understand those concepts enough [06:57] That's why, after you've merge php5 into trunk, you don't need php5 anymore; trunk has all those revisions pointed to. [06:58] right [06:58] now what about implementation? [06:58] where do I have to install Bazaar? [06:58] And it's also what makes the merge tracking work right; bzr knows which revs are already merged, because it can see them in the history. [06:58] Where in terms of where on a machine, or where in terms of on what machines? [06:58] on what machines [06:59] hi all [06:59] Well, in one sense, you don't _need_ it on the server; bzr can hold a repository on a machine and just access it via sftp or other "dumb" protocols. [06:59] But that won't help you checking it out on the live site there of course. So you need it on the server, practically speaking. [06:59] And having it on the server lets you use the smart protocol, like bzr+ssh, which will be more efficient. [06:59] oh, for the automation, yeah [07:00] hmm... ok [07:00] And of course, you need bzr (with whatever frontend) on whatever machines developers are working on. [07:00] Pretty much the same as asking "Where do I need to have cvs installed". [07:00] * fullermd waves at vila. [07:00] right [07:00] hmm, I suppose [07:01] Now, if you want to talk about available GUI frontends, I'm the wrong guy to ask :) [07:01] Now, let's assume that I can't get it installed on the server right away... that only affects automated syncing with the live site, right? [07:02] Well, it means you need to use dumb protocols to access the branches on the server, which can be slower. [07:02] and the protocol used [07:02] which brings me to another question... is it easy to switch from one protocol to another? [07:02] And it does mean you'll have to find some way to deploy that doesn't involve having the working files directly on the server. [07:02] Oh, yes. Trivial. [07:02] OK... and it seems like either ssh or sftp will work fine... which is faster? [07:03] bzr+ssh is a smart protocol; sftp is the dumb one. [07:03] assume I don't have access to server-side bzr [07:03] Well, then sftp is the only choice :) [07:03] oh, ok [07:03] no standalone ssh? [07:04] GPH-Laptop: sftp is standalone ssh [07:04] meh [07:04] Well, once you ssh in, what do you do? :) [07:04] oh... good point [07:07] so what would be the commands I would have to issue to create the repository and trunk branch on the server? [07:07] cd /repo ; bzr init-repo . ; bzr init trunk [07:08] I meant assuming I'm issuing them from my local machine [07:08] You should be able to bzr init-repo sftp://server/repo/ ; bzr init sftp://server/repo/trunk too, without bzr up there. [07:08] Now, you may have (I would suggest) already made a branch locally with the files in it, and you want to turn that into the trunk. [07:09] In that case, you'd replace the last step with "cd /where/ever ; bzr push sftp://server/repo/trunk/" [07:09] (and then do something like "bzr bind :push" to turn your 'till-now-independant branch into a checkout of the central trunk) [07:09] what if I only have some of the files on my local machine, but the server should have all of them? [07:10] Slurp 'em all down and put 'em in the branch. [07:10] before or after all that stuff? [07:10] Now, if you have ssh access to the server, and it's already got python and such in place, you could pull down a copy of a bzr tarball and run it out of the source dir until you can get somebody to install it system-wide. [07:10] That would let you do more of the stuff on the server and save transferring files back and forth. [07:11] Well, before or after. It'd just have to be before you started considering that trunk authoritative of course. [07:11] right [07:11] well, I guess all my changes are already on the server [07:11] I advocate before; get it all working right locally and fiddle with it a bit, then set things up centrally. [07:12] The ease of rearranging workflows means that you can bite off a little at a time, and get it digested before trying the next push. [07:12] so would that be init or init-repo to set it up on my machine first? [07:12] init to setup a branch. init-repo would create the shared repo to share storage among multiple branches. [07:13] But you can skip the repo for now; can deal with that when you need it. [07:13] so init on my local, download all the files, then init-repo on the serveR? [07:14] Mmm. Let's forget the server for now. init on your local, download all the files [that you care about] [07:14] bzr add to schedule them for addition, and bzr ci to commit them. [07:15] Now you've got a branch (with all of 1 revision) setup with the necessary files. [07:15] so this would be ~/site/trunk/ [07:15] right? [07:15] Then you can bzr init-repo sftp://server/repo/ ; bzr push sftp://server/repo/trunk" at any time now or in the future to create a central trunk. [07:15] Right. [07:16] You can init-repo in ~/site/ now if you want. But it doesn't much matter. [07:18] does it matter if I init after I download? [07:19] Not really. init just sets up a bzr branch in the directory you specify (or current dir if you don't) [07:19] ok [07:20] what about whoami and other peripheral stuff? [07:21] Well, when you commit, we have to mark who committed. [07:21] With CVS, that's easy; we just take the username. [07:21] Since there's only one system, a username is unique. [07:22] With a distributed system, since commit can conceptually happen on any machine in the universe... username? Not so great. [07:22] So we have to come up with a committer ID somehow. whoami is how you set that. [07:23] Generally they look like RFC822 addresses. "Name " [07:23] If you don't explicitly set it, bzr guesses that your email is `username`@`hostname`, or various other heuristics. [07:24] (which is more than likely wrong, so you want to explicitly set it :) [07:24] right [07:25] how do I set it for this specific repo? [07:26] whoami has a --branch option to set it for a specific branch. [07:26]