I think this is a directory layout problem. I recommend :
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.maint.html#svn.branchmerge.maint.layout
You have :
trunk/proja
projb
libc
libd
libe
tags/...
branches/...
What you shoud consider :
proja/trunk
proja/tags
proja/branches
projb/trunk
projb/tags
projb/branches
libc/trunk
libc/tags
libc/branches
libd/trunk
libd/tags
libd/branches
libe/trunk
libe/tags
libe/branches
pck_proja/trunk (holding externals pointing to above sub-projects)
pck_proja/tags
pck_proja/branches
pck_projb/trunk (holding externals pointing to above sub-projects)
pck_projb/tags
pck_projb/branches
You may also group code (see ex bellow), but the point is that
- each code module (living at its own development pace) should have its own
TTB (trunk-tags-branches),
- that these TTB have to be terminal in your repository tree,
- and that your repository topology is not necessarely driven by your usual
software trees, but rather your re-use and dev team policy.
I use something like :
Applications/proja/trunk
Applications/proja/tags
Applications/proja/branches
Applications/projb/trunk
Applications/projb/tags
Applications/projb/branches
Libraries/libc/trunk
Libraries/libc/tags
Libraries/libc/branches
Libraries/libd/trunk
Libraries/libd/tags
Libraries/libd/branches
Libraries/libe/trunk
Libraries/libe/tags
Libraries/libe/branches
Packages/pck_proja/trunk (holding externals pointing to above)
Packages/pck_proja/tags
Packages/pck_proja/branches
Packages/pck_projb/trunk (holding externals pointing to above)
Packages/pck_projb/tags
Packages/pck_projb/branches
Of course, it is always possible to move/rename/reorganise things
afterwards (TTB are just a way of working and mays as well be named riri
fifi loulou) but a planned repository layout can save much effort.
Jean-Baptiste Maillet
Quoting Christopher Key <cjk32@cam.ac.uk>:
> Hello Paul,
>
> Thanks for the reply. I'd not considered such a design, but it does work
> nicely, keeping all of a project's dependencies available within one
> directory. The problems cited in the SVN book do make it less than ideal
> though, particularly as mentioned in relation to creating SVN branches and
> tags. Is support for relative external paths something that's likely to be
> added to a future version?
>
> One thought did occur to me that would allow, say, project 1 to depend on
> something that you didn't want to have as an external like the Widgets. If
> you were able to have externals that didn't recurse into subdirectories
> would be to have:
>
> trunk
> export1
> code
> project1 - svn:external /trunk/code/project1
> common
> Widget 1 - svn:external /trunk/code/Common/Widget1
> Widget 1 - svn:external /trunk/code/Common/Widget2
> export2
> ...
>
> This would still suffer from the problem of not having relative svn:external
> paths, and would still have to be updated manually. At least, if the
> Widgets are with the project, then you know that the dependencies are
> covered. The normal working copy simply wouldn't build unless all its
> dependencies were there.
>
> I'll have a think, and see if I can find a way to restructure my repository
> to make this work.
>
> Chris Key
>
> -----Original Message-----
> From: Durden, Paul [mailto:Paul.Durden@avocent.com]
> Sent: 09 March 2006 14:40
> To: Christopher Key
> Subject: RE: Export Groups
>
> Christopher,
> You might be able to use externals to do this, although it won't be
> automatic.
>
> You could use the following structure...
>
> trunk
> code
> project1
> Files for project 1
> Widget1 - svn:external /trunk/code/Common/Widget1
> Widget4 - svn:external /trunk/code/Common/Widget4
> project2
> Files for project 2
> Widget1 - svn:external /trunk/code/Common/Widget1
> Widget2 - svn:external /trunk/code/Common/Widget2
> project3
> Files for project 3
> Widget2 - svn:external /trunk/code/Common/Widget2
> Widget3 - svn:external /trunk/code/Common/Widget3
> Common
> Widget1
> Files for Widget1
> Widget2
> Files for Widget2
> Widget3
> Files for Widget3
> Widget4
> Files for Widget4
>
> You can check out the online documentation for a discussion of svn:external
> here
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals
>
> Hope this helps,
>
> Paul
>
> ________________________________
>
> From: Christopher Key [mailto:cjk32@cam.ac.uk]
> Sent: Thu 2006-03-09 7:57 AM
> To: users@subversion.tigris.org
> Subject: Export Groups
>
>
>
> Hello,
>
> I have a repository containing various projects sharing a certain amount of
> common code, e.g.:
>
> trunk
> code
> project1
> Files for project 1
> project2
> Files for project 2
> project3
> Files for project 3
> Common
> Files used by none, any or all of projects 1--3
>
>
> What I would like to be able to do is to be able export a copy of the entire
> hierarchy with only those files required for a given project, or group of
> projects. I would envisage something similar to a makefile, that
> recursively searches for dependencies. I've not been able to find any
> support for this sort of functionality with SVN, and I'm certainly not sure
> if a version control system is the right place to put this anyway.
>
> Is there a recommended way of achieving the above in conjunction with SVN,
> using something like a 'dependson' property for the file? Am tackling the
> problem from completely the wrong end?
>
>
> Many thanks,
>
> Christopher Key
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 9 18:01:55 2006