This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is a version control system? How is Git useful?
I am new to Ruby on Rails platform, and so this may sound a little naive.
Why and when do we store our work in a version control system like git?
I mean what is the advantage of it ! Can't we just keep it in our local machine ?
Advantages for using git/source control:
For yourself
Remembering what you have coded and when you did it
Being able to compare what you did to previous work
Allow you to work on something experimental, and if it doesn't work switch it back to where it was before
Working with a team
It makes working with others easier - you can work on the same file at the same time and really easily combine your changes.
It will allow you to work in multiple locations and easily have the most recent code
It will help in deploying your code to a server
Git workflow for teams
Git branching model
When to store or commit your work:
You want to do this each time you finish on a particular "idea" or piece of work you are working on. This means you can have a useful commit message and can go back im time to that feature you just wrote or that bug that you just fixed.
How often and when to commit
Reasons for using Git over other source control
Its fast (switching branches is really fast and you have a local copy, so you dont have to communicate to a server for a lot of things unless you want to push or pull changes to the server)
Yes, this seems quite naive, but every question is worth asking!
First of all, using a SCM (software configuration manager) will greatly help you in a number of scenarios:
trying out experimental features without touching the main code
developing several independent ideas at the same time
recovering from failed changes, whenever they are complex and include changes in multiple files.
tracking the exact code used in a specific release, to fix a reported bug.
This doesn't even start to touch the infinite amount of work you'd have if working in a team without SCM.
And using a SCM doesn't involve network, git and any other distributed SCM is equally valid for local development, as the repository is all in your computer. You just don't pull and push.
The choice is not whether to store code in version control versus storing it on your local machine. In fact, unlike other version control systems (like Subversion, known also as svn), Git does not need a server to run.
Version control makes it easy to understand what changes were made, view and restore older versions of files, and even import changes from one version to another.
RETRIEVAL: Imagine you are working on a project on your own. You delete an old file you don't think you need anymore. A week later, you realize that the file was very important. If you use version control, you can see what the file looked like just before you deleted it, and restore it as if it were never deleted. Also, most changes committed to version control contain messages; if you join a team and the previous developer used version control (with good commit messages) you can get an easier context for when changes were made and why.
MULTIPLE RELEASES (BRANCHES): Now imagine that your software is version 1.0. You're busy working on version 2.0, but someone files a bug. What can you do? With version control, you can zoom back to version 1.0, make some changes, and then create version 1.0.1. Most version control platforms even let you apply the changes made in version 1.0.1 onto the work you're doing in version 2.0.
MULTIPLE FEATURES: Your software is so successful, you start releasing it weekly. However, not every feature is ready for release. First you start working on the widget feature, than you start working on the doodad feature. If you work on both of these at the same time, you may have two half-coded features in development at the same time, and nothing is working well enough to release. With version control, once one of the features is done, you can merge it into the "main" release as if you wrote it in one day.
COLLABORATION: Finally, now imagine that you're in a team of five or six developers all working on the same code. Naturally, you don't want to email zip files of code back and forth, especially when every developer is working on a separate feature. With version control, you can have a single history, to which all of your developers write and read.
Naturally, some of the above can be done by keeping multiple copies of the same files in different adjacent directories. The benefit of version control software is that it can handle much of the work for you while avoiding duplicating the same file over and over on your disk.
Long winded--sorry--but hope that helps!
Advantages of using git:
Code will be safe in remote repo, even if the local project crashes
You can try out new things without worrying about previous works as they can retrieved
The code can accessed from anywhere in the world
When working in team, all the work will be stored in a single place so that it will be accessible to everybody in your team
Each and every change can be tracked easily, who did it and when they did it
Deployment of application will more easier
You can have multiple versions/branches so that it will be easy for you to identify the new features added to the application in every version
you see #arulmr, #kieran-andrews, #Jeff and #rewritten that post many advantages but still if you want learn more in details you can see below links
1) http://git-scm.com/book/ch8-1.html
2) http://www-oss.fnal.gov/~mengel/git_vs_subversion.html.bak
3) https://git.wiki.kernel.org/index.php/GitSvnComparison
4) http://www.wikivs.com/wiki/Git_vs_Subversion #History, Architecture, Licensing, Performance, Features of git and svn
now the difference between git and subversion
1) http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/
I apologize for the length of this post but I needed to include a lot of information for proper answers. I hope this does not discourage responses...
Our shop historically has coded web sites using Classic ASP with some newer ASP.NET sites configured as web sites. As everyone knows this means that the source files (*.asp, *.aspx, and *.aspx.vb (or *.aspx.cs)) files are deployed to development and production servers as is.
The configuration management process was (and still is) entirely manual and includes the following steps (requirements):
Taking copies of the modified files and storing them in a "release" folder for archiving.
Taking copies of the production files that will be replaced and storing them in a "archive" folder for easier rollback.
Generating a diff report of before and after source files for code review or general reference when diagnosing a post-release issue.
The developer who coded the changes is not the person who performs the production release. The original developer is required to hand off the source files to another developer for some additional testing and production deployment.
To make the situation more difficult (not with the above..but with what I talk about below) we do not follow a formal release schedule. As individual bugs or enhancements are completed they are released. This means we could easily be making several releases to a site a week. It is even possible that a given site gets two different releases to individual pages on the same day!
Since I came on board I have been trying to transition the team to newer technologies like ASP.NET web applications and ASP.NET MVC. (We have also taken on responsibility for stand-alone applications and console utilities used for non-web processes...so my dilemma still applies.)
The difference between these technologies and the legacy technologies is the pre-compiling. Instead of deploying the code-behind files (*.aspx.vb (or *.aspx.cs)) a dll or exe gets deployed. This type of deployment package has raised several questions (issues ??).
Generating difference reports when the source has been compiled. While the newly modified source files are sitting on the developers system the production copy is a compiled copy.
Making sure that changes related to other bugs or enhancements are not included in the particular release. This would apply to both the original developer and the person performing the release.
Allowing the original developer to pass along the changed files to another developer for build, testing, and deployment.
Up to now I was the only developer on the team working on these types of sites and applications so the conflicts and issues mentioned above where non-existent. (I skip the difference report step and the I do my own deployments.) However, I am trying to push the rest of the team to embrace this plus allow for better distribution of bugs and enhancement tasks.
We are currently using VSS but I am pushing (and will most likely succeed) in getting us moved over to TFS. Some ideas I have are
Setting up a separate build system for use by the developer to do the deployment. This will solve two problems -- (1) Different versions/patches of Visual Studio and other libraries between developers and (2) instances where the person performing the release has checked out files locally for another change. (Of course this does not guarantee differences between the build system and the original developer but at least that means the release is from a consistent config.
Using labels to tag just the modified files. My problem is that while I can identify (and pull down for a build) the modified files, how do I identify the files that need to be included in the build but have not changed. Again, the idea is to not included checked in files that are related to un-released changes.
Using labels to tag all the files for the release (the modified files and the unchanged files). My problem with this is similar to the last one...how do I make sure that a file checked in by another developer (say they went on vacation) for an un-related change is not labelled and included in this build.
Using the labels I could probably write a script to generate difference reports for the labeled version and the previously labeled version. If the process works properly that should result in exactly what changes are included in the the particular release..?
Any other ideas, concerns, points of interest? While I do have some flexibility of the process some of the requirements (like difference report or some way to easily view differences and having separate developer/deployer) are most likely untouchable.
Thank you so much for any help you can provide on this.
To keep track of different versions of the code and to help you manage very fast release cycles (daily) vs long term enhancements you can use branches in TFS.
There is a ton of information out there on branching, but in general I like to try to keep things simple. For example, have one branch called "release" and another "development". Everybody works on the development branch but the code to be deployed to production is merged into the release branch right before release.
This blog post describes the process:
http://team-foundation-server.blogspot.com/2008/01/how-we-branch-our-code-in-tfs.html
Well, based on my experience with VS2003 vs VS2010 for example is that the project structures are different and allowing VS to do a conversion often times results in a solution that either requires a lot of refactoring or is unusable. Having said that; if you can transition everything over to TFS2010 then one way to handle it is to setup different projects for each solution and use the TFS built in version handling for the different releases. You can also set up a build server and schedule nightly builds. If the build is ok then you can push this version into testing and ultimately production. You should really read up on TFS because it's totally different from VSS and is definitely a huge upgrade in allowing you to do team-focused development.
P.S. TFS has a really good Sharepoint integration which will help you and your team keep track of all the bugs and tasks.
I've used TFS for about 18 months now and I'm really not excited about it. It seems like the worst of the current versions of SCMs on the market.
I think this thread will help people decide if TFS is for them vs. other source control systems. While TFS does a lot more than that, I think that source control is so critical to software development that any system (or combination thereof) that you pick needs to consider source control first.
What are the good things about TFS vs. other source controls -- what does it do well that no one else does?
What are the things that TFS is bad at that everyone else seems to do just fine?
Pros
Fundamentally it's a sound system. Robust and reliable.
Integrated with work items, reporting, etc.
The power tools are really good.
[edit] It is improving, and has taken good jumps forwards with 2010, 2012, 2013
TFS is highly accessible for custom tools. There's a rich API that makes it so easy to write dashboards and other tools to get at the data in TFS. And as all the data is stored in SQL, you can browse it and query it directly if need be. I've worked with many different SCMs over the years and have never found one that is so open and accessible - everything (user stories, tasks, bugs, issues, test plans, iterations, source code control & branches, builds, unit testing, continuous integration) is just there at your fingertips. This is an awesome feature of TFS. A lot of the UI failings of TFS have been addressed in a few afternoons writing tools and a dashboard for my team to use. And let's face it, if you write your own, it does exactly what you need.
Cons
There is one area where the robustness fails miserably: If you apply several changes to a file (add, rename, edit) in "one go" it gets horribly confused. If you don't check in these actions separately, both TFS2005 and TFS2008 crash when you go to merge those changes across branches. In 2010 onwards it no longer crashes, but it often doesn't correctly check in the changes, so you have to go in and clean up a mess of missing and incorrectly named files.
There is no standalone source control browser. It's integrated into VS, which is really annoying when you want to just work on source control items without needing to run up another copy of VS. Of course, you can give your artist a Team Explorer, but let's ask ourselves if an artist who only ever wants to view the files, check out, check in, and GLV really needs a fully blown complicated VSTS instance running to achieve it? In addition, the integration is so poor that you can't realistically use TFS from the Solution explorer (it simply lies about what you have checked out, and is so unreliable when you apply actions from that window that you soon learn to open the source control window and work in there, which defeats the point of it being integrated in the first place) [edit: The file explorer extension is excellent - close to a standalone browser - and is simple and easy to use. The main drawback of it is lack of proper integration with file commands - to rename or delete files you must remember to use the TFS submenu, or you will rename/delete locally and this screws up source control completely as TFS knows nothing of the changes you have made. This unfortunately means that only 'advanced' TFS users can be trusted to use it. So, essentially, it's still a case of "no stand alone browser" for most users]
The user interface sucks (but is improving, at least on the web-access side). Sure, it works, but there is so much that could be done to make it efficient, pleasant, and more foolproof to use. e.g. [prior to 2012] When you click "check in" it ticks all remaining un-checked-in items so that if you accidentally click Check in again in future, it checks in a load of stuff you didn't want to. And after this, it would be so easy to supply an "undo last checkin" option to quickly roll it back - but there isn't one. [Edit: The UI is improved, but these specific problems are still present in VS2010, although it does now have a check-in confirmation dialog that reduces the risk of accidental checkins][edit: in 2012 it's much better, but they've gone mad and rolled all the separate TFS dialogs into a single window, which was a serious step backwards. The pending changes window doesn't work nearly as well as in 2010 - it is harder to find things, it takes more clicks to achieve the same things, and if you check in a file from anywhere all the currently 'included' files get chucked into 'excluded' so if you have several things on the go they all get mixed together]
Workspaces. In most cases, every team member has to have essentially the same workspace mapping, slaved off a local root folder. We need 7 mappings defined, which takes about 5 minutes to set up. There is no way to push the workspace definition from the server. There is no [edit]easy[/edit] way to duplicate a workspace so you can use an existing one (or another users one) as a starting point. No, you have to manually re-enter all the bindings over and over and over and over. If you change your active workspace in the source control explorer, it doesn't get synced to your pending changes window, so you spend 15 minutes wondering why the file you merged from your other branch just isn't listed. [edit: This is getting better with 2010/2012, as you can see workspaces on other PCs and copy and paste them more easily, but it's still a pretty clumsy UI]
It has changesets, but you can't bundle items into separate changesets in your pending checkins list as you can in Perforce, you can only associate them with a changeset by actually checking them in. You can really only work on one changeset at a time, or you have to separate the files out manually in your pending list as you go to check in. [still very poor in 2012]
The merge tools are terrible. As in: they simply don't work, and unnecessarily introduce bugs into your code if you rely on the automatic merge. These tools are just as bad as they were when I first used SourceSafe in 1994. So the first thing you have to do after buying a very costly VSTS licence is replace the merge tools with something that actually works. And that means that every time you get a merge conflict, you must select each file. Choose to resolve the conflict and ok. Choose to use your 3rd party merge tool and ok. Then merge. Then save. Then choose to accept your merged changes. (You should be able to choose "automatic merge" and have it simply use the third party merge tool that actually works without hitting you with a barrage of pointless and annoying dialogs that always default to the wrong option) [Edit: InVS2010 the merge tools are still awful. But the front-end UI is much improved (merging a conflict now takes a single click rather than 4 or 5 clicks - a massive improvement when you have to merge many files][In 2012 there have been further improvements, but they are still 'ok' rather than good]
It doesn't sync between running instances of VS. So if you check in a file in one VS, another one will still list that file in your pending checkins. (it's clearly easy to sync it because any changes made by the power tools windows-explorer extension are reflected in VS instantly). [Edit: In 2012 they have fixed this problem. Now every time you switch to the pending changes view it spends 15 seconds refreshing (in 2010 it cached it and showed it instantly but it was occasionally out of date)]
Branching is the standard way of working these days. So you'd expect the branch/merge tools to make this quick and easy. But no. [edit: Big improvements were made in 2010 and 2012, but merging is terribly supported - it is really labour intensive. Just little things like only being able to merge a contiguous set of changes, so if you want to merge 5 changes that are not contiguous you have to do them one by one, but each time you open the dialog it starts from scratch instead of remembering where you were, what you last merged, the list of availablke changesets, etc. You should be able to select any changesets you want and it should automate the rest]
If you GLV (get latest version of) a solution, and some of the projects in it have been changed, VS repeatedly asks if you wish to reload each changed project. It is about 10x faster to close your solution, then GLV, then open the solution again than to GLV with it open. If I'm GLV'ing then of course I want to reload the projects! When I buy my food at the supermarket they don't ask me for every item "do you wish to take this item home with you?". [Edit: Still broken in VS2010][Fixed in 2012. Hurrah!]
[edit] If two team members add a new project to a solution, then when the second person goes to check in, they must (obviously) resolve a merge conflict. However, TFS treats the .sln as a text file, and corrupts it (it adds the two project entries but the project count is effectively only incremented once). It would be so easy to fix the sln format to make the files mergeable.
[edit] I don't do any source control operations from within the Solution Explorer window, as it has been rather unreliable ever since "integration" first came along. Even in 2008 it usually has random "checked out" icons on files that are not checked out, and recursive operations sometimes do weird things. Almost every source control 'glitch' we have is a result of someone starting an operation from the Solution Explorer. Luckily, I prefer to work in a Source Control window anyway.[2012: Sorry, can't tell you if this is fixed, as I haven't used this feature since 2008]
[edit] Where to start with the Source Control Bindings window? VS could say "Your Source Control settings have been corrupted again for no obvious reason. I never could get the hang of Thursdays. Shall I fix this for you? [YES]", but instead, it shows a complicated, confusing dialog full of information that makes no sense to anybody, resulting in a UI so scary that it makes junior programmers soil themselves. The trick is to ignore the whole window, hide behind your desk and click the "fix it" button, and it fixes it.
[edit - added 12/2010] When you Get source code, especially when resolving merge conflicts, other windows are often brought to the front (either the Solution Explorer jumps in front of my Pending Changes view, which I have docked in the same tabbed area, or the Source Control window vanishes behind another document window. This is really annoying when you have another file to merge or another folder to Get, as you have to keep "finding" the Source Control/Pending Changes windows. Getting code should not constantly reorder my document/tool windows.[2012: Still broken]
[edit - added 1/2014] With TFS 2012/2013, there is a choice of Server or Local workspaces. Server is the name for the old system where you must be online with the server to check files out. Local is the new default and makes a copy of the entire source repository on your computer, allowing you to make edits to any files without needing to check them out first. TFS then diffs your files against its local copy to work out what you changed. This sounds good, and for many people it probably is good, but it has some serious drawbacks that you should be aware of:
As you no longer check out files, they do not get locked when you edit them, and thus several people can edit any given file simultaneously, requiring a merge operation when they check in. This is fine for text-based source code files, but results in difficult situations or lost work when the files are unmergeable. Unmergeable or non-automatically mergeable files include Solution, Project, Resource (resx), XAML and any other XML files - so this causes a lot of problems in a development environment. If (like us) you also want to store Word and Excel documents and binary files under source control, local workspaces are positively dangerous. We have lost several days of work because someone unwittingly used a local workspace and then it was not practicable to merge their changes. You can reconfigure the TFS server to make Server workspaces the default to defend against this.
With Local workspaces you have to keep two copies of everything on your computer. When we upgraded TFS we suddenly found everyone lost 25GB of disk space, and it took several weeks to work out where the disk space had gone! This was a major problem for us because we all use SSDs and it is only now (2014) that SSDs are getting large/cheap enough that we can afford to be so inefficient with our disk space.
In the few weeks that we used local workspaces we had several incidents where TFS corrupted files or lost changes, presumably due to bugs in the implementation. Quite simply, we cannot accept anything less than 100% reliability for our source control system.
TFS is getting much easier to manage; these days if you don't want to customise anything too much you can set up a server in a very short time (hours) and setting up continuous integration builds and backups etc is extremely easy. On the flip side, while I found it very easy to set up backups of a TFS database, restoring that database and getting up and running after our server bricked itself was another matter - it took 4 days to work through all the unnecessary blocking problems (e.g. you have to restore the backup form a network drive, the data can't be local. When I tried to restore the image to the rebuilt server, TFS kept telling me there were no databases that could be restored. When I got past that, TFS wouldn't use the databases because they didn't match the host server (because that server was gone, the OS had been reinstalled). It took a lot of searching and fettling to get the backup to restore. Restoring should "just work"!
As you can see, most of the above are just trivial UI gripes. There is such a lot that could be improved about the UI. But the actual underlying product is good. I prefer TFS to pretty much every other SCM I've used over the last 28 years.
I wouldn't even mind the poor UI so much, except that it is one of the core UIs developers have to use on an hour-by hour basis, and they have to pay such a lot to get it. If the subscription money from a single developer was invested on improving the UI it would make a massive difference to the usability of TFS! It's painful to think that TFS is merely good or ok when it could so easily be excellent with a bit of nice UI.
Hates
Doesn't track changes to files unless you've checked them out, so if you edit a file in Notepad++ TFS is unaware that anything changed.
It's very easy for someone to check out a fille and lock it so that nobody else can make changes. TFS shouldn't drop this ability, but it certainly should make it much harder to do than it is currently.
The methods to undo a commit or two is very unclear, so much so that I'm never quite sure if it worked or not.
The way that TFS makes files read only unless you check them out is obnoxious, though it does help me remember to check files out before I save the edits I've made.
Loves
I suppose built-in integration with visual studio is nice, if you like that kind of thing (I don't)
I am a member of the Team Foundation Server team at Microsoft. There are a lot of very valid issues raised here. Some of them are addressed in the 2010 release. Others remain as issues, but we do recognize them and are working to improve the developer experience with the next release. Discussions like this are great for helping us make sure we're solving the right problems.
Here is some info on issues that are at least partially addressed today in the 2010 version:
Stand alone client
For non-developer customers that want to use the product outside of VS, they can use the Windows Shell extension powertool.
If you have users (developers or not) that need to access TFS from non-Window machines, they can use Team Explorer Everywhere. This is supported on platforms including Mac & Linux.
Copy workspace
There are two ways to copy a workspace today. The 1st is by using the workspace template command at the cmd line. Ex.
Tf /workspace /new /template[workspace name/owner to copy from]
Alternatively, you can open a workspace in the UI, select all of the mappings, copy them, & then paste them into a file/email. Someone else can than paste those same mappings into their workspace.
It would definetly be great if you could simply specify a default workspace that clients automatically pick up, but we don't have this today.
Merging robustness
The scenario described where you do an add, rename, add & then have problems when you merge has been addressed in TFS 2010.
Branch/Merge as a 1st class experience
In TFS 2010, branches are now 1st class objects in TFS. You can visualize your branches & even track changes as they move through the branch. Branching is also now a fast server based operation.
Get Latest Version of multiple projects
You can do this today by choosing the TFS instance node in source control explorer & then selecting get latest. This is the equivalent of the root folder ($).
File locking
By default TFS never locks files when users checks them out. This is the way we use TFS at Microsoft & how we see the majority of our customers using TFS. It is possible to enable users to explicitly lock files. Some customers find this desirable, but it is not the default path experience.
Con: Checkout model. Many applications do not deal well with files that are marked as read-only then change to writable (Word 2007, Notepad). So you open a file, edit the file, try to save then you're told that you can't save because it's read-only. Great, now you have to Save As..., delete the original and renamed the new one to the old name. If there's an upside to having local files be read-only I don't see it. I really prefer Subversion's approach to this.
The one upside to making files read-only is that it reminds you to check them out. However that's really just a symptom of the check-out model.
I think that TFS is the single best ALM product on the market today. Looking at it from only a source control platform is slanted. I have used many products in my career to date: VSS, SVN, Git, StarTeam, CC/Harvest, and ClearCase - apart from TFS. Personally, I cringe at the thought of going back to anything other than TFS.
TFS is an extremely powerful platform. My biggest problem with it is often related to people not knowing how to use it or using it incorrectly. It is not meant to be an application that "just works". Sure, you can use it for basic source control without learning much about it - but if that is all you use it for, then you really are better off using one of the less robust tools out there. In reality, what TFS does not give you is the way to interpret features how you want to. It is specifically built from the ground up to support process and not just be a repository.
Con: Timestamps. There's no way to set TFS to use the remote last-modified timestamp as the local last-modified timestamp. The local file's timestamp only tells me when I got the file. If I get a file that's 2 years old, there's no way to know that based on the local timestamp.
Other source controls that I have used have this ability.
Cons:
workspace version: You can't identify the version of a workspace without doing a recursive search.
terrible offline experience. attrib -r + tfpt online shouldn't be the way to work offline. Give me something like git that allows me to track status, undo and make changes. I'm even fine if it only stores the difference between the workspace version and current.
Merging robustness: a changed file on the server + a local edit on different lines is not a conflict. a writeable file should not be an automatic conflict. The automerge button should NOT exist, because it should never be a scenario.
Workspaces: the idea of being able to rearrange the source structure is just odd, and causes issues. the requirement of having both branches mapped in order to merge is odd. The requirement of having to do an operation multiple times, because my workspace mapping doesn't have a true root folder is wrong.
Full reliance on remote server: There are some nice things about having all these things stored on the server, but really, you could store information locally and then upload it when needed. Keep pending changes, workspace mappings, basic undo history locally, etc.
Pros
Shelvesets: I love these, and wish support for them was brought to the local disk as well (think git stash)
Source control view in VS: It's pretty cool to be able to view the entire repository without downloading it. There are some usability issues, but the overall idea is cool.
Workspaces: yep, both places. While re-arranging a repo is odd, the ability to only download what you need is pretty awesome. I often wish I could choose a root folder and then check box the paths I need, but oh well.
Dislikes:
Using the history to figure out what has been done is cumbersome to say the least. You have to click on every single history entry to see what files were changed, and then you need to go through a context menu to get a diff.
Working while disconnected from the network is a big no-no. Ever heard of working on an airplane?
No Windows Explorer integration for when you work with files outside of VS (think TortoiseSVN).
Process methodologists (configuration managers) love to not allow shared check-outs. This is absolutely horrible for example for config files that you need to modify for testing.
SC gets confused with complex move/delete operations.
SC does not recognize when a checked out file has not changed. For example, service reference updates check out all related files and often regenerate the exact same content. These files should implicitly be removed from check-ins because they just add noise when you look at your changeset later.
Likes:
Shelving.
Anybody guessed which is my favorite SCM system? SVN + TortoiseSVN + VisualSVN :-)
Search functionality is not implemented in TFS 2010 ?
VSS we have search in file; TFS 2008 we have search file ...
Con: If you want to move multiple files to a subfolder of the existing location, you have to do that one at a time. Wow, that's horrible.
The lack of rollback has been my biggest pain point.
The lack of true rollback support and the inability to rename a TFS Project are my two main pet peeves with TFS. Other than that, I've been very happy with it for 2-3 years.
The fact that certain applications do not support in-edit changes from read-only to writable (forcing you to reopen the file in question) is annoying but is really a problem with those specific applications. The fact that a file is read-only while not checked out has certain uses, one of which being that it reminds you to check out the file. It does occasionally, however, lead to confusion when trying to get specific revisions of files. Writable files are not re-downloaded unless you enable a flag, because they're considered local edits.
Which version control system should I use for a Rails app: Git or SVN?
Here are some factors to consider:
I'm the sole developer
I'm familiar with SVN
I've only used Git for a week, it seems pretty similar to SVN really.
I want to put my repository on a remote location and connect to it via SSH or other protocol (which I already do with SVN).
Edit: Thanks for the responses so far. It seems like Git is slightly more favoured. Does it have any SSH functionality?
I'd say go for Git. Mostly because I'm biased, but also because you don't need to setup any sort of server with Git, you just git init and go. Git is generally just better, it provides more flexibility and power than SVN does.
Edit: This is a bit of a dupe of Why is Git better than Subversion, or at least relevant.
Edit2: Git has 3 primary methods of communication, the Git protocol, SSH and HTTP. Github uses SSH for "push access", e.g., git#github.com/user/repo.git.
As a single developer who is already familar with SVN - if you want to be as productive as possible use SVN.
If on the other hand you really want to learn GIT and can afford a bit more time to learn it, use GIT.
Use Git, if for no other reason than that you can use it almost exactly like SVN (including remote management of multiple branches over SSH) and it's much, much faster and more reliable. Local checkins and branches, distributed version control, revision history management, etc. are only side benefits.
In my experience the only reasons to prefer SVN over Git are: a legacy SVN repository, or the requirement to use Windows on the client.
I would have replied in comments but I can't, yet.
For those who don't know, Git work with Windows. If you don't like the msys's version, TortoiseGit is already usable.
Since you're solo and want to put it on a remote location: SVN, but you should learn/use Git as well. You could also combine the two, use Git locally and SVN for the remote..
It's probably a good idea to use some sort of version control. It's also probably a good idea to have remote backups of your code.
Git and svn are both good version control solutions and are both popular within the Ruby/Rails community.
If you were in a distributed development group I'd suggest git might be more appropriate since one of its specific design goals was for that situation.
If you were on Windows, I'd hint that TortoiseSVN probably provides a less challenging experience than, say, msysGit.
Mostly, though they both seem to do a similar job and do it well.
If you specifically want to learn a new source control system while building your project, go for git. Or if you intend spending a lot of time in, for example, edge Rails, which lives at Github, again might as well go for git.
Otherwise I'd say you should stick to svn.
If you have a day to learn Git, then learn Git. It has all the functionality that svn has, plus cheap branching/merging, local commits, and the option of distributed development.
It is easy to work with remote repositories. If you're just looking for some kind of public hosting, then you might want to look at Github, which has free public hosting, good Ruby integration, and many pretty graphs.
I'd say there's no particular difference.
Both systems are just tools, and both of them will provide you with with the functionality you're looking for. If there's no other parameters to consider, I'd say go with SVN as you already know it and you don't need time to learn it.
I'd add one follow-up question: are you working on this alone? The GUI tool support for Git is generally lagging that of Subversion, so if that is or might become a consideration, then I would opt for Subversion.
For example, if your designers use Adobe CS4, they can use its built-in Subversion support (and you don't have to teach them Git). So consider the current and future composition of your team as a factor in your decision-making.
I used to love git, but have recently switched to mercurial. It has exactly the same syntax as git, but is written in python, and has lots of nice bells and whistles out of the box, like a web server for visual tracking of commits.
I know that this can be set up for git using gitweb for example, but it requires a bit of work.