# Friday, January 21, 2011

This blog post is a repurposing of content I created for a presentation I gave on DVCS on 01-11-2011 to the Twin Cities Developer Group.

...

What is DVCS?

Source code version control without a central master server repository (think peer to peer).

Market leaders: git, hg / Mercurial

New competitor with potential: SourceGear Veracity

http://en.wikipedia.org/wiki/Distributed_revision_control

...

Is DVCS better than non-distributed source control (aka Subversion/SVN, VSS, TFS, etc.)?

Usually, yes, but there are exceptions.  Don't underestimate the learning curve.

http://stackoverflow.com/questions/111031/comparison-between-centralized-and-distributed-version-control-systems

...

What are the Disadvantages of DVCS?

Lack of mature graphical front ends (although people seem okay with TortoiseHg/TortoiseGit), the majority of DVCS users appear to use the command line.

The learning curve for DVCS is different.

There are different complexities like workflow & backup process creation.

Many people struggle with the concept of "no canonical master".

Large binary files don't work well in a DVCS where everyone has a local copy of basically the entirety of every version of every binary file.

There are currently tools to migrate to DVCS, but not necessarily tools to migrate away from DVCS.

...

Advantages of DVCS – Better Implementation

What could non-distributed version controls systems do better to compete with DVCS?

  • Implement better merging
  • Implement better handling of versioning directories

What are some of the reasons that merging is better in DVCS?

  • Change sets
  • Likely more version history available to work with since smaller check-ins are better supported
  • Better ancestor tracking/usage
  • Better directory revision management
  • Better file rename detection

The battle is not DVCS (git/hg) vs. SVN, but that is how it is often characterized.  SVN is lacking in some areas compared to it's (sometimes commercial, sometimes more mature) non-distributed version control competitors.

...

Advantages of DVCS – Better Design

What can’t non-distributed version controls systems do?

  • Working "offline" (faster history access, faster commits)
  • Better experience working peer to peer for integration testing
  • QA can manage their own repository
  • Can commit a logical unit of work without tests passing or the code even compiling

...

DVCS Trends

Where is DVCS catching up?

  • GUIs
  • ALM integration
  • Hard locks
  • User/role permissions
  • Centralized admin, etc.

DVCS in corporations is very interesting to me personally and Veracity will likely solve those problems better than git/hg ever will since they are primarily targeted at open source projects, not corporate/enterprise environments.

Obstacles to an enterprise DVCS - http://www.ericsink.com/articles/vcs_trends.html

...

Some differences between Mercurial and Veracity

http://www.capprime.com/software_development_weblog/2011/01/20/SourceGearVeracityMercurialLookupChart.aspx

Friday, January 21, 2011 2:58:14 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, January 20, 2011

Please note: The following information is specific to the 01-19-2011 Veracity nightly build (version 0.5.5.10370).  I may come back from time to time as the Veracity command API solidifies to update this to newer and more accurate information.


SourceGear Veracity tends to be more like Mercurial / hg than like git.  There is a ton of documentation on Mercurial, but not much available for Veracity at the moment.

While learning Veracity, I often found myself reading docs for Mercurial and then figuring out how Veracity was different through trial and error.

This blog posts contains my notes on some of the things I've learned.

It's often possible to replace an hg command one for one with a vv command (i.e. hg status ~= vv status) and the results will be meaningfully similar if not exactly the same.

...

Generally, step one is to create your repo.  In Mercurial, this is done by creating a new directory and executing "hg init" within that directory.  For Veracity, you do the same basic thing, but you also need to give the repo a name as a parameter to init:

vv init repo1

After initializing a repository, the first logical step is to setup your user.  In Mercurial, this is done by creating an .hgrc file in the appropriate location.  In Veracity, you must first create the user if they don't yet exist (use "vv users" to show existing users) using:

vv createuser myemail@example.com

Once the user exists, you set the current user using:

vv whoami myemail@example.com

You can use "vv whoami" at any time to see who Veracity thinks you currently are.

...

Once you have a repository, you can startup a web server to view the repository (although there obviously won't be much to look at if you just initialized it).  For Mercurial, this is simply:

hg serve

For Veracity, the "vv serve" command requires you first run "vv localsettings set server/files <path>" to provide a path to the website files.  I suspect Mercurial does not need this "set server files" step because the installer takes care of setting this path somehow.

...

The status command works the same, but the output is visibly different (git's output is visibly different for the status command as well).

...

The add command requires a file or directory name in Veracity, whereas Mercurial will add all files if you don't specify a parameter.

Like Mercurial (and unlike git), you only need to use the add command on new files (modified existing files are automatically part of the change set by default).

...

The commit command works similarly, although hg has a nice feature where it will pop up an editor to provide a commit comment while Veracity works more like git in that you provide the commit message with a command line parameter (which is also possible with hg).

...

A basic no parameter diff works very similarly between Veracity and Mercurial.

...

The branch and branches commands with no parameters work exactly the same.

Creating a new branch in Veracity requires adding a "--new" parameter (Mercurial doesn't need/use "--new"):

vv branch branch_name_here --new

One interesting branching difference is that the default branch in Mercurial is named "default", but in Veracity (as well as git), the default branch is named "master".

...

To switch branches in Veracity, you use the branch or update (with -b parameter before the branch name) command.

vv update -b master -aka- vv branch master
vv update -b branch1 -aka- vv branch branch1

To switch branches in hg, you use the update or checkout command.

hg update default
hg update branch1

(To switch branches in git, you use the checkout command.)

...

Cloning a repository from a web server is different.

hg:

hg clone http://localhost:8000/ .

Veracity:

vv clone http://localhost:8080/repos/corprepo localdevrepo
vv checkout localdevrepo

...

Pushing and pulling from a repository is basically the same in the no parameter scenario:

>hg pull
pulling from http://localhost:8000/
searching for changes
no changes found

>hg push
pushing to http://localhost:8000/
searching for changes
no changes found

>vv pull
Pulling from http://localhost:8080/repos/corprepo:
Retrieving dagnodes...done
Retrieving blobs...done
Committing changes...done
Merging databases...done

>vv push
Pushing to http://localhost:8080/repos/corprepo:
Sending dagnodes...done
Sending blobs...done
Committing changes...done
Cleaning up...done

Veracity currently only supports pushing and pulling from a cloned repo to it's "parent", but SourceGear is actively working on enhancements in this area.

Thursday, January 20, 2011 6:11:41 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  |