I think that the most practical consecuence that can be extracted from
this discussion is:
- There is no agreement between users willing to have pristine copies
in ".svn" dirs and users that doesn't want this "burden" in their hard
disks.
- Is obvious that these copies play an important role in the protocol
performance
So, my Eur 0.02 is: Why not to make this behaviour optional via a
command line switch or a more sticky mechanism (config files,
registry entries, etc.)? So, a user can select the option more suited for
its disk space/performance needs, always being aware that more disc
space -> more performance and the opposite.
Obviously I by no means am saying that this feature must be put in
the "urgent" feature list but that it can be taken into account for futures
releases as a facility.
Regards
On 9 Mar 2004 at 12:10, Erik Huelsmann wrote:
> > On 2004-03-08 23:52:16 +0000, Mike Mason wrote:
> > > One of Subversion's design axioms is "disk space is cheap". Saving it
> > > now is pointless.
> >
> > I think this should be reconsidered. One may have very large files
> > on not so large disks. And what about having a working copy on a
> > PDA? (I plan to do that.)
> >
> > I think that it would be important to allow to have a missing base
> > version of files (for instance, I have large files that I'll probably
> > no longer modify, and such copies of these files in the .svn/text-base
> > directory are useless).
>
> The axiom should probably read 'disk space is cheaper than bandwidth' which
> holds even on PDA's which presumably are going to use mobile phone
> connections to synchronize with repositories. Retrieving or sending full text-bases
> will make the Subversion communication protocols *much* slower than they
> currently are. Removing the text-bases will remove the ability to send diffs over
> the wire...
>
> bye,
>
> Erik.
>
> --
> +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
> 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 9 12:22:42 2004