Hi All,
It’s been a long time since I last posted on here.
Quick question, I am thinking about using some kind of Version Control / Source Control for my online store. However I am not entirely sure how they work. I have a linux VPS server which uses CentOS and cPanel. Has anyone else had any experience of setting up source control?? What was your thoughts?? How did it help you with your web projects??
Any help would be great.
Thanks
I’ve used SVN for years after losing an entire project due to working late and running a rogue command that wiped it out.
Most hosting services can setup SVN through a control panel and you can then use TortoiseSVN or something similar to interact with it locally. The basics of source control are you import your current set of files, then you checkout your repository so you can work locally, and as you make milestones/changes you commit them back to the repository.
Here is a good read and a few of their examples are using SVN:
http://betterexplained.com/articles/a-visual-guide-to-version-control/
Hey Cp 
I’m gonna have to recommend using mercurial or git over svn. I used svn myself for a few years and couldn’t see anything at all wrong with it. Sure, Mercurial and Git are much faster and can work offline - also supporting different workflows, but I still didn’t see this as an absolute essential or anything like that.
The moment I changed my mind about this was the first time I got my head around how branching works in Mercurial (Mercurial and Git are both very similar, but we use Mercurial at work - the way branching works is so similar that at least in my use-case you can consider them to be the same). Because I’d used svn for years, I was scared of branching (had only ever tried it at a previous company, and the process was a nightmare - took us about a week to do a complicated merge between two branches and everything broke), so I didn’t branch for probably the first 3-4 months of working there (thinking back on this, it may have been a good 6 months into my job before I first did it).
I then came across this scenario: I had a system that was live. I had been working on a new feature for about 2 weeks, but this feature was not yet finished. Because I develop locally, my boss hadn’t seen the (unfinished) changes I’d been working on at this point. My boss comes to talk to me to tell me there’s a couple of new reports he wants to see on the site, and they are considered a top priority. Now I have a problem - I have two weeks worth of changes that are not yet finished - I must have edited 50 files or more during those two weeks, and now my boss wants some new reports on the site… So how do I make sure none of this unfinished code goes live? In svn, this would have been a nightmare. I’d have probably had to comment out loads of my code to make sure none of the new stuff went live, but when you’re dealing with 2 weeks worth of code, it’s really messy and not gonna be much fun…
So I had a go at branching in mercurial. Oh my god - I couldn’t believe how good it was. All I did was this - I reverted back in time in my code base to the current live version. I then created a new branch from that point called “new-reports”. I then did the work on these reports, got it working and put that code live. This mean my boss could only see the new reports, and that branch had NO code from my unfinished feature on it at all.
Then comes the really cool part - I then took this branch and merged it into my current working branch with the new, unfinished feature, and good god - it merged instantly. So this meant my dev branch had the new reports + my unfinished code. Eventually I finished this feature, and when it came time to put it live, it had both the new reports + the new feature.
Seriously, could you do this with svn?
Just the other day, one of our new web designers (by no means a coder) wanted to be able to edit some design related html/css on our site. No problem. I set him up with his own branch in mercurial and told him how to use it. It’s so clean this way, because he can only push to me and my workmate (not to the server). This way, we can assess his changes, make sure he’s not done anything silly like edited some php or something, and then when we’re happy, we merge his stuff into our branches and it can go live.
One final real world example - we recently had to do some work with a web design agency on a project. They setup svn on their side, and it was such a nightmare for us. If we’re working on a change, we have to contact their guy to make sure we’re not gonna put any of his half finished changes live when we put something live ourselves. It’s really bad. If we were using Git or Mercurial, we could just put stuff live by using our own branch, and he could merge our stuff into his as he’s working on it - it’d be seamless.
To really see branching in action, check out this video: https://www.youtube.com/watch?v=ZDR433b0HJY
Check it out from the 22 minute mark. He sets up a local repo and then starts branching - it’s like magic, and works just like that in practise
One more thing worth mentioning is that branching like this also really encourages experimentation - I have such freedom now, because I can really quickly create a branch and try out an idea. If it doesn’t work, no problem - just discard the branch. If it does work, great, you can easily merge your changes into your dev branch and you’re all set. The freedom this gives you is very powerful.
A very good introduction to mercurial is here: http://hginit.com
It also has a section dedicated to svn users: http://hginit.com/00.html
Actually, yeah. SVN does branches too.
This example, on the other hand, does require a distributed version system. In SVN, there’s only one server you can commit to. The rest of us only have working copies. Whereas in a distributed system, we clone the repo, and our copy is then indistinguishable from the master. That allows your designer to commit into your personal copy.
SVN does branches too…
Branching in svn is expensive and messy though. You wouldn’t merge 3 or 4 times a day in svn, would you? I found branching and merging very difficult and cumbersome in my experience with svn. Like I said with the example of the external agency we had to work with recently, the issue we were having could have been solved with branching easily, but because they use svn, they didn’t branch and so we had to deal with the pain.
Merging is the real key difference here - merging is simple in git and mercurial, so much so that it’s normal to do 3 or 4 merges in a day. It’s trivial to create branches for everything. On the project I’m working on now for example, we’ve probably had between 40-50 branches on the project in total (a 3 month project), and typically we’d have about 5 branches running concurrently at any one time. Again, I highly doubt you work like that if you use svn.
Added to this is the fact you can use it offline and it’s much, much faster than svn. When we had to use svn with this agency, it was such a pain. It felt like a real step back, and I just wouldn’t even consider using svn for anything if I had the final say.
Actually… yeah. I always thought branching in SVN was simple and straightforward. And merging was equally easy.
EDIT: Which isn’t to say that it’s necessarily better than Git or Mercurial, just that your experiences with it seem… unusual.
Here’s a screenshot from some of the most recent commits in our project. You can see we’re branching and merging for fun. Again, I just don’t think a workflow like this would be realistic in svn:
I’m gonna have to disagree with you there - you must be the first person I’ve known to say branching is simple in svn - I take it you’ve experienced using either git or mercurial and how they branch? I think it’s far better.
For example, would you feel comfortable merging say 2 weeks worth of changes to 50 files in svn?
Yeah…
Well you’re the first person I’ve known to say that.
Regarding my other question - have you experienced branching in git and/or mercurial?
Can you describe the process of branching in svn? Let’s say you take my first scenario - the example of having two weeks’ worth of changes that are unfinished, and then you’re asked to add a new “reporting” section to the live site. Can you describe the actual process for branching and merging in svn?
I’ll do the same in mercurial.
So you update to the live branch:
hg update live
you branch from this point:
hg branch reports
You can then commit on the branch as normal.
When it’s time to merge, you go to your live branch:
hg update live
and merge:
hg merge reports
Done.
What’s the subversion process?
Take a look at this article, and note the “Lightweight Branches: Frictionless Context Switching” section: http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
Git and Mercurial are actually better than svn, they’re not just different.
No offense, but I don’t see SVN having difficult branching/merging strategies either… I’ve yet to run into a problem with branching and merging where it was unbearable or incredibly difficult. Another thing to keep in mind, the OP is primarily talking about a Version Control for himself, not necessarily a team. In that regard something simple, such as, SVN makes a lot more sense over GIT and Mercurial. GIT and Mercurial can make sense when you need a distributed repo, SVN makes a lot of sense when you don’t. I’m not at the point of recommending GIT and Mercurial in this situation since it doesn’t seem to make a lot of sense.
To show how to merge I’d have to know what kind of merge you are referring to (as you can do multiple kinds with SVN). Most cases would follow a feature branch, which would simply use
svn merge --reintegrate current_path url_of_master_branch
If you are doing team branches (multiple teams developing the same project across their own branches doing weekly merges), then you would most likely merge changesets from the last merge you did
svn merge -r 13:HEAD url_of_master_branch
Neither of those seem convoluted to me… Plus if you use any IDE with SVN support, this becomes painless. Don’t get me wrong, I’m sure GIT and Mercurial are nice and all, but when you speak of ease of use, your way off base. It is far easier to describe the workflow of SVN than it is GIT or Mercurial. Explaining to someone you have multiple repos in multiple locations and you need to know when you want to push changes to each one is complicated. SVN there is only 1 repo and you typically work within a specific branch, it is far easier to describe to a new user (my opinion of course).
Yes, but I think if you look at that link above, you can see how much better branching and merging is in git/mercurial:
"Before I begin explaining this, which is actually my favorite feature of Git, I need you to do me a favor. Forget everthing you know about branches. Your knowledge of what a ‘branch’ means in Subversion is poisonous, especially if you internalized it pre-1.5, like I did, before Subversion finally grew some basic merge tracking capabilities. Forget how painful it was to merge, forget how long it took to switch branches, forget how impossible it was to merge from a branch more than once – Git gives you a whole new world when it comes to branching and merging.
In Git, branches are not a dirty word – they are used often and merged often, in many cases developers will create one for each feature they are working on and merge between them possibly multiple times a day, and it’s generally painless. This is what hooked me on Git in the first place, and in fact has changed the entire way I approach my development.
When you create a branch in Git, it does so locally and it happens very fast. Here is an example of creating a branch and then switching to your new branch to start doing development.
$ time git branch myidea real 0m0.009s user 0m0.002s sys 0m0.005s $ time git checkout myidea Switched to branch “myidea” real 0m0.298s user 0m0.004s sys 0m0.017s
It took about a third of a second for both commands together. Think for a second about the equivalent in Subversion – running a copy and then a switch
$ time svn copy -m ‘my idea’ real 0m5.172s user 0m0.033s sys 0m0.016s $ time svn switch real 0m8.404s user 0m0.153s sys 0m0.835s
Now the difference between 1/3 of a second and 13 seconds (not to mention the time it takes to remember each long URL) may not seem huge at first, but there is a significant psychological difference there. Add to that the fact that your network speed, server load and connectivity status are all factors in Subversion, where it always takes 1/3 of a second in Git and that makes a pretty big difference. Also, branching is considered a fast operation in Subversion – you will see even more pronounced speed differences in other common operations like log and diff.
However, that is not the real power of Git branches. The real power is how you use them, the raw speed and ease of the commands just makes it more likely that you will. In Git, a common use case is to create a new local branch for everything you work on. Each feature, each idea, each bugfix – you can easily create a new branch quickly, do a few commits on that branch and then either merge it into your mainline work or throw it away. You don’t have to mess up the mainline just to save your experimental ideas, you don’t have to be online to do it and most importantly, you can context switch almost instantly.
Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.
As an anecdotal case study, take my Pro Git book. I put the Markdown source of the book on GitHub, the social code hosting site that I work for. Within a few days, I started getting dozens of people forking my project and contributing
copy edits, errata fixes and even translations. In Git, each of these forks is treated as a branch which I could pull down and merge individually. I spend a few minutes once or twice a week to pull down all the work that has happened, inspect each branch and merge the approved ones into my mainline.
network graph Why You Should Switch from Subversion to Git
As of the time of writing this article, I’ve done 34 merges in about 2 weeks – I sit down in the morning and merge in all the branches that look good. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes. Once again, I will leave it as an exercise to the reader to contemplate how that would have gone in Subversion.
Becoming a Code Artist
You get home on Friday after a long week of working. While sitting in your bean bag chair drinking a beer and eating Cheetos you have a mind blowing idea. So, you whip out your laptop and proceed to work on your great idea the entire weekend, touching half the files in your project and making the entire thing 87 times more amazing. Now you get into work and connect to the VPN and can finally commit. The question now is what do you do? One great big honking commit? What are your other options?
In Git, this is not a problem. Git has a feature that is pretty unique called a “staging area”, meaning you can craft each commit at the very last minute, making it easy to turn your weekend of frenzied work into a series of well thought out, logically separate changesets. If you’ve edited a bunch of files and you want to create several commits of just a few files each, you simply have to stage just the ones you want before you commit and repeat that a few times.
$ git add file1.c file2.c file3.c $ git commit -m ‘files 1-3 for feature A’ $ git add file4.c file5.c file6.c $ git commit -m ‘files 4-6 for feature B’
This allows other people trying to figure out what you’ve done to more easily peer-review your work. If you’ve changed three logically different things in your project, you can commit them as three different reviewable changesets as late as possible.
Not only that, which is pretty powerful in itself, but Git also makes it easy to stage parts of files. This is a feature that has prevented coworkercide in my professional past. If someone has changed 100 lines of a file, where 96 of them were whitespace and comment formatting modifications, while the remaining 4 were significant business logic changes, peer-reviewing that if committed as one change is a nightmare. Being able to stage the whitespace changes in one commit with an appropriate message, then staging and committing the business logic changes seperately is a life saver (literally, it may save your life from your peers). To do this, you can use Git’s patch staging feature that asks you if you want to stage the changes to a file one hunk at a time (git add -p).
These tools allow you to craft your commits to be easily reviewable, cherry-pickable, logically seperate changes to your project. The advantages to thinking of your project history this way and having the tools to easily maintain that discipline without having to carefully plan out every commit more than a few seconds before you need to create them gives you a freedom and flexibility that is very empowering.
In Subversion the only real way to accomplish the same thing is with a complicated system of diffing to temporary files, reverting and partially applying those temporary files again. Raise your hand if you’ve ever actually taken the time to do that and if you would consider the process ‘easy’ in any way. Git users often do this type of operation on a daily basis and you need nothing outside of Git itself to accomplish it."
Also, I’d still recommend using git or mercurial over svn, even for a single developer. For one, you can use both offline and they are much, much faster than svn, but also, and I’m just gonna repeat myself here - branching and merging is far superior. See the above quote…
I find svn really painful to use. Like I say, using it for this recent project (where we were forced to) felt so painful. It definitely felt like a backwards step to me.
What I would say though is that a really nice version control client can make a big difference. I run on a mac and use source tree: http://www.sourcetreeapp.com/ This app has just been released in beta version on windows, and makes the whole process so much more simple. Using this, I really don’t think you can argue svn is more simple - I’d argue it’s actually more difficult. To setup an svn repo, you require a server and have to mess about setting up the repo. To start a repo in git, you do this: “git init”. To start a repo in mercurial you do this: “hg init”. It’s true that git/mercurial can handle more complex workflows than svn, but it’s also the case that for quite simple usage, I think they’re actually easier to use + you get the benefits of superior branching and merging.
I’d like more explanation why you find it expensive. It isn’t like SourceSafe where branches actually created copies of each file. Instead of only creates copies of files that are actually changed, the others are links to the original files. So I’m not sure I see the “expensive” side of things.
I can still do it all from a command line (if I so desire) or within an IDE. It doesn’t take long for the branch to be created and checked out, so I’m just not seeing this description being accurate. Maybe you just had a bad experience because your workflow didn’t match with SVN or your branching strategy wasn’t up to par with a Centralized Version Control.
Taken from the article I linked to:
Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.
It’s not so much branching, as it is merging that is better in DVCS. There’s also the fact that when you switch between branches, you instantly switch between them in your working copy, so there’s just no messing about. The way merging works in DVCS is almost like voodoo - it just works so smoothly it might as well be black magic at times.
Put it this way - would you have 5 concurrent branches running at the same time in svn and find it trivial to merge them all together at the correct times? What about doing this while at the same time being able to easily commit bugfixes (hotfixes) on the live branch, and merge those same bugfixes into your branches if required?
It takes me less than a second to create a branch in mercurial, and I can switch between branches in a second - every time I switch, it switches my working copy so I can see the branch I’m on instantly. If I want to merge it’s easy, and just takes seconds. This is not the experience I’ve had with svn.
There’s no need for the whole “trunk” and “branches” directories in mercurial/git, because you just context switch cheaply and instantly. I can switch to my colleague’s branch to see what he’s doing and see if his stuff is working, commit any changes I need to make to his branch and then switch back to my own branch in seconds. If I’m happy I can merge these branches whichever way I want, and we can do this even with 10 people working on say 15 branches at the same time if you really want to - all of it done quickly, offline (if necessary) and what’s more - cheaply.
You mean to tell me svn import url ./ is not simple? I’m sorry, but how is that much different than git init (I could script an alias called svn init and tada!)? I could do that locally too, if I wanted, but you lose all the benefits of doing it locally, you lose your local machine due to an idiotic command line execution or a dying hard drive and you are still screwed. You need a remote server period.
Your reasons seem purely personal. I don’t see anything special about the way it branches or merges that is inherently different to SVN. branching is branching, merging is merging. If you do it often you won’t run into many problems with differences in files that result in conflicts. If you do it after a long time inbetween, be prepared for conflicts and resolve them. In both scenarios you will always have the ability to run your project again before committing it to the target branch.
I still think you are caught up in an experience you had due to improper layout/workflow. I’m working in TFS a lot of late which is very similar to SVN workflow and we have 8 teams all interacting with each other. We have no problems with branching and merging (and this system is massive we are talking hundreds of gigs of code/data). I just don’t see how recommending something that is designed for a team workflow for a single developer makes sense. He can always convert to git and mercurial when the need arises, but I find it much better to start with something straight forward that is already packaged on most servers (and control panels) before going the route of having to setup/install a system that is meant for so much more.
Plus I could easily name off a dozen tools for SVN that make life easier too, but that really isn’t the point.
I must use a much more refined workflow, as I rarely have conflicts with SVN merging… Oh well. I still don’t see the big deal. I don’t have to spend hours on end merging with the workflow we have established nor does anyone else… Personally I just think the issues people have with SVN is they did it backwards. They created their web of branches wrong and they are now paying the price for it. If you think about what you need upfront and create it properly there is very little concern with merging, it just works as intended.