File Handling by Source Control

What are the files that needs to be check in VSS for better handling of files when we do development. There are many file types and are stored and updated internally for each developer based on their own settings. So in other words these files doesn’t need to be part of Source control system. Here are the list of file types that we might need to look in as developer

You can add the following files to Visual Studio source control:

• Solution files (*.sln).

• Project files, for example, *.csproj, *.vbproj files.

• Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.

But the Files that you cannot add to source control include the following:

• Solution user option files (*.suo).

• Project user option files, for example, *.csproj.user, *.vbproj.user files.

• Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.

• Build output files, for example, *.dll and *.exe files.

For more information

FSFS vs BDB

FSFS and BDB are Subversion file system implementations. Traditionally Berkeley DB (BDB) was the standard file system used by Subversion. It solves many serious concerns with BDB such as data corruption and added improvements such as smaller space requirements. Now the FSFS is the standard, the default setting, and recommended by Subversion developers.

How FSFS is Better

• Write access not required for read operations
• Little or no need for recovery
• Smaller repositories
• Platform-independent
• Can host on network file system
• No unmask issues
• Standard backup software
• Can split up repository across multiple spools
• More easily understood repository layout
• Faster handling of directories with many files
• (Fine point) Fast "svn log -v" over big revisions
• (Marginal) Can give insert-only access to revs subdir for commits

How FSFS is Worse

• More server work for head checkout
• Finalization delay
• Lower commit throughput
• Immature code
• Big directories full of revision files
• (Developers) More difficult to index
  

SVN and SVN Repository

Subversion (SVN) is a very popular open source versioning system. It manages files, directories, and changes made to files and directories over time by single of multiple users

SVN is a client-server application where the SVN repository serves the tasks of a server. It is a central storage place which stores information in the form of a file system tree. Users share data by reading and writing to the repository. The repository keeps track of all changes written to the file i.e. modifications to the files, file contents, and directory structure. Users see the latest version of the file system by default but they can view every change ever make to the contents of the repository.

A decade ago Concurrent Versioning System (CVS) was the most-widely used versioning. It is built on Revision Control System (RCS) and thus inherits its flaws and this inheritance is precisely the reason it is very difficult to fix these flaws in CVS. SVN was created to overcome the flaws of CVS. It offers all the benefits of CVS without its flaws.

Although SVN is primarily used by programmer to track their project, it is capable of managing any sort of file collection. Important features of SVN are:

• users can store ongoing work (code, docs, data, etc.) in a central repository
• users can access the latest versions in the central repository
• automates the process of updating local working copy of the project with modifications made by others?
• users can track all changes ever made and revert to previous versions

Following are some important features which make SVN a better choice over CVS.

• Subversion versions entire trees i.e directories, renames, and file metadata
• changes are atomic. If you commit files a.aspx and b.aspx.cs, either both will be updated or neither will be updated
• tagging and branching are not resource intensive
• Subversion is designed as a client/server application