Gerrit Voß wrote:
> Hi,
>
> On Sun, 2009-08-02 at 13:00 -0500, Carsten Neumann wrote:
>   
>>      Hello Allen,
>>
>> Allen Bierbaum wrote:
>>     
>>> What about using Mercurial (Hg) on google code instead?  I have heard
>>> that it has a much simpler interface so to most users it would look
>>> very similar to svn, but for those of us that may want to have
>>> distributed repositories we can still do it.  So basically use a model
>>> where the google hosted one is the master repository with
>>> user/organization specific distributed repositories pulling/pushing to
>>> that repository.
>>>
>>> Would this work for your needs?
>>>       
>> probably (well, for me at least), but so does the current setup with a 
>> local git repo ;)
>> I don't think we have compelling reasons to change VCS, so we probably 
>> should not add that work to the list :)
>>     
>
> Similar for me. git in combination with svn works fine for all my needs.
> I really don't need more. svn in this setting actually behaves like a
> linear git repository, you just use different commands to pull/push.
>
> And this is something I would like to keep, even if the master switches
> to hg.
>
> And the one thing that makes an 'official' git or hg repository 
> interesting, providing a platform to publish individual developer trees
> from a single location is currently not available on google code.
>
> http://code.google.com/p/support/issues/detail?id=2563
>
> But at least it's priority is high so it might be resolved in a 
> reasonable amount of time.
>
> Is there anything on your side that would be easier to handle with
> a distributed repository like git or hg ?
>   
I'm probably too late in jumping in here, but I've been on vacation. :)

One _huge_ advantage with the git/hg style is that it allows developers 
to work on fixes individually and publish those changes for review, then 
the core authors may choose what changes/branches to pull for 
integration into trunk.

It also allows easier maintenance of local fixes (vendor branches), as 
each checkout is a full repo, making the playing field more level across 
all developers (i.e. core/non-core) across the project.

I've worked with github.com for some buildbot hacking, but am using 
bitbucket.org (mercurial ditto, very nice with wiki, bugtracker and all) 
for my private work, as I prefer mercurial due to ease-of-use.

Now, this doesn't really matter that much, as we could always make sure 
there are both official git and hg mirrors of the
svn. We should just make sure those end up on github/bitbucket, as those 
sites provide a very fast way for a developer to clone a repo and start 
hacking. It makes implementing, publishing, reviewing and integrating 
patches amazingly simple. (I've been on both sides.)

For me, DVCSes has been like a small little revolution, and I feel it 
makes Open Source more open, as everyone can clone and start 
hacking/committing, not just the core-devs. (We use Mercurial here at 
work, btw.. )

Cheers,
/Marcus

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core

Reply via email to