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

Re: Coping with repository bloat

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-14 12:37:18 CEST

Pete Gonzalez wrote:

> At 12:20 AM 5/14/2004, you wrote:
>> No, Subversion is exactly just version control. I never understand
>> what's wrong with putting the unversioned data on network filesystem.
> Heh, you must be one of those "relatively small projects" guys
> I was alluding to. ;-)

Oh be serious. Is 100 developers and 7Mloc small? Yes I've worked on
such a project, and we did keep our unversioned bits on a well-known
network share.

> Seriously though, suppose some of your GUI windows rely on lots
> of bitmap images, and that your math code depends on source files
> containing huge lookup tables generated by various tools that
> are complex to setup. It's very desirable to have this stuff
> included automatically during a checkout. Although nobody cares
> about "revision histories" for these files, they do present very
> similar version control problems as ordinary source code.
> You will no doubt propose that we simply copy these files to an FTP
> server and instruct the team to periodically download the data files
> to their source code directory, or maybe use rdist or somesuch. But
> have you ever worked on a project with hundreds of data files being
> edited by different people? It's a huge mess, because people are
> always overwriting each others' files, forgetting to delete deadwood,
> etc. Since these files are already in the source code directory tree
> (and many of them are in fact source code), it actually seems quite
> strange to ask that they be managed by a separate filesystem.

All right, providing *integrated* exclusive access to unversioned files
is the best argument to date. Of course, Subversion hasn't a chance of
doing this until it supports exclusive locks -- my pet project for 1.1 :-)

>>> data", but removing data is not losing data. My filesystem doesn't
>>> lose
>>> data, but that doesn't mean it doesn't support unlink().
>> This comparison is tricky, because there are two kinds of "unlink"
>> in Subversion: "svn remove", which we have, and "svn obliterate",
>> which is on the wishlist. The latter would remove all traces of a file,
>> its data and history, from the repository.
> There also seems to be a strong (and valid) design concept of "never lose
> Correct -- this is exactly like implementing "rm -Rf *" and then
> arguing that the ability to delete individual files would be
> "overkill". :-D

Oh I'm sure "svn obliterate" will accept the -r to restrict the range of
revisions, if that's what you mean.

> Once again, you need to think from the perspective of BIG projects,
> where a single file's history might have thousands of revisions.
> Think about that... a file history window with a THOUSAND entries.
> This is exactly the case where complicated global dump/filter
> operations are completely infeasible, and simply regenerating a
> new repository with no history would be too extreme. Subversion's
> job is to manage revisions, and I see nothing outlandish about
> people asking for the ability to manage revisions that occurred
> in the past.

I agree. Like I said, the functionality is on the wishlist, but it
probablu won't happen soon. I'd be pleasantly surprised if it will
happen during the 1.x cycle.

> I want to write a check-in hook that deletes the histories
> of .bmp files except for their most recent 3 revisions. Is
> that crazy?

It's...interesting. But I see your point.

> This seems like exactly the kind of problem that
> version control models are supposed to facilitate.

Yup. I'll just note that we've now moved away from the "unversioned" to
the "versioned in a limited number of instances" world, and this is
_way_ more complicated.

What I'd like to see is discussion about how unversioned files behave
wrt branching and merging, for example; the edge cases are interesting/

-- Brane

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 12:39:53 2004

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.