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

Re: CVS to SVN, best practice

From: BRM <bm_witness_at_yahoo.com>
Date: 2007-04-10 16:11:04 CEST

--- 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

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.