Re: [GNUnet-developers] towards gnunet 0.9.x

[Christian Grothoff]

I was having a similar problem the other day.  Downgrading (!) to SVN 1.5.1 
helped.

Christian

On Sunday 07 June 2009 01:50:15 am Sony Mohanty wrote:
> Hi Christian
>
> I am not able to open in open the link https://gnunet.org/svn/gnunet/.
>
> Regards
> Sony
>
> --- On Fri, 5/29/09, Christian Grothoff <address@hidden> wrote:
> > From: Christian Grothoff <address@hidden>
> > Subject: [GNUnet-developers] towards gnunet 0.9.x
> > To: address@hidden
> > Date: Friday, May 29, 2009, 1:02 AM
> > Dear all,
> >
> > I've just created a new "branch" in the SVN repository
> > (https://gnunet.org/svn/gnunet/) which contains about 50
> > kLOC towards an
> > implementation of GNUnet using a radically new
> > architectural redesign.  The
> > code there only has TCP support and no real applications,
> > but basic
> > (encrypted) messaging between peers is working.  In
> > other words, this is not
> > useful for anyone but developers and those interested in
> > contributing to the
> > discussion as to how the code should evolve.  Note
> > that development on the
> > existing 0..8.x-branch is expected to continue (albeit at a
> > slower pace) for a
> > while.  Once we've sorted out the quirks in the new
> > tree, moving existing
> > applications from 0.8.x to 0.9.x should not be too much
> > work.
> >
> > I want to briefly state the main advantages that the new
> > architecture will
> > provide:
> >
> > 1) Fault isolation.  We're using more processes,
> > literally replacing all
> >   threads, which will ensure that if one component
> > crashes it doesn't take the
> >   whole system down -- and we can tell *which*
> > component is responsible, as
> >   opposed to component A corrupting memory and the
> > code crashing in component
> >   B. Also, 1000 lines of locking code can disappear.
> >
> > 2) Language independence.  Since plugins into the
> > framework run as independent
> >   processes, it will be easier to contribute to GNUnet
> > using languages other
> >   than C/C++.
> >
> > 3) We're also addressing various long-standing API and
> > protocol issues,
> >    including more consistent naming
> > conventions, better support for multi-
> >    homing and IPv6.
> >
> > A more detailed rationale describing not only what changed
> > but also why can be
> > found in the repository at https://gnunet.org/svn/gnunet/RATIONALE. 
> >
> >
> > Happy hacking!
> >
> > Christian
> >
> >
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnunet-developers