On Mar 28, 2009, at 09:48, Paul Koning wrote:
>> On Mar 27, 2009, at 15:43, B Smith-Mannschott wrote:
>>
>>> I now have a 1.6 GB repository which I no longer able to back up
>> using
>>> svnsync. Correcting the problem would mean dumping, editing the
> huge
>>> dump file and reloading the repository. I have no way of preventing
>>> this from occuring again since the server doesn't protect itself
>>> against misbehaving clients.
>>
>> I have not tested to verify this problem. But I agree Subversion
>> should prevent it. Until it does, you can prevent it by writing a
>> pre-
>> commit hook which tests the svn:ignore property (and possibly
>> svn:externals and others). If you want to correct the problem in your
>> existing revisions and can tolerate a dump and load cycle,
>> svndumptool should be able to help you.
>
> I don't think that's the right approach.
>
> If Subversion starts to enforce a restriction that it didn't
> enforce in
> an earlier version, it's the responsibility of Subversion -- not of
> the
> admin -- to provide backwards compatibility.
I agree. With the dump/filter/load cycle I was suggesting a way that
the OP could move forward in the present absence of that support from
Subversion.
> Preferably it should
> accept the older, less restricted, data. Failing that, it should
> provide a conversion process. Telling admins they have to construct
> hook scripts to deal with something Subversion did to them is not a
> good
> answer.
Hook scripts have often been the answer to restricting things from
going into the repository that are generally a bad idea. In this
case, prevent properties from having incorrect line endings.
Personally, I think it's a good idea to also prevent case-only
filename collisions, prevent filenames that are problematic on
Windows (there's a whole list), prevent backup files, maybe you want
to prevent files greater than a certain size, etc. etc.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1458716
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-28 18:32:00 CET