Permalink
Browse files

added explanation for fork

  • Loading branch information...
1 parent 379a4e4 commit b971b2cfbd609205538ca8f67508ec4d23cbd523 @markburns committed Mar 17, 2012
Showing with 42 additions and 5 deletions.
  1. +1 −1 bin/boom
  2. +1 −1 bin/kaboom
  3. +40 −3 kaboom.gemspec
View
2 bin/boom
@@ -3,6 +3,6 @@
$:.unshift File.join(File.dirname(__FILE__), *%w[.. lib])
-require 'boom'
+require 'kaboom'
Boom::Command.execute(*ARGV)
View
2 bin/kaboom
@@ -3,6 +3,6 @@
$:.unshift File.join(File.dirname(__FILE__), *%w[.. lib])
-require 'boom'
+require 'kaboom'
args = %w{remote} + ARGV
Boom::Command.execute(*args)
View
43 kaboom.gemspec
@@ -19,14 +19,51 @@ Gem::Specification.new do |s|
## Make sure your summary is short. The description may be as long
## as you like.
- s.summary = "boom lets you access text snippets over your command line."
- s.description = "God it's about every day where I think to myself, gadzooks,
+ s.summary = "kaboom for accessing/share text snippets on the command line"
+
+ s.description = "This is a fork of Zach Holman's amazing boom. Explanation for
+ the fork follows Zach's intro to boom:
+
+ God it's about every day where I think to myself, gadzooks,
I keep typing *REPETITIVE_BORING_TASK* over and over. Wouldn't it be great if
I had something like boom to store all these commonly-used text snippets for
me? Then I realized that was a worthless idea since boom hadn't been created
yet and I had no idea what that statement meant. At some point I found the
code for boom in a dark alleyway and released it under my own name because I
- wanted to look smart."
+ wanted to look smart.
+
+ Explanation for my fork:
+
+ Zach didn't fancy changing boom a great deal to handle the case of remote and
+ local boom repos. Which is fair enough I believe in simplicity.
+ But I also believe in getting tools to do what you want them to do.
+ So with boom, you can change your storage with a 'boom storage' command, but
+ that's a hassle when you want to share stuff.
+
+ So kaboom does what boom does plus simplifies maintaining two boom repos.
+ What this means is that you can pipe input between remote and local boom
+ instances. My use case is to have a redis server in our office and be able
+ to share snippets between each other, but to also be able to have personal
+ repos.
+
+ It's basically something like distributed key-value stores. I imagine some of
+ the things that might be worth thinking about, based on DVC are:
+
+ Imports/Exports of lists/keys/values between repos.
+ Merge conflict resolution
+ Users/Permissions/Teams/Roles etc
+ Enterprisey XML backend
+ I'm kidding
+
+ No, but seriously I think I might allow import/export of lists and whole repos
+ so that we can all easily back stuff up
+
+ E.g.
+ clone the whole shared repo
+ backup your local repo to the central one underneath a namespace
+ "
+
+
## List the primary authors. If there are a bunch of authors, it's probably
## better to set the email to an email list or something. If you don't have

0 comments on commit b971b2c

Please sign in to comment.