[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [feature request]: prevent subversion from keeping track of changes

From: Jared Hardy <jaredhardy_at_gmail.com>
Date: 2007-02-26 22:28:25 CET

On 2/23/07, Steffen Gumpert <me@privacy.net> wrote:
> Hi,
> I know the subject sounds a little strange to be a feature
> request addressed to a version control system. So let me
> explain: most development environments store their project-
> oriented settings in text files within the project directory.
> And most of this information changes very frequently
> (nearly every commit) and is not a point of interest to
> keep track of its changes. But some information (such as
> the current version, release- and build-number the compiler
> uses to generate the executable) is important. But indeed
> not its history (moreover, one can run into trouble under
> some circumstances).
> To prevent the repository from beeing blown up by needless
> information, I found it useful to be able to tell subversion
> only to hold the latest version of a particular file
> (lets say by a new property) and so overwrite the current
> repository entry at each commit of this file. (The revision
> number of this file should then always be 1 or 0 to show
> this special treatment).
> Would this be possible?
> Thanks for your comments, Steffen.

I just wanted to note that such a feature would be useful for large
binaries, or compressed files, where everyone should have the latest
version as part of any atomic update, but file diff history (except
for path position and other low-cost meta-data) is not important.
Storing diff history would take too much storage, and would be very
inefficient for compressed files. A user-defined history-depth limit
value definition method would be even better (the use-case example
described here would be depth 1).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 26 22:28:40 2007

This is an archived mail posted to the Subversion Dev mailing list.