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 email@example.com
Once the user exists, you set the current user using:
vv whoami firstname.lastname@example.org
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:
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 clone http://localhost:8000/ .
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:
pulling from http://localhost:8000/
searching for changes
no changes found
pushing to http://localhost:8000/
searching for changes
no changes found
Pulling from http://localhost:8080/repos/corprepo:
Pushing to http://localhost:8080/repos/corprepo:
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.