Another option would be to locally store a text-base cache of some sort
outside the actual working copies. This cache could be shared between
multiple working copies of the same project tree. The text base cache
itself could potentially use some kind of delta storage model to provide
multiple cached revisions of files. That way not just svn diff and svn
status could be local, but potentially diffing between trunk and a branch
that are both in cache could be. The cache can be as sparse or as filled as
a user likes, with the ultimate cache being a mirror of the entire
repository, making every operation disconnected.
Michael
On 10/16/06, Brandon Ehle <azverkan@yahoo.com> wrote:
>
> Peter Samuelson wrote:
> > And the UI:
> >
> > - New flag for 'svn co', 'svn ci' and 'svn up' to indicate desire for
> > missing or compressed text-bases.
>
> I assume that some sort of flag in the entries file is needed to
> remember this setting to remember this flag after a commit.
>
>
> Did the developers ever have a discussion about where to pull the
> text-base wanted/unwanted flag from?
>
> I see at least three possibilities:
>
> 1) Local configuration option per repository (per filetype or other?)
>
> GUI's would be able to share the setting with the command line.
>
> 2) Optional server side properties per file
>
> Would work well for extremely large teams and repositories with mixed
> code and assets. You would probably still want the code to have
> text-base, but for large binary assets you would want to disable it.
>
> 3) Command line option like suggested above
>
> Does not make it easy to checkout repositories with mixed code and
> assets. Users are required to pass the option each time they update.
> Good for performance testing, unit tests, and automated processes that
> do not need text-base (on the same machine as a seperate copy of the
> repository that has text-base).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Mon Oct 16 22:48:48 2006