markhI just like avoiding duplication of effort *before* that effort happens ;)00:00
jamI 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 overhead00:01
jamwhich is already too high00:01
abentleymarkh: I don't think we have no interest, but we don't have enough to do it ourselves right now.00:01
jammy rough testing here00:01
jamshows that it may not cost as much as I was originally worried00:02
jampoolie: call time?00:04
pooliegood point!00:04
markhwouldn'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
pooliespiv, call00:04
jammarkh: well, in traditional C code, I'm pretty sure you sprinkle _() liberally throughout your code00:05
jamrather than just at the point of display00:05
markhjam: lucky we aren't writing traditional C code ;)00:06
markhpersonally, I think gettext was invented by people who thought considering l10n *before* coding was for wimps ;)00:06
markhjam: 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:11
pooliethat's probably a reasonable answer00:17
* markh will one day learn to accept a simple answer... :)00:45
markhanother 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:46
markhthen later, bzr could adopt them at runtime if it can work out how to without costing too much perf00:47
markham I just making things hard on myself?00:47
pooliethat could be good00:49
fullermdMaking things hard on himself?   :)00:50
johanI 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
johanthis is from launchpad, what am I doing wrong?00:54
mwhudsonjohan: using bzr 1.500:55
mwhudsonif you upgrade to 1.6 it will go away00:55
mwhudson(the message from the client is a bit misleading, yes)00:55
johanmwhudson: sure, will do, thanks00:56
johanmwhudson, beuno: btw, great work on loggerhead. 1.6 is really nifty00:57
mwhudsonit's getting there :)00:57
johanworks fine here00:57
johanexcept that I couldn't quite figure out how to configure user-dirs properly00:58
mwhudsonit's still too slow, uses too much memory00:58
mwhudson(but you probably won't notice unless you're us)00:58
mwhudsonah yes, the user dirs thing is a strange beasty00:59
johanit's not instant, but /much/ faster than before00:59
* mwhudson afk for a bit00:59
=== kiko is now known as kiko-zzz
spiv_poolie: hi, sorry I missed the call.  Today I'm going to try land most of my patches that are approved in bundle buggy.02:00
=== spiv_ is now known as spiv
Peng_mwhudson: ping?02:31
mwhudsonPeng_: hi02:31
Peng_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
ubottuLaunchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New]02:33
mwhudsonPeng_: i can easily believe02:33
mwhudsonPeng_: whenever i think about url generation in loggerhead i just want to cry :/02:34
Peng_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:35
mwhudsonPeng_: care to help me configure apache locally to reproduce?02:38
Peng_I run Lighttpd. :P02:38
Peng_I dunno. I run a pretty basic mod_proxy setup.02:41
mwhudsonah, ok, can reprp02:44
* mwhudson stabs simpleTALES02:47
Peng_Oh, good (or not).02:48
mwhudsonwell, it's just so fun to debug02:48
mwhudsonWARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: 'int' object is not callable02:49
mwhudsona traceback would be nice02:49
=== jamesh_ is now known as jamesh
mwhudsondoes this stuff work at all?02:56
Peng_Is it just me, or does serve-branches not use loggerhead.trace.setup_logging()?02:58
mwhudsonPeng_: breadcrumbs03:01
Peng_mwhudson: When I filed bug 268867, they seemed fine, aside from that bug.03:02
ubottuLaunchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New] https://launchpad.net/bugs/26886703:02
Peng_I run a stripped-down version of serve-branches. Stop improving it, guys, it's getting hard to hack it all out. :(03:02
mwhudsonPeng_: can you try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs ?03:05
mwhudson(when it gets there)03:05
mwhudsonPeng_: try now03:08
Peng_Argh, that's based on the tip. I still haven't merged that.03:09
* Peng_ 's head spins03:10
mwhudsonPeng_: what changes do you have from tip?03:10
Peng_mwhudson: Mainly my stripped-down version of serve-branches.03:10
mwhudsonPeng_: what does serve-branches do that you don't want it to, by default?03:11
Peng_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
mwhudsoni see03:14
mwhudsoni guess it would be easier for you to call your script something else :)03:15
Peng_Hmm, that's not a bad idea.03:15
=== Peng__ is now known as Peng
PengPacket loss to your server is a good excuse not to work on LH, right? :P03:19
mwhudsonheh heh03:27
Peng_Wait, I only needed to change like 2 lines in serve-branches. Thank you, "bzr diff".03:48
Peng_mwhudson: Err, now I just got a traceback.03:50
mwhudsonPeng_: darn03:50
Peng_Hold on03:50
mwhudsonPeng_: pastebin?03:50
Peng_Damn, I forgot about Paste not logging exceptions.03:51
Peng_Which the new serve-branches code I didn't merge may have fixed.03:51
Peng_mwhudson: It was when I visited the root page. Here's the tail of the traceback, fwiw. http://paste.pocoo.org/show/86566/03:52
mwhudsonoh ffs03:53
abadger1999mwhudson: What's wrong with breadcrumbs?03:54
Peng_They attract roaches.03:54
Peng_And housecats!03:54
abadger1999well housecats aren't so bad.03:56
abadger1999except the vet bills.03:56
mwhudsonPeng_: try pulling rev 22803:56
Peng_Hold on03:56
Peng_mwhudson: Of which rbanch?03:57
Peng_fix-breadcrumbs? I don't see a new revision03:57
mwhudsonbzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs rev 22903:57
mwhudsonit'll be there in a minute03:57
Peng_Yeah, there iti s03:57
mwhudsonyou want 229 though, 228 is trivially broken03:57
Peng_Hey, no instant explosion!04:00
Peng_mwhudson: Seems to work perfectly (testing only the root and a /changes page)04:01
mwhudsonPeng_: good good04:01
Peng_(Aside from how the links don't end in a /, but that's only a minor inefficiency, not a real issue.)04:01
Peng_mwhudson: Thank you! :)04:03
mwhudsoni guess i'll merge to trunk then04:04
Peng_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:13
mwhudsonPeng: nope04:14
Peng_Thanks again for fixing this. :)04:15
abadger1999mwhudson: Hmm... I have errors with that branch.04:17
mwhudsonabadger1999: that's not a very useful url :)04:18
abadger1999There should be a "/" between bzr and packagedb04:18
abadger1999heh.  yeah.04:18
abadger1999mwhudson: server.webpath = 'http://localhost/bzr/'04:20
abadger1999And... I'm using my mod_wsgi script rather than serve-branches.04:20
mwhudsonabadger1999: ah, what happens if you don't have the slash on the end of the webpath?04:21
mwhudsonwell, nothing i guess04:21
* mwhudson hates urls04:21
abadger1999mwhudson: I get the same error.04:21
abadger1999well not error.  Same url.04:21
mwhudsonyeah, sorry, that was daft04:22
mwhudsonabadger1999: where do you get it?04:22
abadger1999Those are the links on the front page.04:22
abadger1999So that's one of my branches04:22
abadger1999The branches are autoconfigured.04:22
abadger1999auto_publish_folder = '/bzr/packagedb/'04:22
mwhudsonabadger1999: um, is this new with this branch?04:23
abadger1999mwhudson: yeah.  I wrote the breadcrumb patch that was merged at revno 224.04:23
abadger1999mwhudson: It worked at that point.04:23
abadger1999Actually... Let me just make sure I didn't have any other patches in my mod_wsgi branch that have bearing on this.04:24
mwhudsonyeah, rev 227 _really_ shouldn't have changed the browse view at all04:26
abadger1999mwhudson: My browse.pt  has:                     <a tal:attributes="href python:branch.static_url('/' + project.name + '/' +  view.name)"04:26
abadger1999yours doesn't have the '/'04:26
mwhudsonthe first one?04:26
mwhudsonabadger1999: is this a change you made?04:27
abadger1999I think I must have added that specifically for the mod_wsgi stuff.04:27
abadger1999I just confused the browse.pt and breadcrumbs.pt changes.04:27
* mwhudson grumps04:31
mwhudsonit seems that all calls but that one to static_url have '/' as path[0]04:32
mwhudsonso i may as well change that one04:32
abadger1999mwhudson: Cool.  Have you looked at my mod_wsgi branch?04:33
mwhudsonabadger1999: no04:33
* mwhudson looks04:33
abadger1999mwhudson: https://code.launchpad.net/~toshio/loggerhead/mod_wsgi04:34
mwhudsonabadger1999: do you know how unicode ends up in SCRIPT_NAME ?04:36
abadger1999mwhudson: Well, mod_wsgi and paste both put it there.04:36
abadger1999mwhudson: I'm talking to the mod_wsgi upstream right now... it might be part of the wsgi spec04:37
mwhudson"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
mwhudson(from pep 333)04:38
mwhudsonbut whatever04:39
mwhudsonabadger1999: i think on trunk, you should be able to call loggerhead.trace.something rather than copy/paste the logging config04:39
mwhudson(in loggerhead.wsgi)04:39
abadger1999That would be nice.04:40
mwhudsonand in general it would be nice for start-loggerhead and loggerhead.wsgi to share slightly more code04:40
mwhudsonlooks fine in other respects though04:40
abadger1999mwhudson: Sure.  Do you want the code moved into loggerhead and the two scripts just call them?04:41
abadger1999Or just to use the same code?04:41
mwhudsonabadger1999: i think that would be great04:41
mwhudson(the former)04:41
GPH-LaptopIf 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
fullermdNo, it won't change any existing stuff.05:20
fullermdIt'll only affect new branches.05:21
GPH-LaptopCan those files be edited directly?05:21
fullermdWhich files?05:21
GPH-LaptopLemme explain the situation and give some background05:21
GPH-Laptopour web team here has been maintaining the large (university) website using one SFTP user05:22
GPH-Laptopall developers use that same user to upload changes to the server05:22
GPH-Laptopwhich means that conflicts occur, and no one know who did what or when05:22
GPH-LaptopI would like to switch development over to Bazaar05:22
GPH-Laptopso... would it be best to init-repo right over the htdocs, or should I put it in a separate location?05:23
fullermdOK, so that's not _quite_ the right question.05:23
GPH-LaptopI would prefer that each developer be able to use their own username to commit changes05:23
fullermdRepos (init-repo) don't contain files; you don't work in repos.  Branches (init) do.05:23
thumperlifeless: ping05:23
GPH-Laptopinstead of the master username05:23
GPH-Laptopah, OK05:24
fullermdRepos are used to share storage among related branches.  We can ignore them for now.05:24
thumperjames_w: I don't suppose you have insomnia?05:24
fullermdGPH-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
fullermdGPH-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:25
fullermdThat'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
GPH-LaptopI'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
GPH-Laptopbut those personal directories need not be included05:26
fullermdWell, those aren't in htdocs, right?  They're off in userdirs.05:26
GPH-Laptoptrue, yeah05:27
GPH-Laptopbut there are a lot of symlinks to custom dirs05:27
GPH-Laptopthat might not quite map to a specific user05:27
GPH-Laptopbut nonetheless act like a userdir05:27
GPH-LaptopI think05:27
fullermdWell, that probably doesn't matter.  bzr won't walk _through_ the symlinks, though it could version the symlinks themselves.05:27
fullermd(you can choose to ignore and not version them of course)05:27
fullermdPresumably 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
GPH-Laptopnot something that would be actively developed05:28
fullermdSo, 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
GPH-Laptopsounds good05:29
fullermdWhich 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:29
fullermdOne 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
fullermdOn 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
fullermdOn 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
GPH-Laptopno way to delete that stuff?05:31
fullermdWell, yes and no.05:31
fullermdIt's permanently part of that history; there's no way to go back to a revision and take out parts of it.05:31
jmlwhy does TransportConfig.set_option() take value, name rather than name, value?05:31
fullermdYou could create a new history from scratch, that's pretty much like the old one EXCEPT without those pieces.05:31
fullermdBut 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
GPH-Laptopoh, wow, no file-by-file?05:31
fullermdRight.  Revisions are the whole tree.05:31
GPH-Laptopgotta remember that05:32
fullermdNow, 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:32
fullermdSo 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:33
fullermdIt 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
fullermdSomebody needed somewhere to stick that MPEG to send to their friend, 6 years ago, and forgot about.05:34
fullermdAt 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
fullermdThrowing away history like that makes ME twitch, of course.  But a lot of people are less obsessive than I am   :)05:35
GPH-Laptopis the repo compressed in any way?05:35
GPH-LaptopI'm probably more on your side of that line ;)05:35
GPH-Laptopbut I don't know how the rest of the web team is05:36
GPH-LaptopI just joined it05:36
fullermdYes, changes are stored as deltas rather than as continaul full-texts.  And there's gzip compression of the whole repo.05:36
GPH-Laptopoh, OK05:36
fullermdFuture formats will probably feature much better compression, especially for binary files.05:36
fullermdAs 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
GPH-LaptopI tried to find something that fit what we needed... Git and Mercury didn't seem to cut it05:37
GPH-Laptopthe problem is, there aren't any good Mac OS X GUI clients05:38
GPH-Laptopand we could really use that05:38
fullermdWhere did git and hg fall short?05:39
GPH-LaptopI forget... just at places that I consider important... I think they just did things differently than I would prefer05:39
GPH-LaptopWhy? Would you recommend one of those instead?05:40
fullermdWell, if I did, I'd be in #hg or #git rather than #bzr   :)05:40
GPH-LaptopThat's what I figured05:40
fullermdPartly, I'm just curious.05:40
GPH-LaptopYeah, I don't remember05:40
GPH-Laptopit was probably things we won't even wind up using05:40
fullermdAnd partly, despite a lot of higher-level differences the base models among the three are very similar.05:40
GPH-Laptopbut I'm a kind of guy who thinks CVS does some things better than SVN05:41
GPH-Laptoplike tags and branches and stuff05:41
fullermdSVN does tags and branches?   ;)05:41
fullermdI 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
GPH-LaptopWikipedia's got a nice comparison05:42
abadger1999GPH-Laptop: Tags I agree with you, branches not so much.05:43
GPH-Laptopabadger1999: Maybe not in the sense of merging05:43
abadger1999True. svn has branching but merging was not fun.05:43
fullermdOf course, CVS by its nature allows things that none of the modern VCS's do.05:44
GPH-Laptopeither way, Bazaar looks to be a good choice05:44
GPH-Laptopand I'd like to implement it ASAP ;)05:44
fullermdAlways a good plan   :)05:44
GPH-LaptopI just had to deal with a editing conflict05:44
GPH-Laptopwhich is not good over SFTP05:44
fullermdNow, here's the last sticky question; what's your deployment plan?05:44
fullermd(deploying the website, that is, not bzr)05:44
fullermdWhen 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
GPH-Laptopwe actually have two different websites... htdocs-dev operates on :8888, htdocs is live at :8005:45
fullermdSo you need some way to actually update the files the webserver sees.05:45
GPH-LaptopSo they can't be the same files?05:46
fullermdWell, 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
fullermdYou 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
GPH-LaptopOK, so they'll need to be pushed live either way05:47
fullermdIt's analogous with bzr; commands like "bzr push" shove around the 'repo', not working copies.05:47
fullermdRight.  There are a number of possible routes, but which is best depends on your case.05:47
fullermdFor 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
GPH-LaptopI was thinking cron05:48
fullermdFor devs that need a Mac GUI client, this is obviously not so hot a choice   :)05:48
fullermdcron is an option; just have a checkout where Apache looks for the site, and "bzr up" every 12 hours or something.05:48
bob2(don't forget the bzr-update-after-push plugin)05:49
fullermdThat could be supplemented by a carefully-crafted secure page with a "click here to force update".05:49
GPH-LaptopOK, now we're getting fancy05:49
GPH-Laptoplet's get the thing set up first :P05:49
fullermdAs 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:49
fullermdThough 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
fullermdThere's also a "bzr upload" plugin, which deploys/updates working files via sftp (or probably other transports) out of your local working dir.05:50
fullermdThe 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
GPH-Laptopso first I set up a repository outside of htdocs05:51
fullermdDoing 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
fullermdI'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
GPH-Laptoparen't dot-prefix files automatically off-limits?05:52
fullermdA thing to realize is that the location of and relationship between branches are MUCH more fluid than in CVSVN.05:52
fullermdNot in any server I've ever worked with....  Apache blocks and reserves .ht*, but no other dotfiles.05:53
GPH-Laptopoh, OK05:53
GPH-Laptopwell, what if I set up everything on the server, but outside the realm of the public website05:53
GPH-Laptopand basically pretend like I'm committing to the website05:54
fullermdHere's what I would suggest.05:54
fullermd1) 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:55
fullermd2) 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
fullermdUp 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
fullermdThen, 3) strongarm your associates into making their own checkouts and working from them.05:56
fullermd(up to here, you're still _deploying_ the files however you're doing it already; FTP or rsync or whatever)05:56
fullermdThen 4) choose the deployment strategy; making the live site a checkout, etc.05:57
fullermdNow, note that you're actually _using_ bzr pretty much like CVSVN here; there's one central branch that everybody checks out.05:57
GPH-Laptopthe problem I'm having in my head is the terminology, e.g. the difference between a branch and a repository, etc.05:58
fullermdThe 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
fullermdGimme a sec to finish off this email, then we can chat about that.05:58
fullermdThere.  Darn clients...05:59
fullermdSo, 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.05:59
fullermdBranches are implicit, and essentially properties of certain revision numbers.06:00
fullermdSVN is similar, except worse in making branches social constructs of various paths within the repo.  *shudder*06:00
fullermdIn both cases, you actually check out [some subset of] the repository.06:00
fullermdIn bzr, things are a bit different.  The checkout is still pretty much the same; it's where you work on files.06:01
fullermdThe 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
fullermdYou can't "check out" a repository; the concept is just without meaning.06:01
fullermdThere'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
fullermdA branch is what says "THIS is the current revision", basically speaking.06:02
fullermdEach 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
lifelessthumper: pong, but leaving poolies soon, topic ?06:02
fullermdSo essentially, a branch describes WHICH revisions are important for a particular line of development.06:03
GPH-LaptopI see... and these revisions are the who repository, not just specific files, right?06:03
fullermdThe 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
fullermdIn 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
fullermdWhen 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:04
fullermdAnd you can have other cases where all 3 pieces are in different places.06:05
fullermdBut in most ways, it doesn't matter which way things are setup; everything works the same.06:05
GPH-LaptopOK, this is the part where I lose you, hang on06:05
GPH-Laptopwhat do you mean when you say "colocated"? the same directory?06:06
GPH-Laptopso what does init-repo do?06:06
fullermd(well, technically, the checkout metafiles are in .bzr/checkout/, the branch in .bzr/branch/, and the repo in .bzr/repository/, but...)06:06
fullermdinit-repo creates a shared repository, which is a repo that multiple branches can refer to.06:06
fullermdTake your site.  Let's presume it's big, and has a lot of history.06:06
fullermdEnough that the whole history is a hundred megs.06:07
fullermdAnytime 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
fullermd(to say nothing of eating 200 megs of I/O, or worse, a hundred megs of network)06:07
fullermdObviously, this doesn't scale well.06:08
fullermdIn CVSVN, there's only one copy of the history, ever; on the central server.06:08
fullermdThis means that access the history can be slow, or even impossible if you're disconnected from the network (or it is)06:08
fullermdSo with the distributed systems, everybody has a copy of the history locally.06:08
fullermdWhich 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
fullermdEnter, the shared repository.06:09
fullermdBecause remember, branches don't actually hold the history; the repository does.  So you _need_ one copy per repository.06:09
fullermdYou can thus share one copy of the history across multiple branches, IF the branches share one repository, rather than each having their own.06:09
fullermdWe often say "repository" when we MEAN "shared repository", and so we say things like "you don't need a repository"06:10
fullermdOf 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:10
fullermdThe 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
fullermdIt just saves space (and time, since there's less data to shuffle around in various operations)06:11
fullermdSo, for instance, let's say we're both working on this site, and we each have 3 branches.06:11
fullermdLet's say they're the same 3, for simplicity.  trunk, fixlinks, and newimages.06:12
fullermdWe'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
fullermdSo 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:12
fullermdSo instead of taking up 3*N space, it just takes up N+<a few little bits of the differences>.06:13
fullermdNow you've got a repo in ~/website, with the 3 branches checked out in it: ~/repo/trunk, ~/repo/fixlinks, ~/repo/newimages06:13
fullermdEr, ~/website/, not ~/repo/ in all those cases.06:13
fullermdNow I've got all 3 checked out too: ~/website/trunk, ~/website/fixlinks, etc.06:13
fullermdBUT, for whatever reason, I *DON'T* have a shared repo in ~/website/06:14
fullermdSo on MY machine, each of those branches has their own (internal) repo, so I have 3 full copies of the history.06:14
fullermdRather stupid on my part.06:14
fullermdBut it doesn't have any impact on how I work with you, or with the central server.06:14
fullermdAny 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:14
GPH-Laptopon the central server?06:15
fullermdOn any place.06:15
fullermdIt'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
GPH-Laptopso what is the difference between my files and your files?06:16
fullermdIf I create a repo in ~/website/ later on, it doesn't affect those existing branches.06:16
fullermdBut I can explicitly convert them to using a repo, and so regain all that space.06:16
fullermdSo 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 constructs06:16
fullermdAnd (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
GPH-Laptopso the shared repo is for me and my multiple branches?06:17
fullermdEssentially, the difference between my files and your files is...   well, my files are my files, and your files are your files   :)06:17
fullermdRight.  A shared repo only has meaning where it is; it doesn't affect anything outside.06:17
GPH-LaptopI think I'm having trouble letter go of the central server06:18
fullermdAll commands work on and between _branches_, not repos (not quite true, but close enough).06:18
fullermdYou never checkout a repo, or branch a repo, or commit into a repo; you do things on branches.06:18
fullermdSure.  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
GPH-Laptopone shared repo06:18
fullermdIt 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
fullermdBut there's no technical different; no separate setup, no special "I am master" flag.06:19
GPH-Laptopso, in my case, a shared repo on the server06:19
fullermdIf you're going to have multiple branches (even possibly in the future), yes, a shared repo.06:19
fullermdBut you don't need to; if all you'll ever have there is trunk, you could just make it a standalone branch.06:20
GPH-Laptopwould be the "central" location06:20
GPH-LaptopI think we'll be needing multiple branches06:20
* fullermd nods.06:20
fullermdProbably a good idea to plan for that, even if it doesn't ever come about.06:20
GPH-LaptopOK, so the server has the one central shared repo06:20
GPH-Laptopnow how do the branches work?06:20
GPH-Laptopare they on the server, or local, or what?06:21
fullermdSo, 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
fullermdLet's take the example of bzr itself.  It's developed in bzr.06:21
fullermdI keep a local mirror of the bzr development.06:21
fullermdI did that via "bzr branch http://bazaar-vcs.org/bzr/bzr.dev/", which is where that branch is available.06:22
fullermdAnd every few days, I do a "bzr pull" to keep it updated.06:22
fullermdSorta like using cvsup to mirror a CVS repo.06:22
GPH-Laptopyeah... I used GUI for CVS, too :P06:22
fullermdNow, _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:22
fullermdBut 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
fullermdSo 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:23
fullermdIn 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
fullermdIn your case, you'll have a branch of the site on server:/repo/trunk/, and a branch on workstation:~/website/trunk/.06:24
fullermd(assume you do a 'branch', not a 'checkout', which you probably won't, but for the purposes of this discussion...)06:24
fullermdYou'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:25
GPH-Laptopso I commit locally first, and then push the commits to the server later?06:26
fullermdBy 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
GPH-Laptopoh, ok06:26
fullermdIf you're working in a branch rather than a checkout, yes.06:26
fullermd(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:26
GPH-Laptopconsider it done06:27
fullermdThe 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:27
fullermdThe extra commands come when you deal with multiple branches and moving stuff between them.06:28
GPH-LaptopOK, well, we're in the process of moving from PHP4 to PHP506:28
fullermdpush 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
GPH-Laptopbut they need to be independent of each other06:28
GPH-Laptopso that would be branches, no?06:28
fullermdmerge is used to merge together changes from another branch into one you're working on locally.06:28
fullermdSo, let's pretend that you're the only one doing the 4->5 conversion.06:29
fullermdThe other half dozen people are just continuing to work on the existing site.06:29
fullermdThere's a server:/repo/trunk/ branch that's used for that.06:29
fullermdAnd you've got a checkout of it in ~/site/trunk/06:29
fullermd(and so does everybody else of course)06:29
fullermdYou work with this just like you'd work with CVS.06:29
fullermdNow, 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
fullermdInstead, you just make a branch locally.  You do something like "cd ~/site ; bzr branch trunk php5"06:30
fullermdNow you've got a new branch in ~/site/php5/ to do that work.06:30
fullermdYou 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
fullermdSo you keep your trunk copy updated: cd ~/site/trunk/ ; bzr up06:31
fullermd(and you may still do some work on trunk too; who knows)06:31
fullermdAnd every so often, you merge those changes into your ongoing PHP5 work: cd ~/site/php5/ ; bzr merge ../trunk06:32
fullermdThis 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
fullermdRinse, repeat; this process goes on for about 20 freakin' years, until you finally get done the conversion.06:32
fullermdThen 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
fullermdAnd now the branch is landed, you take it live, receive worldwide adulation.  Riches, power, beautiful women throwing themselves at your feet, etc.06:33
fullermdThere's a few things to notice here.06:33
fullermd1) 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
fullermdYou 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:34
fullermdbzr 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
fullermd2) This php5 branch you did all this work in, never existed on the server.  It only ever exists on your local drive.06:35
fullermd3) 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:35
fullermdAnd 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:36
fullermd(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
fullermdNow, let's back up a little, and pretend you're partway done.06:37
fullermdAnd 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
fullermdI do that by making my own branch of your php5 branch in my ~/site/php5/.06:37
fullermd(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
fullermdMy 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
fullermdEventually 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:38
GPH-Laptopthanks a lot06:39
fullermdAgain, 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
fullermdBoth 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
fullermdBut 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:39
fullermdSo 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
fullermdOf course, we can't just each go off our separate ways; we have to stay in sync.06:40
fullermdSo, 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
fullermdAnd you would do the same in reverse; merge my changes back.06:41
fullermdThis 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
fullermdOf 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:41
fullermdAnd 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
abadger1999mwhudson: I have good news and bad news.06:42
fullermdBut wait; that's a little annoying, us having to merge back and forth.06:42
mwhudsonabadger1999: tell me the good news now and the bad news tomorrow? :)06:42
thumperlifeless: sorry, fixed the problem anyway06:43
fullermdAnd 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
abadger1999Good news is I'm testing the combined mod_wsgi paste.httpserver stuff and it works for mod_wsgi.06:43
fullermdAnd what about 4 people, or 5, or 50?  Eeek.06:43
abadger1999mwhudson: bad news has to do with breadcrumbs :-(06:43
fullermdSo 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/trunk06:44
mwhudsonabadger1999: argh06:44
fullermdThen 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
mwhudsonabadger1999: can you file bug reports?  i'm really too fried to think hard about this stuff now :/06:44
fullermdThen 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
abadger1999mwhudson: No problem.06:44
fullermdAnd 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
abadger1999mwhudson: If I understood simpleTAL better I'd do a better job of debugging :-(06:45
fullermdGPH-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:45
GPH-Laptopbut, by spelling it out for me, it helps me wrap my head around it06:46
fullermdGPH-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
fullermdWe 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
fullermdAnd converting over to working that way is very, very easy.06:46
fullermd(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:47
fullermdSo 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
GPH-LaptopSo, if we had the central php5 branch... would our local files be a branch or a checkout?06:48
fullermdSo 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
fullermdThey 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:48
fullermdOr I could make it a checkout, and work straight-line in it.06:49
GPH-Laptopso a branch is pretty much a middle man?06:49
GPH-Laptopa local branch, that is06:49
fullermdAnd if I had write access to your ~/site/ somehow, I could checkout YOUR ~/site/php5 too, instead of branch'ing it.06:49
fullermdHm.  I'm not sure I'd phrase it that way.06:49
GPH-Laptopalright, nevermind then06:49
fullermdA branch is the thing you work on, via a checkout.06:49
GPH-Laptopnow, if you did check out my stuff, too, could you still merge the two?06:50
GPH-Laptoptwo checkouts06:50
fullermd(which checkout COULD just be colocated with the branch, in simple cases)06:50
fullermdWell, technically, you merge branches, not checkouts.  But you do all the work in a checkout.06:51
fullermdLet's take the case where there's trunk and php5 on the server, and I've checked out both.06:51
fullermdWhen I cd ~/site/trunk ; bzr merge ../php506:51
fullermdWhat I'm DOING is actually merging the php5 branch into the trunk branch, and preparing the merge to be committed.06:51
fullermdOf 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:51
fullermdSo it sorta steps down through all 3 pieces to get what it needs.06:52
GPH-Laptopso... 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:52
GPH-Laptoprelative to the central repositor06:53
GPH-Laptopor branch06:53
GPH-Laptopor whatever06:53
GPH-Laptopthe central server06:53
fullermdMmm.  I'm not sure that phrasing means much...06:53
fullermdWhen you commit, the process goes something like:06:53
fullermd1) Get the current state of everything from the checkout06:53
fullermd2) Get the previous revision (which is at the moment the latest) from the branch (slight lie, but close enough)06:53
fullermd3) 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
fullermd4) Stuff that revision in the repository (wherever that might be for this particular case)06:54
fullermd5) Update the branch to tell it "Your head revision is now <newrev>"06:54
fullermd(this glosses over details, and skips some others, but it's close enough for understanding)06:54
fullermdMerge works somewhat crossing levels.06:56
fullermdOn one level, it's just as if you'd made changes to the files manually; it just does it for you.06:56
fullermdBut on another level, it queues up the revisions you're trying to merge, so they become part of the history.06:56
fullermdOn a normal commit, the revision you create has one "parent"; it's the revision you start from.06:56
fullermdOn a merge, though, the revision has TWO parents; the first is as above; the one you started working from in your checkout.06:56
fullermdThe 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
GPH-Laptophmm... OK06:57
GPH-LaptopI think I understand those concepts enough06:57
fullermdThat's why, after you've merge php5 into trunk, you don't need php5 anymore; trunk has all those revisions pointed to.06:57
GPH-Laptopnow what about implementation?06:58
GPH-Laptopwhere do I have to install Bazaar?06:58
fullermdAnd 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
fullermdWhere in terms of where on a machine, or where in terms of on what machines?06:58
GPH-Laptopon what machines06:58
vilahi all06:59
fullermdWell, 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
fullermdBut 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
fullermdAnd having it on the server lets you use the smart protocol, like bzr+ssh, which will be more efficient.06:59
GPH-Laptopoh, for the automation, yeah06:59
GPH-Laptophmm... ok07:00
fullermdAnd of course, you need bzr (with whatever frontend) on whatever machines developers are working on.07:00
fullermdPretty much the same as asking "Where do I need to have cvs installed".07:00
* fullermd waves at vila.07:00
GPH-Laptophmm, I suppose07:00
fullermdNow, if you want to talk about available GUI frontends, I'm the wrong guy to ask   :)07:01
GPH-LaptopNow, 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:01
fullermdWell, it means you need to use dumb protocols to access the branches on the server, which can be slower.07:02
GPH-Laptopand the protocol used07:02
GPH-Laptopwhich brings me to another question... is it easy to switch from one protocol to another?07:02
fullermdAnd 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
fullermdOh, yes.  Trivial.07:02
GPH-LaptopOK... and it seems like either ssh or sftp will work fine... which is faster?07:02
fullermdbzr+ssh is a smart protocol; sftp is the dumb one.07:03
GPH-Laptopassume I don't have access to server-side bzr07:03
fullermdWell, then sftp is the only choice   :)07:03
GPH-Laptopoh, ok07:03
GPH-Laptopno standalone ssh?07:03
lifelessGPH-Laptop: sftp is standalone ssh07:04
fullermdWell, once you ssh in, what do you do?   :)07:04
GPH-Laptopoh... good point07:04
GPH-Laptopso what would be the commands I would have to issue to create the repository and trunk branch on the server?07:07
fullermdcd /repo ; bzr init-repo . ; bzr init trunk07:07
GPH-LaptopI meant assuming I'm issuing them from my local machine07:08
fullermdYou should be able to bzr init-repo sftp://server/repo/ ; bzr init sftp://server/repo/trunk too, without bzr up there.07:08
fullermdNow, 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:08
fullermdIn that case, you'd replace the last step with "cd /where/ever ; bzr push sftp://server/repo/trunk/"07:09
fullermd(and then do something like "bzr bind :push" to turn your 'till-now-independant branch into a checkout of the central trunk)07:09
GPH-Laptopwhat if I only have some of the files on my local machine, but the server should have all of them?07:09
fullermdSlurp 'em all down and put 'em in the branch.07:10
GPH-Laptopbefore or after all that stuff?07:10
fullermdNow, 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
fullermdThat would let you do more of the stuff on the server and save transferring files back and forth.07:10
fullermdWell, before or after.  It'd just have to be before you started considering that trunk authoritative of course.07:11
GPH-Laptopwell, I guess all my changes are already on the server07:11
fullermdI advocate before; get it all working right locally and fiddle with it a bit, then set things up centrally.07:11
fullermdThe 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
GPH-Laptopso would that be init or init-repo to set it up on my machine first?07:12
fullermdinit to setup a branch.  init-repo would create the shared repo to share storage among multiple branches.07:12
fullermdBut you can skip the repo for now; can deal with that when you need it.07:13
GPH-Laptopso init on my local, download all the files, then init-repo on the serveR?07:13
fullermdMmm.  Let's forget the server for now.  init on your local, download all the files [that you care about]07:14
fullermdbzr add to schedule them for addition, and bzr ci to commit them.07:14
fullermdNow you've got a branch (with all of 1 revision) setup with the necessary files.07:15
GPH-Laptopso this would be ~/site/trunk/07:15
fullermdThen 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
fullermdYou can init-repo in ~/site/ now if you want.  But it doesn't much matter.07:16
GPH-Laptopdoes it matter if I init after I download?07:18
fullermdNot really.  init just sets up a bzr branch in the directory you specify (or current dir if you don't)07:19
GPH-Laptopwhat about whoami and other peripheral stuff?07:20
fullermdWell, when you commit, we have to mark who committed.07:21
fullermdWith CVS, that's easy; we just take the username.07:21
fullermdSince there's only one system, a username is unique.07:21
fullermdWith a distributed system, since commit can conceptually happen on any machine in the universe...   username?  Not so great.07:22
fullermdSo we have to come up with a committer ID somehow.  whoami is how you set that.07:22
fullermdGenerally they look like RFC822 addresses.   "Name <em@ai.l>"07:23
fullermdIf you don't explicitly set it, bzr guesses that your email is `username`@`hostname`, or various other heuristics.07:23
fullermd(which is more than likely wrong, so you want to explicitly set it  :)07:24
GPH-Laptophow do I set it for this specific repo?07:25
fullermdwhoami has a --branch option to set it for a specific branch.07:26
fullermdYou can use patterns in the location.conf file (~/.bazaar/locations.conf on *nix) to set a specific whoami based on the path to where you are at the moment.07:26
fullermdI think whoami --branch sets it in the branch's local config, so that's not as great an option if it's a branch that multiple people commit on.07:27
fullermdOf course, if it's just on your local machine, that's not a worry.07:27
GPH-Laptopwell, I've got a global whoami to my regular e-mail address, but I want to set this school repo to my school e-mail address07:27
GPH-Laptopbut that spans (or will span) multiple branches07:28
fullermdYou could setup a locations.conf that looks like:07:28
fullermdemail = GPH <gph@school>07:28
fullermdemail = GPH <gph@play>07:28
fullermdAnd then just have all school-related branches under ~/school/, etc.07:28
GPH-Laptopcan I use DEFAULT for the latter case?07:29
fullermdWell, you could just leave off the second case if gph@play is your default setting.07:29
GPH-Laptopand this goes in ~/.bazaar/locations.conf?07:29
fullermdIt would be a different place on Windows...   I think OS X uses the same as *nix.07:30
GPH-LaptopI'll give it a try07:30
fullermdCheck "bzr version"; it'll list "Bazaar configuration:" as the directory where that stuff goes.07:30
GPH-Laptopyeah, same place07:30
GPH-Laptopdoes it have to be absolute, or can I use ~ in the conf file?07:31
fullermdI'm not sure.07:32
fullermdI know it supports some globbing, so [/home/gph/*/school] would do what you'd expect.  But I'm not sure if it does ~-expansion.07:32
* fullermd prods lifeless.07:32
fullermdI s'pose I could just try it and find out...07:33
GPH-Laptophow do I get it to kick in?07:34
* fullermd frowns.07:34
fullermdOK, it looks like it doesn't.  And it only kicks in when there's actually a bzr branch there.07:35
fullermdThat sounds like a bug...07:35
* fullermd files.07:35
GPH-LaptopOK, works07:36
chandlercwow, 70mb resident memory doing bzr update??07:37
chandlerc80 now07:37
chandlercis that... normal?07:37
* GPH-Laptop shudders as he starts to download the entire server07:37
GPH-Laptopalright, I think it's about time for bed07:39
GPH-Laptopfullermd: Thank you very much for your help07:39
GPH-LaptopYou're a regular here, I gather?07:39
fullermdOh, yes.  Any excuse not to get work done...07:39
GPH-LaptopWhat do you think I'm doing? ;)07:39
fullermdSee?  We're helping each other.  God bless the Internet.07:40
GPH-LaptopI'll be back again to distract you soon enough07:40
GPH-Laptopbut I need some shut-eye07:40
fullermdWell, I guess I should actually get work done anyway.07:41
GPH-Laptopas I download the entire website07:41
GPH-Laptopgeez... it's just going through directories right now... it hasn't even started on the files yet07:41
GPH-LaptopI really hope I don't run out of disk space while I sleep07:42
fullermdThat would bode poorly for using bzr on the files   :p07:42
GPH-Laptopwell, I still have to filter out all the junk07:43
GPH-Laptopyeah, alright, bed07:44
GPH-Laptopgotta stop talking07:44
TreenaksIs there a way to get the patch + log at the same time in bzr? (like "git log -p" in git)08:02
TreenaksI've figured out something like 'bzr send -r 3..4 -v -o- .', but it's not really intuitive to figure out :)08:03
luksthere is no equivalent of git log -p08:06
Treenakshm.. so my 'bzr send' hack is really the best approximation?08:08
luksI'm not sure what does the -v do08:09
lifeless-v shows a status between commits08:09
chandlercjelmer: i figured out what the deal was with the crash -- i stopped working with trunk/tags/branches, and started on a flat svn repo... with trunk/tags/branches, I get the segfault again08:28
chandlercjelmer: but there is nothing in my .bzr.log or in the output to provide a bug report... kinda at a loss08:28
chandlercfun times08:37
chandlercpdb is useless because the whole python interpreter crashes08:37
fullermdIf you're gonna have tools, they might as well be thorough   :)08:40
Treenakslifeless: is there a reason for not being able to show diffs with log?08:42
lifelessTreenaks: not implemented ?08:46
Treenakslifeless: Yeah, ok.. but no 'deeper' reason ("we don't want it", etc.)08:51
james_whey thumper, 'fraid not.09:01
chandlercjelmer: Bug #276219 filed.09:12
ubottuLaunchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/27621909:12
AfCAh the joys of calling native libraries from managed code.09:19
gmbI'm having trouble doing a bzr upgrade --1.6 in a repo.09:26
gmbI get the following error:09:26
gmb'bzr: ERROR: Directory not empty:  "/$path-to-repo/.bzr/repository": [Errno 39] Directory  not empty'09:27
gmbDoes anyone have any idea why I'd get that?09:27
gmb(Note that I've subbed in $path-to-repo there; it was a long path ;))09:27
gmbSomewhat, yes :)09:29
james_wcan you grab a copy of the repo to test with?09:29
gmbjames_w: I have a backup copy. I'll rsync it to somewhere I can play with it, hang on.09:29
james_wjust don't want to trash your data09:30
gmbjames_w: Good plan!09:31
* gmb notes that he should probably clear that repo out more often :/09:35
gmbjames_w: I now have a repo to muck about with.09:43
james_wso can you try the upgrade again, but with -Derror this time please?09:44
james_w(that's a command line argument if you haven't seen -D before with bzr)09:44
=== cjwatson_ is now known as cjwatson
lifelessrobertc@lifeless-64:~/source/unittest/testresources$ bzr merge http://bazaar.launchpad.net/~jml/testresources/tests-meaning-cleanup11:49
lifelesshttp://bazaar.launchpad.net/%7Ejml/testresources/tests-meaning-cleanup is permanently redirected to /~jml/testresources/tests-meaning-cleanup/changes11:49
lifeless^ little ugly ?11:49
jmlyeah, a little.11:51
jmlbut, I'm not sure why it's happening.11:51
lifelessalso, merged and pushed11:55
jmllifeless: thanks :)11:57
quicksilvervila: ping?12:29
vilaquicksilver: pong12:36
quicksilvervila: I'm finding DVC is getting pretty slow now we have 800 revisions in our tree :(12:36
quicksilvervila: at least, for view revision logs.12:36
vilaha, I never do that :-/12:36
quicksilvermaybe I'm doing things wrong.12:37
quicksilverI am the main patch reviewer12:37
quicksilverso I update my tree to other people's recent commits12:37
quicksilverhit C-x V L and then review their commits one by one12:37
* vila looking at sources12:38
vilahmm, there is a last-n parameter, but I can't find a way to specify it directly12:41
vilamay be you can just rebind C-x V L to show the last 20 or whatever12:41
* quicksilver nods12:42
quicksilvervila: has there been developmend on dvc recently?12:42
quicksilverbecause I have a fairly old version.12:42
quicksilveris there some mailing list it's discussed on.12:42
viladev continues at almost the same speed, the list is: dvc-dev@gna.org, subscribe at https://mail.gna.org/listinfo/dvc-dev12:43
vilait seems they miss the deadline for inclusion in emacs-23 and they now target 24 (or 22/23 :-)12:44
vilathey made good progress to support other DVCs too, bzr support staying almost stable, generic parts have improved too12:45
quicksilverI will join the list! thanks12:46
vilaquicksilver: you're welcome ;)12:46
quicksilvervila: it would help if the log mode could parse incrementally12:46
quicksilver(Rather than waiting for the command to terminate)12:46
quicksilverbut as I understand it, asynchronous stuff is pretty hard in emacs.12:46
vilaquicksilver: as always, the hard things are the ones you never did :)12:49
quicksilverwell, worse than that12:49
quicksilverthe hard things are the ones other people never did for me ;)12:49
quicksilveror not yet, anyway.12:50
=== bac_afk is now known as bac
jammorning vila14:48
vilamornign jam !14:48
vilanearly good :)14:49
vilamorning jam !14:49
=== kiko-zzz is now known as kiko
=== kiko is now known as kiko-phone
jelmerjam, Keep up the good work!15:53
Stavrosi have a use case i need some help with:16:32
Stavrosi branch off some code to develop a feature, and push that to production. i need to fix a bug in HEAD, so I do, how can i push that bugfix to production while retaining the branch's changes?16:32
Takmake a separate branch of HEAD, fix the bug there, and push it?16:34
Stavroswell, head does have a branch already16:34
Stavrosso i just push it? how does it merge the changes?16:34
Takmaybe I'm misunderstanding your question16:37
Stavroslet me explain better16:37
Stavrosi have head and branch, creating branch A16:37
Stavrosi merrily make changes to branch a16:37
Stavrosthen i make a change to head and want to merge it into branch a16:37
Stavroshow do i do that?16:37
Takoh - wouldn't you just pull from head to branch a?16:38
luksbzr merge path/to/head16:38
luksthis will merge all head's changes, which you might not want16:38
Stavrosis there a way to only merge some?16:39
nefertum|is it possible to commit the tags to a remote repository?16:39
Stavrosnefertum|: yes, just push it16:39
Stavrosnefertum|: with --overwrite, probably16:39
luksStavros: you can do bzr merge -c X path/to/head, but then you have to commit a new revision16:39
luksStavros: and bzr doesn't know it's the original one16:39
nefertum|mmmm, yes Stavros i'm using push without --overwrite...16:39
luksusually it's best to have small branches, so that you can merge them in cases like this16:40
Stavroswell i probably won't need to merge some changes, so the first alternative should work, thanks16:40
Stavrosnefertum|: yeah, you have to use overwrite because tags aren't versioned16:40
Stavrosluks: that's what i'll do then, thanks16:40
lukshttp://www.venge.net/mtn-wiki/DaggyFixes if you want some interesting and (maybe) confusing reading :)16:41
Stavrosoh i've read that, it has some good ideas16:49
Stavrosi'll read it again to refresh my memory, thanks16:50
=== kiko-phone is now known as kiko-fud
=== fta_ is now known as fta
=== kiko-fud is now known as kiko
=== mw__ is now known as mw|food
nefertumi'm trying to do a checkout from a svn repository, i've installed bzr-svn, and i have this error: http://pastebin.ca/121496619:51
nefertumany idea about this?19:51
=== mw|food is now known as mw__
=== mw__ is now known as mw|out
=== mw|out is now known as mw
nefertumcould anyone explain me what means "branches without working trees" (--no-trees)20:17
beunonefertum, just the repository20:18
beunoso you would just have a .bzr directory20:18
beunobut no files20:18
nefertumbeuno: and if i want to add a project or a branch of a project? bzr init ??20:19
nefertumand that's all?20:19
beunonefertum, you want to add more files to the branch?20:19
nefertumwell, really i'm reading the bazaar doc and i didn't understand this...20:19
nefertumi'm a newbie with bzt20:19
beunoworking tree-less branches are usually so use remotely20:20
beunoso you would have a branch with a WT locally20:20
beunoand push20:20
beunoto the remote branch20:20
beunowhich really doesn't need to have all the files laying around20:20
beunolocally, you probably want a working tree to actually work on  :)20:20
nefertumbeuno: so then, i only need a WT in the branches but not in the repository, isnt it?20:22
beunonefertum, are you using a shared repository?20:23
nefertumi'd like to have a server with the repository, yes20:23
nefertumi should configure in it a repository without WT then20:23
nefertumand push branches in it?20:23
beunonefertum, if you push remotely, you don't get a WT20:24
nefertumbeuno: if i start the repository in local, to push it later to a remote server, and then have to use WT or not?20:24
nefertumi think i'm not understanding this :-P20:24
Verteroknefertum: if you push there is not WT involved20:29
asabilis it normal that bzr dpush uses 100% cpu21:12
jelmernefertum, hi21:18
jelmernefertum, please try a newer version of bzr-svn21:18
jelmerasabil, it's not very heavily optimized21:19
asabilI mean uses 100% cpu for about 1 minute and hangs there doing nothing21:19
asabilI had to kill it21:19
jelmerasabil, how many revisions were you trying to push?21:20
jelmerit's got a very high per-revision overhead21:20
asabil1 revision21:20
jelmerwhat version of bzr-svn?21:21
asabilthe one from the PPA21:21
jelmerasabil, have you ever pushed anything to that repository befoer?21:22
jelmerin that case it may just be filling the cache looking for older bzr-svn revisions21:23
jelmerthat'll be slow the first time you access the repo21:23
asabilwell, the repo is branched from bzr-mirror21:23
jelmerthat shouldn't matter21:24
asabilhmm ok21:24
asabilI am trying again21:25
asabilI just don't know what is happening21:25
nefertumjelmer: thanks, i'll try21:49
nefertumjelmer: i'm using 0.40.10-2 version, from debian unstable...21:50
nefertumwhich one is the last version?21:50
jelmernefertum, 0.4.1321:50
jelmernefertum, experimental has the latest21:50
nefertumthanks jelmer !21:51
nefertumjelmer: it worked, thanks a lot21:59
jelmernefertum, you're welcome21:59
asabiljelmer: is 35 minutes too much ?22:00
jelmerasabil, how big is the repository?22:01
asabilabout 1800 revisions22:01
asabiljelmer: is using bzr push faster ?22:13
jelmerasabil, it is faster, I'm not sure whether it's significant though22:15
chandlerc[g]jelmer: ping22:21
jelmerchandlerc[g], pong22:23
chandlerc[g]gah, sorry22:30
chandlerc[g]stuff keeps distracting me22:30
chandlerc[g]0.4 branch22:30
chandlerc[g]and i agree, that it seems like the entire PyArg function failed22:31
chandlerc[g]anything i can do to help debug it?22:31
jelmerIf you can find out what causes PyArg_ParseTuple to return NULL, that would help :-)22:32
chandlerc[g]where do i look?22:33
jelmerI'm a bit at a loss as to what's happening here22:33
chandlerc[g]yea, me too22:33
chandlerc[g]weird thing, its happening for multiple different svn repositories22:33
chandlerc[g]i'm adding empty directories to the repository, could that do it?22:33
jelmerIf you can attach a script that reproduces the problem for you with a local svn repo, that would help22:35
chandlerc[g]it's totally blocked my work though22:35
chandlerc[g]so i'm willing to do anything i can to help22:35
chandlerc[g]i'll try to set up a local svn when i get home today though22:35
jelmerA script that reproduces it would allow me to reproduce the problem locally22:36
jelmerIt's hard for me to say anything sensible about it if I can't reproduce it :-/22:36
chandlerc[g]i've got it reproduced on two separate remote repositories22:36
james_wthumper: hey, can I still be of assistance to you?22:50
thumperhi james_w22:50
thumperjames_w: I've managed to sort out my issues22:51
thumperbut thanks for asking22:51
james_wthumper: coolness22:51
hsn_why my bzr log shows 195 revisions and bzr check 201 and 0 unreferenced revisions?22:57
pooliehsn_: well, depending on how you're counting, there may be 6 merged-in revisions22:58
hsn_poolie: how can i count merged revisions?23:00
pooliethey're shown indented in the log display23:00
pooliethere's also a bzr-stats plugin iirc that might be interesting23:00
hsn_part of bzrtools?23:02
jampoolie: just letting you know I won't make it to the standup tonight, have to watch my son. Though if you want to call my cell phone, I guess I could participate that way23:06
pooliehsn_: launchpad.net/bzr-stats23:15
james_wjml: hey hey23:34
james_wjml: would you have a little time for a chat today?23:34
jmljames_w: yes23:34
jmljames_w: when's good/23:34
james_wjml: great, I'd just like to figure something bzrlib out, and then I'm done for the day, so perhaps 30 minutes?23:35
jmljames_w: fine by me23:35
james_wwell, done coding that is23:35
james_wjml: great, thanks23:35
james_wanyone know how to request a file over a transport where it will be redirected?23:46
james_wah, got it I think23:48
lifelessjames_w: redirects are exceptions23:48
lifelessjames_w: so catch it and rerequest23:48
james_wlifeless: yeah, there's do_catching_redirections to help. I was requesting the transport of the new location of the file, rather than it's parent dir, so when I did the final .get() it ended up with the filename doubled on the end23:49
james_wthanks though23:50
nefertummmm, i'm starting with bazaar and i'd like to have a shared repository in a server and do distributed development with bazaar23:50
nefertumi've started a repository in /bazaar with bzr init-repo23:50
nefertumi'd like to use the nested style i've read in the user guide23:51
nefertumthe doubt is...i push a man branch to the server, or many of them, and later can i get all the content of the repo?23:51
lifelessnefertum: yes23:52
nefertumlifeless: i've created the repo with --no-trees23:53
nefertumbut i don't understand well the meaning of this...23:53
lifelessnefertum: a 'shared repository' is just a DB23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!