| ejv | i know it goes against my personal mantra of silence and lurking | 00:26 |
|---|---|---|
| ejv | but another Humble Bundle has appeared on the radar, support them! | 00:26 |
| ejv | http://www.humblebundle.com/ | 00:26 |
| ejv | the perfect gift for all nix users this christmas ;) | 00:27 |
| === gidim_anunaki is now known as gidimanunaki | ||
| itnet7 | Thanks ejv !!! | 00:45 |
| ejv | itnet7: my pleasure ;) | 01:33 |
| ejv | Revenge of the Titans looks fantastic | 01:33 |
| MichelleQ | oooh, I totally got 'em, too. | 01:33 |
| MichelleQ | I've had Machinarium for a long time - love it. | 01:34 |
| ejv | the pay-what-you-want model has apparently raised over 280k for them | 01:34 |
| ejv | it was 30k a matter of hours ago | 01:34 |
| MichelleQ1 | I love that they're supporting charitable orgs, too. | 01:36 |
| MichelleQ1 | And yay for brighthouse fail. | 01:37 |
| === gidimanunaki is now known as Guest70087 | ||
| === Guest70087 is now known as gidim | ||
| === drspeedo|away is now known as drspeedo | ||
| reya276 | Morning everyone | 15:57 |
| DammitJim | hey reya276 | 16:42 |
| reya276 | hey | 16:42 |
| reya276 | subversion = total hate | 16:43 |
| mhall119 | +1 | 16:45 |
| DammitJim | what's the alternative? | 16:48 |
| maxolasersquad | +1 | 16:50 |
| maxolasersquad | DammitJim: bzr or git | 16:51 |
| DammitJim | git is maxolasersquad 's friend | 16:51 |
| maxolasersquad | We seem to get along pretty well. | 16:53 |
| reya276 | I guess, but my app seems to work great with subversion, and it does not support git | 16:59 |
| reya276 | so.... | 16:59 |
| maxolasersquad | reya276: What does your application do? | 17:01 |
| crashsystems1 | Bah, I hate being late for work | 17:02 |
| maxolasersquad | crashsystems1: Are you west coast now? | 17:03 |
| crashsystems1 | Yep | 17:03 |
| maxolasersquad | How is it? | 17:04 |
| crashsystems1 | Quite nice | 17:04 |
| crashsystems1 | Much better food | 17:04 |
| reya276 | maxolasersquad, web dev stuff | 17:05 |
| crashsystems1 | Better weather too | 17:05 |
| reya276 | the latest beta of Aptana supports git though so that would be good | 17:06 |
| reya276 | right now version 2 only supports csv and svn | 17:06 |
| crashsystems1 | The down side is that californians don't know how to drive in the rain, nor do they seem to know what heavy rain is | 17:07 |
| reya276 | do you guys know how to remove repositories from Eclipse | 17:11 |
| reya276 | meaning SVN repositories | 17:11 |
| maxolasersquad | crashsystems1: Sounds exciting. I definitely love eating at the restaurants out west. It really makes Tallahassee restaurants seem sooo meh. | 17:12 |
| maxolasersquad | reya276: You can't use the Eclupse git plugin in aptana? | 17:13 |
| reya276 | I'm not sure | 17:13 |
| reya276 | probably | 17:13 |
| * mhall119 is now an edubuntu-dev \o/ | 18:50 | |
| tiemonster | YAY! | 18:52 |
| maxolasersquad | Google just released tools to allow enterprise management of Chrome deployments in an organization, including an MSI installer and management through Window's Group Policy objects, as well as tools for Mac and Linux deployments. | 18:57 |
| DammitJim | weird | 19:18 |
| mhall119 | heh, Gwibber can translate tweets/dents for you | 19:58 |
| mhall119 | that rocks | 19:58 |
| maxolasersquad | mhall119: Do you know which version that started in? | 20:03 |
| mhall119 | nope, but I'm running daily builds, so it could be very recently | 20:04 |
| mhall119 | I'm on 2.91.2 | 20:04 |
| MichelleQ | mhall119: anyone at work have food allergies? | 20:05 |
| RoAkSoAx | itnet7: ping | 20:08 |
| DammitJim | I do, why, MichelleQ ? | 20:12 |
| mhall119 | MichelleQ: not that I know of | 20:12 |
| MichelleQ | otay | 20:12 |
| MichelleQ | making scones, then | 20:12 |
| mhall119 | I think we have one vegetarian though, but I'll let him know if they have eggs | 20:12 |
| reya276 | hey when you use version control tools like Subversion how to you Test the applications is there a branch where the files which are ready for testing get moved to? | 20:32 |
| reya276 | *do you Test | 20:32 |
| mhall119 | reya276: I usually have a "trunk" and "production" branch, at a minimum | 20:34 |
| reya276 | ok so I can do say Trunk and Test? | 20:34 |
| mhall119 | if you have a separate group doing testing, you might want to fit a "testing" branch in between | 20:34 |
| reya276 | ah ok, the production is in a totally different server | 20:35 |
| mhall119 | having a production branch is good when you have an emergency fix, you don't need to worry about rolling back your testing branch | 20:35 |
| mhall119 | once your code is finished being tested, you merge it into your production branch, then deploy from the production branch | 20:36 |
| reya276 | We have a central development server then after testing we manually moved the files to the production server | 20:36 |
| mhall119 | likewise you do your day to day development against trunk, and merge it into the testing branch when it's ready to be tested | 20:36 |
| mhall119 | reya276: what would you do if there was a critical bug discovered in production after you'd already moved new code to the testing server? | 20:37 |
| reya276 | we fix it on test then move it to prodcution | 20:37 |
| mhall119 | what about all the new code on test? does that go to production too? | 20:38 |
| reya276 | no | 20:38 |
| reya276 | only the things we know that are good to go | 20:38 |
| mhall119 | so you have to back out the testing changes, so your test box matches production,then make the fix? | 20:38 |
| reya276 | the Test server and production in terms of configuration are mirror images | 20:38 |
| mhall119 | but by definition, you have stuff in testing that isn't necessarily ready to be in production yet | 20:39 |
| reya276 | so if it fails on Test it will fail in production and vice versa | 20:39 |
| reya276 | right | 20:39 |
| mhall119 | suppose you just majorly refactored a piece of code, and just put it into testing, then you find a critical production bug in that same code | 20:39 |
| mhall119 | can you make the fix in the pre-refactoring code used by production | 20:40 |
| mhall119 | ? | 20:40 |
| reya276 | then we fix it, test it and then after testing we move it to production | 20:40 |
| mhall119 | or will you have to push the post-refactoring code through testing in a rush | 20:40 |
| mhall119 | fix it where? in the pre-refactored code or the post-refactored code? | 20:40 |
| reya276 | yeah we can also fix it production as well if wee need to | 20:40 |
| mhall119 | it's much better practice to have a separate production branch | 20:41 |
| reya276 | yeah I don't think your understanding, our production code is not tied in to any repositories so we can remove/add any file(s) at any given time | 20:41 |
| mhall119 | that way if you have to do an emergency production fix, you can apply the fix to the production branch, put that on the test box, make sure it work, and go to production, without having to rollback or cherry pick changes from new code | 20:41 |
| reya276 | only our dev and test code is | 20:41 |
| mhall119 | I understand, I just think it's not an ideal setup | 20:42 |
| reya276 | right but then the server would not be different | 20:42 |
| mhall119 | ideally you want the ability to insert a change between testing code and production code, and keep that change as part of your source control history | 20:42 |
| mhall119 | the server would not be different from what? | 20:42 |
| reya276 | from what I'm looking at in subversion you create a repository for one specific location, I could be wrong but I have not seen anywhere I can add multiple server locations to deploy to | 20:43 |
| mhall119 | hmmm, maybe you're using some fancy svn stuff, because I don't know what it has to do with deployments | 20:44 |
| mhall119 | when I used subversion, you had a single repository for the project, and branches for the different stages of development (trunk, testing, production) | 20:44 |
| mhall119 | then we'd build packages or rsync the contents of the production branch to the production environment | 20:45 |
| mhall119 | same for testing | 20:45 |
| reya276 | ok right now I'm looking at the svn preferences and in the Repository tab I have Trunk, Branches and Tags nothing else | 20:46 |
| mhall119 | okay, that's the default SVN layout | 20:47 |
| mhall119 | so I would make Branches/Testing and Branches/Production | 20:47 |
| mhall119 | your developers will work on Trunk until the code is as ready as they can make it, then you merge Trunk->Branches/Testing | 20:48 |
| mhall119 | then your QA guys test it, and anything wrong the developers fix and checkin to Branches/Testing (not Trunk!) | 20:48 |
| mhall119 | they'll merge from Branches/Testing->Trunk once it's fixed | 20:49 |
| reya276 | right | 20:49 |
| reya276 | which is what I saying | 20:49 |
| mhall119 | then, when QA is happy with everything, you merge Branches/Testing->Branches/Production | 20:49 |
| mhall119 | and deploy Branches/Production to your production env | 20:49 |
| reya276 | right but the issue that we have is that Production sits in an entire different server | 20:50 |
| reya276 | so we manually move files over to that server | 20:50 |
| mhall119 | then, if someone finds a bug in production, your devs check out Branches/Production, make the fix, check it back into Branches/Production, then you deploy Branches/Production to your testing env, verify the fix works, then deploy it to your production env | 20:50 |
| mhall119 | instead of manually moving files from the testing env to the production env, you should have a place where you checkout Branches/Production and copy them from there to the production env | 20:51 |
| reya276 | right but the way our servers are setup right now that is not possible only Dev and Test as production sits on a different server altogether | 20:51 |
| reya276 | which is why I asked if SVN can create branches to multiple locations as in different servers | 20:52 |
| mhall119 | you don't need the svn repo on the servers the code is running on | 20:52 |
| mhall119 | you can svn checkout Branches/Production to your local box, then rsync it to your production box | 20:53 |
| mhall119 | in fact, you shouldn't be running the code from the repo itself | 20:53 |
| reya276 | right which is what we are doing | 20:54 |
| mhall119 | you can run it from a checkout, if you want | 20:54 |
| mhall119 | go to the production server and svn checkout Branches/Production | 20:54 |
| mhall119 | that way a deployment is just svn update | 20:54 |
| mhall119 | but the repo itself wouldn't be on the production box | 20:55 |
| mhall119 | that would be fine | 20:55 |
| reya276 | ok I see what your saying, create a prodcution directory within the Dev/Test server then merge code there and then after that move it to the actual production server | 20:55 |
| mhall119 | that would work too, yes | 20:55 |
| reya276 | k, thanks | 20:56 |
| mhall119 | np | 20:56 |
| mhall119 | again, the benefit to that is you can make changes to production code without worrying about it getting mixed up with testing code | 20:56 |
| mhall119 | you just have to make sure you merge the fix back from Branches/Production->Branches/Teseting->Trunk | 20:57 |
| mhall119 | or you'll get regressions | 20:57 |
| mhall119 | and, i'll just warn you, svn sucks at merging backwards like that | 20:57 |
| mhall119 | supposedly it got better around like 1.7 or something | 20:57 |
| mhall119 | but when I was using it, it didn't remember the last time you went Branches/Testing->Branches/Production, so going backwards you had to specifically tell it which revisions were new | 20:58 |
| mhall119 | bzr/hg/git are all so, so much better at that | 20:58 |
| mhall119 | anyone want a Perl job in Boca Raton? | 21:00 |
| mhall119 | it'll by system programming, not web | 21:00 |
| reya276 | hey in subversion does it have file checkout, or file ock | 21:36 |
| reya276 | *lock | 21:36 |
| reya276 | I know that you can manually lock it, but for some reason it wont do it automatically when you open a file | 21:36 |
| maxolasersquad | Woot, just got a cr48 | 22:47 |
| * maxolasersquad_ is excited. | 22:53 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!