Reinoud Zandijk wrote:
> Dear folks,
>
> i'd like to request a new feature for svn; the option to specify for a
> directory if it should be backed up with `pristine copies' or not i.e.
> forcing a network access for the pristine one.
>
> I'd love to see an `svn online' that fetches pristine copies of all the
> files (or copies them if found not altered) recursively for the current or
> specified local repository and its counter `svn offline' that removes all
> the pristine copies recursively for the current or specified local
> repository.
>
> This to facilitate huge repositories of around say 2+Gb with lots of source
> files say 200000 files. Having an extra 2+Gb of disc space (and 200000
> inodes!) only for a `pristine copy' for the occasional time one works
> offline is very heavy; especially for older or smaller machines.
>
> By being able to fetch or purge selective subdirectories in the repository
> that can significantly be reduced and the tradeoff between network fetching
> and local storage can then be chosen at will. If a pristine file is not
> present while working offline when the user asks for f.e. a diff then the
> user could just be notified that the copy is not yet present and inform of
> the `online/offline' switch. Or let the user use a kind of `svn edit'
> command that makes sure that the current file has a backup file in the
> repository (that may not be pristine, but an aproximation). On online
> operation this file could then be replaced by a pristine one.
>
> Thoughts?
See issue #525: http://subversion.tigris.org/issues/show_bug.cgi?id=525
The idea of optional text-bases has been around for a while, but there
hasn't been much work done on it, mainly because the current working
copy library is such a mess. Several developers are spec'ing out a new
working copy library, which would have optional text-bases as one of the
design requirements. Although not available initially, it would make
implementing such a feature much more easier (and likely).
Does this match what you are looking for?
-Hyrum
Received on 2008-03-05 21:54:14 CET