On Wed, Feb 5, 2014 at 4:45 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Tue, Feb 4, 2014 at 7:25 AM, Stephen Connolly
> <stephen.alan.connolly_at_gmail.com> wrote:
>> Nope I cannot. I don't use windows, and I only use SVN for those projects I
>> work on that are still on SVN.
>>
>> I think you are missing the point that *everyone* has been trying to get you
>> to see...
>>
>> What is the benefit in stopping 1GB+ commits?
>
> In my experience, they're almost inevitably mistakes. They're often
> accidental including bulky binary files, which then are incredibly
> painful to "obliterate" from the repository because there is still no
> "obliterate" option for inappropriately stored files in the repository
> itself, and from the current code lines, there *never will be* such an
> option. The dump/filter/reload echanism is extremely painful for
> clearing such accidentally stored binaries.
That one is a nice use case for enforcing a maximum size on *files*,
not necessarily on the entire commit (i.e. use 'svnlook filesize' to
check in the pre-commit hook). If accidentally committing large
binaries is the problem that the OP wants to prevent, it's clear that
'svnlook filesize' is a good fit for his problem.
> The other common error is accidentally relocating large source trees,
> where an "mv" command is accidentally relocating entire sets of
> projects rather than merely branches.
That one is more difficult, and actually not a good fit for limiting
either file size or commit size (the commit in this case will be tiny,
since no files are transferred at all). That's more something for
other types of hooks (perhaps access control related) or something
like mod_dontdothat.
> I'm not saying this is easy to build into Subversion, the pre-commit
> filter would have to summarize and asses the size of the entire
> commit. I'm just saying there are reasonable reasons to want such a
> filter.
--
Johan
Received on 2014-02-05 10:59:51 CET