You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bill Hoffman <bi...@kitware.com> on 2008/10/22 18:58:39 UTC
svn config file and mime types
So, this is a feature request of sorts.
We are using commit checks to make sure mime types are set correctly in
our repository. This works great. However, it means that each client
must have a correctly configured client.
Basically something like this:
UNIX ~/.subversion/config
Cygwin ~/.subversion/config
Windows ~/Application Data/Subversion/config
The problem is that this config file is not under version control! Each
user has some random copy of it from when they installed svn. There is
no way to update this file for all of the users other than sending out
an email.
There should be some way to store this file in the repository itself.
Maybe svn could first look here:
UNIX ~/.subversion/config
Cygwin ~/.subversion/config
Windows ~/Application Data/Subversion/config
Then append anything it found in the root of the project tree with the
name config. Basically, this information should be part of the project
or repository. I maybe missing something. Is there a better way to do
this? Right now we have a wiki entry that has a list of mime types that
you have to copy into your config file. Almost without fail each new
user forgets or mis-configures the file. Then things become a mess.
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Bill Hoffman <bi...@kitware.com>.
Ryan Schmidt wrote:
>
> On Oct 22, 2008, at 21:35, Bill Hoffman wrote:
>
>> Ryan Schmidt wrote:
>>
>>> You are welcome to put that file or any other file into your
>>> repository and instruct your users to run "svn up" on the config
>>> directory on occasion.
>>
>> Sure, but that is leaving the update as something each user has to
>> remember to do. Why not make it part of the process?
>>
>>>> Right now we have a wiki entry that has a list of mime types that
>>>> you have to copy into your config file. Almost without fail each
>>>> new user forgets or mis-configures the file. Then things become a
>>>> mess.
>>>
>>> But you have a pre-commit hook that ensures things that come into the
>>> repository have the right properties, yes? And if not, it prints an
>>> error message to the user? The message to the user can tell them what
>>> to do to fix it, be that manually copying data from a wiki page into
>>> their config file or running "svn up" on their config directory.
>>
>> Yes, I do, but here is what always happens.
>>
>> 1. new users gets access to repository.
>> 2. new user tries to add lots of files (say 100's )
>> 3. new user gets tons of errors from the pre-commit hook
>> 4. I tell user to fix config file
>>
>> Also, the process for getting the config file in the right place is
>> different for each install of svn (Mac,Linux, and Windows).
>>
>> I guess my main point is that this is a project decision and not an
>> individual user decision. The pre-commit hook can prevent them from
>> checking in stuff that we don't want in the repository. But why stop
>> at prevention. Why not just do it for them? By having the pre-commit
>> hook on the repository, I am saying that I will not allow files
>> without mime types set. So, why make the user do extra work? Why
>> not have a way for the project to define a configuration file that
>> affects all new files in the project?
>
> It's a long-standing feature request:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
>
Figures. This really is a pain in the neck. I have a problem right now
with a user trying to commit 1 gig of files and I am basically going to
have to turn off the commit check, as the config file does not match all
the types, and he basically gave up...
It might be good to be able to just set a default mime type on a project.
>> Or is there a way for the pre-commit hook to set the mime types if
>> they are not already set?
>
> Not easily. You could write a post-commit script. The server would have
> to maintain its own working copy, and after every commit, update that
> working copy, set the MIME types as you want them, and do a second
> commit. And then the person who did the first commit would have to know
> to immediately update their working copy to receive those property
> changes. Not ideal. IMHO it's preferable to teach the developers to set
> the properties correctly before committing.
No it would be better to implement the above feature request...
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 22, 2008, at 21:35, Bill Hoffman wrote:
> Ryan Schmidt wrote:
>
>> You are welcome to put that file or any other file into your
>> repository and instruct your users to run "svn up" on the config
>> directory on occasion.
>
> Sure, but that is leaving the update as something each user has to
> remember to do. Why not make it part of the process?
>
>>> Right now we have a wiki entry that has a list of mime types that
>>> you have to copy into your config file. Almost without fail each
>>> new user forgets or mis-configures the file. Then things become
>>> a mess.
>>
>> But you have a pre-commit hook that ensures things that come into
>> the repository have the right properties, yes? And if not, it
>> prints an error message to the user? The message to the user can
>> tell them what to do to fix it, be that manually copying data from
>> a wiki page into their config file or running "svn up" on their
>> config directory.
>
> Yes, I do, but here is what always happens.
>
> 1. new users gets access to repository.
> 2. new user tries to add lots of files (say 100's )
> 3. new user gets tons of errors from the pre-commit hook
> 4. I tell user to fix config file
>
> Also, the process for getting the config file in the right place is
> different for each install of svn (Mac,Linux, and Windows).
>
> I guess my main point is that this is a project decision and not an
> individual user decision. The pre-commit hook can prevent them
> from checking in stuff that we don't want in the repository. But
> why stop at prevention. Why not just do it for them? By having
> the pre-commit hook on the repository, I am saying that I will not
> allow files without mime types set. So, why make the user do
> extra work? Why not have a way for the project to define a
> configuration file that affects all new files in the project?
It's a long-standing feature request:
http://subversion.tigris.org/issues/show_bug.cgi?id=1974
> Or is there a way for the pre-commit hook to set the mime types if
> they are not already set?
Not easily. You could write a post-commit script. The server would
have to maintain its own working copy, and after every commit, update
that working copy, set the MIME types as you want them, and do a
second commit. And then the person who did the first commit would
have to know to immediately update their working copy to receive
those property changes. Not ideal. IMHO it's preferable to teach the
developers to set the properties correctly before committing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Bill Hoffman <bi...@kitware.com>.
David Weintraub wrote:
> On Sat, Oct 25, 2008 at 11:55 PM, Bill Hoffman <bi...@kitware.com> wrote:
>> That is not really what I had in mind. I was thinking that each project
>> could have a config file. Maybe it is a property set on the project.
>> If you could set a property for that project in svn that marked a file in
>> the tree as the config file. Then svn would look at that file for config
>> information. It would always be a file that is on the client. So, the svn
>> command would not have to talk to the server.
>>
>> So, something like this:
>>
>> svn propset config src src/config
>>
>> That would set the config property on the directory src. It would say that
>> in the src tree there is a file located at src/config.
>
> As far as the Subversion client is concerned, each directory in your
> working directory is the root of the Subversion tree. That's why each
> directory has its own .svn file.
OK, so what if the config property was global for a tree. The data for
the config file would be duplicated to all .svn directoires that it was
set on. svn propset config src/config --recurse or something like
that. It would push the config information into all .svn directories
and store the information in the .svn directory of each.
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by David Weintraub <qa...@gmail.com>.
On Sat, Oct 25, 2008 at 11:55 PM, Bill Hoffman <bi...@kitware.com> wrote:
>
> That is not really what I had in mind. I was thinking that each project
> could have a config file. Maybe it is a property set on the project.
> If you could set a property for that project in svn that marked a file in
> the tree as the config file. Then svn would look at that file for config
> information. It would always be a file that is on the client. So, the svn
> command would not have to talk to the server.
>
> So, something like this:
>
> svn propset config src src/config
>
> That would set the config property on the directory src. It would say that
> in the src tree there is a file located at src/config.
As far as the Subversion client is concerned, each directory in your
working directory is the root of the Subversion tree. That's why each
directory has its own .svn file.
Let's say you set this property on your src directory, but now you are
three or four directories deep below your src directory. How would
your Subversion client know that it needs to go up four or so
directories to find the config directory. As you also pointed out, if
someone checks out a directory below your src directory, then
Subversion really has no way of knowing what your config file looks
like since it isn't even in your working directory.
It really becomes pretty much the same scenario as I pointed out in my
earlier post, your Subversion client would have to work its way up
your directory structure checking each and every directory for the
configuration file property, then if it did find it, it would have to
find the property file to read. It isn't an impossible task, but it
does add some overhead to the Subversion client.
Not that it is necessarily a bad idea. One of the problems with
Subversion is that it doesn't lend itself out to more complex
configuration management techniques. For example, what if you work on
two totally different projects under two totally different
departments. And, each department has its own idea of how the
Subversion configuration file should be set. This can't easily be done
with Subversion. Then again, Subversion isn't for everyone and was
never meant to be.
A lot of people have asked me which is the best revision control
system, and there is really no answer to that. Each system has its
advantages and disadvantages. Subversion's main advantage is that it
is easy to administer, easy for most developers to understand, and is
open source and free.
Another big advantage is that Subversion's protocol is fully mapped,
so anyone can develop their own client. Thus, we can have TortoiseSVN,
Subclipse for Eclipse, and even a Subversion client for XCode. There
must be at least three dozen Subversion clients of various sorts.
As I said, the idea of multiple configurations that can be centrally
controlled is not a bad idea, its just that some design decisions that
Subversion made makes that virtually impossible to do. For example,
Subversion was designed so developers can easily work "off line". You
can edit files, add files, and delete files without being connected to
the server, and that makes it extremely difficult to have centralized
server control.
In theory, someone could modify the Subversion command line client to
do exactly what you stated. Of course, that means that the three dozen
or so Subversion clients would have to be able to do something
similar, and I doubt that the people who maintain the Subversion
project will accept such changes in Subversion -- at least in the
short term -- due to the complications of coordinating these changes
into the three dozen or so Subversion clients not to mention to the
overhead in maintenance, documentation, and programming overhead to
implement such a feature.
In practice, I have found that a little training and documentation
will help your programmers understand what they need to do. On my
company's Wiki is a page entitled "Subversion for Dummies and/or
Developers" which explains the basics of Subversion, where our
repository is located, how to log in, etc. I also explain about
configuring their system and have a copy of the Subversion config file
attached to the document.
The developers do gripe about Subversion, and it rejecting changes
because they're missing a property. But, the auto-properties does
solve these issues, and developers do get the idea fairly quickly. As
for the griping, I hear it no matter what the version control system
we use.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Bill Hoffman <bi...@kitware.com>.
David Weintraub wrote:
> On Sat, Oct 25, 2008 at 10:34 AM, Bill Hoffman <bi...@kitware.com> wrote:
> Server side configuration files is not an easy addition into
> Subversion. Maybe the trick is to allow a configuration directory in
> the root of a project, and if that exists, have Subversion use that
> instead of the one in the user's $HOME directory. This could be a
> .subversion/config just like under the user's $HOME directory.
>
> Of course, Subversion has no way of knowing what is the root of the
> project, or what would happen if someone checks out a directory that
> is not in the root of a project. For example, I have a file
> svn://localhost/myproj/trunk/.subversion/config. That way, anyone who
> checks out this project, will get the config file under the
> .subversion directory. But, if this is a Maven project, there will be
> a src/main/java/com/company/myproj directory. If I am in this
> directory, the Subversion client would have to know that the config
> file is located at ../../../../../.subversion/config. Also, it is
> possible that someone decides to only checkout the
> svn://localhost/myproj/src/main/java/com/company/myproj directory
> since they only have to make minor changes in the Java code. No need
> to checkout the entire project tree! Now, the Subversion client would
> have no way of knowing that there is a special .subversion/config file
> for this project since the developer didn't even bother to checkout
> the directory that contains the project's config file.
>
> Which really just shows how hard it actually is to get a project
> configuration file in Subversion to work. Remember that Subversion is
> designed to work without a constant server connection. One of the
> biggest complaints about Perforce and ClearCase is that they prefer to
> be connected to the server in order to work. One of Subversion's
> advantages is its ability to work in a disconnected fashion.
>
That is not really what I had in mind. I was thinking that each project
could have a config file. Maybe it is a property set on the project.
If you could set a property for that project in svn that marked a file
in the tree as the config file. Then svn would look at that file for
config information. It would always be a file that is on the client.
So, the svn command would not have to talk to the server.
So, something like this:
svn propset config src src/config
That would set the config property on the directory src. It would say
that in the src tree there is a file located at src/config. When the
svn command did an add for a directory src or below, in addition to
adding the .subversion/config file, it would also read src/config as a
config file. That way a project could store the config file in itself.
svn would still not have to talk to the server before adding a file.
Now this does fail if you do not check out the whole project. The only
way around that would be to duplicate the config file in each directory
that is checked out from the server. The duplication would be on the
client side. I guess a copy could just be stored in each .svn
directory. You would set the property on the root of the project tree,
and then when you did the checkout of any file or directory it would be
put into each .svn directory that is created.
Although I bet a lot of folks would be happy if it worked with the whole
project being checked out.
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by David Weintraub <qa...@gmail.com>.
On Sat, Oct 25, 2008 at 10:34 AM, Bill Hoffman <bi...@kitware.com> wrote:
> The real solution is to put the config file for a project into the project,
> that would do the trick. Seems like a pretty simple modification to svn.
>
> When the svn command is run, it would load the config file from the usual
> locations, and then it would load one from the project if it exists.
But that means that every time the "svn" command executes, you need
access to the server. In Subversion, this isn't always the case. In
fact, the "svn add" command is a perfect example where the server
isn't contacted,, and the "svn add" command is exactly where your
project needs to contact the server to get the configuration too.
Server side configuration files is not an easy addition into
Subversion. Maybe the trick is to allow a configuration directory in
the root of a project, and if that exists, have Subversion use that
instead of the one in the user's $HOME directory. This could be a
.subversion/config just like under the user's $HOME directory.
Of course, Subversion has no way of knowing what is the root of the
project, or what would happen if someone checks out a directory that
is not in the root of a project. For example, I have a file
svn://localhost/myproj/trunk/.subversion/config. That way, anyone who
checks out this project, will get the config file under the
.subversion directory. But, if this is a Maven project, there will be
a src/main/java/com/company/myproj directory. If I am in this
directory, the Subversion client would have to know that the config
file is located at ../../../../../.subversion/config. Also, it is
possible that someone decides to only checkout the
svn://localhost/myproj/src/main/java/com/company/myproj directory
since they only have to make minor changes in the Java code. No need
to checkout the entire project tree! Now, the Subversion client would
have no way of knowing that there is a special .subversion/config file
for this project since the developer didn't even bother to checkout
the directory that contains the project's config file.
Which really just shows how hard it actually is to get a project
configuration file in Subversion to work. Remember that Subversion is
designed to work without a constant server connection. One of the
biggest complaints about Perforce and ClearCase is that they prefer to
be connected to the server in order to work. One of Subversion's
advantages is its ability to work in a disconnected fashion.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Bill Hoffman <bi...@kitware.com>.
David Weintraub wrote:
> I don't even want the option to run hooks on client machines. It
> simply causes more problems than it is worth. I like the way
> Subversion handles hooks and I don't want it to change.
>
Agreed doing this from a commit hook would not be practical. I was just
looking for a hack.
The real solution is to put the config file for a project into the
project, that would do the trick. Seems like a pretty simple
modification to svn.
When the svn command is run, it would load the config file from the
usual locations, and then it would load one from the project if it
exists. Having the config file complete separate from the projects is a
real pain. Without fail anyone that converts from CVS to SVN at my
company complains about this issue. They try to do a commit and the
commit hook yells at them, then they spend 15 minutes or so trying to
figure out how to put the config file in the right place for the
particular installation of svn. Then they have to restart and try to
add the files all over again. Or run the set mime stuff from the
command line.
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by David Weintraub <qa...@gmail.com>.
On Wed, Oct 22, 2008 at 10:35 PM, Bill Hoffman <bi...@kitware.com> wrote:
> I guess my main point is that this is a project decision and not an
> individual user decision. The pre-commit hook can prevent them from
> checking in stuff that we don't want in the repository. But why stop at
> prevention. Why not just do it for them? By having the pre-commit hook on
> the repository, I am saying that I will not allow files without mime types
> set. So, why make the user do extra work? Why not have a way for the
> project to define a configuration file that affects all new files in the
> project?
>
This would require access to the user's working directory and having
the user's permission to munge their files upon commit.
ClearCase does just that. When you execute a "check in" in ClearCase,
it runs the ClearCase pre-op checkin triggers (what Subversion calls
the pre-commit hook) on the user's machine and using the user's view.
Thus, in ClearCase you could write a hook (trigger in ClearCase's
parlance) to do exactly what you want -- modify the user's commit
before the commit actually takes place. If the user is suppose to
enter a defect number, you could query them. If the user needs a
special property on that file, you could do just that. If the user had
the file formatted wrong, you could correct the error during the
commit. Sounds just great!
Now, why I think that is an utterly stupid idea:
Since the hook runs on the user's system, it means that you have to
ensure that the user's system is correctly configured to run the hook.
Does the user have Python or Perl or whatever you are using installed?
Are all the correct modules needed installed? Are their directories
and mount points or network shares setup as you think they should be?
Congratulations, you now have to be responsible for making sure each
user's system is correctly configured.
Imagine a user environment of say 100 people, and an average
developer's PC lasts about four years. That means you have at least 25
percent of your users needing their systems reconfigured each year.
That means you're configuring at least one user's system every two
weeks. Don't forget new employees who get new machines (what is the
turnover in a typical development shop?) and users who suddenly have
new projects or those Windows system updates that seem to destroy your
carefully balanced environment. You could be spending 20% of your time
doing nothing but configuring users' computers.
Now, there's that guy who want to work from home. You can't configure
that system! What do you do? Tell developers they can't work from home
or over the weekend?
With Subversion's system, you only have one computer that has to be
configured to run your hook: The server. You get that working, you're
fine. Users can use any computer or any Subversion client they want.
If they made a Subversion client for the iPhone, and some goof ball
wants to use that, it's not your problem.
I was a ClearCase administrator for almost 15 years, and hooks
(triggers in ClearCase parlance) were the biggest pain because someone
always had a system where it didn't work. You did all sorts of tricks,
and checks, and sooner or later it will break. Even worse if there's
an upgrade and you're now stuck making sure all users have the upgrade
installed correctly. Plus, there's always some bozo who learns how to
get around the hooks. You can't get around a server-side hook.
I have a Subversion configuration file with the auto-properties
already configured for our project on our Wiki. This includes
installation instructions, etc. After a few failed commits because
they don't have the right properties on their files, users learn to
setup their Subversion clients to do the auto-properties. After a few
failed commits because they didn't put the defect ID in the ticket,
they learn to do it without thinking.
I don't even want the option to run hooks on client machines. It
simply causes more problems than it is worth. I like the way
Subversion handles hooks and I don't want it to change.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Bill Hoffman <bi...@kitware.com>.
Ryan Schmidt wrote:
> On Oct 22, 2008, at 13:58, Bill Hoffman wrote:
>
> You are welcome to put that file or any other file into your repository
> and instruct your users to run "svn up" on the config directory on
> occasion.
>
Sure, but that is leaving the update as something each user has to
remember to do. Why not make it part of the process?
>> Right now we have a wiki entry that has a list of mime types that you
>> have to copy into your config file. Almost without fail each new user
>> forgets or mis-configures the file. Then things become a mess.
>
> But you have a pre-commit hook that ensures things that come into the
> repository have the right properties, yes? And if not, it prints an
> error message to the user? The message to the user can tell them what to
> do to fix it, be that manually copying data from a wiki page into their
> config file or running "svn up" on their config directory.
>
>
>
Yes, I do, but here is what always happens.
1. new users gets access to repository.
2. new user tries to add lots of files (say 100's )
3. new user gets tons of errors from the pre-commit hook
4. I tell user to fix config file
Also, the process for getting the config file in the right place is
different for each install of svn (Mac,Linux, and Windows).
I guess my main point is that this is a project decision and not an
individual user decision. The pre-commit hook can prevent them from
checking in stuff that we don't want in the repository. But why stop at
prevention. Why not just do it for them? By having the pre-commit hook
on the repository, I am saying that I will not allow files without mime
types set. So, why make the user do extra work? Why not have a way
for the project to define a configuration file that affects all new
files in the project?
Or is there a way for the pre-commit hook to set the mime types if they
are not already set?
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn config file and mime types
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 22, 2008, at 13:58, Bill Hoffman wrote:
> We are using commit checks to make sure mime types are set
> correctly in our repository. This works great. However, it means
> that each client must have a correctly configured client.
>
> Basically something like this:
>
> UNIX ~/.subversion/config
> Cygwin ~/.subversion/config
> Windows ~/Application Data/Subversion/config
>
>
> The problem is that this config file is not under version control!
> Each user has some random copy of it from when they installed svn.
> There is no way to update this file for all of the users other than
> sending out an email.
>
> There should be some way to store this file in the repository
> itself. Maybe svn could first look here:
> UNIX ~/.subversion/config
> Cygwin ~/.subversion/config
> Windows ~/Application Data/Subversion/config
>
> Then append anything it found in the root of the project tree with
> the name config. Basically, this information should be part of the
> project or repository. I maybe missing something. Is there a
> better way to do this?
You are welcome to put that file or any other file into your
repository and instruct your users to run "svn up" on the config
directory on occasion.
> Right now we have a wiki entry that has a list of mime types that
> you have to copy into your config file. Almost without fail each
> new user forgets or mis-configures the file. Then things become a
> mess.
But you have a pre-commit hook that ensures things that come into the
repository have the right properties, yes? And if not, it prints an
error message to the user? The message to the user can tell them what
to do to fix it, be that manually copying data from a wiki page into
their config file or running "svn up" on their config directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org