Re: [Libmesh-devel] sourceforge Allura migration

[Derek G. <fri...@gm...>]

Allura looks ok.  We've been successfully using Trac for 4 years now... and
it's available on Sourceforge as well:
http://sourceforge.net/apps/trac/sourceforge/wiki/WikiStart

It's a pretty sweet system that integrates very well with SVN.  TONS of
Trac plugins available on the net to do anything you want:
http://trac-hacks.org/

Also... they have a great "build bot" style first party plugin called
Bitten: http://bitten.edgewall.org/  It's how we manage all of our hundreds
of test scenarios for MOOSE and MOOSE apps.

Not against Allura... just letting you know that Trac is a great system.

As for SVN vs Git: We've been battling this internally ourselves for a
while.  Right now we use an SVN repo as the main repo... but all the main
MOOSE devs use Git on top of SVN (git-svn).  It works _really_ well for
exchanging patches amongst ourselves before they make it to the repo... and
there is nothing better than using git local branching to manage your work.

I can't imagine just using SVN again.  It feels so limiting every time I
use it on one of our users machines.

That said... there is something I like about the main repo still being SVN.
 The way that all history is serialized before it makes it to SVN keeps
things simple.  There isn't any advanced branch merging to deal with that
way.  There is some flexibility that you lose that way... but I think the
benefits of simplified repository management and user interaction (our
users don't want to have learn or mess with Git) outweigh the cons.

This is still an ongoing discussion here at INL though.  There is some
thought that when MOOSE goes open-source we might put it on GitHub....

Derek

On Sat, Sep 15, 2012 at 12:26 PM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

> >> Check out Allura -
> >>   https://sourceforge.net/p/allura/wiki/Features
> >>
> >> It is a new hosting option for sourceforge projects. For those of you
> >> familiar with redmine, it should seem familiar.
> >>
> >> I'm very interested in migrating to it and using the issue tracking for
> >> better integrated development.
> >>
> >> This is a pretty big move, though, and would like to hear other
> thoughts...
> >>
>
> > I see they now offer git and hg. Any plan to switch over, or do you
> > prefer to stick with svn?
>
> I bet John could convince me why we should switch to git, but honestly I'd
> rather make this move first.  Unlike cvs, there is nothing I don't like in
> svn versions 1.6 and newer, so I'm not in a hurry to move off it.
>
> I'm sure I could be convinced, but I'd rather focus on the Allura question
> for the moment.
>
> > I really like it. It would make much more transparent the open issues in
> the
> > library and provide an opportunity for would be developers to more
> easily get
> > involved. I think it would also make things much more organized. Having
> a wiki
> > page available I think would also be beneficial.
>
> I agree Paul.  The only downside I see is the svn URL will change, which is
> a one time annoyance on a lot of machines.  Otherwise it looks way better
> and more tightly integrated than the existing set of sourceforge features.
>
> I'll be anxious to hear the INL position.  But I do think it gives us way,
> way more capability than we currently have for tight collaboration, and is
> a
> good move.  Getting rid of our old hardly supported wiki will be good
> riddance, and this puts much of the feature maintenance burden back on
> sourceforge where I'd prefer it.
>
> -Ben
>
>
>
>
> ------------------------------------------------------------------------------
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>