> So given that svn:externals does not equate to VSS sharing, what
> other solutions have people come up with to achieve this?
I get annoyed when people respond to my questions with new problems
instead of solutions, but there are times, I think, when system
transitions like the one you've undertaken simply require adaptations
in workflow. This might be an opportunity for you to re-evaluate some
of your older procedures and develop new habits to take better
advantage of the facilities Subversion *does* provide.
For example, you may find benefits in splitting your shared libraries
and common files out into separate projects you can manage
independently. Development on these common components can proceed
separately from your main projects, revisions to the common code
won't be tied up in revisions to main project code, and with
Subversion's branching and tagging features, you can even maintain
build compatibility with older projects by linking them against older
tags.
It may require some changes to your main projects, however. In
projects I work on, I make sure code that references shared libraries
refers to a common location not specific to any individual project
(like a /lib directory, for example). If the libs are there, great.
If not, the compile fails (in the case of source libraries) or the
application dies with an error (in the case of runtime libraries) --
but these are coding practices, not versioning practices. As far as
versioning is concerned, putting the libs where they go is a simple
matter of dropping a working copy of the lib project in the global
location, at which point everything snaps back into place.
I hate to say it, but if your code doesn't already do this, or isn't
easily adaptable to such a scheme, you may be facing a problem for
which a version control workaround is not a sustainable solution anyway.
Maybe you can present the case to your boss that there have been long-
standing vulnerabilities in your current workflow that you can
finally address now that you're on Subversion, among them being the
need to link shared files into multiple projects all over the place,
with the version inconsistencies and accountability headaches that go
along with that. Now that you're away from the VSS way of doing it,
you can build more robust applications with standalone components,
The Subversion Way(tm).
j
Received on Thu Sep 7 09:59:12 2006