In an effort to reduce the often recurring threads revolving around
some features, I think it would be useful to have some sort of a
"development FAQ", which would serve as an easier way to get up to
speed regarding the development of something than reading mailing list
archives and the issue tracker.
Ideally, it should be a low overhead solution, which could be updated
as progress is made or just in a frequently raised subject fashion as
necessary.
I first thought of adding some of this to the project FAQ, but now I
am not at all certain if that is a suitable place. However, I already
wrote some things and am considering committing them.
-- Naked
Index: www/project_faq.html
===================================================================
--- www/project_faq.html (revision 9162)
+++ www/project_faq.html (working copy)
@@ -124,6 +124,19 @@
</p>
<li><a href="#ramdisk-tests">How do I run the regression tests in a
ram disk?</a></li>
+<p>
+<strong>Development questions:</strong>
+</p>
+<li><a href="#locking">I need some sort of locking to prevent
+ concurrent editing, is it coming?</a></li>
+<li><a href="#adm-dir-size">The Subversion administrative directory
+ (.svn) is taking too much space, can it be helped?</a></li>
+<li><a href="#adm-dir-contents">The Subversion administrative directory
+ (.svn) contents are causing me problems, what can be done?</a></li>
+<li><a href="#adm-dir-existence">The Subversion administrative directory
+ (.svn) existence is a problem for me, can it be somewhere else?</a></li>
+<li><a href="#svnroot">Is SVNROOT, or something akin to CVSROOT, under
+ development?</a></li>
<p>
<strong>References:</strong>
@@ -1595,6 +1608,100 @@
<p>
<hr>
<p>
+<h2>Development questions:</h2>
+<p>
+
+<h3><a name="locking">I need some sort of locking to prevent
+ concurrent editing, is it coming?</a></h3>
+
+<p>First of all, unless you are handling binary files that are
+difficult to merge, do consider the alternatives. Merging and
+conflicts may sound chaotic at first, but it often ends up saving time
+in the end. Locking is no substitute for communication.</p>
+
+<p>But if you do really need locking, then rest be assured, you are
+not alone. It is a fairly high priority development item. See <a
+href="http://subversion.tigris.org/issues/show_bug.cgi?id=1478">issue
+1478</a> for further details.</p>
+
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="adm-dir-size">The Subversion administrative directory
+ (.svn) is taking too much space, can it be helped?</a></h3>
+
+<p>Proposals around this issue mostly center around two approaches:
+eliminating text-base and compression.</p>
+
+<p>Suggestions for eliminating text-base (pristine copies of every
+file in the Subversion administrative directory) have been
+numerous. Not having one at all would mean a big rewrite to the
+working copy library and would make Subversion require network access
+for operations which it now doesn't (svn diff/status/revert). Creating
+one on-demand when the user starts editing a file would require
+explicitly telling Subversion when you are about to do that and errors
+would have to be caught with checksums. See <a
+href="http://subversion.tigris.org/issues/show_bug.cgi?id=525">issue
+525</a> for further details.</p>
+
+<p>Compressing the text-base is a viable alternative and will be
+considered in Subversion development. There has been a working patch
+to this effect already. See <a
+href="http://subversion.tigris.org/issues/show_bug.cgi?id=908">issue
+908</a> for further details.</p>
+
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="adm-dir-contents">The Subversion administrative directory
+ (.svn) contents are causing me problems, what can be done?</a></h3>
+
+<p>The administrative directory has a number of files for various
+purposes, and some of these end up causing problems for some
+people. Part of the problem are tools that inadvertently end up
+looking inside the administrative directory.</p>
+
+<p>Most of the files inside the administrative directory are
+read-only. There have been recent changes on this to solve some
+issues. See <a
+href="http://subversion.tigris.org/issues/show_bug.cgi?id=1294">issue
+1294</a> for further details.</p>
+
+<p>There have been several proposals for combining the multitude of
+files in the administrative directory to a single file or database,
+possibly even compressed at the same time. There are however many
+practical and performance problems to this. See the development list
+archives on discussions on the subject.</p>
+
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="adm-dir-existence">The Subversion administrative directory
+ (.svn) existence is a problem for me, can it be somewhere else?</a></h3>
+
+<p>There have been several suggestions to be able to place the
+administrative directory somewhere else. Eliminating the
+administrative directory from working copies entirely makes tracking
+working copies very problematic. Being able to declare some
+directories opaque, storing their administrative files in the parent
+directory, is much more viable as an alternative. See <a
+href="http://subversion.tigris.org/issues/show_bug.cgi?id=707">issue
+707</a> for further details.</p>
+
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="svnroot">Is SVNROOT, or something akin to CVSROOT, under
+ development?</a></h3>
+
+<p>Discussions on this are a common sight on the development list, but
+none have produced results yet. The issue is generally seen to be
+really low priority. The problem is to remain consistent with the rest
+of <tt>svn</tt> client user interface and yet provide something
+significantly easier than using environment variables directly.</p>
+
+<![CDATA[=========================================================]]>
+
+
+<p>
+<hr>
+<p>
<h2>References:</h2>
<p>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 20 04:43:59 2004