CODEWITHSUNDEEP
svnversion-controltfs
Machado
Machado

Reputation: 741

From source-control perspective, how does TFS operations compare to SVN?

From the source-control perspective, what are the real differences between TFS and SVN for the user ?

For example: On SVN we have the basic commands:

And each file has its own revision number.

Does TFS have those commands as well ? Each file has its own revision number ?

Please answer only from source-control perspective. Bug tracking, ALM and pricing are not at stake on this question.

Upvotes: 2

Views: 405

Answers (2)

mliebelt
mliebelt

Reputation: 15525

THe main difference in my opinion is, that Subversion supports (only) a real optimistic locking strategy, that means you normally work in parallel with each other, and the second (and later ones) have to merge their changes to the ones of the others.

In TFS you have to first checkout, that means, reserve the file for your changes, to do any work. This leads to a more pessimistic locking strategy.

And yes, one big difference is, that working offline is not an option with TFS, and perfectly supported by Subversion.

TFS has in my opinion better support for branching and merging (at least the UI helps a lot here).

TFS and Subversion have different terms with similar meanings when committing / checking in. (The following comes from a co-worker which has worked with both tools.)

Def: Revision: An svn commit operation publishes changes to any number of files and directories as a single atomic transaction -> http://svnbook.red-bean.com/

Def: ChangeSet: A changeset is a logical container in which Team Foundation stores everything related to a single check-in operation, specifically: file and folder revisions -> http://msdn.microsoft.com/en-us/library/ms181408%28v=vs.80%29.aspx

During CheckIn every File is associated with the CheckIn Number (counted up as in Subversion). If you browse the history of a folder / file you can see the history as a table with columns: changeSet Numbers / date / comment A nice feature from my point of view is the @Annotate function. With this function you can see the changesets of one file on LOC level (line 2-5 was changed by changset 2 "Adding logging, line 10 was changed by changset 5 "Check for null values" ;-) )

Upvotes: 2

ChrisLively
ChrisLively

Reputation: 88064

The commands you listed are supported by ALL source control systems as they are the absolute minimum any SC must have to even be considered functional.

There are really only a couple things to consider when deciding between them, most of which were explicitly excluded in your question...

Point is, if you boiled TFS down to just a source control system then the differences are negligible. FYI, I've used both extensively (over 5 years each) and currently only use TFS due to the additional features that are wrapped up into a single package.

Upvotes: 0

Related Questions