I've been a SVN lover for a lot of years but since I moved to a project that uses Git I started to understand what all the fuss is about.
To be disconnected and still have a full powered SCM is a huge plus.
I use local branches a lot and merging is pretty straight forward.
I agree that tends to be a bit more complicated at the beginning, specially for Windows people that are not so used to the command line but with time it really turns out to be easier to manage the basic tasks in the terminal than in the UI tools.
Well, as long as your company has VPN, being disconnected is not that big of a deal. The positive of Git is also the negative, you're carrying along a huge repository (relatively) all the time. In SVN, you only use the repo when you need it.
"Well, as long as your company has VPN, being disconnected is not that big of a deal."
"Disconnected" and "VPN" in the same sentence?
"you're carrying along a huge repository (relatively)"
It's really relativelly... as long as you don't have a lot of binary files inside (and a lot of versions of them) the source control overhead should be pretty small. We're only speaking about Deltas so at the end is not a bad compared to what you get in return.
Although my biggest plus to Git is actually the ability to do branches commit, rollback and all that only locally without messing with the remote repository and of course, even if I'm off-line.
I don't, but seeing how many people do has made me think that I probably should.
I'm the only one who does .Net development at my company and so I manage all of my source code on my laptop with daily backups.
In this case, how would you actually implement source control? I want to be able to get to all of my projects without an internet connection when I am out of the office so I would have to install the SVN server on my laptop. Does that not kind of defeat the purpose of it?
"I'm the only one who does .Net development at my company and so I manage all of my source code on my laptop with daily backups."
Source Control is not (only) about backing up your work.
It's about having an interactive way to see what/who changed what and when.
It's the ability to create separate branches of work without messing each other
It's about having separate branches per environment, or at least a separate branch for production and being able to pick what goes into that branch.
Man... I could go on and on with this...
For the scenario you describe, use Git...
With Git every machine have a full repository.
You can commit (locally), create branches, see history, etc.
Everything works locally and once you have a connection with the remote repository you can push your changes. This is actually the thing that makes Git different from the others.
Merges work pretty well so if you have conflicts with other people changes you can easily fix them.
So you're saying that creating a copy of a project and appending _old, _old2, _old3 etc to the folder name isn't the correct way to handle different versions?
Thanks, I'll take a look at Git, I had messed around with SVN a while back but had thought the need for a server to to be running a bit of an overkill.
My backups are incremental so I can restore certain files from certain dates but it's obviously not ideal.
_old1, _old2, etc. is not very useful - or do you keep track of what _oldN really means?
Setting up a local SVN repository is zero effort (a one-liner, beside installing the software). On the local machine, you do not need a server running.
Honestly I don't feel safe working without an SCM...
Even for more simple things like for instance you want to test something that will probable screw up a lot of code. With and SCM you can just do whatever and at the end if it didn't turn out to be as expected just rollback everything (or just a subset of it).
If you want to keep your brain in your head, you should also have a look at Mercurial (abbreviated as hg). Ir's a distributed VCS like Git, but is way friendlier to the user, having sane command line parameters, easy to understand documentation and the most awesome GUI, which is the only usable GUI, which is the same on any current desktop OS (TortoiseHg).
Furthermore, it doesn't need an isolated Unix environment on Windows, which makes working with Mercurial a lot more portable than using Git in your projects.
Everybody may have his or her reasons for using this or that VCS, but I strongly advise you to at least have a look at Mercurial, because you are probably going to regret it, if you started all your projects with something else and had to learn about Mercurial afterwards.
You will be able to have local copies of your sourcecode.
I am in the same situation, and to be honest: Visual Source Safe saved my ... more than once because I was able to track source changes to see when a modification was made or to simply "throw everything away" with a simple "undo check-out".
Use Git for that - it is made to (also) work offline.
Source control is not for teams only and its main feature is not "backup" in the traditional sense.
Beside several other features, a version control system allows:
- encapsulating logically meningful and commented change sets (e.g. of several files) that allows to specifically roll back if needed
- adding associations with issue tracking systems (the lowest level of intergation is to mention the fixed issues in the change set comment)
- producing a worklog and/or create some kind of release notes
- creating concurrently existing variants of the sources (AKA branching)
Ask yourself if you can achieve this with your backup "solution" - without re-inventing the wheel, i.e. without trying to mimic the version control systems featurs.
I'm the only one who does .Net development at my company and so I manage all of
my source code on my laptop with daily backups.
Lets see some scenario why this source control is important.
1.If your laptop got corrupted or broken accidently then what you'll do?
2.If you'll make some changes and then you wants to rollback the same then how can you achieve this efficiently? copy the old files from your local backup wasn't a smart move!
3. If suppose you want to share your works to your colliques, then how can you splits and how you can integrate your codes after finishing it?
The answers for all the above question is maintain your codes in Source control.
I've working similarly what you're working now, but laterly i've realised the importance of source control. Now i've using SVN was the best.
Use something that doesn't have a central repository (i.e. Git, Mercurial). Don't forget constant backups take up way more space then if you were using source control (since source control only stores differences instead of entire backups). Plus, you have a bunch of added value, a complete history of development, ability to branch code off, ability to create tags for a complete history (i.e. you'll always have the source for every release you make, so you can even support multiple releases), easily see differences in files between any random points in time. There's a lot of value added, plus, most solutions are free... so you really don't have an excuse not to use them...