|
Ok, I'm very glad 
|
|
|
|
|
SVN is to Developers | TFS is to Build/Deployment Engineers!
Do you Agree?
Please share your thoughts...
|
|
|
|
|
I do not agree. Subversion is not appropriate for code development at all.
TFS is somewhat more appropriate.
|
|
|
|
|
SVN is appropriate for development. At least, it is so invisible and does its job so I can concentrate on development.
Nuclear launch detected
|
|
|
|
|
|
I am using branches. I know it's not the state of art of branching as in git (where I hear you need a dedicated guy to do merges), but I also prefer to merge rarely and not spend my life in console. I know what's mercurial and git (not much), but svn is - for me, as part of both a small team and large teams - the right tool for the job.
Nuclear launch detected
|
|
|
|
|
Branches aren't exactly the easiest to deal with in SVN, but after you do it a few times it's not all that bad.
|
|
|
|
|
Having used version control systems that did branching right and witnessing all the problems with SVN branching, to me it's bad enough to never use SVN if I have a say.
|
|
|
|
|
|
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
|
|
|
|
|
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)
|
|
|
|
|
I disagree. More like:
SVN is to Developers | TFS is to Project Management, Developers, Build/Deployment Engineers
/ravi
|
|
|
|
|
Thanks Ravi.
That's short but good answer.
|
|
|
|
|
|
Mohammed Hameed wrote: TFS is to Build/Deployment Engineers!
Why not developers? I use TFS for source control, so why is it not for me as a developer?
|
|
|
|
|
I didnt say it is not for Developers.
I mean TFS should be preferably used by Build engineers because of its features.
|
|
|
|
|
No: used TFS as a developer for a few years and it does a good job. Used Subversion in the past and it was fiddly and unpredictable so perfectly suited for white board project managers.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Thank Mark.
I also have similar experience for TFS & SVN as yours.
|
|
|
|
|
SVN is to people with modest hardware available | TFS is to people with money
Assuming self hosting, anyway.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
Did it mean all the options/features available in TFS is also available in SVN?
|
|
|
|
|
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')
|
|
|
|
|
After managing TFS (while doing lots of coding as well) I switched over to SVN when I started working at a new company. I have to say I that I much prefer TFS. In SVNs defence, I have very little working experience with it. Having said that, I found that TFS is a full ALM solution which made collaboration and deployments much, much easier than anything else I've used.
My plan is to live forever ... so far so good
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
