[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r15070 - trunk/subversion/libsvn_wc

From: <kfogel_at_collab.net>
Date: 2005-06-16 20:57:32 CEST

lundblad@tigris.org writes:
> Log:
> * subversion/libsvn_wc/README: Bring more up-to-date regarding the
> working copy format.

Peter, thanks so much for cleaning this up! I was about to go review
the patch you posted fo rit, when this commit came in, so I reviewed
the commit instead. Looks good to me.

-K

> --- trunk/subversion/libsvn_wc/README (original)
> +++ trunk/subversion/libsvn_wc/README Thu Jun 16 01:40:31 2005
> @@ -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'
>
> @@ -364,12 +371,6 @@
> especially local modifications. wcprops, on the other hand, are
> just internal tracking data used by the system, like the 'entries'
> file.
> -
> -------------------------
> -todo: some loose ends
> -
> - 1. filename escaping in .svn/entries
> - 2.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 16 21:44:53 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.