You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/12/02 20:20:14 UTC
Re: svn commit: r17588 - trunk/subversion/libsvn_wc
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
Re: svn commit: r17588 - trunk/subversion/libsvn_wc
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > lundblad@tigris.org writes:
> > In rNNNNN, I made a few minor tweaks. Some comments/questions:
> >
> Thanks for doing that!
Duh.
I meant to fill in the "NNNNN" with the number before I sent the mail,
and forgot. Sorry. It was r17602, but of course you know that now.
> > 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*? :-)
>
> Nope. That would be strange; at least not so useful. Look at
> take_from_entry in libsvn_wc/entries.c. That's where the "inheritance"
> takes place.
Okay, thanks.
-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
Re: svn commit: r17588 - trunk/subversion/libsvn_wc
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 2 Dec 2005 kfogel@collab.net wrote:
> lundblad@tigris.org writes:
> In rNNNNN, I made a few minor tweaks. Some comments/questions:
>
Thanks for doing that!
> > --- 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.
>
That seems correct to me. Someone who worked with wc-replacements maybe
could double-check.
> > @@ -366,10 +308,199 @@
> > just internal tracking data used by the system, like the 'entries'
> > file.
> >
> > +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.
>
Well, you're right. *We* put it first in our code. I think that's good
since one could stop parsing the entries file after having read this_dir
if that is all that's wanted (I thinking of this like a status operation
of depth 0 which some GUI clients have shown interest in). But that's
just an optimization opportunity. Our code will not break if this_dir
isn't first.
> Second, in this explanation, we should probably set off the words
> "this dir" somehow, otherwise it reads oddly.
>
It is better after your tweak.
> > +`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*? :-)
>
Nope. That would be strange; at least not so useful. Look at
take_from_entry in libsvn_wc/entries.c. That's where the "inheritance"
takes place.
> > +`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?
>
They are optional a) because committed-rev is and b) because date and
author may not be available for all revisions.
Thanks again for looking this over and fixing stuff for me,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org