Showing posts with label dropbox. Show all posts
Showing posts with label dropbox. Show all posts

Sunday, February 14, 2010

on Dropbox

I have been using Dropbox for a few weeks now. There are several solutions to address our storage issues and I have found all those solutions inadequate in one way or another. Dropbox seems to have solved most of those problems for me.

There are two important things we want to do with our data (besides creating and consuming it, of course): Sharing and Backup.

Sharing We need to share our data either with others or with ourselves but on a different computer. When we want to share data with others the first thing comes to mind is Email. If your data is of specific type, say image or video, you can use services that specialize in handling those types of data (Flickr, Picasa, Youtube). If it is the documents that you want to share, you will think of Google Docs or Zoho. If it is any arbitrary kind of data, then you may need a network drive. If the other individual you want to share the data with is in the same household or if you yourself want to access the data from different machine in the same household, you would use a NAS box. Mount that shared storage as NFS or CIFS drive on your computers. Here you need some administration expertise and need to maintain it over time.

Backup No one wants to loose their data. But we know our computers are anything but immortal. The solutions I mentioned above for sharing data, also serve as backup solutions. Moreover, if you are tech savvy, you can use mirrored RAID hard drives.

I've found that Dropbox satisfies both of the above needs and requires zero setup and maintenance efforts on user's part. Dropbox is a service provider that provides storage as a service. After you install the Dropbox software on your computer (Windows, Linux or Mac OSX), it will appear as just another folder on your computer. You can create, delete, rename a file in your Dropbox drive on one machine and the action will reflect almost immediately on other machine (depending upon the network speed). That's all. Now let me enlist what all complicated things this simple setup has solved.

  • You don't have to worry about NFS/CIFS or what data sharing protocol the service uses and if the OS on your different machines will talk that protocol or not. Dropbox uses some proprietary (!! yes, I'll come to that later) protocol and provides free clients for all platforms that seamlessly talk that protocol.
  • You can share data with others if they have Dropbox account. Imagine telling your mom that she can copy the photos she has taken in this folder on her desktop and her son will see it instantly on the opposite face of the planet. No need to upload them to Picasa or whatever.
  • Dropbox has an option called "Enable LAN sync". This is killer. If you want to share your data between a laptop and desktop that are in the same LAN, Dropbox will sync the data without going over network. I tried this yesterday - actually unknowingly, because I expected my Macbook to take much longer to sync a week's worth of git history and it did it almost instantly. I am not sure if this will work if you are not connected to Dropbox servers. The daemon on desktop might have to exchange some meta data with Dropbox servers, but the actual data transfer takes place entirely on your internal LAN, and hence is very fast. This makes Dropbox a solid alternative to a NAS box.
  • When you sign up, you get 2GB of data for free to start with. For more storage you need to pay an yearly amount. (Don't know about you, but it will take a while for my shareable data to exceed 2GB.) Moreover you will get 250MB for every person that signs up through your referral. Furthermore, it's a data storage and not a version tracking repository. So you can free some space if you hit the limit by deleting unwanted files. (I am not 100% sure if that actually frees space or not. When I have lot of data to delete I will test it)
  • Offline availability: If your ethernet/wifi connection breaks, the NAS share on your machine will be inaccessible to you. That's not the case with Dropbox. You can still access the files in your Dropbox folder even when you are offline - just that they won't be up to date.
Dropbox talks a proprietary protocol. The client daemons are closed source too. These days "open" has become such a fashion statement that few people care to find its relevance in a given context. Here are two aspects of the Dropbox service that make me feel safe when putting my data in it.

  • Lock in - This is a major issue with document storage services like Google Docs or online MS Office. You need to make sure that they have the ability to export their document in a format that can be opened by other software of your choice. Creately is a great product, but I don't want to use it to draw my flowcharts because it saves the doc in a proprietary format. I can only export it as PNG image. I would have used it, if it had an option to export to SVG. By the nature of its service Dropbox doesn't have lock-in problem. Your files are stored as raw data, so there is no worry of format lock in.
  • Evil/Bankruptcy - In case Dropbox goes bankrupt overnight, or gets bought by someone evil and shuts down their servers except for paid customers, do we loose our data? The "Offline Availability" feature of Dropbox will let you access your data on your local machine, even if the Dropbox server is not reachable. Now it is arguable, if Dropbox can plant a malware in their proprietary daemon to sabotage your data or make it inaccessible. I leave it to you to decide if a popular service provider will do such a thing on purpose. (If you think it can, you may want to stop using Gmail)

I hear Dropbox has an iPhone app, but without iPhone I can't check it out. But they are soon publishing Android and Blackberry apps, so I will review it then. They do have mobile-friendly web site though.

So overall, I think Dropbox is a great service to solve our storage worries.

Having said that, there are some minor issues that I've found or don't know enough about that may concern some of you.

  • Dropbox can share files across Linux and Windows, but I don't know how that affects access control bits on those files. I can see the -rwx- fields on my files alright even when I put them in Dropbox. I don't know if they affect when the file is modified from a Windows machine (I don't use Windows myself). I have been using Dropbox as my Git repo for few weeks and I haven't found any problems doing that.
  • On a Windows machine, the installer is little unclear when dealing with multiple accounts. I installed it from an Admin account on my parents' laptop, but it didn't show up in my parents' account that have no admin privileges. I had to temporarily give admin rights to those accounts, install Dropbox and revoke the rights later. It worked alright after that.
I have used the service only for a month, so I may or may not find things in future that may change my impression of the service. Never say never. But so far, I've found Dropbox to be the best solution for data sharing and backup.

(There is a competing service named Sugarsync, but I haven't tried it. I think it lacks support for Linux, so no-go for me.)

Wednesday, January 27, 2010

on Git: tips for SVN users and Git in Dropbox cloud

I gave in to the hype of Distributed VCS and decided to learn Git about 6 months ago (No, it's not a hype, even for single person projects). I started managing my latest projects with Git. Learning Git was not a cake walk, but I put my faith in Git's promise of power and climbed the beginning slope of the learning curve. If you are switching to git after using Subversion for years, then this slope can be steeper. But now I am comfortable with my Git setup and starting to see the glimpses of power that git has to offer.

Here are few tips for subversion users shifting to Git, which could have saved me some agony when I was new.

1. How can I do svn revert in Git?
Believe it or not, but you do that with git checkout . When I first learned that, I was shocked. (And the best part is, the manpage of git-checkout talks about this functionality only in 3rd paragraph and in not so clear words). Over time you will find out that "checkout" is highly overloaded sub-command in git. Besides reverting your changes, it is used to switch to new branch, or create a new branch altogether. Its semantics are nothing like svn checkout. (The closest git analogue of svn co would be git clone, but not exactly)

2. What's all about branching being easy in Git?
Once your projects starts to grow beyond certain size, you appreciate the ease of branch management that Git provides. But it takes little effort to understand it. In Subversion, the central repository lies on a web server or a backed up disk partition. You as a user, "checkout" a local copy of it. In Git as well, there can be a center repository (but it's not necessary), however you do not checkout code from it. You as a user "clone" the entire repository. Because the entire repository is available locally, creating, deleting and switching between branches is very fast. Others don't see your branches unless you create a corresponding remote branch on central repository (check git push and --track option of git checkout to find out more about it)

3. Here are two useful git subcommands that I wish were more publicized, rather than documented like corner cases.

stash
When you start using multiple branches, more often than not you are faced with a situation where you have some uncommitted code in branch B, but to fix a customer reported crash you want to immediately switch to branch A. When I first faced this situation, all I could find was do a commit and switch the branch. After some later point I accidentally  came across 'git stash' and found how handy it was.

cherry-pick
You are working on some new feature in branch B and you find a critical bug while doing it. You find the  fix for it and you want to release it immediately without waiting for this feature to complete. Your releases are built from branch A (from which you create B). Commit your fix in branch B (don't include any feature code in that commit), then git the SHA id of that commit to cherry-pick.

4. git mergetool
Git has the most intuitive conflict resolution mechanism in the form of git-mergetool. Actually, I am not sure if it's git or (g)vimdiff that deserves the credit (or both). After doing merges across branches, if you end up with conflicts, then use git mergetool --tool=vimdiff (git may automatically prompt you for this). I have done some merges with Perforce in the past (they call it crossport, integrate, etc.), and suffice it to say it was bad enough for me to avoid that task altogether. But the three windowed diff view makes this task as intuitive as possible.

5. Best Git GUI I've found so far: Git-cola

6. Book recommendation: Progit (It's Free. It explains different use cases with examples and that helps a lot)


Now on to the second part of the post. Something that I discovered recently. First understand that, you don't need any central repository to git-fy your project. You have a directory of source files and you want to start tracking it with git, just do git init and you are good to go. git-add, git-commit, git branching all can be done after this point.


However, in little bigger use cases you need a central repository. In my case, I work on same project from two different machines located at two different locations. I could create my git repository on USB key and carry it around with me. But it's not reliable - media corruption, physical loss, theft - you get the point. So it's advisable to have your central repo in cloud.

I rented such service from repositoryhosting.com for $6 per month. They provide many other project management tools in the package too, but I primarily used it for git. Recently I started using Dropbox. Although Dropbox storage resides in cloud, they have done perfect job of exporting it as native file system. More importantly it works on all three platforms. So for all practical purposes (that I have covered in last two weeks at least), it's a native file system, but magically synced across different machines. So I just created the git clone of my git repositories in one of the folders inside Dropbox. I can now push and pull to/from this repository on different machines. See this post for detailed instructions.

Dropbox comes with 2GB of free storage and by doing some referrals you can stretch it up to 2.5GB. It's plenty for versioning source code files, don't you think? Be careful not to version big files though (release binaries for instance), you won't be able to free up space by removing them once they are in the repository.

I hope you found the git tips useful. Hoping to explore more of git.