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

Re: Keeping stuff out of my repository?

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Thu, 30 Oct 2008 14:41:57 -0500

On Oct 30, 2008, at 13:25, caston first wrote:

>>> Is there ANY way I can enforce my repository's ignore rules? I know
>>> it's kind of a mainframe mentality but the added hassle is just
>>> driving me
>>> insane...
>>
>> You can reject commits with a pre-commit hook. See the text of
>> hooks/pre-commit.tmpl in any repo.
>
> But unfortunately, the Book says: "do not modify a commit
> transaction using hook scripts."

Right. Do not modify a commit. Merely inspect it, and either accept
or reject it as a whole.

> Essentially what I want to do is enforce the ignore list, not
> create more work for people importing their code base. (I do not
> agree with the Book's assertion that people will learn good habits
> if I deny their commits -- they're more likely to just give up and
> email me a tarball.)

You can't modify the commit to silently ignore some of the files that
have been committed (or in any other way for that matter). You can
only accept or reject the whole commit.

> I suppose there's some kind of script I could write to continually
> walk the repository, or maybe use a pre hook to write a URI file of
> stuff to auto-delete. Am I the only one who's ever had this issue?

I wouldn't recommend auto-deleting things from the repository after a
successful commit.

For one thing, it wastes space in the repository. Suppose you were
wanting to prevent people from committing enormous disk image files
to the repository. If you allow the commit and then silently
subsequently delete the file, the space for that disk image is still
used in the repository.

Second, what if the developer really did mean to commit that file?
They will be confused that their commit succeeded but the file is
then not in the repository. If you were to instead reject the commit
in the first place, the developer would learn via the pre-commit
hook's stderr output why that type of file is not permitted.

Perhaps the most insidious reason not to do this: Consider the
sequence of events:

Developer adds a type of file they shouldn't have
Developer commits
Repository accepts the bogus file
Some script runs which auto-removes the bogus file with "svn rm"
Developer updates working copy
The bogus file is removed from the developer's working copy!

What if that was a file the developer needed? Now it's gone, and he
has to go hunt through the repository history to find the revision
where it was added and retrieve it from the repository. This would be
very annoying.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-30 20:42:40 CET

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

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