> > 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.
Ok, that makes a lot of sense.
> > 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.
True, but those examples are different. Each of those is an example of
something Subversion explicitly supports and allows, but which for some
installations may be undesirable (and, for others, perfectly ok). That
sort of site policy enforcement clearly belongs in hooks.
On the other hands "incorrect line endings" in svn:ignore is a new
Subversion notion; users don't particularly care one way or the other
and neither did Subversion before 1.6. So it's an internal restriction
rather than a site policy choice, as in the hook examples you gave.
Yes, as with the dump/filter/load, putting such a hook script in place
is a reasonable *workaround* for the lack of Subversion handling of this
issue. But only a workaround.
paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1459085
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-28 19:08:36 CET