Arguments For Distributed Repositories
So — you are using distributed repositories (DRs) like Git or Hg. And you are thinking — why the heck use branching? Branching is great for local one-offs but I can copy/paste for that!”
I admit that I have struggled with this questions as well — for instance thinking that SVN is just as good of a tool for developers. IN the beginning people pushed these DRs but we never, ever used them in the manner that they were intended; they were just shiny new toys. Some of us, me included, took a lot of guff for not being the earliest of adopters. After a lot of hands on over the years, working with these repos the correct and incorrect ways I finally have solid arguments for using distributed repositories, especially when it comes to branching.
Note this is *not* in any way an anti-SVN post; that repo has great tooling and was revolutionary when it came on the scene. You can even use plugins like git-svn with some success in front of a central SVN repository; and in many ways I find build masters preferring its branch and tag methodology. But I would argue that from a developer’s standpoint a distributed is tough to beat.
- Fluidity
- Ease
- Sharing
- Functionality
Fluidity
For me the definition of fluidity is how much something aides your development process. A DR seems in the way at first with the double-check in steps . . .check into your local, check into your central. But once a developer sees the advantage of the local repo it becomes much easier to create batches of changes locally and then push them up to the central repo. (Central repo is usually where the build server points and everyone agrees to push to). DRs accept the merge bumps we all run into and make it part of their process . . . so development becomes something with less in the way. You can worry less about the checkin process.
Also, their is the speed of creating and switching between local and remote branches in a DR; uber-fast. This alone in hands-on makes these tools worth it.
Ease
Have you ever had to work on a branch in SVN? Check out the whole thing and switch workspaces with your IDE — what a pain. With Git (for instance) I just issue a git checkout branch and nothing else needs to be done. That’s as easy as it gets. Adding and committing are all as easy as any other repo.
One thing is with RVs is that it’s also *easy* to get into trouble with merging and getting code out of sync. These systems are more sophisticated so that’s part of the problem. Git has the merge/rebase wars, and a lot of time in Hg and Git you’ll see unintended branches pushed out by new users. This is OK, it takes a while to learn. Make the learning process easy. All too often I see an experienced person blowing up on a newb forgetting that they too usually can’t write documentation and probably made the same errors.
But — the flow makes you do small commits; this in the long run helps keep you out of trouble. Easy!
Sharing
Remote branches are SO simple with a DR. Since they store their diffs much differently — and SVN has to create whole new copies of directories, the speed is so slow comparatively. Team members can share remote repos in seconds, and with Hg and Git you can fire up local servers in your local directory for sharing right away sans central server.
If you sit down and work with the tools — SVN, TFS vs DRs it doesn’t seem obvious off the bat how this might work. I have some use cases below that, when you run into them can immediately see how useful sharing becomes outside the central repo; it is very powerful and not immediately obvious to non-coders as to why.
I mention this because often non-coders get to pick the big tools: people like management, paper architects, PMs and build masters, maybe even QA. Their input is important, but as a developer not always relevant for *doing* the work. I guess that’s why there is git-svn as a compromise and/or transitional tool. Sometimes newer management and QA tracking tools, Rally for a while, only worked with more legacy repositories like SVN and TFS.
Functionality
I am a combination command line/UI person. For instance, I always make sure my build scripts can run on the command line (as will the build server) and in my IDE which is usually Eclipse, sometimes IntelliJ. You can get intra-build errors that are difficult to debug if you don’t master this. With a DR — you simply get more tools. The command line options for Git are endless; I love the interactive staging UI on the command line (git add -i); I also use Tortoise for eyeballing all my files, it lets me add/commit at the same time; the log and branch viewers are fantastic and picking out commits its simple. The amount of commit history is great as well.
In fact DRs really make you think beyond coding as to how you push forth your code.
—
Some Workflows
Commit types: Build masters and managers are more concerned with feature pushes and rollbacks on a macro level; developers with micro commits and history. I find DR tooling makes this workflow much simpler.
Branching: A lot of times when there is a large test suite and a refactor or major requirement change must go in a lot of those tests and other code will break. The main build must not break. The best way to handle this, with ease, is to use a Git or Hg branch; make your changes while consistently merging trunk into your branch; anyone can work on it as well. Fix everything, then merge back to the trunk (after a merge from trunk of course). This is one of the most powerful and easy to do activities with a DR. You’ll know it when it happens to you. Many times you can do this by yourself with SVN by just not checking in and making updating from trunk; but you don’t get the ease of branching or the ease of sharability.
Postscript
Using DRs properly and leveraging the features is not immediately obvious; you have to dig in and experience it to see why they might deliver more value. SVN and TFS are certainly very adequate; I like SVN’s integration into everything there is and I like TFS’s concept of a shared shelveset. Many build masters prefer SVN’s straightforwardness for *their* tasks. And SVN was certainly maligned (to CVS for instance) when it first came out. As developers we should avoid harsh orthodox judgments and see if something will actually put forth value or if we are just doing something for newness/coolness sake.
It’s taken years to see the value for me because almost everyone doesn’t branch/develop the same way on different sites. I guess that’s the lesson. Again, deferring to SVN which was the first repo to put out this mantra while they were still hosted on tigress.org: “We don’t provide you with a process, just a framework to do YOUR process.” Brilliant.
And someday there will be something better anyway.