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

svn:externals, library sharing

From: Klimek Manuel <m.klimek_at_el-me.de>
Date: 2005-01-24 12:35:54 CET

Hi there,

I just read that the svn:externals relative path issue (1336)
is not going to be implemented before subversion 1.5.

Now after googling around and talking to other people who
ran into the same problem while switching to svn in their
company, I desperately need a solution to the following
problem, and I couldn't find one that satisfies my needs
(svn:externals with relative paths would solve the problem, though).
I'll outline the problem, give the solutions I found and
explain why they don't fit my needs. If anybody can think
of a magical solution to this all, please tell me :-)

Problem:
We've got a real lot of code in, say, N projects proj1 ... projN.
They all share a library liblog, which has some header files where
project-independent defines for logging are stored, because the
log files of all projects can be viewed via the same tool, let's
call it LogView.
The structure is like this (but we're free to change the structure,
of course):
/
        proj1/
                trunk/
                        liblog/
                                tag.h
                tags/
                        v1.0.0/
                                liblog/
                                        tag.h
                branches/
      ...
        LogView/
                trunk/
                        liblog/
                                tag.h
                tags/
                        v3.4.0/
                                liblog/
                                        tag.h
                branches/
        liblog/
                trunk/
                        tag.h
                tags/
                branches/

The procedure is, that we have one or two developers per project,
who will add logging tags on demand (in liblog). The other projects should
'see'
this log information at once, so they don't use the same log
tag in different projects by accident.

Now I need a solution, where:
1) If a header in liblog gets changed, all other projects see
   the update at the next svn up.
2) When we tag or branch, the usual tag/branch semantics should apply,
   as if liblog was really a subdir in every project.
   We can't use scripts, because most of the developers use gui
   clients like tortoisesvn or rapidsvn on linux.
3) Our developers don't want to check out _all_ projects if
   checking out a clean copy. When building binary releases
   we'll do a clean checkout for every run, and usually multiple
   runs a day are executed before passing quality assurance.

Possible solutions:
a) Using svn:externals which links to /liblog/trunk.
   (1) and (3) are fulfilled, but (2) is not. Since developers
   tend to forget stuff, we'll end up having release tags
   that don't link to the correct headers when trying to
   'rebuild' them later. Issue 1258 deals with this problem, but,
   as mentioned above, we're not able to use scripts for
   this stuff.
b) Using svn:externals which links to /liblog/trunk@some_revision.
   Now (2) and (3) is ok, but (1) is not. We'll end up with
   multiple tags defined in different projects (worst solution).
c) Building one big trunk, and putting the -I in every project
   relative so that it finds liblog. This gives us (1) and (2)
   but not (3). The (nearly identical) solution with relative
   paths in svn:externals would solve this giving us (3) also,
   but it will not come before 1.5.

If I can't find any better solution, I'll have to propose (c),
I think.

Thanks in advance for any help and ideas,
Manuel

-- 
Manuel Klimek
EL-ME AG
Phone: +49 8752 864 0
Email : m.klimek@el-me.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 25 19:24:13 2005

This is an archived mail posted to the Subversion Users mailing list.