Developing memcached, how should we do it?

[Les Mikesell]

Dustin Sallings wrote:
> 
>   Um, because svn is not conducive to community development.  In order 
> to branch, I must first have commit access.   In order to obtain commit 
> access, I must first demonstrate that I'm worthy to be in the small 
> official circle of developers.
> 
>   During the initial "proving" stage, I have to build a manual workflow 
> around maintaining my own changes and rebasing them over or merging them 
> with the upstream changes.  This already requires tools beyond what 
> subversion offers.
> 
>   In the longer term, we're either cluttering up the official repo with 
> tons of experimental branches, or we're just not experimenting.

OK, I guess I never understood 'community development' to mean 'making a 
lot of clutter that shouldn't be saved', but your description does make 
sense.

> Either 
> way, we're only doing so with the elite core or the really determined 
> (and only when connectivity and availability allow, which it often 
> doesn't).

I haven't used it, but I thought svk was designed to interact with 
subversion in exactly this way - that is you can check out an svn 
project as a mirror, then make a local branch for your work.  Svk is 
supposed to offer the same functionality as svn whether standalone or 
with a mirrored svn checkout, but in the latter case when you merge your 
branch changes back to the mirrored, checked out copy, it also commits 
them back into the subversion repository.
http://www.bieberlabs.com/wordpress/svk-tutorials/
I'm not sure how this works if you initially have read-only rights and 
later are granted commit access, but I'd expect it to work.

-- 
   Les Mikesell
    lesmikesell at gmail.com