weblog.masukomi.org

Using SSCM as a Version Control System Fail-over September 7, 2007

The primary reason behind my creating SSCM was because I don’t feel I can trust Perforce. And when you can’t trust, or can’t afford to exclusively trust, a critical system you use a fail-over. Any large company worth it’s salt has fail-over systems. When one critical machine goes down another is ready to take it’s place. Sadly, there are a lot of companies not worth their salt, but that’s a separate discussion.

Fortunately for you, the benefits of SSCM extend far beyond my personal needs. Imagine that you work at a company with a centralized version control system. What happens when the server goes down, or becomes unreachable? Maybe you’re on a plane, or spending the weekend in a cabin in the woods. Why you can’t reach the server doesn’t matter. What matters is that you want / need to hack and are totally unable to use your version control system. No comparing your current version to those of the past. No diffing branches. No new branches. No merging branches. Nothing.

Or…. it would be nothing if you weren’t using SSCM. You see, if you use SSCM to keep a Distributed Source Control Manager like Mercurial (Hg), Darcs, or Git in sync with your main centralized system then when it goes down you have fully functional version control system with a full* revision history.�

* There’s an asterisk next to “full” there because its full back to the point you started using the DSCM unless you take advantage of Tailor which can convert revision histories between source control managers, which is great for migrating your old data to a new system.

So how would you go about using something SSCM as a fail-over system? Like this:

SSCM v0.2 Released September 6, 2007

I am very happy to announce the release of
SSCM
v0.2.

It is a massive refactoring, way more test coverage, and much easier to add new
Source Control Managers (SCMs) to.

I’ve also, of course, fixed a few bugs, added some features, and improved the
documentation.



Now a 0.2 version might not seem like much but I don’t foresee any notable
structural changes to the system between now and 1.0.

Main thing that needs to be added is the ability to support file renaming.



I think SSCM is at a point where you should give it a whirl. If you’re wondering
why you would, there’s a bit at the top of the home page to give you some good
reasons.

SSCM v0.2 update coming soon September 5, 2007

Just a quick note to let you know that sscm v0.2 should be out early Thursday morning (round midnight I’d guess) so if you haven’t downloaded it yet hold off. v0.2 is a complete refactoring with TONS more unit tests. I refactored it to make it more manageable and discovered that that made it way more testable too. Yay! And testability is a damn good thing when we’re talking about something as important as a version control system. I’m about 1/2 way done with the refactoring now and what’s left is more grunt work than problem solving. I did the problem solving tonight, now I need to finish implementing it.

Put Up or Shut Up (Take 2) September 4, 2007

Put Up or Shut Up (take 2)



You probably saw that I spent the beginning of this weekend whipping up a tool
to synchronize a distributed system with Perforce. Well, I got to thinking, and
thinking leads to refactoring, and unit testing, and bug fixing, and TONS OF NEW
FEATURES. So many in fact that I’ve given it an entirely new name.



Introducing:
SSCM

Catchy name huh? It stands for Simultaneous Source Control Managers (manager)
and it enables you to easily keep any combination of Subversion, Perforce,
Mercurial (Hg), Git, and Darcs synced, tag all their repos simultaneously, and
do quick commits to all of them (except Perforce).



Why would you want such a thing?

• Your employer requires you to use a standard centralized SCM like Subversion
  or Perforce and you’d like to take advantage of a Distributed Source Control
  Manager like 
  Mercurial (hg),
  Git, or 
  Darcs without having to duplicate all
  your adds, commits, and so forth for the distributed system and the system
  everyone else at your company is using.
  
• You manage an open source program and would like to reach the largest
  possible audience by offering its source code via a variety of SCMs at the
  same time. Or, maybe you just can’t decide on a single distributed system.

It’s free, it works, it’s got a helpful
README and
plenty
of API docs to boot.



Side note: This should not be considered a substitute for learning how to
actually use the SCMs you  want to manage with it. Although if you know one
it’ll get you the basic operations in the other ones you add while you’re still
learning them.

Advice for the creators of Distributed Version Control Software September 2, 2007

Some advice from the trenches for the creators of distributed version control
software:



Just some small pieces of advice that I think would really help based on
observations using
Darcs,
Mercurial
(hg), and Git.

1. Get together and decide on a common term for this stuff. I don’t care what
   you call it just pick something! I
   keep hearing / seeing:
   
• distributed version control system
• distributed revision control system
  
• distributed source control system
  
• distributed source control management system
  
2. If you’re not working on Darcs go check out how it interacts with people.
   I’m not a huge fan of it’s speed or the way it thinks about things but I
   keep wanting to use it because it’s so damn easy (for most things).
3. Sharing a repo via a web site should require zero steps beyond uploading it.
   In Darcs if you upload it to a public site, it’s shared. The end. In
   Mercurial you have to install and configure a cgi. In Git you have to clone
   the repo, then upload the clone, then on the server call “git –bare
   update-server-info” from within the clone directory. I have no clue what
   this does, why it’s required, or if it can be done before uploading because
   the docs suck.
4. The ability to download a repo from a web site should be build it. Darcs and
   Mercurial have this, although Mercurial requires that cgi to be running on
   the server. Git requires you to compile git with “curl support” but nowhere
   do they tell you HOW to compile git with curl support and when you end up
   compiling without it it doesn’t let you know you’ll never be able to use it
   for http:// or ftp:// repos.
5. Do not assume that because a file is missing I want it removed from the
   repository. Destructive behavior should NEVER be the default. Mercurial gets
   this right.
6. Make it easy to roll back the changes in a single file. Darcs is the only
   one that gets this wrong and it’s because Darcs doesn’t think in terms of
   files. It thinks in terms of patches which gives it uses in great ways, but
   its still a pain in the ass to just get back a file I deleted or roll back
   changes in just that file. It’s doable, but a pain.
   
7. Follow Git’s example (I think Mercurial does this too) and give me a cryptographic guarantee that what i expect to be in the repository is what’s in the repository and that nothing has become corrupted or maliciously altered

Put Up or Shut Up

Put Up or Shut Up

(or what masukomi wrote to survive with Perforce)

This article has been deleted owing to the fact that I completely refactored the app into something much better.