Matt and Loren,
It is good to see that this topic is being addressed once again. I am
currently in the process of moving my company's former version control
system that used shared files to Subversion. I have used shared files
extensively in the past, and the practice has worked flawlessly for me
for my ten years of enterprise development. I understand many of the
arguments against using shared files, but I will attest that, when done
properly, it makes a world of sense.
First, let me present how our team has established our original system.
We develop Windows desktop applications (among other applications), so
our developers run Windows (so using *nix linked files will not work).
The directory structure is divided by system, subsystem (client, server,
etc.), and then application, and we do indeed have a directory of common
third-party / shared files that are compiled into our software. When a
shared file is used in the application, we create a link to it within
the directory hierarchy of the application itself. This has a few benefits:
1. One can see all files compiled into an application without having to
search through the code to find which common files are being used. When
there are half a dozen Windows applications being built with completely
different functionality, third-party visual tools are abound. This
architecture has helped us easily keep track of which files are being
used in each application.
2. Developers can easily use relative paths to the shared files,
without having to back out of the application directories into the
common directories (e.g.
"../../../../common/shared_folder/shared_file.cpp"). Moreover, these
relative paths will cause problems in Subversion, since the "trunk"
should contain a compilable application, and "branches/branch_date" or
"branches/developer/branch_date" should also be compilable. In a
contained environment, absolute paths can work, but you are then
mandating that all developers have their project root at the same
location (at least under Windows). In our solution, one can go into any
trunk or any branch of any application and compile it without question
and without the need to build all other subsystems.
3. Performing a "get" or "update" on the application's root folder will
retreive the latest versions of all files for that application. There
is no need to perform a secondary "get" on the shared library, which can
easily be forgotten. An easy solution in Subversion would be to have
one project that contains the directory of common files as well as all
application files and then update the entire project, but this (a) is
time-intensive when a lot of development is occurring, and (b) requires
all users to have all source code to all projects, unless you start
setting all sorts of permissions.
Now, developers can obviously live without these benefits, but I do not
see how this design can lead to problems. Like anything, there is a
right way and a wrong way to use it. Matt suggested that many common
files will eventually need to be branched to support different
applications in a different manner. With careful design, especially
with a good object-oriented framework, this is not the case. Absolute
worst case scenario: add a compiler directive for the application that
must be treated differently -- this is not the best solution, but it
certainly is a better solution than maintaining two separate files with
99% of code being identical. With good forethought of *both* the
application design and version control design, there should be no issue
whatsoever.
The one thing that I am finding it hard to live without is the inability
to share files that are used by multiple applications but are not
compiled into the application, such as images, XSLT and CSS files, etc.
As with compiled files, our practice has been to create shares of these
files, where they can reside in the directory of the application in the
folder structure that makes the most sense for the application, rather
than shipping a directory of common files whose format is unwieldy
because it must be available to all applications. One solution would be
to have a common folder structure during development, and install the
files into "better" locations during the installation process, but this
has obvious issues during the development / debug process.
One last note: I have often read (including this thread) that there are
two workarounds to providing shared files in Subversion: either use *nix
linked files or use the svn:externals feature. Both of these are
inadequate for many users (i.e. either the user is on Windows, or shares
need to be created at a file level), but doesn't that immediately defeat
the arguments against using shared files all together? If "Thou Shalt
Not Use Shared Files" is a version control commandment, this should
never be a recommendation by anyone to anyone! My point is that there
are obvious benefits, this question is continually asked, and there are
enough developers that are finding other ways to accomplish the same
goal. So why not build it natively into the version control system?
Feel free to add the warning, "you should not use shared files unless
you have a darn good reason." :)
Thanks to the Subversion team for all of their hard work on an
outstanding project!! Despite shared files, I am still very anxious to
get our new version control system off the ground!
Christopher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 28 23:16:20 2005