Hi,
[Insert usual disclaimer about only being the cvs2svn guy, pretty
ignorant of svn internals]
This discussion reminded me again that the text-base part of a working
copy resembles an incomplete, read-only svn repository. Perhaps both
could be accessed via a common API?
Obviously text-base is not a complete repository--it only contains the
most recent copy of any file, and only for a subset of the directories
in the full repository. It would have to return some kind of
SVN_ERR_DATA_UNAVAILABLE error if it is asked a question that it is
incompetent to answer (for example, information about older file
revisions). In this case there could be a mechanism to forward the
question to a more complete (though presumably remote and slower to
access) repository.
The hope would be that this approach would be general enough to cover:
- the current text-base, which contains the history of every file but
only to depth=1
- a working copy with no text-base at all (to save disk space)
- an enhanced text-base that could include a local copy of the whole
remote repository. (Such a mirror could potentially be shared among
multiple WCs.)
- anything in between
- more dynamic possibilities, such as a local partial copy of the repo
that lazily fills in gaps in its knowledge from the upstream repository
whenever needed to answer inquiries
The fallback behavior could be implemented in the form of a virtual
repository type that actually consisted of a list of references to
other, real repositories, listed in increasing order by cost of access.
The virtual repository would delegate inquiries to the subsidiary
repositories one after the other until it found one that is competent to
respond.
A read-only slave repository could use the same "I am incompetent to
service this request" mechanism to respond to write requests, which
could then be forwarded to a centralized writable master repository.
Since text-base-less WCs and support for detached operation are
currently both hot topics, it seems to me that most of this work will
have to be done anyway. So perhaps a unified approach could be a more
general solution that doesn't cost much additional work.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 31 23:02:30 2007