=== yofel_ is now known as yofel
=== r0bby is now known as robbyoconnor
[06:37] <eagleon1> hi guys, I was just wondering if you can help me figure out if my workflow is well thought out, or flawed... might anyone be around to help? :)
[06:46] <eagleon1> anyone?
[06:50] <vila> eagleon1: just ask your question or nobody knows if he/she can answer ;)
[06:52] <eagleon1> ah ok, thank you vila :) ... well my current situation is this: I am a single developer who works on multiple machines (varying OSes and locations).... and my main line of work is web dev
[06:52] <eagleon1> so the goal is to (1) local dev (offline if no connection, like when I am on a flight) .. (2) upload all changes to the remote test server when done in working condition
[06:53] <eagleon1> and before starting work on an project, I want to make sure that the machine that I am working on at the time has the latest version
[06:53] <eagleon1> so in order to accomplish this I am doing the following:
[06:53] <eagleon1> 1) bzr pull
[06:53] <eagleon1> 2) bzr update
[06:54] <eagleon1> then I work on the project and make changes (being confident that I have the latest version on this machine)
[06:54] <eagleon1> 3) after making changes (online or offline) I make local commits along the way...
[06:55] <eagleon1> 4) when I am ready to test it on the test server, I do a bzr upload
[06:55] <eagleon1> 5) then a bzr push
[06:55] <eagleon1> thats it!
[06:55] <vila> That sounds correct.
[06:55] <eagleon1> at this point, I assume the remote test server (e.dg www.example.com/test) is the latest version
[06:56] <eagleon1> so the next time I do a pull, it will also be from here...
[06:56] <eagleon1> :) correct! yay!
[06:56] <eagleon1> in the docs, I was reading about 'bzr checkout' ... this is not necessary then right?
[06:56] <vila> A couple of questions though: where are your branches, do you have one on the test server (and/or the production server)
[06:57] <eagleon1> when ever I create a new project, I will create a branch for that project on the test server... then get it locall using the step #1 above...
[06:57] <eagleon1> for that, I will only do bzr init, bzr add znd bzr commit
[06:58] <vila> ok, so you have a bzr branch on the test server. Is bzr installed there ?
[06:58] <eagleon1> yep installed and ready :)
[06:58] <vila> so you can use the bzr-push-and-update plugin instead of bzr-upload
[06:59] <eagleon1> ah, excellent! whats the difference in this case?
[06:59] <vila> If you haven't (yet) read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief you can ;)
[06:59] <vila> working trees and branches are especially relevant here
[06:59] <eagleon1> havent, but will do right now! thanks :)
[07:00] <vila> you have to understand that a working tree can be in sync or not with its associated branch (they generally are)
[07:00] <eagleon1> im still new to versioning ... terms like branches and tress can be a little confusing in terms of application (vague)... but this link might help understand ...
[07:00] <vila> In some cases, one can push to a branch but the working tree is not updated
[07:01] <eagleon1> oh I see
[07:01] <vila> roughly, the working tree is the files you're editing, when you do a commit, a revision is created and becomes the branch's new tip
[07:02] <eagleon1> I understood everything up to the point where the revision is created...
[07:02] <eagleon1> so a branches new tip is the version history data?
[07:03] <vila> so, a branch is a directed graph of revisions (the history of your work, the tip being the most recent revision and the graph entry point)
[07:03] <eagleon1> oh got it, that makes sense
[07:03] <vila> so, back to your workflow,
[07:05] <vila> most of the time, (bzr branch, bzr init, bzr pull), your WT is updated automatically so your step (2) is probably not required
[07:05] <eagleon1> ok, thats good to know
[07:05] <eagleon1> so that would be a redundant step
[07:06] <eagleon1> but I didn't have bzr branch in my workflow before,
[07:06] <vila> if you install and configure bzr-push-and-update (requires ssh access to the server), your step (4) becomes useless too
[07:06] <eagleon1> ssh access is ready
[07:06] <eagleon1> thats good!
[07:06] <vila> and if in (5) you're pushing to the same place that you're uploading in step (4), you're on thin ice
[07:06] <vila> ,,,
[07:06] <vila> ...
[07:07] <eagleon1> in what sense (and yes, it is the same place) ...
[07:07] <vila> I thought bzr-upload will refuse to upload to an existing branch... am I wrong ?
[07:07] <eagleon1> no it uploads
[07:07] <eagleon1> ive been testing this workflow for a bit now, but I dont know when I am really working on a project what sort of variables might mess things up
[07:07] <vila> and you then push to the exact same url ?
[07:08] <eagleon1> yes
[07:08] <vila> hmm, anyway, that's still risky :)
[07:08] <eagleon1> how come? :)
[07:09] <eagleon1> just asking to know... i believe you tho, I want to understand this better
[07:09] <vila> so, if you have ssh access *and* you already maintain a branch there, better use push-and-update
[07:09] <vila> well, bzr-upload is targetted at uploading a tree relying on a local branch
[07:09] <eagleon1> yes, the branch will always be created on the remote test server first
[07:11] <eagleon1> (in some cases i may create it locally and send it to the remote server) then sync back... if I want to do that, will push-and-upload have any conflict?
[07:11] <vila> bzr-upload needs to upload the whole files, whereas 'bzr update' running remotely (via push-and-update) deals with local files
[07:11] <vila> push-and-update :)
[07:11] <vila> no, it's fine
[07:11] <eagleon1> cool
[07:11] <eagleon1> this is great, I am so glad I asked... your help is invaluable :)
[07:12] <vila> in a nutshell: if you have bzr installed where you want to push, use bzr-push-and-update,
[07:12] <vila> if you don't have bzr installed OR don't want your bzr branch to be readable (think production servers), use bzr-upload
[07:12] <vila> happy to help ;)
[07:13] <eagleon1> oh, right~ I was thinking on putting things manually to production servers without bzr involved (but perhaps knowing this may make a difference, once I am vry comfortable with bzr) ...
[07:14] <eagleon1> one last question if you dont mind vila... what about "checkouts" they are not necessary right?
[07:14] <eagleon1> checkins and checkouts?
[07:14] <vila> well, no, they aren't
[07:14] <eagleon1> in the docs, I read that I would use a checkout if I am a single dev working on multiple machines
[07:15] <eagleon1> just out of curiosity, in what situation would a checkout be appliable over this workflow that I have (with the changes you recommended)
[07:15] <eagleon1> *applicable
[07:15] <vila> it would make sense if you're working on the same project from multiple machines
[07:16] <eagleon1> I am though, that's the thing
[07:16] <vila> by same project, I mean a 'master' branch on a central server
[07:16] <eagleon1> oh...
[07:16] <vila> and it works really well if you're always online and the server is always accessible too
[07:17] <eagleon1> hmm... no my setup is more "distributed" than centralized, if that correct?
[07:17] <eagleon1> *is
[07:17] <eagleon1> i may not always have access to the net, as I travel a lot
[07:17] <vila> outside of these constraints... you need to be more careful and rigorous about committing (locally) when you've been offline and run 'bzr update' before starting edits again
[07:17] <fullermd> When you're push'ing and pull'ing stuff around, you basically have 2 (or 3, or 4, or more) independent branches, that you opportunistically sync up.
[07:18] <vila> eagleon1: what have you done !!! You said 'checkout' !!!
[07:18] <fullermd> With checkouts, you conceptually have _one_ branch, and 2 (or 3, or 4, or...) different working trees you work on it from.
[07:19] <eagleon1> hmmm
[07:19] <eagleon1> again, slightly confused ... let me go over this for a second
[07:19] <fullermd> And you never ever use commit --local, because it's the devil.  See those two l's at the ends of the word?  Those are its horns.
[07:19] <vila> hehe
[07:19] <eagleon1> ah :p
[07:20] <vila> so, basically, avoid checkouts until they *really* make your life easier :)
[07:20] <eagleon1> thats' a great way to remember never to do it, thanks fullermd
[07:20] <eagleon1> will do vila... right now, they dont seem to apply to me
[07:20] <vila> even bound branches are clearer to use when you're offline from time to time
[07:20] <fullermd> And if you don't immediately see how they make your life easier, they probably don't at this point.
[07:21] <eagleon1> yeah, my priorities are to always have the latest version on the local machine that I am working on when I begin coding, then when I finish that latest version needs to be on the test server (which acts as my source if I start working on another machine later)
[07:22] <eagleon1> my biggest concern is losing any work by forgetting a step.. :-S ...
[07:22] <eagleon1> is that possible?
[07:23] <vila> well, pull before your start, push before you end
[07:23] <eagleon1> by push you mean push-and-update right?
[07:23] <fullermd> Or after you end   ;p
[07:23] <eagleon1> haha
[07:23] <vila> oh no, *before*, you're not finished until you do that :)
[07:24] <eagleon1> thats true indeed
[07:24] <vila> eagleon1: oh, and 'bzr missing' is your friend when you don't remember if you did
[07:24] <vila> (pull or push)
[07:24] <eagleon1> excellent, ill read up on missing as well
[07:24] <fullermd> If you make some changes in one place, and don't push them before you start working in another, you'll wind up with two branches that have diverged (both have changes the other doesn't).
[07:25] <vila> 'bzr config' and 'bzr info' will also remind you of which branches you're dealing with
[07:25] <eagleon1> also I suspect 'bzr add' and 'bzr remove' are crucial
[07:25] <fullermd> But that's not any sort of problem; you can just merge them later.  You just won't have the changes from one place in the other until you do.
[07:25] <vila> they're pre-requisites of 'bzr commit' IMHO
[07:25] <vila> 'bzr add/remove' are pre-requisites of 'bzr commit' IMHO
[07:26] <vila> so yeah, 'bzr st' is the moral equivalent of 'bzr missing'
[07:26] <eagleon1> moral equivalent meaning?
[07:26] <fullermd> Yes, there are basically two different sets of commands you work with.  One is the "I'm making new stuff" set, where you have add/rm/mv/stat/commit/etc.
[07:27] <fullermd> The other is the "I'm getting the stuff I've made where it needs to be to deploy/continue deving", where you have push/pull/missing/etc.
[07:27] <eagleon1> hmm, this new info completely upgrades my workflow from what I had in mind initially
[07:27] <vila> so, 'bzr st/bzr diff' is the last command before 'bzr commit', where 'bzr missing' is the last command before 'bzr pull/push'
[07:28] <eagleon1> got it, I hadn't even thought of those previously... thanks vila and fullermd
[07:28] <vila> you're welcome
[07:28] <vila> fullermd: thanks to you too ;)
[07:28] <eagleon1> :)
[07:29] <fullermd> vila: 'k.  Now let's find someone new to confuse!
[07:29] <eagleon1> haha
[07:29] <eagleon1> wow, I just realized... being on the #python chat room has truly deciplined me to no lol
[07:29] <eagleon1> cos their bot keeps bugging you whenever you type lol there :p
[07:29] <eagleon1> so now I keep typing haha by habbit :-S ...equally bad or worse
[07:30]  * vila checks #bzr bot, you slacker
[07:39] <eagleon1> by the way, what is the lp: stand for... like in bzr branch lp:bzr-push-and-pull
[07:40] <eagleon1> I mean push-and-update... :/
[07:40] <vila> hehe
[07:41] <vila> it's a shorcut for launchpad branches
[07:41] <eagleon1> ah cool :D
[07:44] <eagleon1> moving a branch if ever necessary (using the file system itself) should be safe right? I just pulled the push-and-update plugin into the bzrlib dir insited of inside the plugins dir... so doing a mv to where it belongs, should not break anything right?
[07:46] <eagleon1> hmm, there is no setup.py for this plugin... so I assume it will work as long as it is in the plugin dir?
[07:46] <fullermd> Except in the case where it was made in a shared repo (init-repo), and you mv it out of the repo.
[07:46] <eagleon1> oh, got it!
[08:24] <mgz> morning
[08:25] <fullermd> I don't remember authorizing that.
[08:25] <eagleon1> morning :)
[08:25] <eagleon1> authorizing what?
[08:25] <fullermd> Mornings.  They're bad news.
[08:26] <eagleon1> oh ... sorry to hear that, did I miss something.. your comment seemed random ... :/
[08:26] <fullermd> You say that as if it's something unusual...
[08:26] <mgz> it's fulldermd's normal greeting :)
[08:26] <eagleon1> ah! :P
[08:27] <eagleon1> im new here, so its good to know that now :D
[08:28] <mgz> in fact, these days I'm not convinced it's actually random
[08:29] <mgz> I think he's just pseudo-random
[08:29] <eagleon1> lol
[08:29] <fullermd> Being completely unpredictable was getting predictable.  I had to switch to pre-planned things so it didn't look pre-planned.
[08:30] <eagleon1> oh darn, you just gave it away...
[08:30] <fullermd> Or DID I??
[08:31] <eagleon1> :-O
[08:39] <eagleon1> hi guys, I am wondering what I am doign wrong here...
[08:39] <eagleon1> $ bzr push-and-update
[08:39] <eagleon1> bzr: ERROR: Not a branch: "/usr/lib/python2.6/site-packages/bzrlib/plugins/".
[08:47] <mgz> run `bzr info` in the same location?
[08:49] <eagleon1> oh right, im not inside a branch... :( silly me
[08:49] <eagleon1> :)
[08:49] <eagleon1> thanks mgz
[08:56] <vila> hmm, I thought push-and-update could be configured to trigger automatically when one do push...
[08:56] <vila> hi mgz (sry for the delay ;)
[08:59] <eagleon1> is that possible?
[09:02] <vila> according to the code, it's the default behavior, as long as the url used hints that ssh is involved
[09:02] <vila> give it a try
[09:02] <vila> i.e. no configuration needed
[09:02] <eagleon1> will do, im stil documenting what we discussed earlier before I forget :D
[09:02] <vila> good choice :)
[09:03] <eagleon1> all while watching hacker attempting to breach my production server
[09:03] <vila> yeah, always entertaining
[09:03] <eagleon1> indeed
[09:38] <eagleon1> hi guys, when limiting the ssh account that I use to connect to the remote server (when doing a pull) ... what commands should I supply?
[09:38] <eagleon1> what arguments should be there for example
[09:39] <vila> I never remember the details for that as I rely on using only keys to connect to ssh servers
[09:40] <eagleon1> yeah, even with the keys its better to limit the ssh user i think...
[09:40] <vila> note that having ssh access is enough to use the bzr smart server, the bzr client will execute the right command remotely
[09:40] <eagleon1> i never connect with a previledged account
[09:40] <eagleon1> hmm
[09:41] <vila> and if you use bzr-push-and-update, you need to allow a different command for that too
[09:41] <vila> it's certainly doable but I've never done it myself
[09:42] <eagleon1> I guess I will have to allow some freedom to this user then...
[09:42] <eagleon1> will definitely have to limit bzr to the test server, and update production manually for now..
[09:43] <vila> you can use a dedicated key on the test server and pull from the production server
[09:43] <mgz> probably don't need to be too paranoid
[09:44] <vila> hehe, all paranoids will disagree with that I think :)
[09:44] <eagleon1> well im getting hacker attempts daily, but the hour.. so a bit paranoid ... :-s
[09:44] <eagleon1> *by the hour
[09:44] <fullermd> What?!  How did you know I'd disagree???
[09:44] <vila> . o O (Damn it, damn it, quick, the dried frog pills)
[09:45] <eagleon1> im actually extra paranoid today because they are trying to brute force a specific user account that I created recently... how did the know it exists!?!
[09:45] <eagleon1> although the brute force wont work, im still worried about how they got that specific user name
[09:45] <eagleon1> made up of random letters
[09:46] <vila> wow
[09:46] <fullermd> Well, I certainly didn't tell them via a scrawled note I dropped in a basket outside the local Burger King between 2200 and 2230 last night.
[09:46] <fullermd> That would be suspicious after all.
[09:46] <eagleon1> lol
[09:46] <vila> eagleon1: still, they are trying passwords, if you disallow that on your ssh server allowing only keys, you're done
[09:47] <fullermd> Nono, everybody knows you're supposed to run sshd on a different port.  Then you're totally safe forever.
[09:47] <eagleon1> yeah, im already doing that so safe there... but still wondering how they got that username
[09:47] <eagleon1> (last comment was in response to vila :p)
[09:48] <eagleon1> can they sniff an user name during connect time, even if I was attempting via ssh?
[09:48] <eagleon1> i wonder
[09:48] <fullermd> Obviously what you thought was random was really only pseudo-random.  We know how that turns out.
[09:48] <eagleon1> indeed :P
[09:50] <vila> if they were able to sniff user names, I'd call that a very big security hole
[09:51] <eagleon1> exactly :-S
[09:53] <vila> eagleon1: are you really saying you see hack attempts on a non-standard port with a random user name ?
[09:53] <vila> I'm curious about which of your assumptions is wrong...
[09:53] <vila> because if they are all true, you're in trouble :)
[10:11] <eagleon1> no, they are attempting on a standard port with a known username...
[10:11] <eagleon1> (as well as random ones)
[10:12] <eagleon1> but they only get past 3 attempts with each IP... after that they need to go find more proxies from china :p
[10:42] <vila> eagleon1: fail2ban for the win ?
[10:43] <eagleon1> yes indeed :)
[10:44] <eagleon1> by the way, does bzr commands need to always be run withing the working dir of the branch? is it possible to provide the path of the branch to other commands, like bzr push [host] [branch?] ... unlikely right?
[10:51] <mgz> all commands should either take a path as a param, or -d to tell them where to operate
[10:58] <eagleon1> so bzr push -d /home/user/file/ bzr+ssh://.... is good?
[11:01] <eagleon1> i dont see -d in the help files..
[11:03] <eagleon1> i think bzr bind is what I was looking for,
[11:03] <mgz> I... doubt it?
[11:03] <eagleon1> really?
[11:04] <mgz> what are you actually trying to do?
[11:04]  * fullermd is pretty sure "not bind" is the answer too   :p
[11:04] <fullermd> -d is right there in push's help, frex...
[11:04] <eagleon1> hmm.. well what im trying to do... lets say im in /home/user
[11:05] <eagleon1> i have a branch in /home/user/test
[11:05] <eagleon1> without going inside 'test', while being in /home/user, i want to perform the bzr push (or any bzr command)
[11:06] <eagleon1> i couldn't see the -d in my push's help ... let me check again
[11:06] <mgz> (cd test && bzr anything)
[11:06] <mgz> magic, you've not changed location :)
[11:09] <mgz> otherwise -d is what you want for many commands
[11:09] <eagleon1> ah, nevermind.. looks like i was looking at bzr update's help ... which dosen't have it... my bad, but still missing for this command
[11:10] <eagleon1> mgz, i think you magic command is what im going to use :D thx
[11:10] <eagleon1> nevermind :P
[11:11] <eagleon1> that changes location..
[11:12] <eagleon1> the problem is that I need to execute this as a python subprocess.call
[11:13] <mgz> that's not a problem surely
[11:13] <eagleon1> yea, actualy its not lol
[11:13] <mgz> that has a param to set the cwd of the process you're spawning
[11:13] <eagleon1> really? :-o I didnt know that...
[11:14] <eagleon1> thanks mgs, that helps
[11:14] <eagleon1> *mgz (sorry)
[12:30] <Merwin> hi !
[12:36] <jelmer> hi Merwin
=== elmo_ is now known as elmo
=== mbarnett` is now known as mbarnett
[15:46] <vila> jelmer: what needs to be done for 2.5.1  ? An SRU for precise ? Something for quantal (or should that be some 2.6bx there) ?
[16:04] <jelmer> vila: an SRU for precise
[16:05] <vila> jelmer: ok, can you take care of that ?
[16:19] <jelmer> vila: sure
[16:20] <vila> cool, thanks
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
=== Noldorin_ is now known as Noldorin
[18:51] <eagleon1> hi
[18:52] <eagleon1> i keep getting this strange error: This transport does not update the working tree of: bzr+ssh://
[18:52] <fullermd> That's not an error, just a notice.  Thought it does get old pretty quick.
[18:52] <eagleon1> bzr+ssh is supposed to be a supported transport, right?
[18:53] <fullermd> It's just telling you it doesn't update remote working trees.
[18:55] <eagleon> i keep getting this strange error: This transport does not update the working tree of: bzr+ssh://
[18:55] <eagleon> bzr+ssh is supposed to be a supported transport, right?
[18:56] <eagleon> for the push-and-upload plugin?
[18:56] <fullermd> I dunno if push-and-upload can or bothers suppressing the message from push.
[18:57] <eagleon> hmm... either way, its not working :(
[18:57] <fullermd> push-and-update I think it's called, rather.
[18:57] <eagleon> yeah.. thats what i meant, sorry
[18:57] <eagleon> it works with just doing a bzr push
[18:58] <eagleon> after its installed
[19:00] <eagleon> im tempted to go back to the bzr upload solution like I wanted to originally... but also cant rest until i can figure out why this is broken... :-S
[19:01] <fullermd> What's broken?  I thought you said it works.
[19:03] <eagleon> nope :( ... basically the push-and-update dosen't work... let me show you, one sec
[19:03] <fullermd> 13:57 <eagleon> it works with just doing a bzr push
[19:03] <fullermd> I presume "it" means the WT gets updated.
[19:04] <eagleon> oh... what I meant by that is that doing a bzr push actaully calls the push-and-update plugin when it is installed ... sorry for the lack of clarity, but the WT does not update
[19:05] <eagleon> i get the following error: This transport does not update the working tree of: bzr+ssh://user@domain...
[19:05] <fullermd> That's coming from push.  Unrelated to whatever the problem is.
[19:05] <eagleon> hmm
[19:05] <eagleon> let me show you the whole error, it might make more sense
[19:06] <fullermd> push-and-update basically just adds a hook into things so that when you run "bzr push bzr+ssh://server/some/path", it goes in afterward and runs "ssh server ; cd /some/path && bzr up"
[19:06] <fullermd> It doesn't change the push process itself to do anything to the WT.
[19:08] <eagleon> http://dpaste.com/752205/
[19:08] <eagleon> hmm
[19:09] <fullermd> 'k, well that seems reasonably self-explanatory.
[19:09] <eagleon> you mean the host name?
[19:09] <fullermd> Yah.
[19:10] <eagleon> the funny thing about that, is that it connects to the server.. then I even get authenticated (password request pops up) I enter the pass and then this happens
[19:10] <fullermd> ssh takes a hostname as an arg, not something like a URL fragment.  The plugin apparently doesn't do necessary translations.
[19:10] <eagleon> ah
[19:10] <fullermd> That password prompt is probably from the push, not the update.
[19:11] <eagleon> got it,that makes sense
[19:11] <fullermd> I doubt there's an in-bzr workaround short of extending the plugin's capabilities.
[19:11] <eagleon> i guess a simple work around would be to just run the update myself without the plugin
[19:11] <fullermd> Me, I'd avoid the issue entirely by just using sshconfig.
[19:11] <fullermd> Saves worrying with usernames too.
[19:11] <eagleon> whats that? im not familair with it
[19:12] <fullermd> Add an entry into your ssh config setting the port and the username; then you don't need to specify any of it.
[19:12] <eagleon> hmm
[19:13] <eagleon> within my user's ssh config right?
[19:13] <fullermd> Yeah.
[19:13] <eagleon> not related to bzr?
[19:13] <fullermd> Something like
[19:13] <eagleon> oh ok..
[19:13] <fullermd> http://dpaste.com/752206/
[19:13] <fullermd> Then you could just 'bzr push bzr+ssh://bzr.example/where/ever'
[19:13] <eagleon> ah yes, this shoud work nicely
[19:13] <fullermd> (my config has tabs for the following lines; I don't know if spaces work or not, but I didn't feel like trying to sneak them into bpaste)
[19:14] <eagleon> yeah, the probably do work... but I prefer tabs myself
[19:14] <eagleon> *they
[19:14] <eagleon> thanks so much for the tip
[19:15] <fullermd> I got sick of remembering all the usernames I have to deal with a good while back, and started accumulating lines in .ssh/config   ;p
[19:15] <eagleon> ah yes :)
[19:15] <eagleon> this is definitely helpful
[19:15] <eagleon> only problem that I see however, is that since I work on multiple machines...
[19:15] <eagleon> ill have to update each of them :-S
[19:16]  * fullermd . o O ( cd ~/.ssh ; bzr init ; bzr add ; bzr ci -m 'Version one copy of this I can share' ; bzr push ....  )
[19:16] <fullermd> A little recursion is good for the soul   :p
[19:17] <eagleon> ha! :D
[19:18] <eagleon> never thought of that... good solution! and it keeps things versioned too :D
[19:19] <fullermd> Oh, yes, I've got a lot of little bzr branches like that around, just to have a little history on configs.
[19:20] <fullermd> (.ssh/config being one; a little branch with nothing in it but .bzrignore and config...)
[19:20] <eagleon> actually... this would even work nicely on some /etc/...
[19:20] <fullermd> Also a branch on all my systems   :p
[19:21] <eagleon> :D
[19:21] <fullermd> As is /usr/local/etc.  /usr/local/etc/apache22 is usually another one.
[19:21] <eagleon> I never saw bzr this way until now, this is going to make my life so much easier :D
[19:21] <fullermd> One for postfix config, on the boxes where it matters.  nginx one or two places.
[19:21] <eagleon> thank you x ~
[19:22] <fullermd> I've even got a ~/.rc-files for the handful of little rc files that don't have anything else to justify a branch by themselves.
[19:22] <eagleon> nice
[19:22] <fullermd> (files symlinked to ~.  e.g., "/home/fullermd/.vimrc@ -> .rc-files/.vimrc")
[19:22] <eagleon> do you backup the branches somewhere also or just on the local machine?
[19:23] <eagleon> or server
[19:23] <fullermd> None of those branches ever get pushed anywhere, or deal with merges or any of that.  They're mostly just so I have a history of what's been done, and a backup if I accidentally rm the file or dd too many lines, or need to backout changes, etc.
[19:24] <fullermd> Most of 'em don't get explicitly backed up themselves, though they get caught in sweeping backups of the surrounding FSen.
[19:24] <eagleon> yeah, very cool!
[19:24] <eagleon> FSen?
[19:24] <fullermd> Well, how else would you pluralize "FS"?
[19:25] <eagleon> FSes? :D
[19:25] <fullermd> That doesn't sound nearly as cool.
[19:25] <eagleon> i disagree... :P
[19:25] <eagleon> then again, maybe ur right
[19:25] <fullermd> Of course I am.  It's one of the rules.
[19:25] <eagleon> lol
[19:26] <eagleon> besides, confusing is cool and it just happens to be your style from what i've been gathering lately :D
[19:26] <fullermd> Am I that predictable?  Good.
[19:31] <eagleon> how come you are always online? :p its awesome
[19:32] <fullermd> Well, the alternative would be to get a life.  And who has time for that?
[19:32] <eagleon> indeed!..
[19:32] <eagleon> thats what I always say
[19:34]  * fullermd shrugs.
[19:34] <fullermd> I work a lot.  And my IRC window is always sitting there anyway.
[19:34] <eagleon> yes, thats what I tell everyone as well.. they never beieve
[19:35] <fullermd> Infidel defilers.  They shall all drown in lakes of blood.
[19:36] <eagleon> :-O