If the file system had the new code to give you the following
information for filesystem directory entries, would this be enough to
ensure that the generated version-url for foo/baz/quux included a
version URL of 4 instead of 5?
* First visible on path to me at Revision XYZ.
* First visible on path to me at Revision XYZ via CopyID ABC.
The first bit of information should be enough for your needs, and the
second bit of information would be extra info for log/status reports so
that the output for svn log foo/baz/quuz could now include a "branched
from A/B/C at revision XYZ" output on lazily copied repository paths.
Bill
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
>
> Unmodified files in tag or branch directories do not have stable DAV
> version-urls. This could affect the performance of HTTP caches and
> other DeltaV-based tools, although it does not affect Subversion
> directly. Read on for details.
>
> Consider the following repository:
>
> % svnadmin create /repos
> % svn mkdir -m '' file:///repos/foo # Rev 1
> % svn mkdir -m '' file:///repos/foo/bar # Rev 2
> % svn co file:///repos/foo/bar bar
> % cd bar && touch quux && svn add quux && svn ci -m '' quux # Rev 3
> % cd .. && rm -rf bar
> % svn cp -m '' file:///repos/foo/bar file:///repos/foo/baz # Rev 4
>
> Here's a list of what's in the repository, with created_revs:
>
> % svn ls -Rv file:///repos
> _ 4 ghudson 0 Oct 17 21:46 foo/
> _ 3 ghudson 0 Oct 17 21:46 foo/bar/
> _ 3 ghudson 0 Oct 17 21:46 foo/bar/quux
> _ 4 ghudson 0 Oct 17 21:46 foo/baz/
> _ 3 ghudson 0 Oct 17 21:46 foo/baz/quux
>
> Notice that the CR of foo/baz/quux is 3, even though foo/baz/quux
> doesn't exist as of revision 3. This is expected due to lazy copying,
> but it has some implications for DAV. Observe what happens on a DAV
> checkout:
>
> % svn co http://hostname/repos/foo/baz baz
> % grep -A 2 'name="quux"' baz/.svn/entries
> <entry
> committed-rev="3"
> name="quux"
> % grep '\!svn' baz/.svn/wcprops/quux.svn-work
> /svn/repos/!svn/ver/4/foo/baz/quux
>
> Notice that even though the committed-rev is 3, the version-url
> mentions revision 4. This is because of
> mod_dav_svn/util.c:dav_svn_safe_get_cr(), which makes sure that the
> version-url actually works by falling back to the version of the root
> (that is, the version you are checking out or updating to) if it finds
> that a lookup of (CR,path) doesn't yield the same node-revision as
> (checkout-rev,path).
>
> The resulting version-url is unstable. For instance:
>
> % rm -rf baz
> % svn mkdir -m '' file:///repos/unrelated # Rev 5
> % svn co http://hostname/repos/foo/baz baz
> % grep '\!svn' baz/.svn/wcprops/quux.svn-work
> /svn/repos/!svn/ver/5/foo/baz/quux
>
> What's the impact? If many people are checking out a branch or tag of
> some popular source tree through an HTTP cache, the cache won't be
> able to do much good if there is unrelated commit activity in the
> repository. I'll check out revision 1952 and get one set of
> version-urls; you'll check out revision 1955 and get a different set.
> The cache will see different URLs and have to fetch the files over
> again.
>
> For a bit of history,
>
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=4011&list=d
ev
> is a discussion about this problem from a couple of years ago. (For
> "DAV-ID" read "version-url".) There have been other discussions; we
> eventually settled on (CR, path) as the ID, but that obviously doesn't
> work for unmodified files inside copied directories.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-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 Fri Oct 18 19:08:16 2002