[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:41:21 CET

On 1/16/2006 9:33 AM, Andy Levy wrote:
> On 1/16/06, Duncan Murdoch <murdoch@stats.uwo.ca> wrote:
>> 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).
> Good point, and why I asked if he'd tested yet. Depending upon upon
> the type of files, diffs may not be efficient.
>> 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.
> Is your binary content generated from text files (source) that's also
> in the repository? If so, why not store just the source and generate
> the binaries when doing a release to the site? This would work best
> with zipfiles and executables, obviously.

That's what we do for some of the binaries. But others are generated on
different machines (e.g. I do Windows builds, but the main web site is
hosted on Linux). My build script makes a copy of the Windows binaries
available, and the main site copies them.

And if someone wants a copy of the site, they need to use rsync or wget
(and not get the Subversion history), or a mixture of svn and one of those.

It would be more convenient if I could just do a build and a commit, and
have the main site do an update to get them displayed.

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 17:57:11 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.