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

vendor branches

From: Tim Van Epps <tvanepps_at_efs-us.com>
Date: 2004-04-20 18:35:17 CEST

I'm trying to convert a medium-sized software development environment to
subversion from SCCS. Our source code is arranged into three major
subdirectories, incl, lib, and app. A typical app directory will contain
source code to build several applications.

We usually think about working on projects here, so I've created a
couple of test
projects that use svn:externals and a project-specific makefile to build
the application(s) in a project. Thus the workflow would be something like
    cd $HOME/projects
    svn checkout http://.../projects/foo myFoo
    cd myFoo
    make
and the existing project is built and ready for updates.

We use the boost libraries here and have them installed in our repository
under vendor/boost. Since project foo uses boost/shared_ptr.hpp, I added
"vendor/boost" to my svn:externals; unfortunately, this means that I add
all of vendor/boost to my working copy even though I only needed
boost/shared_ptr.hpp. This wouldn't be a major issue except that it
quadruples
(at least) the amount of time needed to create a new working copy of foo.

So, finally, the question: do I just bite the bullet and live with this or
have others developed a creative alternative. I thought about just adding
those files from boost to my vendor/boost repository directory as needed,
but this seems an administrative nightmare. I've thought about leaving
boost out of the repository, but that causes issues when the boost
environment is updated. Any other ideas would be appreciated.

Thanks,
Tim Van Epps

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 20 18:36:02 2004

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.