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 <[email protected]> wrote: > > From: Christian Grothoff <[email protected]> > > Subject: [GNUnet-developers] towards gnunet 0.9.x > > To: [email protected] > > 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 > > [email protected] > > http://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
