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

Re: svn config file and mime types

From: David Weintraub <qazwart_at_gmail.com>
Date: Sun, 26 Oct 2008 00:53:04 -0400

On Sat, Oct 25, 2008 at 11:55 PM, Bill Hoffman <bill.hoffman_at_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_at_gmail.com
---------------------------------------------------------------------
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-26 05:53:24 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.