| fullermd | bairui: So how did your designing-layouts/workflows stuff turn out? | 00:58 |
|---|---|---|
| bairui | so far, so good... methinks. I have a workflow doc and I'm creating some images to go along with it now. | 00:59 |
| fullermd | Cool. | 01:02 |
| fullermd | 's long as it doesn't end up in a Powerpoint or something, anyway... | 01:03 |
| bairui | I am just putting it in pastebin if you'd like to cast your critical eye over it, fullermd? | 01:03 |
| fullermd | Well, it'd be a pretty cursory glance. I'm evaluating and collating incomplete and outdated information for a pointless meeting on Monday about a doomed project. | 01:05 |
| bairui | fullermd: http://pastebin.com/88sNi5Wv | 01:08 |
| bairui | and thanks for even glancing at it :) | 01:08 |
| bairui | hate meetings... especially pointless ones, and so many are. :-( | 01:09 |
| fullermd | I would suggest using a checkout rather than a branch for trunk. Then you can just merge/commit, and it also makes it harder to accidentally go the other way and swap around the mainline accidentally. | 01:13 |
| fullermd | And you're already using checkouts for the feature branches anyway, so might as well be consistent. | 01:13 |
| * bairui is taking notes | 01:13 | |
| bairui | ok. good to know. | 01:13 |
| fullermd | I'm not sure why you have the "merge --pull" stuff in youe trunk branch notes here either. | 01:14 |
| fullermd | I suspect you really meant just 'bzr pull'. | 01:14 |
| bairui | i think we were originally doing a bzr pull and saw someone use merge --pull and thought, well that saves a command if we had to merge... wrong? | 01:14 |
| fullermd | Well, for one thing, after a merge you'd have to commit the merge. | 01:15 |
| bairui | ah. ok. | 01:15 |
| fullermd | But also, if pull failed on trunk, I'd think that's a red flag to stop and go "whoah, wait, wtf". Not something to gloss over. | 01:15 |
| bairui | so - we'll go back to bzr pull and be explicit about the merge if that was necessary | 01:15 |
| bairui | agreed | 01:15 |
| fullermd | That would mean that somehow your local 'trunk' ended up with something the upstream trunk doesn't have. That shouldn't happen. | 01:15 |
| bairui | like a local commit | 01:16 |
| fullermd | And if it did and you merge, you get into the mainline-swapping situation. | 01:16 |
| bairui | ok. to be avoided. noted :) | 01:16 |
| fullermd | Is it necessary to have the feature branches on the server? I mean, sure, it's nice for longer lived stuff, but it may be overkill for simpler. | 01:17 |
| bairui | i was originally not putting them there - just keeping them on our local dev machines, but someone raised the concern that these are not on the server... | 01:18 |
| fullermd | Well, if a feature branch is taking weeks, or being worked on by multiple people, you definitely want it central there. If it's lasting hours or a day or two, for just one person, though... | 01:19 |
| bairui | i guess after they get merged into trunk then they're 'available'... I think there was concern over being able to easily go back to that piece of work if rework was necessary | 01:19 |
| fullermd | Maybe you want to avoid people thinking case-by-case like that, which is valid. | 01:19 |
| fullermd | Oh, yes. Once it's merged into trunk, it can be recreated trivially. | 01:19 |
| bairui | ok... | 01:19 |
| fullermd | If you do "bzr branch -r123.4.5 trunk newbranch" (assuming that rev is the head of the branch you had, that got merged in), you've [almost] recreated it exactly as it was before you merged. | 01:20 |
| fullermd | The only stuff you miss is transient branch config (the nick, saved parent/push/etc branches, and so on). | 01:20 |
| bairui | nick? | 01:21 |
| bairui | the local branch name? | 01:21 |
| fullermd | So any time a branch is "completed" and merged, if you don't expect to pick it back up as-is, it can be rm'd away. | 01:21 |
| fullermd | Branches have nicknames, which are recorded in the revs created in them. The default is just the dir name, but you can set it manually. | 01:21 |
| bairui | right - and it was that rm'ing that freaked a team member (and I didn't know bzr well enough to assuage their fears) | 01:21 |
| fullermd | It shows up in `log`, for instance. Just cosmetic, but helps keep straight what you think you were doing. | 01:21 |
| bairui | ah - we've just been using dir name as branch name | 01:22 |
| bairui | ok - so for small dev work and bug fixes, you'd say: branch locally, hack, commit, merge, rm ? | 01:23 |
| bairui | for collab stuff, branch on server | 01:23 |
| bairui | or longer living / huge stuff | 01:23 |
| fullermd | I usually always branch locally, then also push the branch up to the server if it winds up being long-lived or needing collab. | 01:23 |
| bairui | ok. i saw that flow sometime yesterday - was nice to know one could always push a local branch at a later date | 01:24 |
| fullermd | `bzr branch bzr+ssh://some/thing bzr+ssh://some/thing/else` is kinda wacky, since you copy all the data across the network twice. | 01:24 |
| fullermd | My work tends to go something like | 01:24 |
| bairui | good to know | 01:24 |
| fullermd | cd ~/work/projfoo; bzr co bzr+ssh://central/trunk # pretty much always a central trunk, just make local checkout. | 01:24 |
| bairui | ok | 01:25 |
| fullermd | For utterly trivial stuff, I often just do and commit right on trunk. If it's 5 minutes of work, and just one commit, why bother with the overhead of branches, I say. | 01:25 |
| bairui | ok | 01:25 |
| fullermd | If it's going to be more than one rev, especially if half-broken in the middle, or take longer, I make a local branch | 01:25 |
| fullermd | cd ~/work/projfoo ; bzr branch trunk featfoo | 01:25 |
| fullermd | Then I can work in featfoo. If I decide to put it central for some reason, I can just `bzr push bzr+ssh://central/featfoo` then. | 01:26 |
| bairui | right. cool. | 01:26 |
| fullermd | And either remember to 'push' my changes Every So Often(tm), or convert the branch into a checkout at that point. | 01:26 |
| bairui | so that each commit effectively pushes, right? | 01:26 |
| fullermd | (see `bzr reconfigure`; you can turn a checkout into a branch, a branch into a checkout, a standalone [non-repo-using] branch into one using a shared repo, a shared repo branch into a standalone, blah blah blah) | 01:26 |
| bairui | nice. awesome | 01:27 |
| bairui | scary :) | 01:27 |
| fullermd | Correct in essence [auto-pushes]. That gets into philosophical issues. | 01:27 |
| bairui | heh, let's keep this pragmatic for now - my bzr-fu is not ready for philosophy :) | 01:28 |
| fullermd | Now, you may want to just fiat declare "all branches are always on the server", for either political reasons or to avoid asking people to make judgements. That's down to your situation. | 01:28 |
| fullermd | So anyway, over time, I can always `cd ~/work/projfoo/trunk ; bzr up` to have my trunk copy up to date. Merge changes from it into featfoo if/as necessary. | 01:29 |
| fullermd | And when featfoo is done, I can just rm -rf it. | 01:29 |
| fullermd | (for various external reasons, I often don't exactly, but that's another matter) | 01:30 |
| bairui | mmm... I smell pancakes cooking... *drool* | 01:31 |
| fullermd | Oh, I notice you mention a 'settings.php'. Here's a trick I use a lot in webdev: we want separate configs in testing vs live (actually run credit cards vs. fake, different databases, all sorts of things) | 01:31 |
| bairui | ok, fullermd... that's cool. I'm logging this, so I will show it to the other team members. | 01:31 |
| bairui | yep | 01:31 |
| fullermd | So what I do is I have a 'live.conf.php' and 'dev.conf.php' versioned. The includes look for "conf.php", which I make an [unversioned and ignored] symlink to whichever one is appropriate. | 01:32 |
| bairui | drupal, as I'm sure you've guessed | 01:32 |
| fullermd | Or in some special cases, a hand-crafted one. That way we don't worry about versioning local changes, but we still have standard configs versioned and ready. | 01:32 |
| bairui | I keep a config.yml file and generate the appropriate settings.php from the current env | 01:32 |
| fullermd | (actualy deployment happens via Makefile, which creates the proper symlinks in the destination) | 01:32 |
| bairui | config.yml gets versioned and the settings.php is always re-created | 01:33 |
| bairui | I don't have the luxury of running a Makefile on some of my deployment hosts - cheap :) | 01:33 |
| fullermd | If I don't admin the system, it's not a deployment host; it's something I complain to the client about and bill triple time for any interaction with :p | 01:34 |
| bairui | heh... that will be a glorious future, but for now, we suck it up. :-/ | 01:34 |
| fullermd | As far as the testing/XPT/later stuff, it sounds like something particular to your process, so I don't have much of an opinion. | 01:35 |
| bairui | i will compare your settings.php approach with our current way and reconsider our choice. | 01:35 |
| bairui | fair | 01:35 |
| fullermd | Is //todd/ on the LAN? | 01:35 |
| bairui | the XPT is now a single branch that we merge releases into and tag if happy | 01:35 |
| bairui | yep | 01:35 |
| fullermd | 'k. I'd avoid using lightweight checkouts across anything slower than a very fast LAN. They work great on local disk; on an uncongested LAN it's not too bad. But I wouldn't try it farther than that. | 01:36 |
| bairui | wow. really? why? | 01:36 |
| fullermd | They're really made for use on local disk, so they move a lot of data and a lot of round trips. | 01:37 |
| bairui | ah... didn't know that. ok - so, what? branch or checkout as necessary? | 01:37 |
| bairui | instead | 01:37 |
| fullermd | With a gigabit of bandwidth and sub-millisecond latency, that's ignorable. With a couple megabit and dozens or hundreds of ms, not so much :) | 01:37 |
| fullermd | Using a [regular, 'heavy'] checkout in their place would be fine. | 01:37 |
| bairui | oh - so it's merely a speed issue? not a lost-data one? | 01:37 |
| bairui | ok | 01:37 |
| fullermd | Oh, yes. No data safety; just speed. But a lot of speed. | 01:38 |
| bairui | cool - good to know. if we notice lag, heavy she is. | 01:38 |
| fullermd | A heavy checkout is basically the same as a light one, except it keeps a local cache of the whole history (like a branch). | 01:38 |
| bairui | ironic - i thought light would move less - no history, after all... what am I missing? | 01:38 |
| fullermd | If you can spare the space, it can be worth doing heavy just because it gives you an extra 'free' backup on another box, too. | 01:39 |
| bairui | that is a good point | 01:39 |
| bairui | space is easy to spare | 01:39 |
| fullermd | Well, on the one hand, because it has no history, it has to go to the server to even find out what the pristine state of the _current_ files are. | 01:39 |
| bairui | ah... which reminds me... I haven't read about bzr backup yet... it's on the todo list | 01:39 |
| bairui | that makes sense (light) | 01:39 |
| fullermd | So doing e.g. 'bzr diff' has to go grab the originals of all the changed files from the server, every time. | 01:40 |
| bairui | yuck | 01:40 |
| bairui | ok - sold. | 01:40 |
| fullermd | And it does the internal lookups in very network-unoptimized ways. | 01:40 |
| fullermd | There are cases where somebody has done light checkouts of couple-meg trees, and foudn that an 'update' moves hundreds of megs across the network. | 01:40 |
| fullermd | (due to egregious bugs, rather than the suboptimal-for-usecase design, but still) | 01:41 |
| bairui | *shudder* | 01:41 |
| bairui | ok - we'll go heavy - space is not a concern. | 01:41 |
| bairui | so, any other nasties in our proposed workflow, mate? | 01:42 |
| fullermd | Well, all your uses of "--remember bzr+ssh://...." are a bit of an eyesore. | 01:42 |
| fullermd | If you're --remember'ing, why specify each time? ;) | 01:42 |
| bairui | ok... i think the designer had assumed that these were previously non-existing dirs - recreated as necessary. | 01:43 |
| bairui | we'll look at that. | 01:43 |
| bairui | thank you very much, fullermd, for your time and advice on all that. <3 | 01:44 |
| fullermd | I'm somewhat curious about the "rm -rf web ; bzr co [...]" bit at the end of the XPT migration thing. | 01:45 |
| * bairui smells pancakes, honey and maple syrup... | 01:45 | |
| fullermd | Surely you don't want to do that every time? Maybe that's just meant to be a "first time" instruction block... | 01:45 |
| bairui | /var/www/xpt/web held the last (view into) a site in xpt | 01:46 |
| fullermd | Yah, but wouldn't it already be the existing branch/checkout from last time you do it? So why rm ; re-checkout instead of just 'update'? | 01:46 |
| bairui | we would do that *if* we didn't care for the previous view | 01:46 |
| bairui | right - so it it's the same view (site), we'd update | 01:46 |
| bairui | if it's a different website then we'd rm | 01:47 |
| fullermd | Ah. So it's a single location potentially used by different things. | 01:47 |
| bairui | we were just being lazy - keeping a single xpt site | 01:47 |
| bairui | yep | 01:47 |
| fullermd | Speaking of some of my unfavorite things about webdev... | 01:47 |
| bairui | heh | 01:47 |
| fullermd | (this is why I often don't rm my feature branches when I'm done with them; instead I rename them to a new feature branch, because webdev means there's always extra setup to do when creating a new workspace :| ) | 01:48 |
| bairui | ah, yes... we generate code for that reason | 01:48 |
| fullermd | Can people just use userdirs on todd? | 01:48 |
| bairui | userdirs? like /home/user/public_html ? | 01:48 |
| * fullermd nods. | 01:48 | |
| bairui | um... i haven't set that up... why? what would that give me? | 01:49 |
| bairui | gack! pancake call! :-o | 01:49 |
| bairui | can we pick this up again in a bit, fullermd? :-D | 01:49 |
| fullermd | Well, maybe it's usable instead of xpt; that way you don't worry about stomping on each other so much. | 01:49 |
| fullermd | Or maybe it fit your flow; I'm just spitballing. | 01:49 |
| bairui | we can create multiple xpt sites (with our generator scripts) very easily - we were just documenting the lazy case :) | 01:49 |
| fullermd | Ah. Laziness is next to godliness. | 01:50 |
| fullermd | But both are far removed from pancakes, so I dunno why you're wasting time talking about them when the latter are in offing :p | 01:50 |
| bairui | agreed! thanks, mate. later! :-# | 01:50 |
| fullermd | Oh, [when you get back] have you worked out in-repo perms on todd so things keep working for everyone? | 01:53 |
| bairui | back... delicious pancakes. And oh, my gosh, yes... permissions. A colleague has threatened nasty things with pliers if I don't sort out the permissions thing pretty soon. What's the good oil there, fullermd? | 03:02 |
| fullermd | I dunno. Break-Free maybe? That should make the pliers run smoothly. | 03:03 |
| bairui | keeping my bits away from pliers is the goal here, fullermd... | 03:03 |
| * bairui suspects fullermd's still looking for that stick ;) | 03:04 | |
| fullermd | Oh, I'm supposed to be helping YOU in this instance, then? | 03:07 |
| fullermd | That's way less entertaining. Hold oh, I'll go cancel the popcorn then... | 03:07 |
| * bairui needs to invest more in team management skills... | 03:08 | |
| fullermd | Team management is tough sometimes. Depending on the floor plan, it can be difficult to get enough voltage to everyone's chair. | 03:08 |
| bairui | lol | 03:08 |
| fullermd | What OS it the server running? | 03:08 |
| bairui | linux | 03:09 |
| fullermd | Wow, people still use that thing? Amazing... | 03:09 |
| bairui | oi! | 03:09 |
| fullermd | OK, so you've got SysV filesystem semantics. Presumably you're using a shared group with everyone in it? | 03:10 |
| bairui | yep | 03:10 |
| fullermd | 'k. So you'll need g+s on all the dirs under the repos, to keep the group ownership. | 03:10 |
| fullermd | And g+w of course. | 03:10 |
| bairui | out of curiosity, what OS are you on? BSD? | 03:10 |
| bairui | got that | 03:10 |
| fullermd | bzr will preserve that in existing bzrdirs. The tricky thing is new branches; they'll get set based on umask. | 03:10 |
| fullermd | Yah. | 03:11 |
| bairui | my current umask is g-w | 03:11 |
| bairui | which sucks | 03:11 |
| fullermd | As it probably should be. And anyway, you couldn't make them g+s with umask anyway. | 03:11 |
| bairui | oh | 03:11 |
| bairui | i haven't even *tried* looking into solving this yet | 03:11 |
| fullermd | So, any time a new branch is created (or a new repo, though that would be way less often), its perms will wind up wrong. | 03:11 |
| bairui | correct | 03:12 |
| bairui | so, bsd then... also in the curiosity realm... editor preference? | 03:13 |
| fullermd | The cheap easy ugly solution is to brute force the living crap out of it, and setup a cron job to `chgrp -R ; chmod g+ws -R` on /mnt/repos/websites every {hour,day,whatever}. | 03:13 |
| bairui | ah - I was thinking of a script to do the same - manually atm, cronned probably later | 03:13 |
| bairui | i was wondering if a hook might work | 03:13 |
| fullermd | Then anything new will be "correct" soon enough as to hopefully not matter. | 03:13 |
| bairui | right - is that my *best* approach? | 03:13 |
| fullermd | vi, of course. Is there another choice somehow? | 03:14 |
| bairui | it certainly is... easy | 03:14 |
| bairui | vim | 03:14 |
| fullermd | That falls under the rubric. Shoot, I've even used elvis. | 03:14 |
| bairui | as long as it has a v and an i in there somewhere, we're cool | 03:14 |
| fullermd | It may be your best approach. The other option is for people to do it manually (and that means logging into todd directly and doing stuff). | 03:15 |
| bairui | nope | 03:15 |
| fullermd | It's possible you could create a third option by hacking bzr on the server. | 03:15 |
| bairui | nope | 03:15 |
| bairui | ok - so, scripts it is | 03:15 |
| bairui | good to know | 03:15 |
| fullermd | Squirreling with the VFS stack to auto-force perms on the filesystem is another outstanding choice. I kinda like it, personally. | 03:15 |
| fullermd | It's a sorta-bug (call it a misfeature, maybe) that bzr won't propogate the repo's permission to newly created branches. If that got fixed, it would take care of most of your situation. | 03:16 |
| bairui | and there's no harm in chmod -R g+ws on a repo, eh? I mean, don't waste time cherry-picking dirs for that treatment - just smack the lot. | 03:16 |
| fullermd | You'd still need manual intervention on creating new repos though, whenever you started a new project. | 03:16 |
| bairui | i have a repo-making script that does that atm | 03:17 |
| bairui | it's not remotely callable yet | 03:17 |
| fullermd | Not as far as bzr is concerned, no. So as long as it's the same group for everything, and everyone gets equal access to everything, should be OK. | 03:17 |
| bairui | that is the case. cool. | 03:17 |
| fullermd | Never try to be clever when brute force will solve them problem :) | 03:18 |
| fullermd | (and when it won't, redefine the problem!) | 03:18 |
| bairui | heh - never underestimate the power of force | 03:18 |
| bairui | we share quite a few aphorisms, fullermd. Chances are we have a common ancestor, at least academically :p | 03:19 |
| bairui | well, thanks again, fullermd for your advice. That clears up quite a few todos on my bzr/server plate. yay. :) | 03:20 |
| fullermd | I just think of it as "sharing good sense" ;) | 03:22 |
| bairui | fair | 03:22 |
| bairui | i tend to do much the same on #vim | 03:22 |
| bairui | what goes around comes around | 03:22 |
| bairui | and as long as the pliers *never* come around, all's good | 03:22 |
| fullermd | Oh, them coming around is fine, as long as they don't close first... | 03:23 |
| bairui | closing after would be uncomfortable too... | 03:23 |
| bairui | especially were they to encompass *bits* between arrival and said closing oO | 03:24 |
| fullermd | Anyway, glad to be of help. Now I have to go find a way to explain to people why their plans are impossible and their project is hopeless, without continual profanity... | 03:24 |
| bairui | well, you just had some good warm-up training with me :) | 03:24 |
| bairui | thanks again, mate. enjoy. later. | 03:25 |
| fullermd | Though I'm not sure why I'm bothering. I've been doing that to date, and the project still won't die. Maybe I should stop censoring... | 03:25 |
| bairui | start supporting it | 03:25 |
| bairui | amazing how that kills a project, I've found ;) | 03:25 |
| === Mkaysi_ is now known as Mkays | ||
| === Mkays is now known as Mkaysi | ||
| === krow_ is now known as krow | ||
| === gour1 is now known as gour | ||
| === Mkaysi is now known as Mkaysii_ | ||
| === Mkaysii_ is now known as Mkaysi | ||
| === Vorpal_ is now known as Vorpal | ||
| maxb | Hmm | 18:19 |
| maxb | criss-cross merges are annoying | 18:19 |
| maxb | And bzr doesn't seem to be being as smart as I'd have hoped about not generating conflicts | 18:20 |
| maxb | Oh, no, I was wrong to blame bzr | 18:25 |
| * jelmer waves to maxb | 18:25 | |
| maxb | jelmer: Your latest merge into ~bzr/bzr/daily-ppa seems to have gone rather wrong, and included text changes from bzr.dev, without recording their ancestry | 18:26 |
| maxb | hence the conflicts | 18:26 |
| jelmer | that's something that often happens during criss crosses | 18:27 |
| jelmer | as there isn't an obvious common base | 18:28 |
| maxb | uhm | 18:28 |
| maxb | Why would bzr even be considering any text versions that happened in the future, with respect to all of the tips being merged? | 18:29 |
| maxb | I'm inclined to just push --overwrite the daily-ppa branch with the Debian unstable-2.5 one | 18:31 |
| jelmer | maxb: I'm not sure what you mean | 18:32 |
| jelmer | maxb: +1 on overwriting with unstable-2.5 | 18:32 |
| maxb | The current daily-ppa branch contains text changes from bzr.dev r6038 | 18:32 |
| maxb | However, it does not include bzr.dev's r6038 in its ancestry | 18:32 |
| vila | jelmer: lp:~jelmer/bzr/more-get-transport-from => 5878 lines ? You're overdoing it ;-p | 18:33 |
| maxb | This seems rather WTF-worthy | 18:33 |
| vila | jelmer: something went wrong with test_controldir.py, can you check ? | 18:33 |
| mgz | looked like a line ending change to me. | 18:34 |
| vila | mgz: I thought that at first, but unlikely from jelmer, instead a looks like including 2 copies of itself or something | 18:34 |
| mgz | I nearly commented but was reading mail in a hurry and didn't have time to check if it was | 18:34 |
| vila | s/a looks/it looks/ | 18:34 |
| vila | mgz: hello by the way :) | 18:35 |
| jelmer | vila: looking | 18:35 |
| * mgz waves | 18:35 | |
| jelmer | maxb: what lines are in daily-build from bzr.dev r6038? | 18:36 |
| jelmer | maxb: r6038 was manually backported to lp:bzr/2.4 | 18:38 |
| vila | one should always merge up asap after backporting so *others* don't wtf'ed on further merges | 18:40 |
| vila | just saying | 18:40 |
| jelmer | vila: well, the debian packaging wasn't updated for bzr.dev until recently | 18:41 |
| jelmer | so there wasn't much to merge up to | 18:42 |
| maxb | ahhh | 18:42 |
| maxb | right, I think I understand | 18:43 |
| vila | jelmer: I was talking about upstream backport, packaging is a totally different beast (but merges not done upstream are likely to impact packaging too) | 18:43 |
| maxb | So really the problem is that bzr doesn't track backports, so it's necessary to ensure backports get merged back up into their source branch ASAP to avoid surprises | 18:43 |
| vila | maxb: exactly | 18:44 |
| vila | maxb: err, sorry, we're talking about two different kind of backports, your point is similar to mine though | 18:46 |
| jelmer | vila: I've updated the more-get-transport-from branch | 18:49 |
| james_w | hello all | 19:14 |
| jelmer | Hey James | 19:19 |
| * maxb wonders which is the lesser evil - forking the bzr-daily recipe into three, or backporting python-meliae-dbg and python-configobj | 19:21 | |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!