On Fri, 2008-10-31 at 14:48 +0000, Rob Hubbard wrote:
> Hello Caston,
>
>
> Don't forget that in addition to the per-directory svn:ignore, there's
> also
> a global-ignores section in the SVN config file.
>
> Often it is possible to balance the nuisance of implementing policies on
> the
> repository with some helpful automation in the clients.
>
> Why don't you make available a "standard" or "template" config file to
> offer
> some balance to the policies you implement in the pre-commit hook?
>
> For example, if your pre-commit hook rejects all "*.obj" files being
> added,
> then include "*.obj" in the global-ignores in the config. This won't
> prevent
> someone explicitly trying to add a *.obj, but it will certainly help
> them to
> avoid accidentally adding them. (And make sure your programmers are
> aware of
> the problems of "shell expansion": with shells such as Bash, an
> unquoted "*"
> will be expanded by the shell, not by SVN.)
>
> As another example, if your pre-commit hook checks that added files have
> particular properties set (e.g. svn:eol-style, svn:executable,
> svn:mime-type), then include those as auto-props in the SVN config
> file.
>
> See the sections
>
>
> http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.pre-commit.html
>
>
> http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposa
> dmin.create.hooks
>
>
> http://svnbook.red-bean.com/en/1.5/svn.advanced.props.html#svn.advanced.
> props.auto
>
> in the manual for details.
>
> One problem with this is that you must distribute the config file, and
> try
> to keep everyone up to date. But why not use subversion itself to do
> this?
> You could set up a copy of the config file in the repository at a URL
> such
> as
> http://svn-repos/meta/configuration/svn-clients/config
> and then have all users checkout the directory URL
> http://svn-repos/meta/configuration/svn-clients/
> to their local machines at
> C:\Documents and Settings\[username]\Application Data\Subversion\
> or
> /etc/subversion/
> or wherever the config happens to be located on the machine.
>
> Then to update, they just, (svn) update!
>
>
> I hope that adds to the help already given by others.
>
> Regards,
> Rob.
>
>
> Rob Hubbard.
>
>
> > -----Original Message-----
> > >>> 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...
>
> ________________________________________________________________
Rob, et al.
The problem with the current Subversion implementation is not manifested
when using a single source code repository. I can almost even buy into
it when you have many static developers. However, this changes if you
have to work against multiple repositories with conflicting
requirements. For instance - if I have to work on a .Net web project
for part of my day and then switch to a Java project and then switch to
a different .Net project. I have each of these workspaces on my
computer. Each project has different "requirements" for what should or
should not go in. The challenge becomes harder when working with other
disparate groups that are only temporarily working with certain segments
of our code base (corporate partners, special projects, etc). It
doesn't matter how small the section, every subversion client that
touches the systems needs to be configured.
The concept of the pre-hook script is ok, but the only thing it will do
is tell me that I have done wrong. Most likely not _exactly_ what is
wrong or what I might need to do to remedy this. Global-ignores is
useless in the multi-repository case. SVN:ignore will work if I
remember to add it to each additional folder that I or another developer
might add to whatever project. I love Subversion. Try working with guys
who are MS zealots who think this one gap makes this product so much
less than theirs (ugh)...
Anyway - there is this bug -
http://subversion.tigris.org/issues/show_bug.cgi?id=1974 - anyone
wanting to discuss this bug should make a note of it in their mailing
list subject and continue the discussion. The more _constructive_ the
discussion the more likely we could see movement on this topic.
I think if 1) there is enough community interest and/or 2) someone has
the time to implement it after some agreed upon core functionality then
all of us waiting for this could be very happy. Merge tracking took a
lot of discussion and time, but the wait was definitely worth it. Shout
out to the Subversion Dev Team!
Sorry for the ramble...
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-01 00:05:03 CET