NAME
tor - The One Ring to manage all other version control systems
SYNOPSIS
# cd svn_repository_checkout
# tor update
# tor diff
# tor commit -m "woot"
# cd cvs_repository_checkout
# tor update
# tor diff
# tor commit -m "woot"
# cd git_repository_checkout
# tor update
# tor diff
# tor commit -m "woot"
# cd svk_repository_checkout
# tor update
# tor diff
# tor commit -m "woot"
DESCRIPTION
If you're a developer of multiple projects like me, you'll find yourself needing to switch between multiple different Version Control Systems (VCSs). After I've worked on one project using, say, SVN for an hour I may need to switch to a different one that's using, say, git. That's where I start beating my head on a wall.
Not because I dislike either system; I actually like both of those. It's because my mind thinks "check that in" and then my fingers have already started typing "svn commit ..." instead of using "git". It's just habit. The VCS should be getting out of my way, but because there are so many it just got in my way. I can't work on auto-pilot because different projects need different VCSes.
95% plus percent of your version control operations are the simple ones: modify, diff, commit, update, status, info, etc. It's actually fairly rare that you need to dive into the more advanced operations. Thus, I thought, why can't I have a system that automatically figures out what sort of checkout path I'm in and invoke the right command for me. Better yet, they can merge the common features of them all and do translations to the oddballs when necessary (for example, -N in many systems means "non-recursive" but in CVS it's "-l" (of course)).
Hence, The One Ring was forged. And it was good (not evil).
tor is the command line application that is a wrapper around SVN, SVK, CVS and GIT (currently just these 4; others are easy to add). Internally most of the work is done by the TheOneRing perl module which does the brute force of the work (which is really driving the slave modules appropriately).
MAIN OPTIONS
The main options must go before the version control command to be processed.
SUPPORTED COMMANDS
The following are the currently supported commands that tor understands and can convert from one system to the next. Their individual options are shown as well. The individual options must go after the command.
info
remove
add
status
annotate
- -r STRING
- --revision=STRING
-
Revision to update to
- -N
- --non-recursive
-
Don't decend into subdirectiories
commit
- -m STRING
- --message=STRING
- --msg=STRING
-
Commit message
- -N
- --non-recursive
-
Don't decend into subdirectiories
- -q
- --quiet
-
Update quietly as possible
revert
diff
- -r STRING
- --revision=STRING
- --msg=STRING
-
Revision to diff against
- -N
- --non-recursive
-
Don't decend into subdirectiories
log
- -r STRING
- --revision=STRING
-
Revision to update to
- -N
- --non-recursive
-
Don't decend into subdirectiories
- -q
- --quiet
-
Quiet output
export
update
- -r STRING
- --revision=STRING
-
Revision to update to
- -N
- --non-recursive
-
Don't decend into subdirectiories
- -q
- --quiet
-
Update quietly as possible
list
- -r STRING
- --revision=STRING
-
Revision to update to
- -N
- --non-recursive
-
Don't decend into subdirectiories
- -q
- --quiet
-
Quiet output
EXAMPLE
Debugging: use the -d and -n switch just to see what it'll do:
# tor -d -n commit -m "do a commit"
found subtype SVK
running SVK->commit
would run: 'svk' 'commit' '-m' 'do a commit'
CAVEATS
tor will never replace all the other command line utilties and wrap around them completely. There will be times you'll need to switch back to your natice client for complex operations. But by that point, your brain will likely already be thinking about the version control system in question and it won't be a big leap to switch back.
STATUS
Alpha; it's just begun. But I'm already using it. Expect some bumps though, or missing features.
AUTHOR
Wes Hardaker <hardaker ATAT users.sourceforge.net>