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

Re: Storing unversioned files in a repository.

From: Jean-Luc Wasmer <jl.subversion_at_wasmer.ca>
Date: 2003-04-02 05:01:50 CEST

----- Original Message -----
From: Greg Stein <gstein@lyra.org>

> Personally, I can see unversioned files as a very handy feature. Yes,
> Subversion is a version control system, but an unversioned file type is a
> minor step to a great content management / publishing tool. I'm certainly
> not about to reject it out of hand. I'd be quite curious what it would
> actually take to implement such a thing.

I agree. I wanted this feature once (using CVS at the time).

I had two reasons to mix versioned and unversioned files:

1) We decided in the organization to have EVERY file within the same
repository. Just for consistency.
2) Maintenance is easier when files included in other files (like a picture
in a HTML file) are located in a directories which paths are relative the
paths of the files that include them.

The reason I didn't want a revision history for unversioned files is simple:
disk space.

Some files don't need versioning because they never change (like a
contract). They don't take more space in a version control tool than on a
regular public directory.

Unfortunately, most files that don't need versioning are files generated
from versioned source files. Having a script to generate them "on the fly"
is not always possible:
- no tool available (eg. convert a Visio drawing into a Gif file on a Unix
- the process is too slow (convert a OpenFlight file to a Tempest file can
take up to 5 minutes... For 80 files that's almost a day long). Our average
Tempest file is 20 MB... so that's between 1 and 2 gigs of disk space lost
at every release.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 05:01:35 2003

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

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