lundblad@tigris.org writes:
> Log:
> * subversion/libsvn_wc/README: Bring the description of the WC format mostly
> up-to-date and hopefully make it clearer and more complete.
Peter, thanks! This commit is going to be valuable to new developers
who are trying to learn the working copy code.
In rNNNNN, I made a few minor tweaks. Some comments/questions:
> --- trunk/subversion/libsvn_wc/README (original)
> +++ trunk/subversion/libsvn_wc/README Thu Dec 1 15:53:52 2005
> @@ -123,114 +130,45 @@
>
> [...]
>
> +`dir-prop-revert':
> + This is the base-props for this directory for the deleted directory
> + in a schedule replace situation. If this file doesn't exist, the
> + `dir-prop-base' file is used.
> +
> `lock'
This wasn't completely clear to me: "...for this directory for the
deleted directory in a schedule replace situation". Would this be
equally correct?:
In a schedule-replace situation for this directory, this holds the
base-props for the deleted version of the directory (i.e., the
version that is being replaced). If this file doesn't exist, the
`dir-prop-base' file is used.
If you approve, I can make that change.
> Present if some client is using this .svn/ subdir for anything that
> requires write access.
>
> -`log'
> +`log' and `log.N'
>
> - This file (XML format) holds a log of actions that are about to be
> + These files (XML fragments) hold a log of actions that are about to be
> done, or are in the process of being done. Each action is of the
> sort that, given a log entry for it, one can tell unambiguously
> whether or not the action was successfully done. Thus, in
> recovering from a crash or an interrupt, the wc library reads over
> the log file, ignoring those actions that have already been done,
> and doing the ones that have not. When all the actions in log have
> - been done, the log file is removed.
> + been done, the log files are removed.
> +
> + Some operations produce more than one log file. The first log file
> + is named `log', the next `log.1' and so on. Processing the log
> + files starts at `log' and stops after `log.N' when there is no `log.N+1'
> + (counting the first log file as `log.0'; it is named `log' for
> + compatibility.)
All praise to your log.N file explanation; it is a model of clarity.
(In rNNNNN, I made a slight tweak to the pre-existing text, though.)
> @@ -366,10 +308,199 @@
> just internal tracking data used by the system, like the 'entries'
> file.
>
> +`empty-file':
> + This files was added in format 4 and earlier. This was used to
> + create file diffs against the empty file (i.e. for adds and
> + deletes).
> +
> +`README':
> + This file was removed in format 5. It used to contain a short text
> + saying what this directory is for and warning users not to alter
> + its contents.
> +
> +The entries file
> +----------------
> +
> +The entries file contains an XML document with a top-level element
> +named `wc-entries'. This element contains one or more `entries'
> +elements, one for each directory entry. The first `entry' element is
> +the this dir entry with values for the directory containing this admin
> +area.
Two things:
There is no requirement that the "this dir" entry be first. Rather,
its identifying characteristic is that it's entry name is the empty
string.
Second, in this explanation, we should probably set off the words
"this dir" somehow, otherwise it reads oddly.
In rNNNNN, I've made an attempt to fix both of these issues, see what
you think of the result.
> +`committed-rev':
> + The last committed revision for this entry if this entry is in the
> + repository. NO default; optional.
Wait -- if this is optional, isn't the default the this_dir entry's
committed-rev? Or the this_dir entry's base-rev? Or *something*? :-)
> +`committed-date':
> + The date of the `committed-rev' if available. No default;
> + optional.
> +
> +`last-author':
> + The author of the `committed-rev' if available. No default;
> + optional.
Hmmm. But these are optional too... Maybe I'm wrong about
committed-rev?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 2 22:44:58 2005