As stated in the title, my agency (also whole software department of my company) still use Visual SourceSafe 2005 as Version Control System.
My company is a hardware manufacturer for over 5 decades, and software development have started for nearly 2 decades. Just only my agency there are 30 developers, and the head office have even more devs. My agency VSS database is around 133 GB and the head office is more than 200 GB.
I've also skimmed through Google:
How do I convince my team to drop sourcesafe and move to SVN?
How to convince a company to switch their Source Control
Visual SourceSafe: Microsoft's Source Destruction System
Source Control: Anything But SourceSafe
etc.
I also know that extended support of VSS will end at July 11 2017. I also verified many things listed in the articles (lack of atomic checkins, poor branching/merging, binary files trouble, slow history, etc.). For example, I just status search through whole agency database (I can't check HQ since permissions):
55 "File names.dat maybe corrupt. Ask your SourceSafe administrator to run Analyse utility on this database."
5 "Error reading files."
1 "VSS/data/terqeaaa.b not found."
Is the situation of database bad? If it's right, then, how can I convince them to switch to other VCS? I need some reliable recently information and some evidence. The guide how to show/proof them is better.
I asked the admin to run Analyze but he ignored my words since I just started to work for a few months. People can see VSS basic weakness. They also complain "who check out this file?" and resolve conflicts by barehands. They have to use WinMerge to diff and compare, Get latest version instead of branching and checking out, never comment orsee history log, create entire new folder for new code, etc. However, they do not give up on SourceSafe. (They are using Visual Studio 2012 to develop and didn't notice Team Foundation Server).
I think you already summed up many of the reasons:
VSS is already in extended support and is only kept secure, but barely functioning. It's on life support in the palliative care ward. Extended support, in the real world means unsupported. Unless you have a very strong credit limit, Microsoft will not help you if it turns out you need the support.
VSS officially supports only the following operating systems, none of which are currently supported anymore:
Windows XP, Windows 2000, Windows NT 4.0 with SP6 or later, Windows Server 2003.
It hasn't has any improvements, fixes since 2008.
The Visual Studio and TFS documentation have been advocating the migration to TFS since 2008. There has been a full migration tool since 2012.
It has known issues with stability, internal consistency and corruption. A conscience administrator will need to spend regular time to ensure internal stability and consistency.
It doesn't support modern development workflows (transactional commits, distributed version control, modern branch/merge, cherry picking, optimistic locking etc).
It has a very limited security capacity, users with access to the share can simply grab the whole file share and force access.
It's not useful for remote access. Or at least requires VPN and a stable, very fast network connection. Even then it'll likely increase the chance for corruption.
The user experience in Visual Studio and other tools that directly support TFVC or Git is much, much better.
Cross platform support is non-existent. In the current market this is becoming more and more important.
The standard backup (archive) tool built-into the product has a limit of 2GB repositories.
Microsoft recommends at least weekly analysis of the sourcesafe database and recommends the logs and backups of the repo to be kept so corruptions can be manually be put back together by copying files from the backup back to the active share.
There is a supported migration path from VSS to TFS.
A migration to TFS brings more, ability for Continuous Integration, Release Management, Work Management (Agile tooling, backlogs), Test Management on top of a much more stable, performant and secure backend that makes use of the qualities of SQL Server for robustness, integrity and security.
Related
Different developers check in the code touching the same file or different branches could be getting merged. I am new to TFS from the admin side but I do know how to do basic check-in of the code. How can I avoid the code collision from admin side? We are using Microsoft Team foundation server as version control.
Version control systems are made to allow different users to edit the same files and so that when merging, it provides a reasonable experience upon merge. The ability to check out the same file by multiple developers is one of the things that allows teams to become highly productive. When multiple versions of the same product are being developed or maintained, it's impossible to prevent conflicts altogether.
There is a lot of additional guidance available through the ALM RAngers' guides. I highly recommend you and your developers read this.
Note:
Visual Studio 2013 offers a much better merge experience than older versions. 3rd party tools like Semantic Merge further improve the experience by parsing the code being merged and applying some additional intelligent logic to prevent conflicts.
For certain notoriously hard to merge files, like SSIS packages, there are additional specialist tools such as BIDS Helper Smart Diff.
Some things you can do:
Make sure developers communicate
Teams that do a daily scrum (stand-up meeting) or have the ability to use Team Rooms in TFS can signal intent and keep others up to date on what they're doing pro-actively. Making sure that there is a dedicated communication channel available and that the users have the Team Rooms extension installed in case they're not co-located. Communication prevents many of these type of issues and is the best solution once such a merge issue occurs.
Have developers perform a get-latest and check-in frequently
While there is no server setting for this, having your developers trained on branching, merging and general source control patterns can help a lot. If a user regularly checks for incoming changes (get latest) and checks in as soon as he is relatively confident about his code (say after the first test passes when using TDD), then chances of conflicts is substantially lower.
The Incoming Changes Lens
Codelens has been updated with a new Lens as one of the updates that was released after RTM. The lens requires both the Client and the Server to be upgraded to at least Update 2 and at least Visual Studio 2013 Ultimate Update 2. It's recommended that when you start applying the Updates, you always stay current, thus I'd recommend you install Update 4.
While Code Lens is an Ultimate feature, it will be moved into Professional with the release of Visual Studio 2015.
Use Exclusive Checkout
If users use the Checkout and lock option to check out a file, they can signal other users that the file is undergoing major changes. This feature requires that all users have their workspace type set to "Server Workspace". Local workspaces, given their disconnected nature, ignore the Lock flag. Though individual users can always override their workspace type, it is possible to set the default workspace type at the collection level.
Disable Merging and Multiple checkout for individual file types
A better solution is to mark file types that are hard to merge, the old style SSIS packages with lots of XML and GUIDs are agood candidate here. Open the Source Control settings and add the extensions of "bad files". This setting applies partially in Visual Studio regardless of the workspace setting (Visual Studio will only offer Take Local or Take Server and will not offer to merge.
Disable Multiple Checkout
It is possible to set the Project's Source Control option not allow "Multiple Checkouts", this will automatically acquire a Lock when a file is checked out. It's not recommended to turn this feature on, as it introduces a lot of frustrating things while working in Visual Studio (most importantly when adding any file, one has to acquire a lock on the project file). As with Exclusive Checkout, this requires all users to use Server Workspaces.
As this feature will prevent any file from being checked out by multiple people, it's often trying to apply way to much force to solve this issue. Only in case your developers mess up on a high frequency, you may enable this feature temporarily while they receive training.
Challenge:
We currently have 100+ vb6 applications. Our setup is that for every desktop server that we have (currently 20), those apps should be installed. So all in all, you can do the math. Users would then approach that server, or connect through RDC, and they will generate their reports there. Problems have already popped up, but the main reason the management now chose to upgrade is because we do not have VB6 dev't licenses anymore.
What we are currently using:
Visual Studio 2010 SP1 Professional
Microsoft Server 2008 R2 (For the deployment)
Oracle 11g (where the data are coming from)
The Question:
Given the cards we were dealt, I would like to seek a proper strategy in consolidating these decentralized reports. Right now, I'm suggesting we do MVC. However, I am not certain how it should be done in such a way that multiple developers can contribute in the development simultaneously. How/what will be the layers (DAL/BLL)?
We are new to this coming from a VB6 background. Thanks!
Well, not to rain on your parade, but questions like this always boil down to ROI (return on investment), and based on what you've said, your ROI is incredibly small. MVC is a good bet, since it's based on a pattern that all good applications should follow to a greater or lesser extent, but if you're stuck with VS2010, you won't be able to work with the latest and greatest versions of MVC/Web API/Entity Framework/etc. That means your brand spanking new app will already be out of date and rotting before you even kick it out the door.
If your organization is unwilling or unable to upgrade to at least VS2012 (but as long as you're doing that you might as well go all the way to 2013), so that you can utilize MVC5, Web API 2, and Entity Framework 6, then forego any new development and just do the bare minimum to make your current applications work. From a cost perspective it's just insane to go into new development on old, out-dated technology.
I currently work in a company that uses FogBugz for issue and bug tracking and SourceGear Vault for source control.
We are now introducing Team Foundation Server. Clearly TFS will replace Vault for source control. My question is, with the following requirements:
Large existing base of FogBugz cases (some obviously open) that we need to support ongoing
Support desk needs to be able to raise bugs / support calls
Want changes to source to be linked to a case number
... what is the best split between using FogBugz cases and TFS WorkItems?
Is it possible to totally migrate from FogBugz to TFS?
If it is not possible to migrate from FogBugz to TFS then what is the best way to use the FogBugz case and TFS workitems together?
Initially I'd say bugs and defects stay in FogBugz, stuff on the project plan as work items. You could manually get the developers to create a work item for each case in FogBugz and associate the code with that work item but I can hear the howls of derision already :-)
You might want to take a look at the TFS Integration platform. I don't know if there are any tools that link directly to FogBugz but these tools are highly extensible. You could then decide to either migrate everything in to TFS or run both systems and synchronise. Running both is nice as each discipline can use the tool they are most familiar with, devs use TFS for everything and the testers / support can continue to use Fogbugz and the toolkit keeps everything in step.
I am currently creating a business case for rolling out TFS 2010 as our source control and bug/release management tool.
We currently use OnTime for our bug tracking software and subversion for our SCM.
I was wondering what advantages TFS 2010 has over OnTime?
I have done some thinking so far and would love to hear responses:
TFS 2010 allows linking changesets->work items->builds
TFS 2010 provides greater customisation of workflow than OnTime
TFS 2010 is integrated into the Visual Studio IDE - This requires less apps to be open and less window flicking
Thanks in advance.
TFS is one of the least intuitive Version Control systems I have ever had the misfortune to have to use. It may have numerous "bullet point" advantages over OnTime (and other comparable systems), in terms of raw feature-lists and capabilities, but the key factor is whether it can fit in with your working processes.
My experience with TFS is that you will be required to adapt to the TFS way of working, because adapting TFS to your way of working will be impossible or too difficult to justify.
We recently reviewed a number of possible alternatives to replace a system comprising SVN and a manual bug-tracking system (Excel spreadsheets). On-Time was evaluated but deemed too expensive and complex.
In the end we opted to continue using SVN, but drastically revised (simplified) our repository structures and chose to combine SVN with the FogBugz issue tracking system. The integration between these two systems was fairly rudimentary "out-of-the-box", but required only a little effort on our part to achieve the much closer level of integration we desired. Certainly far LESS effort than my previous experience of a TFS roll-out involved.
Our SVN/FogBugz system is also now integrated with a FinalBuilder build automation suite.
The result is a system that not only fits our working practices perfectly (since we devised the means by which the systems would integrate to achieve that) but which is also infinitely adaptable as our working practices evolve.
I think that it really depends on the size of your team(s), and what you want out of source control.
I used bugzilla in combination with Perforce for a couple of years and found that both were really very good at their own individual things while working in a very small team (2-3 people), but the suffered from a lack of integration between them and from some little idiosyncrasies that took time to get used to.
I recently moved to a new job where TFS is used extensively. There are 4 main teams in this company with 10-12 developers in each, split into further project teams below that level, and it is in this kind of environment that TFS really shines imo. It's biggest advantages in my view are:
1) The integration with Visual Studio - it's not just a case of having less windows open, but it really does speed things up and make your life easier. Things like VS automatically checking out files for you as you work (no issues with accidental checkouts due to lockless editing), being able to synronise local + TFs builds, being able to quickly compare the local version against previous ones..yes you can get 3rd party plugins to integrate but none to this level and with the same stability.
2) The communication features - simple things like integraton with Live Messenger (provided you configure TFS correctly) are great for large teams. We use WLM to communicate accross the office and for collaboration as its just quicker than walking over to someone else every time you need to ask a quick question.
3) Linking builds/changelists to tasks - Yes other SCMs do this but again it's just done in a very nice, integrated fashion..I guess it's nothing special to TFS but personally I like how it tracks this.
4) Ease of merging/lockless editing. I've had experience with some other merge tools and the TFS one works nicely enough, making merging after concurrent editing pretty simple. It's very similar to perforce in this respect, but also with a usually pretty effective auto-merge tool which I use for tiny edits that I know cannot cause any potential issues with edits other developers are working on.
5) Auto building/build management. Working with a couple of large solutions containing 20-30 projects that depend on each other, this is a godsend. We have it set to queue up a build every 20 minutes IF something has changed, and when one has happened its listed in the history log..so easy to see when you need to update your local libraries.
I don't have any experience with configuring it other than build management, but I have heard that this is the worst part of TFS..that its a bit of a pain to get everything running correctly.
So, translating that to a business case..I'd say that if you are a Microsoft software house with large/multiple teams, then the time savings and productivity improvements that you will see as a result of the above features are worth the investment in setting it up. Its free to use in most cases as you will probably have a MSDN subscription (maybe some CAL issues but i'm not sure) so your biggest cost will be in user training and configuration.
Firstly, I would suggest to consider what is your primary concern, what is the problem that you are tying to solve by rolling out TFS.
In terms of version control I would recommend the blog post from Martin Fowler on Version Control Tools and a follow up results of a version control systems survey. Admittedly this might be and is a subjective view of the subject but one that seems to be pretty popular. TFS clearly looses in comparison to other Version Control Systems.
I currently work with TFS2008 and we have migrated from SourceSafe and IBM ClearCase/ClearQuest and there is no doubt that TFS is far better then any of the previous tool, still it has its serious shortcomings and the new version will only partially address those.
Addressing the individual point you have raised:
TFS allows to link builds with changesets and work items, but so many other systems
I have not used OnTime but the workflow customisation can be both an advantage and a hindrance. Potentially, there might be a lot of work involved in creating a custom process template and you would still need a sensible UI on top of it (Team Explorer or Web Access might not be sufficient)
Integration with Visual Studio is an advantage but there are add-ons to Visual Studio that allow integration with other source control providers
On the advantages of TFS I would probably mention
Distributed builds and separate build agents - if you do many builds
Full integration with Visual Studio via the Team Explorer
Extensive reporting infrastructure (though you can only take full advantage of it when using MSTest for all the testing)
SharePoint collaboration site for each project
Given the substantial cost of rolling out full TFS installation I would really consider what real business benefit would this solution give you that others don't.
Not shure about TFS, but the UI of OnTime is kind of non intuitive.
Also I dont like that you have different fields for Bugs and Tasks. Of course you can always add your own fields, but the default layout should be ready to use.
We endet up using only "Bugs" even if it is a task.
I dont say its a bad product, but if TFS has a better UI for bugtracking now (which it hadnt 4years ago when I had to use it and hated it ), then this would be an argument for TFS.
Sorry to hear that you want to get rid of SVN. Thats a hard decision.
I'm not sure about the licensing for the Axios OnTime but if you have an MSDN subscription then it's no additional cost. See the blog post here
I've been using TFS 2008 only for version control and while it's a nice upgrade from VSS some things that we're tyring to do aren't exactly in line with what is expected. That said, I've written a quick little web app that fills in those gaps. It was pretty easy to develop against using the API and there's lots of addons to help with specific tasks.
Probably not the answer you want to hear, but I'd be doing my damnedest to make a business case against TFS.
In any event, my general advice would be to try it out yourself (or in a small team) on some very small, but real project - maybe some tool you need on a once-off basis, code that can be thrown away or easily migrated to another system because it's small. There's nothing like actually using the system!
I have used OnTime and Subversion. I have not used TFS as bug tracker, but I've used it for source control. The source control part of it is basically still the bad old Visual SourceSafe. If you are currently using Subversion you will be swearing your head off any time you need to rename a file or, heaven forbid, delete a file and then create one with the same name - never mind any branching or merging. It's hard to convey in a post just how primitive and fragile it is as a source control system - that's why you really have to use it. You'll see what I mean when you find yourself stuck with a file you can neither check in nor delete and some meaningless error. Not that Subversion is perfect - but it's a decade ahead of VSS!
The workflow part of TFS, which I've only briefly played with, seems very "heavy" to me. That is, it really restricts the user to that workflow and requires a lot of steps that are often unnecessary. This stuff can help, but it can also just as easily get in the way. A good system provides the workflow when it's needed, but allows you to bypass it when it would just get in the way. When we used OnTime, we found that even its relatively unobtrusive workflow was often just more trouble than it was worth. Of course, this all depends on the specifics of your situation. How are you using OnTime workflows now and what do you want out of TFS that OnTime doesn't provide?
Linking changesets to bugs can be done with Subversion as well. It supports some extensibility mechanism - I don't remember the details, but FogBugz uses it (we switched to it after OnTime). Linking the to builds can be done by adding a simple svn tag command to your build script. Visual Studio integration can be done with VisualSVN.
The cost is also a huge downside of TFS. It is very expensive for what it does, especially when you take into account how well it does it. Yes, it's "free" if you have to have an MSDN subscription for every developer anyway - but do you have to, without TFS? Subversion is free, full stop. OnTime and FogBugz are far more reasonably priced.
I would strongly recommend against TFS. I once tried to restore the source code from a crashed instance, but I gave up after a few days, so source code was lost (= it failed to do the one thing a VCS should do). Of course, I might have done something wrong, but it's not easy to get everything right when the restore guide is two miles long, and it really is something that should happen so rarely that nobody is experienced with it.
Now I use Subversion/Trac, which gets the job done (and customizing the workflow in Trac is so easy it's not fun, compared to TFS).
For the time being, avoid TFS!
I would stick with SVN + FinalBuilder and then choose between FogBugz or CounterSoft Gemini.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Many people suggest to develop web applications in open source technologies.
And one of the reason is the cost involved in hosting and the licensing of software.
How costly can it be to build and deploy an application in asp.net mvc compared to any other open source technology?
I don't think they're talking about the time required to develop on the Microsoft stack. They're talking about the cost of:
tools (Visual Studio, Resharper);
operating systems (Windows Vista, Windows Server); and
databases (SQL Server 2005/2008).
And yes you could use Mono + Linux but that's a feature-incomplete implementation (at this point) and presents greater risk than the Microsoft-certified solution. Plus MonoDevelop isn't as good as Visual Studio. I think Mono is still fairly limited as a production option.
Microsoft has a program for startups (called BizSpark) that can effectively eliminate those costs for startups (less than $1m annual revenue iirc) but get beyond that and it can get real expensive. Based on some of Jeff's comments I have to wonder if Stackoverflow is deliberately staying below this level (by only accepting a certain amount of ad placements) to avoid this. Note: he hasn't said that. That's just a question that occurred to me.
But compare that to say a PHP or Java development stack:
Dev machine: Windows, Linux (free), Mac or whatever;
MySQL (Free) running on Linux;
Apache or nginx (both free);
etc.
That being said, the concept of using really cheap boxes, while popular, isn't universally better. You'll use a lot more power that way (compared to higher spec servers). And higher spec severs will tend to work out cheaper in commercial licensing costs than buying software for lots of cheap boxes. So you have to be careful in comparing commercial vs non-commercial solutions.
Take a look at Scaling Up vs. Scaling Out: Hidden Costs.
I don't want to get into the issue of the cost of development because there are too many factors to make any unqualified statements. Like any other stack, there are probably things it's good at and things it could be better at.
All the discussions here about cost assume that you're going to buy your own server (which is pretty much crazy for 99% of the world). Third-party hosting services are generally pretty cheap, and it doesn't matter whether you go for Microsoft or Linux or whatever. Let the hosting service deal with all that crap, and go with the stack that is easiest for you to use.
Unless you qualify for BizSpark or maybe the Empower program, you will need to buy licenses for Windows Server, SQL Server, Visual Studio, Windows 7 (or Vista, XP). For a startup that can be cost prohibitive.
That depends entirely on which Microsoft products you license for your project. For example, SQL Server 2008 Enterprise alone costs $24,000. If you can get by with the Express addition, however, it is free.
http://www.microsoft.com/sqlserver/2008/en/us/pricing.aspx
Then you need the OS (again several choices) and development tools (yet again more options at different prices).
Summary: If you are building a small app it is not very expensive. There are free versions of most parts of the stack except the OS. And if you are using a hosted solution, the OS cost is even hidden. If you are going large and doing it all yourself, it can be extremely expensive.
On a totally different side of the spectrum, check out the prices at GoDaddy.com for shared hosting (and there are probably other hosts as well). On the 7-buck-a-month plan you get ASP.NET v1.0/2.0/3.0/3.5 and two MS SQL databases. Serious devs will say, "who would use shared hosting?" but seriously, put some hosting up there and hit it hard. You will see that the response times are nice, app deployment is easy (but you do not get full control, so you have to use medium-trust security and other stuff), and you get 1,500 GB of monthly transfer and 150 GB of disk space.
So that's the full MS stack for $7 a month. Of course, everything is shared (even the MSSql instances), but for MANY apps it is a perfect solution. Shared hosting is a joke in certain cases, but colocated servers and all that stuff is a joke for many startups that have no particularly interesting technology needs.
For basic web apps they're strictly talking about Windows itself. Linux is free, so hosting is cheaper for Linux-based hosting than for Windows-based hosting. However, the entire Microsoft stack beyond the initial Windows license is completely free, so long as you stick with the "Express" flavors of all parts. SQL Server 2008 Express is more akin to a straight mySQL deployment than SQL Server 2008 Standard Edition is.
Download: MS Web Platform (free tools)
For enterprise applications, they're talking about the enterprise-class toolsets. SQL Server 2008 Standard or Enterprise edition costs thousands of dollars. Visual Studio 2008 Pro costs hundreds. However, if you're comparing to Linux, you really don't need any of that; anyone who needs that stuff is already working with the Microsoft stack at a heavy level anyway. The Express stack will get most people very far.
I don't know Microsoft's specific licensing policies (I can assume they are pretty reasonable), but I can tell you that developer tools are often more pricey than you'd imagine when you start licensing for your company.
Often when you start buying developer licenses for teams of, say, 20-50 you are starting to talk about millions of dollars up front costs. $100,000 per developer wouldn't be unheard of (not counting the often mandatory annual support fees which can double that number easily).
I wouldn't think this would happen with Microsoft because Microsoft developers are such a wide market, but I wouldn't be surprised if specific MS developer licenses for all your assorted tools--database, MSDN subscription, enterprise servers (which will probably be required by the database or something), ... got to be rather pricey once you started multiplying them by 20 - 50 seats.
If you want to use ASP.NET you need
IIS
A server with Windows (for IIS)
Visual Studio
A work station with Windows for Visual Studio
If you want to use PHP, Perl, Mono, Ruby... you need
A web server that supports the technology wanted. May be Apache, IIS...
An OS that supports your weberver
A workstation with any Linux, Window or mac
So if you chose to use an Open technology, you have the choice to work with what you want.
If you want to use .NET you have to work with Windows.