It Doesn't Refresh Correctly

[White_Lily]

You dont need to be experienced, create a simple one with simple error checking and then just develop it over time.

[Adam]

So take a backup of the site & database before making changes? (Which is what most people and companies do anyway).

 

But then again, what if you debug it locally, and the files become corrupt? youd have to rebuild it all over again, so either way whether you edit online or offline your still guna have pretty much the same risks lol

 

As for keeping users offline while debugging online, which you rather: have the problem there staring every user in the face, or take the site down while you fix the problem so that error doesnt occur anymore?

 

You use version control, that's what most companies and people do. Under no circumstances should you be testing or making changes directly to a live production environment. The production box(es) are generally only configured to report higher level errors anyway, so debugging wouldn't even be practical there.

 

Ideally you want 3 environments; production, local for development/debugging, and then staging that replicates production so you can give things a test run in a like-for-like environment (as close to as possible) before promoting live. Of course the odd code issue can slip through that doesn't occur locally or on staging, which is when you may have to jump on the production box and figure out what's going wrong, but they should be edge cases.

 

You dont need to be experienced, create a simple one with simple error checking and then just develop it over time.

 

For some scripts I would be inclined to agree with you there, but for login/registration, that's a key area malicious users will try to exploit. Better to use a trusted pre-written solution than to figure out security holes after someone's exposed them, or before you've got around to patching them.

Edited October 3, 2012 by Adam

[White_Lily]

Most still take backups whether they make changes directly or not.

 

Im told that if i make a change to a live preview or live site then i take a backup of the site and database before making the changes

[Adam]

No, most don't. Version control allows you to create a build of the code from any point in history. Why would you bother backing up all the files every time you roll something out when you could revert the changes even easier/faster? Database changes are subjective. Sometimes you can write a migration that can easily be reversed and is of little impact, which in those cases a database back-up isn't necessarily needed. If you make any significant changes though, or changes that can't be reversed, then yes definitely create a back-up of the data.

 

Edit: Back-up of the relevant data, that is.

Edited October 3, 2012 by Adam

[White_Lily]

Either way, people clearly do it differently, I just find more easier to do it how I do it now.

[Adam]

Yes fair enough, but what you're recommending here is the release process equivalent of recommending IE6 as a browser -- it's outdated. Version control was invented for a reason. Relying on the person doing the release to make a back-up is always subject to human error, and adds complexity and time. I only make a point of saying this for the benefit of the OP, I'm not just trying to call BS.

[TheNavigator]

We use SVN actually, and it rocks. A record of every single update and you can restore any single minor change. The point is that I missed using this for this project, unfortunately

 

Version control is a must for companies. It was one of my worst moments when 2 hard disks of mine went faulty at the same time, lost 200 GB of extremely important and precious data. SVN just makes tens of copies there, so our work was easily retrieved. My personal one wasn't, though.

[Adam]

SVN? You need to try Git.

[TheNavigator]

Can you please post a simple comparison why Git is better? Other people told me that it's better too, lol

[Adam]

Okay, but it's been a while since I used SVN, tell me if I get anything wrong (anyone).

 

So first SVN is a repository of revisions held on a central server, that the developers pull from and push to. The developer only has a working copy of the code, and uses the server's repository to update, commit and stuff. Git is also held on a central server, but each developer has a local copy of the repository as well, and whenever you do a fetch it syncs your local copy. That means you can work offline while making commits, checking out different commits, merging, etc. And be pretty much up to date with the server most of the time. That might sound trivial, but I tend to do a lot of work on the train, which would be a nightmare with SVN. Not to mention a local copy is always going to be much faster than transferring stuff across the network.

 

For me though one of the main benefits to using Git is the way it tracks changes. Instead of storing incremental changes of whole files, which I believe SVN does, it only tracks what's changed in the files; kind of like a diff between the old and the new, if you're familiar with bash commands. That means the repository is significantly lighter, routine use is much faster, and you can apply these diffs wherever you want. There's no linear revision number it's just a bunch of changes you can stick anywhere -- so long as Git can resolve the change that is, otherwise you'll have to resolve it manually. (Generally though unless two developers have modified the same bit of code or you're trying to cherry-pick a commit into the stone age where the code didn't exist before, Git does a pretty good job.)

 

That storage mechanism though also enables you to cleanly rebase your working branch onto your master/base branch; essentially taking all yours commits on the working branch and reapplying them to the top of the base branch, but back onto your working branch. If that makes sense? During development it's much nicer to have your commit history clean and only relevant to what you're doing, not having a merge stuck in the middle that pulls in everybody else's changes. You can't rebase with SVN, given the way it stores changes as whole files.

 

Both SVN and Git have the concept of "branches" that I've mentioned a few times. Both have a completely different meaning though. SVN branches are basically forks in the code base that generally don't meet again, but subsequent revisions are/can be applied across them all to keep each fork up to date. Git branches on the other hand are just a set of commits "branching" off from the base branch during the development process, that are merged back in later. You can checkout different branches whenever, merge branches together, do anything you want. Everything in Git just boils down to small, flexible changes (commits) that build up a code base. That's it's power.

 

