$ cd /path/to/my/projects/root $ sscm
Name Last modified Size Description
Parent Directory - TODO.html 09-Dec-2007 10:01 5.0K _darcs/ 09-Dec-2007 10:01 - adding_an_scm.html 09-Dec-2007 10:02 8.4K changelist.html 09-Dec-2007 10:02 8.6K docs/ 09-Dec-2007 10:01 - ruby/ 09-Dec-2007 10:01 -
SSCM is a tool for simultaneously managing multiple version control systems. There are a number of good reasons why you'd want such a beast.
SSCM is currently at version 0.4
SSCM is a simple command line tool that allows you to simultaneously use multiple Source Control Managers with one command.
Why would I want that?
There are 3 main reasons why you'd want this:
With centralized systems if the server goes down you loose the ability to compare your work to past versions, do check-ins, or any of the other things we use version control for. If you're using SSCM then when your Centralized SCM goes down (or maybe you aren't on the network at the moment) you can continue on using your chosen distributed system because SSCM has kept it up to date with all your adds, deletes, and modifications. When you can connect to your centralized SCM again just submit the changes you made while offline and you're systems are back in sync and ready to continue being synced with SSCM.
Please check out the flow chart if this is of interest to you.
You need to keep using the central system but want something better. Tools like Darcs and Git allow for Cherry Picking, something which no centralized system I've heard of can do. With Darcs, if you have, say a hundred changesets and realized that the eighty-eighth one introduced a bug, you can simply remove the effects of the eighty-eighth patch from your current branch. Or you can pull a single changeset from another repo without necessarily having to get all the ones before it. Obviously some changesets are dependent upon others, but you get the basic idea.
With SSCM you can get all the benefits of the distributed system you do like, and your employer's system is kept in sync for the benefit of your coworkers without you needing to duplicate all your version control operations.
It's hard enough to get people to use your open source software. Getting them to hack on it and actually send you patches is nigh-impossible, especially if you're using a version control system that they're not familiar with or don't like. By using SSCM you can make your project available however they want it it, and thus increase your odds of getting a patch.
You're trying to decide on a new SCM but you have more than one option you like. With SSCM you can try them all out at the same time. Install them all. Work with them and try using their branching, merging, and recovery mechanisms for a while. See which one is best for your project and team. You can throw out the one(s) you don't like at any time because you've been keeping things in sync with SSCM.
Currently SSCM supports Bazaar (v0.90.0 or higher), CVS, Darcs, Git, Mercurial (hg), Perforce*, and Subversion, but adding support for other systems is both strongly encouraged and trivial to do even if you don't know anything about Ruby, which SSCM happens to be written in.
SSCM needs to be run from the top level of your project. From there it looks around to see what SCMs are in play then chooses the one it finds easiest to work with and uses it's status report of the files in the project as a checklist to walk you through and sync all the systems it finds. It should be noted though that SSCM assumes that your systems are being kept in sync. If you manually remove a file from one SCM and not another you could end up with unexpected results. But, it would be silly to do that anyway so you don't have to worry about it.
As SSCM goes through the checklist of files it will ask you a series of yes no questions. The default answer will NEVER be destructive! So, if you accidentally hit return an extra time there will be no worries.
Actually using sscm is easy but there are three simple things you have to do first:
Once you've done that you'd run it like this:
$ cd /path/to/my/projects/root $ sscm
Then, if there was anything to do, you'd just read the questions it asks you and hit y, n, or enter as appropriate, as with the example run below:
$ sscm Detected the following SCMs: Mercurial (hg), Git, Darcs Using Mercurial (hg) as the default SCM. ---------------------- Edited file: a.txt Add your changes to the repo? [Y/n]: y Mercurial (hg) will record your changes. Git will record your changes. Darcs will record your changes. ---------------------- Removed file: b.txt Would you like me to remove that file from the repository? [y/N]: y Removing from Mercurial (hg)'s repo. Removing from Git's repo. Removing from Darcs's repo. ------------ Almost Done! Your SCMs (Mercurial (hg), Git, Darcs) should be in sync now. All you have to do is commit your changes. If a quickie commit message is good enough you can call me with --commit "some message" ------------
Tip: Once you get used to using SSCM you can call it with the following options to cut down on extra output.
$ sscm -q -i
If you want to force it to use a specific SCM for the checklist just call it with the --scm [bzr/cvs/darcs/git/p4/svn] option.
$ sscm --scm hg
You may have noticed the fact that we support Perforce but it isn't one of the options to --scm. This is because Perforce is evil and can't be trusted to accurately report the status of the files without a lot of work so we don't bother trying to use it for the checklist even though we support it for syncing.
When it's done you just syncing commit your changes to both systems. If you don't want to leave a detailed commit message you can just call sscm with the --commit "your quick message here" option and it will commit your changes to every system that supports something like that.
$ sscm --commit "Fixed bug #4427" Committing changes to Mercurial (hg). Committing changes to Git. Committing changes to Darcs. Done committing changes. Don't forget to back up your work. :)
SSCM and Tailor are complimentary, not competing, tools. Tailor is concerned with what happened before now. SSCM is concerned with what you want to happen right now. Tailor works by replaying all the operations that happened in one SCM in the language of a different SCM to bring the new one up to date. SSCM executes the command you need to execute right now in multiple SCMs at the same time.
You could use Tailor to replay all the changes you made in one system to another system to bring it in sync. The problem with this is that there's a period between when you do your operations in one SCM and when you update the other(s) with Tailor when your SCMs are out of sync. SSCM eliminates this problem. It saves you from having to remember to update the others, and it saves you from having to figure out where to update the others from, and it means you only have to do things once.
This doesn't mean they can't work together. If you've been using one SCM and want to add a new one just use Tailor to bring the new one up to date with the old one. Then, going forward, run all your commands through SSCM.
Usage (all options are optional):
-s, --scm [scm identifier] Force the use of a specific Distributed Source Control Manager
as the default. Options are bzr, cvs, darcs, git, hg, svn
-x, --exclude [scm identifier] Force the exclusion of one or more Source Control Managers.
Options are bzr, cvs, darcs, git, hg, p4, svn.
You can exclude multiple SCMS by separating them with commas
and no spaces. Ex.: hg,p4,svn
-c, --commit [message] Does a commit with just your short message and no other details
-h, --help Displays this message
-i, --ignore Won't ask you about things you've explicitly added, but not
committed, in prior runs, OR things that are modified that will
be included in the next commit (unless you're using Perforce).
-q, --quiet Hides standard notices letting you know what it's done in
each repository it's done it in.
-a, --apps Display a list of detected SCM apps IN THE CURRENT DIRECTORY.
-t, --tag [message] Tags the current version of each SCM (if it supports it).
-m, --move Tells the system to perform a move. Must be accompanied by -F and -T
-F, --from [moving_from_path] Indicates the file you want to move / rename. Must be accompanied by -T
-T, --to [moving_to_path] Indicates where you want to move / rename the file to. Must be accompanied by -F
-v, --version Prints the version number
Check out the ToDo list for other things we'd like to support.
SSCM came into existence due to my firm belief in the following things:
SSCM is distributed under the MIT license and available via the following methods:
If you add support for another DSCM that I can easily throw on a web server then it'll be available via that too.
Download it. Stick it somewhere that makes you happy. Add an alias like the following to your .bashrc or .bash_profile (or the equivalent if you use a different shell) then open up a new shell and try it out.
alias sscm=/path/to/sscm/ruby/sscm.rb
Before you do any branching or merging you must make sure that all your repos are in sync, but you were doing that anyway so it's a non-issue...
sscm -x [scm] sscm --exclude [scm]
The act of pulling / patching from another branch is very SCM specific and, in general, you can't expect the thing you're pulling from to also simultaneously exist in multiple SCMs. So the easiest solution is to:
sscm --exclude [scm] --commit [message]
This is really the same thing as the merging described above. We just tend to think about it differently when we're working with centralized systems. Your central repository really is a separate repository. It's just that (in a centralized SCM) your local copy of the repo is a very limited snapshot.
So just follow the instructions above for merging.
Using a distributed scm to branch and merge with a centralized system.
The technique for doing this is essentially the same with or without SSCM, but if you always use SSCM to keep things in sync then you'll have a complete revision history for your DSCM to use when you branch.
It is much easier to describe how to branch with a DSCM from an SCM and merge back into it via a flow chart.
Tailor
Tailor is a little-known "...tool to migrate changesets between ArX, Bazaar, Bazaar-NG, CVS, Codeville, Darcs, Git, Mercurial, Monotone, Perforce, Subversion and Tla repositories."
If the project you want to work with uses one, but you prefer to keep your work in the other you can branch from the source, use Tailor to convert the revision history to your favorite too (assuming Tailor supports it) and use SSCM going forwards to keep the two in sync so that you can more easily submit patches back to the project maintainers in a means that works well for them. This, of course, assumes that SSCM supports both of the SCMs involved. If it doesn't you'll find it really quite easy to add a new SCM to SSCM.
