I've built Veracity, now what?
You've had a succesful build, the vv command is in your path,
and you'd like to actually do something. Let's get you
started with a local repository, then see what it takes to
push, pull and merge with others.
Creating a repository
Choose your favorite projects folder, or temp, or whatever. Let's
say you've chosen ~/projects. Now create a vvtest working copy
under that:
cd ~/projects
mkdir vvtest
cd vvtest
vv init vvtestrepo
Two things happened: a vvtestrepo repository was created, and
your current directory (~/projects/vvtest) became a working
copy of that repository. The repository, and the folder, are empty
right now.
Who am I?
We should tell Veracity who you are. Run
vv whoami --create myemail@example.com
The --create flag will try to create the user first, so you will only need to use that flag the first time you run whoami.
Adding some stuff
Let's give Veracity something to do. Create a file:
echo Hello, world > file.txt
Then say
vv status
and you should see
Found: @/file.txt
"Found" means Veracity sees a file it doesn't yet know about. "@/" is the root of the repository. To tell Veracity to keep track of this file:
vv add file.txt
vv status will now say:
Added: @/file.txt
Let's commit that to the repository, so we can play with it a bit.
vv commit -m"I added a file"
Where -m="..." is the comment that will be associated with this checkin.
Things we can now do:
vv rename file.txt somethingelse.txt
vv move file.txt someotherdir/
vv remove file.txt
All of which must be followed by a vv commit to be recorded. Prior to
that, vv revert can undo your changes.
If you change the file on disk, e.g.
echo Another line >> file.txt
vv status will list it as "Modified". You can see the changes by saying vv diff file.txt for one file, or just vv diff to see all uncommitted
file changes.
Running the server
So far, this is all local. To share your code and changes with others, you'll need to run a server, or connect to someone else's. For now, you'll be the server.
The first thing you'll need to do is tell Veracity where to find its collateral files (stylesheets, javascript, HTML templates, etc.).
If you unpacked the source according to the BUILD documentation, your collateral files live in `~/v/veracity/src/server_files.
Let's say your home directory (~) is really /home/someguy. You'll want to
do the following:
vv localsettings set server/files /home/someguy/v/veracity/src/server_files
Now, still in your vvtest directory, run:
vv serve
Veracity's internal web server is up and running on Port 8080. Open a browser (not IE, just yet, but Chrome, Safari, Firefox should work nicely) and you can see your history, add work items, and so on.
Playing with Others
What you can also do is push and pull code through this server.
Assuming the machine you've been using is vvhost, move over to vvclient.
On the client, to get a working copy of that same code:
cd ~/projects/
vv clone http://vvhost:8080/repos/vvtestrepo
vv checkout vvtestrepo vvtest
cd vvtest
And you're in a working copy of a clone of the original repo.
Make your own local changes, commit them, then:
vv push
to send them back to the host. If you see an error complaining that this would create multiple heads, that means there are changes on the host side that you haven't pulled yet. Get those, merge them locally, then push. Actually, it's a better idea to always pull, merge, run unit tests, and commit the merge before pushing.
vv pull
vv merge
# test, test, test
vv commit -m"merged changes from host"
vv push