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/
Related
I am designing a branching & merging strategy for my project (We use TFS). Project has plans to have multiple released versions. Currently we are testing v1.0alpha and working in v2.0
The plan is:
After imminent green light from testers, version v1.0 will be released to one client.
Version v1.1 (already in dev) will be deployed to 5-6 clients
Version v1.2 would be installed to dozens of clients.
etc.
We will try to force upgrade of old clients to most recent versions but due to the nature of project and market it can be months (years?) for clients to upgrade.
We want to use standard gitflow but seems more appropriate for having a single version. I have designed a simplification of gitflow:
The approach is:
If a client wants a bug fixed, we will fix it in the Release branch of his version and he has to upgrade to the latest revision of his version. For example client in v1.0 that has a bug would have to upgrade to v1.0.5. If the bug happens in other versions we will fix it there.
If the client wants a new feature we will develop it in the latest version and force them to upgrade if they want it. For example client in v1.0.5 that wants new version will have to upgrade to v1.2
If all the clients of a given version upgrade we will delete that Release branch. For example when the client of v1.0 upgrades we will burminate v1.0 Release branch.
So my questions in order of importance are:
Will my approach work? Any problems that you can see?
Does git-flow have any pattern for this "multiple versions scenario"?
Gitflow has a Master branch. Is it ok not having a Master branch? Could we consider the different Release branches as "Master"?
How will you name Dev and Releases branches?
Your approach should work. There is nothing magical to GitFlow, and variations catering to your needs are fine. Git itself has no issues with a different workflow. A good example is Github flow, take a look at http://scottchacon.com/2011/08/31/github-flow.html .
A few things you could consider:
a) "Principle of least surprise": Try to keep as close to a standard as you can. That means you i) point devs to available documentation on the web instead of writing up everything ii) make it easier for new devs to enter or just work with your projects.
Thus, you should keep the master branch, not because it is needed - it is not, but because it might confuse people when it is not there, and you would have to explain that for years to come.
Branches in git is "just" names (well, a bit more, but you get my meaning), so the only reason to name them the same is convention - making it easy for people.
b) How many devs are working on the projects? If there are many, you could consider the Dev branch an integration branch, and use the master branch as the stable branch. Having a dev branch that you allow to be unstable might solve many issues with many devs. Two teams committing, one from feature and one from a hotfix, the build goes red, the teams blaming each other, the third team try to get out a new release branch, but can't. Having a stable, always green build master branch, which you even could protect with pull requests, is very nice, and makes for a more relaxed environment.
2) Basic Gitflow is centered around a release, so not quite. You have multiple releases at the same time. So you are nearly there, but standard tools, like [Jakob Ehn's] (https://github.com/jakobehn) Gitflow extention to Visual Studio - which is supergreat - will make you try to close a release before you are allowed to open a new one. Ask Jakob to relax that, and the tool will work for you. Otherwise, just follow the convention, but do it manually - that works too.
3) See point 1 above about master and why it might not be a good idea to not have it. But of course you can consider the release branches as kind of masters, but they don't really behave that way in your description. And if so, which one is the real master, the one you create feature branches from, and the one you regard as the latest? Having a stable master solves a lot of questions that pops up without.
4) Dev or Develop, then features should have a name of the feature as close to what it does as possible, like Dev/NewHelpPage, or Feature/NewHelpPage (to be closer to gitflow convention). Release branches, it looks like you already follow the semantic versioning (http://semver.org) principle, so why not use that: Release/V1.0, Release/V1.1 and so on. A hotfix branch is then Release/V1.0.1 .
Let the naming be so that devs easily understand what it is, preferably without needing to have to ask anyone around.
Keep it simple, follow conventions as far as you can, and it tends to work out. Git itself works for mostly any branching scheme.
[Edit]
Just had a quick chat with Jakob, and he said he had requests to support support-branches, which is probably what you are really after. He also pointed to this excellent post on different gitflow scenarios, at the bottom there is the flow for support-branches.
If I have files checked out and run an update later, I'll usually come across a conflict which gives me a few options to resolve. If I pick the 'keep local version' option, do my changes replace the server's version without updating the history?
Is there a reason why you would want an option to alter your source code so secretly?
Nothing changes until you check in the file and you will always have the history and annotations.
Typically unless you have a good reason not to you will want to merge conflicted non-binary files and use common sense when choosing whether to take an updated binary file or not. If it is a non-binary merge pretty much the only time you would keep local is if you specifically knew you didn't want the latest changes since you check the file out to make it in to your copy.
When merging, everything happens on your PC - nothing is checked in to the server.
You have three options:
Keep the server version. This is very much like an "undo checkout" and it overwrites your local copy with the server's version of the file so your local changes are lost.
Keep the local version. This ignores what is on the server and keeps the version on your PC, so your local changes are preserved.
Merge. This allows you to use a diff/merge process to pick and choose text lines from your source file and the server's source file, which allows you (a) to see exactly what has changed in both versions, and (b) decide what the final result should be (all the server's changes, all of your changes, or (usually) some hybrid mixture of both of them.
After you merge, if you have used either of the options that will alter your local copy, you really ought to rebuild your project and check that the changes introduced have not broken your code. You can then continue your work and check in when you are confident that everything is working.
The best approach to use with source control is to aim to make small self-contained modifications that you can check-in frequently (e.g. once or twice a day). Similarly (after checking that the net code is safe to take, e.g. with continuous integration), get the latest code fairly often (after every check-in, and preferably no less than once a day). This team strategy minimises the chance of your changes clashing with those of another developer and a merge being required. In the cases where a clash does occur, it is generally quick and easy to resolve because you are taking small bites of the code frequently, rather than working "offline" for weeks and waiting for thousands of changes to build up on the server. Merges are often complicated and difficult, so choosing strategies that minimise the need to merge can be a very beneficial approach.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I desperately need source control to manage projects between more than one developer.
A long time ago I used Visual Source Safe and it worked quite well.
What free substitutes can be recommended? I have the following basic requirements:
I need to host the repository on my own server.
I do not want extra clutter within my source files, like CVS does.
I need proper check in / check out, so that nobody can change a module until I've checked it back in.
I don't want / need source code merging / branching.
We use Delphi for web development, so many HTML files, images, SQL files, etc.
Any recommendations?
Git or Mercurial.
both are distributed and fast (each repository can act as 'server')
no extra clutter just one .git or .hg directory
you can pull changes from trusted or verified sources
I'll always recommend subversion with Visual SVN for server software and Tortoise SVN for the clients. You can exclusively check out files, so that nobody else can edit them, although that's not the default behavior. The only "clutter" it adds is a hidden .svn folder in every directory that is under version control.
If you insist on zero-clutter, and also free, you have limited choices. If you are open source, you can have a free copy of perforce. No clutter. SVN has clutter like CVS: a .something directory in each directory. git and hg just have one directory of clutter per clone.
If you absolutely insist on a checkout model, you have to give something up. P4 will do it, but none of the others will very well. Most people are more concerned these days with allowing disconnected operation than with a concept of locking. even svn lock only prevents checkin, not starting to modify.
There are other more obscure systems out there (e.g. arch) that you might look into.
I discourage the checkout/checkin approach. A decent version control system should be able to merge changes. This provides you with plenty of choices: CVS, SVN and Git.
As for "clutter" in your source files: I don't consider repository directories (e.g. .svn or .git) clutter, as this allows you to copy the repository structure.
Nevertheless, in SVN (not sure about Git) you can lock/unlock a file, basically mimicking the VSS checkout/checkin.
You should read a bit and learn a bit before you consign yourself and your fellow developers to living in the dark-ages of version control.
Visual Source Safe and the locking model of version control are dead. Most people have moved on. Those that have not are usually afraid of (or loathe) the idea of branching, and merging. Once they see that branching and merging can be easier, and more effective, then they can move onwards and upwards into a new world of version control options.
Ask yourself a few of these questions:
Would I like to separate the act of creating a new feature from the act of inflicting it on other developers, and on the final product (my live website)? If so, then I need branches. One branch = No effective version control.
Have I asked the other developers who will be working with me, what practices they find effective in multi-developer projects, and do they agree with me that locks are the way to go, or am I unilaterally enforcing my way of working with them? (You can have foo.pas for today, but try to get it checked in by 3 pm because I need to make a change to method bar inside foo.pas, later today.)
If I state that I want to make sure developers "avoid using old versions" do I have reasons for that other than that I hate or fear merging? Can we not think of any ways to prevent "using old versions"? Also, can we not think of any reasons when using old versions might be exactly what you have to do? If you used a non-locking tool like Subversion, why not say "please update before you commit". Then you will never have to merge, but if someone wishes to work with a non-changing version of the sources while developing the feature and then wishes to do the merging themselves, and you never have to merge yourself, you could insist that your work be done with locking (using subversion) but allow others the freedom to use a workflow that solves their problems, instead of yours.
Suppose (as you said in comments above) someone is removing something that you are in the act of creating. Wouldn't it be nice to see a complete list of his changes and say "I would like those changes gone, without removing other changes made by other people". This is known as working with "changesets" and is a key feature of DVCS like Mercurial (hg) and Git. In fact, the ability to prevent other people from modifying YOUR local repository willy-nilly, but rather making changes, which you can then review, and either accept or not accept will always be better at creating coherence on your (master) copy of the repository than any localized, centralized locking model can ever be.
W
You might like to investigate Team Coherence (http://www.teamcoherence.com). It doesn't create special folders and has a Delphi bent to it. For example, it groups .pas and .dfm files together by default. Help is excellent. It's also now free for a single license. I've been using it for years after previously using CVS and FreeVCS.
SourceGear's Vault is free for 1 user, and it gives you checkin/checkout plus merge-style operations. It also works totally clutter-free. I have been using it for some time and it works wonders. Transition from SourceSafe is especially easy, and integration with IDEs such as Visual Studio or Eclipse is very good.
Hmm, define "clutter" - to my mind a hidden directory per folder isn't clutter, frankly it hasn't been an issue at all (for reference, 7 years of first CVS then Subversion and prior to that VSS and something distributed the name of which eludes me).
Subversion is excellent and installation is almost trivial with VisualSVN server and use is straightforward with Tortoise as a client. Locking of files is an option, not a good one in the general instance but its there for binary files if you need it. This is probably the closest match to your criteria and I like it. A lot.
For personal use I'm playing with Mercurial - but not done enough to say more than that it works (and of course like most DVCS it fails your "lock" criteria). DVCS is different and has some issues.
If you have money, Vault (http://www.sourcegear.com) is worth a look - especially if you used and liked VSS since it started out as a "better" VSS though it has evolved somewhat. Worth visiting sourcegear just to read Erik Sink's thoughts on version control.
As for the rest, whilst I'm sympathetic to a wish not to (have to) merge stuff, writing off tagging and branching is pretty much the same as saying "I don't need version control" - it turns out not to be the case.
No one is recommending Bazaar, so here I am, I use it in my everyday work with Delphi projects.
It has a diff viewer that rocks, and that, for me at least, makes the difference with the other svn-like repositories.
I haven't used it for many years but I believe Jedi VCS meets all your criteria with the added bonus that it's written in Delphi and has some built-in smarts when it comes to handling dfm files.
We are using Fossil for source code managment of our Delphi programs.
It's very easy to use (if you like the KISS command line approach), and there is an internal web-based interface.
There is no installation needed, since it's only one executable to run. It's perfectly cross-platform: you can have your own repository on your Windows machine, then clone/synchronize it into any other server, running on Windows or Linux.
You can see our repository of Open Source Delphi programs hosted by Fossil on our web site. For internal work, I've found out that Fossil uses little bandwidth (much less than CVS or SVN), and is able to synchronize huge projects in a blitz, even via an ADSL or a 3G connection.
Here are some unique features, included in Fossil (with no third-party component to setup):
Bug Tracking And Wiki
Web Interface
Autosync
Self-Contained
Simple Networking - Fossil uses plain old HTTP
CGI Enabled - No server is required to use fossil.
Robust & Reliable
I would recommend Plastic SCM: http://www.plasticscm.com/
the best (?) merging and branching support!
but you can also use single branch + exclusive checkout (aka lock)
very nice and handy GUI
free up to 15 users
very good support (within a day, mostly within an hour!)
very modern, automatic merging and branching, distributed, etc
Delphi plugin available: http://code.google.com/p/plastic4delphi/