or - The One Ring to manage all other version control systems
# cd svn_repository_checkout # or update # or diff # or commit -m "woot"
# cd cvs_repository_checkout # or update # or diff # or commit -m "woot"
# cd git_repository_checkout # or update # or diff # or commit -m "woot"
# cd svk_repository_checkout # or update # or diff # or commit -m "woot"
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).
or 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).
The main options must go before the version control command to be processed.
Turn on debugging output
Dry run only; just show what would be done.
The following are the currently supported commands that or 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.
Quiet output
Don't decend into subdirectiories
Quiet output
Don't decend into subdirectiories
Quiet output
Quiet output
ERROR: The "SVK" module does know the command "ignore"
Revision to update to
Don't decend into subdirectiories
Commit message
Don't decend into subdirectiories
Update quietly as possible
Don't decend into subdirectiories
Quiet output
Revision to diff against
Don't decend into subdirectiories
Revision to update to
Don't decend into subdirectiories
Quiet output
Revision to update to
Don't decend into subdirectiories
Update quietly as possible
Revision to update to
Don't decend into subdirectiories
Quiet output
Debugging: use the -d and -n switch just to see what it'll do:
# or -d -n commit -m "do a commit" found subtype SVK running SVK->commit would run: 'svk' 'commit' '-m' 'do a commit'
or 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.
Alpha; it's just begun. But I'm already using it. Expect some bumps though, or missing features.
Wes Hardaker <hardaker ATAT users.sourceforge.net>