--- Bob Hiestand <bob.hiestand@gmail.com> wrote:
> On 4/6/07, Hendrik Schober <SpamTrap@gmx.de> wrote:
> > > If you can modify shared code during release of any of the
> sharing
> > > project, I believe you will see many other problems that have
> nothing
> > > to do with the version control software.
> > Why?
> I've worked in two environments that did this. Both ended up
> changing
> to a better managed approach to modifying shared code. The problem
> is
> that it is very, very easy to make bad changes to shared code when
> it
> is embedded into project source trees. The problems come in a number
> of ways, such as project-specific code slipping into the shared area
> or incompatible changes being made to the shared API that isn't found
> until much later (during an unrelated project build).
>
> Overall, it is a lessening of the boundaries between modules and
> makes
> it easy for too many and incorrect dependencies to develop.
If I may add 2 cents here...
I do something similar at home, but not the way that Mr. Schober is
describing. I have a number of projects for shared sources, and a
number of other projects that use them. For example, one project is a
TCP Class for C++ that I use all over the place, and another project is
a program that needs to use TCP comms to send data. For this discussion
I'll call it projTCP and projA.
While I've been using SVN at work for almost 3 years now, I am just
getting around to converting my home setup from CVS to SVN. Under CVS I
used tags to release each project. So projTCP would have a release of
PROJTCP_1_1; and then projA would have some special lines in its
Makefile that would export the specific release PROJTCP_1_1. All the
Makefile needed to know was (a) where to find the repository, and (b)
what release to use.
Why did I do this? As another poster described, whoever maintains
projTCP could go off and rewrite projTCP's API or do something that
breaks how projA works. If I want to maintain configuration management
on projA, then projA needs to only work with a specific release of
projTCP; that way projA will always work as long as it has that version
of projTCP. If there was a new release of projTCP (say PROJTCP_1_2)
then I could update the Makefile in projA to use the new release, and
verify that projA still worked.
You are basically doing something very similar with a script that works
on all the platforms you are supporting.
Now, as I convert my projects over to SVN, I'll have to go in an update
the Makefiles to do this how SVN works over CVS. So, I will have to
specify full paths instead of project and release.
So where my Makefile use to look like:
PROJ_TCP = projTCP
PROJ_TCP_RELEASE = PROJTCP_1_1
...
sharedTCP: projTCP/
cvs export $(PROJ_TCP) -r $(PROJ_TCP_RELEASE)
...
I'll now have to do something like:
PROJ_TCP = https://my.svn.server/projTCP/release/projTCP_1_1/
...
sharedTCP: projTCP/
svn export $(PROJ_TCP)
...
Any how...just my 2 cents.
BRM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 10 16:11:32 2007