Developing memcached, how should we do it?

dormando dormando at
Wed Dec 12 18:31:32 UTC 2007

Trond Norbye wrote:
> Hi all,
> I am working on a team at Sun Microsystems focusing on Memcached, and we 
> have just completed the integration of Memcached 1.2.2 into OpenSolaris 
> (it will be available in the next build). Our next step will be to try 
> to improve the scalability on multicore-machines, so we are about to set 
> up our development and test environment. I would therefore like to get 
> some ideas on how we should do this from all of you.

Good to finally hear from you folks! :) We were wondering what happened. 
Were any patches necessary to integrate 1.2.2 into OpenSolaris?

> My first question is about SCM.
> We are a team of developers here that are going to be working on the 
> code, and want to share our work with the team while we're working. I am 
> not a big fan of sending "diff-files" within the team and applying them, 
> since tracking the changes will become difficult (until we're done so we 
> can push a patch back out to the community to get it integrated into the 
> Subversion repository).
> How is this being solved by other companies?

I despise SVN. I do believe in restricting access to the main 
repository, SVN does not make collaborative development very easy. I 
personally use git while working on memcached. I import the repo via 
git-svn, do all of my branch/etc work in native git, then `git-svn 
dcommit` my data back to SVN when it's ready.

I'd love to switch memcached _to_ git, but it'll take a little more time 
and require more sign-on from the developers at large. Git isn't very 
windows friendly, although it's nearly ubiquitous everywhere else.

For your case I would recommend a local "centralized" git repository, or 
elect one of you to be the local patch integration master. I envision 
workflow a bit like this:

- Either a central git repo, or a git "patchmaster" is elected. This 
repo is imported via git-svn, and tracks updates from "us".
- Each worker uses a local clone of that git repo. Commits are done 
locally, etc.

- If two workers go off on a tangent, they may use local branches and 
pull code from each other.
- Individual code review is a git pull into local branch operation.

- In the case of a patch master, they will pull completed sections of 
code from workers. They'll `git-svn fetch && git-svn rebase` to get the 
latest changes from upstream, then manually merge the finished code. At 
that point you may do integration testing.

- In the case of a centralized repo, I'm not too sure how that would 
work. It would still have to track changes to SVN, or someone will need 
to pull all of the final work and re-integrate it later.

It's a lot simpler than I'm actually explaining this. I figure you guys 
understand ;) It would certainly make our lives simpler today if I could 
just add dustin's work as a remote to my local git clone and pull from 
that for review/etc. Presently it's a disaster with SVN, git-svn, hg, etc.

I'll also take this time to re-iterate that frequently getting patches 
integrated with upstream (ie; sending them to the list for review and 
inclusion) will decrease the amount of pain required to integrate the 
final product. I know you folks like "releasing" finalized things, but 
you wouldn't do that to other programmers internally, so it makes little 
sense to do that to us, too.

Obviously there're exceptions such as withholding nonworking code, 
branches that "might not make it", etc.

> Test environment:
> I want to set up a test-suite to cover as much as possible of Memcached. 
> How are people doing this?

`make test` ;)

Memcached presently has a server test suite (and a client test suite, 
separately) in the trunk/server/t directory. If you're adding or 
changing functionality please add proper perl tests to cover the 
changes. There's already a lot of tests in there. More would be fantastic.

I'd also personally like to see more standard benchmarks we can use for 
testing fill rate and running extended load tests to help discover slow 
moving bugs or memory leaks.


More information about the memcached mailing list