Over the past week the UK government receive criticism of their handling of the new UK web monitoring law they’re attempting to push through parliament. This new law will allow the Government to snoop on emails, instant messaging and any websites you may visit and have a private court discuss it.

I’ve debated this with many people and a common argument is “Why should we care? I have nothing to hide”. In fairness, it’s quite a sound argument on the face of it. Why should you care? You haven’t done anything wrong to feel guilty of and it’s not like your dirty washing is going to come out in public even if it’s a minor offense.

The reason I argue against it is this… As far as I’m concerned it’s a slippery slope. Today we’ll be fine with allowing the government to look at our sensitive data at will and tomorrow they’ll do it without our permission. As each year passes our civil liberties will be whittled away until we have none to speak of. It’s the same as the argument with marijuana. Sure it’s nowhere near as harmful as heroine or cocaine but it’s an entrance drug; one that can and often does lead to harder substances.

Another reason I argue against it is that criminals are wily fellows… just because you monitor the traffic doesn’t mean you’ll get anything from it. All we will manage to do is get criminals to smarten up and encrypt messages that they may send to one another. All of this is over and above the fact that this will massively increase the cost of line rental via ISPs.

We need to draw a line in the sand here to stop further progress, otherwise we’ll see policy creep in later years.

Support the e-petition and put a stop to this. Draw a line in the sand!

Popularity: 31% [?]

Git: Decentralising version control

I’ve been a user of Subversion for a number of years, I was a little apprehensive about moving to a completely different versioning system but now I’m seriously glad I made the move. To recap, Subversion is a centralised version control system. What this means is that you have a centralised code repository, developers use clients to checkout code which they can work on until they’re ready to commit their work back to the main repository.

So what is Git and why move to it at all? Why reinvent the wheel?

What is Git

Git is a decentralised version control system. Clients can clone the repository from any other copy of the repository. In general you all still have a main repository you use as a focal point of committing but you can create your own branches and therefore have more control of your own repository structure (until you need to commit and merge of course). So instead of checking out and committing you clone the repository, commit your changes to your own local repository then push the changes back to the focal repository when you’re ready, merging if and when necessary.

Advantages

• No internet connectivity required – each client has a full copy of it’s own repository
• Distributed development – as mentioned every client has it’s own repository copy
• Strong support for branching / merging – distributed versioning systems lend themselves heavily to branching and merging often because every repository can at some point be considered a branch of others
• Handles large projects efficiently – Git is an order of magnitude faster than other versioning systems
• Ideal for feature development – users can branch themselves and work privately on their own feature independently of others
• Allows for very flexible development – developers can choose who’s repository they want to merge with at any point in time

Disadvantages

• Working in the same code area on similar features is trickier because merging may result in lots of conflicts
• Distributed development tends to encourage private work which is bad for development practices
• Maintenance work tends to be sloppier on distributed systems

Which should I choose

Ultimately it’s a personal decision. Many claim that a centralised versioning systems cannot work with distributed development, however, this is wrong. In a centralised versioning system if all developers worked on their own personal branch effectively you would have something similar to a distributed environment. In both systems you will still have eventually merge with someone responsible for releases, otherwise you have chaos and unpredictable builds, timelines and feature progress becomes difficult to track.

The nice thing I like about Git is just how easy it is to setup and get started in comparison with Subversion. No messing about plus hosting like Github makes things even easier.

Using Git on Github

Here’s just a few useful tips to get you started:

1. Initialise Git repository in current folder

git init

2. Configure local Git to point to Github account

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"
git config --global github.user username
git config --global github.token 0123456789yourf0123456789token

3. Add link to the remote github repository as origin i.e. main repo

git remote add origin http://username@github.com/username/myrepo.git

4. Set the default branch to merge to as the origin – this allows a simple git pull without branch

[branch "master"]
remote = origin
merge = refs/heads/master

5. Pull the code from the remote repository i.e. origin

git pull

6. Add a new file using the client

git add myfile.ext

7. Commit changes to your local repository

git commit -am "Added myfile.ext to repository"

8. Configure your buffer to 500mb so you don’t have issues with the size of commits

git config http.postBuffer 524288000

9. Push the code to the origin

git push

In Summary

I hope this article has provided you with at least some insight into what Git is and in what way it varies from Subversion. Also, a precis on the advantages and disadvantages of each approach. If you agree or disagree feel free to leave me a comment below.

Popularity: unranked [?]