Developing memcached, how should we do it?

[Dustin Sallings]

   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.   
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).

-- 
Dustin Sallings (mobile)

On Dec 13, 2007, at 6:18, Les Mikesell <lesmikesell at gmail.com> wrote:

> dormando wrote:
>> 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.
>
> What problem do you have with using svn directly if you branch for  
> releases and don't insist on the trunk always being in a clean state  
> - and branch for changes you expect to be disruptive, or per  
> developer if the work needs to be isolated for a while?
>
> -- 
>  Les Mikesell
>   lesmikesell at gmail.com
>
>
>
>