I don't know if I'm babbling or making sense here now, but hopefully it's helped!

[TheNavigator]

Okay, but it's been a while since I used SVN, tell me if I get anything wrong (anyone).

 

So first SVN is a repository of revisions held on a central server, that the developers pull from and push to. The developer only has a working copy of the code, and uses the server's repository to update, commit and stuff. Git is also held on a central server, but each developer has a local copy of the repository as well, and whenever you do a fetch it syncs your local copy. That means you can work offline while making commits, checking out different commits, merging, etc. And be pretty much up to date with the server most of the time. That might sound trivial, but I tend to do a lot of work on the train, which would be a nightmare with SVN. Not to mention a local copy is always going to be much faster than transferring stuff across the network.

 

For me though one of the main benefits to using Git is the way it tracks changes. Instead of storing incremental changes of whole files, which I believe SVN does, it only tracks what's changed in the files; kind of like a diff between the old and the new, if you're familiar with bash commands. That means the repository is significantly lighter, routine use is much faster, and you can apply these diffs wherever you want. There's no linear revision number it's just a bunch of changes you can stick anywhere -- so long as Git can resolve the change that is, otherwise you'll have to resolve it manually. (Generally though unless two developers have modified the same bit of code or you're trying to cherry-pick a commit into the stone age where the code didn't exist before, Git does a pretty good job.)

 

That storage mechanism though also enables you to cleanly rebase your working branch onto your master/base branch; essentially taking all yours commits on the working branch and reapplying them to the top of the base branch, but back onto your working branch. If that makes sense? During development it's much nicer to have your commit history clean and only relevant to what you're doing, not having a merge stuck in the middle that pulls in everybody else's changes. You can't rebase with SVN, given the way it stores changes as whole files.

 

Both SVN and Git have the concept of "branches" that I've mentioned a few times. Both have a completely different meaning though. SVN branches are basically forks in the code base that generally don't meet again, but subsequent revisions are/can be applied across them all to keep each fork up to date. Git branches on the other hand are just a set of commits "branching" off from the base branch during the development process, that are merged back in later. You can checkout different branches whenever, merge branches together, do anything you want. Everything in Git just boils down to small, flexible changes (commits) that build up a code base. That's it's power.

 

I don't know if I'm babbling or making sense here now, but hopefully it's helped!

 

Mate it looks like you use SVN's first version or so...

 

Actually, all the points you're talking about is actually there in SVN, except for the "working copy of repository" thing. The point is that you can still develop, but you won't be able to compare, update or commit.

 

About the full file change thing, that's totally, TOTALLY wrong. SVN records and saves only the changes. It supports merging in a perfect way. I didn't use Git before though to be honest.

 

 

So, a rewrite?

[Jessica]

At my work we use SVN, CVS and Git. I've mostly been working with CVS, but I worked with SVN at a previous job. Now my projects are moving to Git.

 

For most people, it doesn't matter which you use, just use SOMETHING.

Beyond that, I think Git is the better of them.

[Adam]

Actually, all the points you're talking about is actually there in SVN, except for the "working copy of repository" thing. The point is that you can still develop, but you won't be able to compare, update or commit.

 

Which would make life hell if, like me, you do quite a bit of work on trains or places where you don't have an internet connection, or just don't have access to the network. SVN does not support rebasing or cherry-picking either, at least not natively or properly.

 

About the full file change thing, that's totally, TOTALLY wrong. SVN records and saves only the changes. It supports merging in a perfect way. I didn't use Git before though to be honest.

 

My apologies, I wasn't sure if I was right there. Perhaps it's CVS that I was thinking of. Given it can't rebase or cherry-pick though, there must be some debilitating feature to it's storage engine that prevents it. That's why I assumed.

 

For most people, it doesn't matter which you use, just use SOMETHING.

 

+1

[TheNavigator]

Which would make life hell if, like me, you do quite a bit of work on trains or places where you don't have an internet connection, or just don't have access to the network. SVN does not support rebasing or cherry-picking either, at least not natively or properly.

 

 

 

My apologies, I wasn't sure if I was right there. Perhaps it's CVS that I was thinking of. Given it can't rebase or cherry-pick though, there must be some debilitating feature to it's storage engine that prevents it. That's why I assumed.

 

 

 

+1

 

Okay I'll consider GIT then. Is there enough GUI applications supported for servers and clients on linux? If not, is there any for Windows?

[premiso]

Okay I'll consider GIT then. Is there enough GUI applications supported for servers and clients on linux? If not, is there any for Windows?

 

The windows gui can be lacking, but it has gotten way better. As far as linux clients, it is native to linux and there are plenty out there, I never used the gui's on linux at all, because I prefer the CLI, but I know there are clients out there, you just have to look for one that suits your needs. This is where your GoogleFU can shine!

[Christian F.]

The Tortoise* clients are quite good, at least the SVN client. Haven't tried the Git client, but it's well worth checking out.