SVN & TFS

[Mohammed Hameed]

I didnt say it is not for Developers. I mean TFS should be preferably used by Build engineers because of its features.

Explore.Code.Experiment.Excel!!! --------------------------------------------------------- My blog - My recent article

[Mohammed Hameed]

Thank Mark. I also have similar experience for TFS & SVN as yours.

Explore.Code.Experiment.Excel!!! --------------------------------------------------------- My blog - My recent article

[Mohammed Hameed]

Did it mean all the options/features available in TFS is also available in SVN?

Explore.Code.Experiment.Excel!!! --------------------------------------------------------- My blog - My recent article

[sir_download_alot]

Agree!

[Fabio Franco]

I've been branching with SVN for several years now with no major problems, unlike TFS that the few times I used branching, caused major headaches and code break outs.

To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

[Steve Naidamast]

I have used SVN, TFS, Mercurial, VSS (and I agree, completely terrible) and IBM's Mercury over the many years I have been in the IT profession. Whatever failings or drawbacks SVN may have, one area in which it really shines where the others don't, with the exception of Mercurial, is that it is completely invisible for use by small teams. You update your code-base in the morning and commit your updates at night letting SVN figure out the complexities of merging many user updates to the same modules at the same time. And all of this can be done through the Explorer plugin, "TortoiseSVN". No mess, no fuss. True there are issues with SVN but there are issues with all SCM systems. Think TFS is better? Try changing the name of your project and storing it in the same place...

Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com

[Stefan_Lang]

It used to be difficult to keep track of which versions you already had merged to a branch and which not, but since about 2 years SVN keeps track of that information for you: i. e. once you wish to merge back to head you can just merge the entire history since you branched and SVN will prevent any duplicate merges! If there are any other issues regarding branching (that other VCSs don't share) I am not aware of them.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Lost User]

NO, I think TFS has a load more features, but you need to look at what you want or need - it's not worth spending money and additional time to learn to use features you don't need

MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')

[Br Bill]

TFS is only for Build/Deployment engineers who can live with easy and simple canned functionality. My experience using it for build/deployment was miserable because we didn't fit the cookie-cutter methodology MS provided. I absolutely hate TFS.

[DarkChuky CR]

It just how you use it.... Both can be used just like a a sharepoint, just to store your files and have a single changeset-checkin id ot track changes... If you only care about storage and share SNV could be the best option, cause you don't need to install Visual Studio to access it.... but then the integraton with your Development IDE can be a pain. If you want to have more tracking, tickets and better contront on version and branches it's better to use TFS, it integrates all in one single IDE, ok you can add third party solution to your SVN and get the same but then you need to maintain 2 products.... So, both are good, at the end it's it just how you use and what can you pay for... (SVN with Trac is beautiful)