13. Version Control in ADS (Revision #0)

Version Control

Aqua Data Studio's Version Control Clients offer a consistent user interface to Subversion (SVN) , Concurrent Versions System (CVS), Perforce and Git. The Files Browser and its contained mounts are the location for most of Aqua Data Studio's version control operations, graphically indicating which files are up to date, out of date, conflicted or unversioned. Repository Browsers for Subversion (SVN), Concurrent Versions System (CVS), Perforce and Git provide fine-grained views of directory and file histories, and include comparison tools to show the differences between versions, filtering of Revisions, Branches, Tags and HEADS with a complete history for every item.

Aqua Data Studio's interface for version control clients includes update, commit, delete, refresh, version control delete (delete from repository) and version control add (add to repository).

For an explanation of how the Files Browser displays version control status, see the screenshot and discussion in the Files Browser page within the Workspace and Docking Framework section.

Click here for full documentation on Aqua Data Studio's CVS Client.

Click here for full documentation on Aqua Data Studio's Subversion (SVN) Client.

Click here for full documentation on Aqua Data Studio's Perforce Client.

Click here for full documentation on Aqua Data Studio's Git Client.

Version Control Integration within Aqua Data Studio

All of the Editors (SQL, HTML, XML, Text, JavaScript, Java) within Aqua Data Studio incorporate in-line difference indicators for files that are part of a repository. As files are edited, indicators instantly mark where edits create differences with the local working copy.

Integration of version control clients includes versioning of mounted scripts directories for database connections in the Schema Browser. When a scripts directory has been configured for a database server connection and included in a version control repository, its contents can provide multiple users an update to a common set of sql scripts and queries.

Branching and Tagging

Branches and Tags can be created, edited and viewed in Aqua Data Studio's CVS and SVN clients. Version Control menus allow for branch and tag creation from within the Files Browser. CVS and SVN implement branching and tagging differently, so each of the repository browsers indicate them in different ways. The CVS repository browser marks branches with a forked path icon. The SVN repository browser does not place any special icons on branches.

CVS and Subversion

The interfaces for Aqua Data Studio's Version Control Clients do vary slightly for CVS and Subversion (SVN) based on the differences between the two version control systems.

What is the difference between CVS and Subversion?

Revision Numbers

• Revision numbers are by file within CVS. CVS employs RCS (Revision Control System) as a backend, and each file has a matching RCS file within the repository. The repository is generally organized according to the structure of a user’s project tree.


• Subversion repositories appear as a single filesystem. Each commit generates a completely new filesystem tree, so the repository can be compared to an array of trees. Revision 57 would refer to a particular tree, which is the way the filesystem appeared after the 57th commit.


• In CVS, you may talk about ’revision 9 of source.d.’ In Subversion, you would say ’source.d as it appears in revision 9.’ In CVS, revisions 8 and 8 of source.d are always different. In Subversion, it’s quite likely that source.d was not changed between revisions 8 and 9.

Commits

• In Subversion, commits are atomic - they all happen at once or none do. The entire change is applied (or rolled back) and is only visible to other users once finished.


• In CVS, a commit alters each file sequentially until it is done. This can cause problems. If a network connection dies in the midst of a commit, this can set the CVS repository partially changed, and often corrupted and unstable. If a user updates their working copy during the commit of someone esle’s change, they could end up with a partial commit from the CVS server.

Handling of Binary Files

• In CVS, each revision of a binary file is stored individually, which can use a lot of storage. In Subversion, all files are stored as binary and a very efficient binary diff algorithm (Vdelta) computes the differences between them. Multiple versions of binary files take up much less space than when using CVS.

Directories

• In Subversion, directories are versioned, just like files. Subversion stores the state of files in a repository, which tracks the history of both files and directories. CVS is unable to track history for a directory.

Renaming Files

$ mv myfile1 myfile2$ cvs remove myfile1$ cvs add myfile2$ cvs commit

$ svn move myfile1 myfile2$ svn commit

Here, the common history of myfile1 and myfile2 is kept.

• CVS does not support the direct renaming of repository files, and cannot trace version history of files that have been renamed.
  To rename a file in CVS, you are forced to do the following:
• The new myfile2 has no record or indication of a common history with the old myfile1 (now in the Attic).
• SVN’s move command can be used to rename files.

Metadata

• Properties support is a Subversion feature allowing users to append metadata to any versionable object within a repository. This can include things such as mime type, whether the file is executable or not, etc.

Branching and Tagging

• In CVS, branching and tagging are extremely processor intensive for large repositories. Their processing is proportional to the number of files being branched or tagged.
• Subversion makes both branching and tagging constant time operations. It doesn’t differentiate between filesystem space and ’branch’ space. Branches and tags are just directories within the filesystem. Branches and tags are created by copying the directory you are tagging.