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

Re: Fwd: omitting history?

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-01-16 15:14:33 CET

On 1/16/2006 8:30 AM, Andy Levy wrote:
> Forwarding to the list, accidentally replied only to Karl before.
> ---------- Forwarded message ----------
> From: Andy Levy <andy.levy@gmail.com>
> Date: Jan 16, 2006 8:30 AM
> Subject: Re: omitting history?
> To: Karl Berry <karl@freefriends.org>
> On 1/15/06, Karl Berry <karl@freefriends.org> wrote:
>> Is it possible to tell subversion *not* to store history for certain
>> files? Or to "obliterate" changes for certain files after they have
>> been made? Perforce can do this (p4 obliterate), for example.
>> For our project (TeX Live), we have many megabytes of binaries we need
>> in our tree, the diffs for which will unnecessarily consume a whole lot
>> of resources.
> Have you tested this out yet? IIRC subversion does store diffs of
> binary files, so you may not be consuming multiple megabytes for each
> revision.

I don't know what Karl's binaries are like, but we have the same
problem, and there the binary diffs *are* large, because the files are
all compressed. For example, adding a 70K zip of a 300K text file to
the repository resulted in a 71K rev. Adding one line to that file,
rezipping and committing resulted in a 68K rev. Compare this to
committing the uncompressed file (107K used), then adding a line (2K).

We're using this to handle web pages, and it means we need two different
methods for distributing text content and frequently changing binary
content. It would be convenient if there were a way to include a file
in the repository, but not maintain any history of it. It goes against
the central idea of svn (a permanent record of the history of a file),
but it would certainly be handy for the secondary use as a way to make
files available to multiple users.

(By the way, I wrote the last sentence above from my own ideas of the
"central idea" and the "secondary use". It would probably be nice if
the Subversion developers put their own ideas of these things
prominently on the web page. Right now it just says "a compelling
replacement for CVS". The intro to the book is better, with

"That is, Subversion manages files and directories over time. A tree of
files is placed into a central repository. The repository is much like
an ordinary file server, except that it remembers every change ever made
to your files and directories."

This sentence captures the central idea, and should probably be
somewhere ahead of mentioning CVS on the web page. I don't know if the
devs want to support my "secondary use" or not.)

Duncan Murdoch

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 16 16:40:57 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.