Subversion vs. Source Safe [VSS vs SVN]

Published Tuesday, November 13, 2007 3:08 PM

i couldn't beleive that there's anyone still using source safe, anyway here's the comparison

Visual source Safe [VSS]   SubVersion [SVN]
  • Commits are not atomic.
  • Renames Affects the whole history
  • only supports locked checkouts 
  • permissiona are supported but anyone can access shares and mess up files.
  • smallest commit block is a file
  • works only on windows shares making hard to go through routers
  • works only on windows
  • proprietry
 
  • Commits are atomic.
  • Renames are supported.
  • Shared checkouts are defaault but supports locking
  • permissions are assignable to granualar level of folders
  • a line is the smallest commit block
  • supports share http,https using apache
  • works on windows, linux, unix, and even macs and also java which makes it ultimaly portable
  • open source (Apache/BSD-style license.)

 

by amir.magdy
Filed under: ,

Comments

# Lahzy said on Thursday, November 15, 2007 8:10 AM

So what r u using at work !!!

# amir.magdy said on Thursday, November 15, 2007 8:18 AM

i have been using SVN for the past 2 years

now that i moved to a new company i am helping the transition :D

# Mahmoud Kassem said on Friday, November 16, 2007 4:44 PM

Give Distributed/Decentralized VCS like Mercurial (Hg) a try. More projects are moving to DVCS solutions. Mozilla moved from SVN to Hg.

With DVCS you can have your own local repositories and commits with no server installation.

You can commit without connectivity, then you push your work to a central location when you are ready.

# amir.magdy said on Saturday, November 17, 2007 2:02 AM

i don't know about that, how does conflicts gets managed in this case?

# Mahmoud Kassem said on Saturday, November 17, 2007 8:51 AM

In a Decentralized SCM (Source Code Management) you can merge repositories easily, It is not a single repository, everyone has own local repository. Push, pull, merge and commit to others.

There is no central/server repository, the central repository is the repository that you choose to let everyone push and commit to at the end of the job. In this comment it is named the team repository.

** see: http://hgbook.red-bean.com/hgbookch3.html">hgbook.red-bean.com/hgbookch3.html

to understand merges/conflicts in Hg

Doing merges locally is faster, safer and then pushing and committing to the team repository keeping it without conflicts.

* You can commit as much as you want locally (without a network connection), create or clone as much repositories as you like.

* You can work and commit from anywhere (commit to local repository). Commit unstable, untested and buggy code. Just push and commit to the team repository when you are ready to share it.

Of course you can imagine how much you can benefit from a distributed SCM. Once you use them, you should never go back to a centralized SCM. Especially not SVN.

** SVN merging of branches that does not work properly, because subversion does not keep track of conflicts yet which were already resolved when the trunk got merged into the branch. Thus many conflicts will reappear when you merge again

ref: mr.uue.org/.../20070506-2338JST

** Mercurial Links:

Hg: www.selenic.com/.../wiki

Hg Book: http://hgbook.red-bean.com

# amir.magdy said on Saturday, November 17, 2007 9:08 AM

well that's a lot of things to check i will follow up on that research

but i think for commercial non open source model centralized is still the best way to go

i am still waiting on the video by linus on git to download so i can read it

Leave a Comment

(required) 
(required) 
(optional)
(required)