* subversion/libsvn_wc/README: Bring more up-to-date regarding the working copy
  format.

Index: subversion/libsvn_wc/README
===================================================================
--- subversion/libsvn_wc/README	(revision 15057)
+++ subversion/libsvn_wc/README	(arbetskopia)
@@ -78,8 +78,7 @@
 analogous to CVS/ subdirs:
 
   .svn/format                   /* Contains wc adm format version. */
-       README                   /* Just explains this is a working copy. */
-       repository               /* Where this stuff came from. */
+       README.txt               /* Just explains this is a working copy. */
        entries                  /* Various adm info for each directory entry */
        dir-props                /* Working properties for this directory */
        dir-prop-base            /* Pristine properties for this directory */
@@ -107,6 +106,7 @@
             text-base/             /* tmp area for base files */
             prop-base/             /* tmp area for base props */
             props/                 /* tmp area for props */
+       empty-file               /* An empty file, for convenienct. */
 
 `format'
 
@@ -119,15 +119,11 @@
    didn't muck things up afterwards, but it's good enough for
    existence-checking.
 
-`README'
+`README.txt'
 
    If someone doesn't know what a Subversion working copy is, this
    will tell them how to find out more about Subversion.
 
-`repository'
-
-   Where this dir came from (syntax TBD).
-
 `entries':
 
    This file holds revision numbers and other information for this
@@ -135,27 +131,37 @@
    does not record much other information about them, as the subdirs
    do that themselves).
 
-   The entries file contains an XML expression like this:
+   The entries file contains an XML document like this:
 
-      <wc-entries xmlns="http://subversion.tigris.org/xmlns/blah">
-        <entry ancestor="/path/to/here/in/repos" revision="5"/>
-            <!-- no name in above entry means it refers to the dir itself -->
-        <entry name="foo.c" revision="5" text-time="..." prop-time="..."/>
-        <entry name="bar.c" revision="5" text-time="blah..." checksum="blah"/>
-        <entry name="baz.c" revision="6" text-time="..." prop-time="..."/>
-        <entry name="X" new="true" revision="0"/>
-        <entry name="Y" new="true" ancestor="ancestor/path/Y" revision="3"/>
-        <entry name="qux" kind="dir" />
+      <?xml version="1.0" encoding="utf-8"?>
+      <wc-entries xmlns="svn:">
+        <entry repos="http://svn.collab.net/repos/svn"
+               url="http://svn.collab.net/repos/svn/path/to/here/in/repos"
+               uuid=""65390229-12b7-0310-b90b-f21a5aa7ec8e"
+               name="" kindr="dir"
+               committed-rev="38"
+               committed-date="2004-11-28T14:14:14.387535Z"
+               last-author="someone"
+               prop-time="2004-04-02T13:08:57.827875Z"
+               revision="5"/>
+            <!-- empty name in above entry means it refers to the dir itself -->
+        <entry name="foo.c" revision="5" text-time="..." prop-time="..."
+               committed-rev="..." last-author="..." committed-date="..."
+               checksum="..." kind="file"/>
+        <entry name="bar.c" revision="5" text-time="blah..." checksum="blah"
+               kind="file"/>
+        <entry name="X" schedule="add" revision="0" kind="file"/>
+        <entry name="Y" schedule="add" copied="true" kind="dir"
+               copyfrom-url="http://svn.collab.net/repos/svn/another/Y"
+               copyfrom-rev="14"/>
       </wc-entries>
 
    Where:
 
-      1. `kind' defaults to "file".
-
-      2. `revision' defaults to the directory's revision (in the
+      1. `revision' defaults to the directory's revision (in the
          directory's own entry, the revision may not be omitted).
 
-      3. `text-time' is *required* whenever the `revision' attribute
+      2. `text-time' is *required* whenever the `revision' attribute
          is changed.  They are inseparable concepts; the textual
          timestamp represents the last time the working file was known
          to be exactly equal to the revision it claims to be.
@@ -171,23 +177,25 @@
          modifications.  Thus a "locally modified" check must examine
          both timestamps if they both exist.
 
-      4. `ancestor' defaults to the directory's ancestor, prepended
+      3. `url' defaults to the directory's URL, prepended
          (according to the repository's path conventions) to the entry
          name in question.  This directory's ancestor may not be
          omitted, but conversely, subdirectories may not record
          ancestry information in their parent's entries file.
 
+      4. `repos' defaults to the repository root of the directory entry.
+         For backwards compatibility, this attribute may be omitted.
 
 
    When a file or dir is added, that is recorded here too, in the
    following manner:
 
-      1. Added files are recorded with the "new='true'" flag; if they
+      1. Added files are recorded with the "schedule="add" attribute; if they
          are truly new, their initial revision is 0, otherwise their
          ancestry is recorded (see files X and Y in the example).
 
-      2. Added dirs get the "new='true'" flag too, but they record
-         their own ancestry.
+      2. Added dirs get the "schedule='add'" flag too, but they record
+         their copy ancestry in both their parent and their own entries file.
 
    Child directories of the current directory are recorded here, but
    their ancestry information is omitted.  The idea is to make the
@@ -210,16 +218,14 @@
 
 `dir-prop-base'
 
-  Same as `dir-props', except this is the pristine copy;  analogous to
-  the "text-base" revisions of files.  The last up-to-date copy of the
-  directory's properties live here. 
+   Same as `dir-props', except this is the pristine copy;  analogous to
+   the "text-base" revisions of files.  The last up-to-date copy of the
+   directory's properties live here. 
 
 `lock'
 
-   Present iff some client is using this .svn/ subdir for anything.
-   kff todo: I think we don't need read vs write types, nor
-   race-condition protection, due to the way locking is called.  We'll
-   see, though.
+   Present iff some client is using this .svn/ subdir for anything that
+   requires write access.
 
 `log'
 
@@ -304,8 +310,8 @@
 
    When the working copy library needs a tmp file for something in the
    .svn dir, it uses tmp/thing, for example .svn/tmp/entries, or
-   .svn/tmp/text-base/foo.c.  When it needs a *very* temporary file for
-   something in .svn (such as when local changes during an update), use
+   .svn/tmp/text-base/foo.c.svn-base.  When it needs a *very* temporary file
+   for something in .svn (such as when local changes during an update), use
    tmp/.svn/blah$PID.tmp.  Since no .svn/ file ever has a .blah
    extension, if something ends in .*, then it must be a tmp file.
 
@@ -317,18 +323,19 @@
    file, corresponding to the revision indicated in `entries'.  These
    files are used for sending diffs back to the server, etc.
 
+   A file named `foo.c' in the working copy will be named `foo.c.svn-base'
+   in this directory.
+
 `prop-base/'
 
-   Pristine repos properties for those files, in hashdump format.
-   todo: may also store dirent props here, lots of good formats for
-   mixing those two, would pick one when we implement the dirent
-   props.  Or may store them some other way; think this will be best
-   answered after having the rest of the library working.
+   Pristine repos properties for those files, in hashdump format.  Named
+   with the extension `.svn-base'.
 
 `props/'
 
    The non-pristine (working copy) of each file's properties.  These
-   are where local modifications to properties live.
+   are where local modifications to properties live.  The files in this
+   directory are given `.svn-work' extensions.
 
    Notice that right now, Subversion's ability to handle metadata
    (properties) is a bit limited:
@@ -343,10 +350,10 @@
       disk into memory, and written back out again.  Not exactly a
       paradigm of efficiency!
 
-   In other words, for Subversion 1.0, properties will work
-   sufficiently, but shouldn't be abused.  They'll work fine for
-   storing information like ACLs, permissions, ownership, and notes;
-   but users shouldn't be trying to store 30 meg PNG files.  :)
+   In other words, for Subversion 1.0, properties work sufficiently,
+   but shouldn't be abused.  They work fine for storing information
+   like ACLs, permissions, ownership, and notes; but users shouldn't
+   be trying to store 30 meg PNG files.  :)
 
 'wcprops/' and 'dir-wcprops'
 
@@ -365,14 +372,8 @@
    just internal tracking data used by the system, like the 'entries'
    file.
 
-------------------------
-todo: some loose ends
 
-   1. filename escaping in .svn/entries
-   2. 
 
-
-
 How the client applies an update delta.
 ---------------------------------------
 
