Paul Koning wrote:
>> >> <madscientist343_at_gmail.com> wrote: > Hi, I am looking to submit a
> >> feature request for unversioned files > stored in the repository
> >> along with normal versioned files. This could > be beneficial for
> >> files such as project licenses which apply to all > revisions
> >> Why would these need to be unversioned but in the repository? Put
> >> them in normally, and if they never change, how is it different
> >> from keeping them in the repo, unversioned?
> Mad> The benefit would be when the files do need to be changed and
> Mad> applied to previous revisions ( eg a license that covers all
> Mad> files in the repository ) you are able to change them on every
> Mad> revision( from the view of a working copy ) instead of just
> Mad> changing the latest revision.
> You might be able to do this with externals.
> Then again, it strikes me that what you're proposing is positively
> evil -- something that goes directly against what any source control
> system should do. The whole point of source control is to be able to
> see history. The mechanism you describe specifically aims to destroy
> history. This is bad. Subversion must not consider ever doing such a
Except that preserving all history of everything forever is impractical
and at some point becomes impossible and will thus cause you to lose it
all. So it is not as evil as you might think to be selective about what
you keep. And it is a very practical choice to not want to duplicate
your access/distribution infrastructure and user training to also manage
content that doesn't need to be archived forever. The only reasonable
approach I can see to this with a current subversion setup is to use
http access to permit using multiple repositories under what looks like
a single url, then periodically purge and reconstruct the repositories
that contain disposable contents. You can also provide http access
through viewvc as a simple way to grab the current version. And it is
still an administrative decision regarding when/what to purge, requiring
file level access to the repository.
This is just a special case of the need for a better administrative tool
to remove unwanted content.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-12 17:32:06 CET