Developing memcached, how should we do it?

[Steven Grimm]

Yeah, git or hg is really a much better tool for this kind of  
development than svn is. In fact, I use git for all of my memcached  
development -- it interfaces reasonably well with svn in the form of  
"import changes from the foreign repository" and "export changes back  
to the foreign repository" operations. Unless you explicitly interact  
with svn, you get to use all the version control goodies you want  
locally without touching (or needing permission to touch) the public  
central repository.

Not sure what the state of hg's svn interface is but even a manual  
"copy the cleartext files out of an svn client and into an hg  
repository" setup (easily scriptable) would offer a lot of advantages  
for local development.

-Steve


On Dec 13, 2007, at 9:02 AM, 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.  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
>>
>>
>>
>>