<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en" xmlns="http://www.w3.org/2005/Atom"><title>Recent changes to feature-requests</title><link href="https://sourceforge.net/p/nativeoberon/feature-requests/" rel="alternate"/><link href="https://sourceforge.net/p/nativeoberon/feature-requests/feed.atom" rel="self"/><id>https://sourceforge.net/p/nativeoberon/feature-requests/</id><updated>2003-02-27T20:50:57Z</updated><subtitle>Recent changes to feature-requests</subtitle><entry><title>Working sf-based build</title><link href="https://sourceforge.net/p/nativeoberon/feature-requests/1/" rel="alternate"/><published>2003-02-27T20:50:57Z</published><updated>2003-02-27T20:50:57Z</updated><author><name>Pieter Muller</name><uri>https://sourceforge.net/u/pmuller/</uri></author><id>https://sourceforge.net5c8a6d580f59a170ac24267fbdc6c01264bad17f</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;Being a simple system, the Native Oberon build tool &lt;br /&gt;
consists of a single Oberon text with some commands for &lt;br /&gt;
building the system from the local file system.  For &lt;br /&gt;
distributed development via sf.net, a CVS-based build &lt;br /&gt;
process would make sense, with a CVS repository on &lt;br /&gt;
sf.net.  This is problematic, since Oberon does not &lt;br /&gt;
currently have a CVS client.  To get going as quickly as &lt;br /&gt;
possible, one way of working around the problem would &lt;br /&gt;
be to use an external CVS client running on another OS, &lt;br /&gt;
and export/import the files on the Oberon file system, &lt;br /&gt;
converting from Oberon text documents to plain ASCII &lt;br /&gt;
along the way.  Of course this would only be an interim &lt;br /&gt;
solution, and true CVS client for Oberon would be a later &lt;br /&gt;
improvement.&lt;/p&gt;&lt;/div&gt;</summary></entry></feed>