Erik Huelsmann wrote:
>
>>> Subversion supports that model by not making more copies of a file
>>> than necessary: all revisions for which a file is the same share
>>> storage. So, for files which change infrequently, you shouldn't be
>>> hesitant to store them in your repository.
>> But... there are files that do change frequently and files where old
>> instances have no use at all - and it would still be nice to be able to
>> use subversions's access mechanisms to store and distribute them. And,
>> of course, it would be nice to have a reasonable way to undo accidental
>> commits of things that don't belong in the repository at all or can't
>> remain for legal or political correctness reasons.
>
> Nice, yes. But: it's not what Subversion is designed for nor will it
> ever be a goal for Subversion.
I think that's an impractical view, since being unable to manage
repository content in all of the commonly needed ways hinders any goals
you might otherwise have.
> If you want to simply distribute files,
> there are other solutions which may work equally well or better. So,
> don't be surprised you're seeing some resistance here.
Of course it is possible to implement a different mechanism to manage
and distribute every separate file and tune each perfectly to the nature
of each file type. But that seems like a bad idea compared to having
people learn to commit changes and update to get new versions.
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
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 18:05:22 CET