svn - How to structure a repository that consists of several libraries and applications -


i've won task of restructuring/recreating existing code repository, either using git or subversion. repository history not important in special case. after analyzing situation i've found problems determining layout. i've read through lot of blogs , threads, i'm still unsure best layout.

the existing repository contains set of include files, set of libraries partially dependent on each other, , many of them depend on set of include files. additionally, there 2 application projects depend on set of libraries. furthermore, there set of scripts makes use of 1 of applications , additional configuration information. i've drawn graph clarify situation:

    +---------->include files     |                ^     |                | library -----> library b <----- library c <----- library d   ^  ^                                |                ^   |  |                                |                |   |  +--------------------------------+                |   |                                                    | application 1        application 2 --------------------+   ^   | script -----> configuration information 

the goal have layout each component can developed independently possible, , have release (for external customers) contains set of components @ defined tag versions, possible go in time , build software specific release.

i've come following structure:

trunk/   include/   lib/     library a/     library b/     library c/     library d/   app/     application 1/     application 2/ tags/   1.0/     include/     lib/       library a/       library b/       library c/       library d/     app/       application 1/       application 2/   1.1/     include/     lib/       library a/       library b/       library c/       library d/     app/       application 1/       application 2/   ... 

each time create new release copy whole repository new subdirectory in tags.

the problem solution libraries not have separate tag directories themselves, , want have release consists of tagged components, , solution not display components have tag versions in release. have considered using separate repositories , create master repository has releases subdirectory link in necessary components `svn:externals' , specific tags subdirectory, different libraries , include files depend on each other , don't see how partition code separate entities.

any ideas?

=============== question continued on 28-1-2011 ===============

ok, i've drawn graph of how plan new layout. goal link tags of various dependencies svn:externals method within 1 repository, example i'd set svn:externals in trunk/projects/lib/library2/dependencies on ^/tags/projects/include/std/1.3.

trunk/   projects/     include/       std/     lib/       library1/         dependencies/           std/ --> tags/projects/include/std/1.2       library2/         dependencies/           std/ --> tags/projects/include/std/1.2           library1/ --> tags/projects/lib/library1/1.4.3       library3/         dependencies/           std/ --> tags/projects/include/std/1.3           library1/ --> tags/projects/lib/library1/1.4     app/       application1/         dependencies/           library3/ --> tags/projects/lib/library3/1.1       application2/         dependencies/           library1/ --> tags/projects/lib/library1/2.1       application3/         dependencies/           std/ --> tags/projects/include/std/1.2           library2/ --> tags/projects/lib/library2/1.5.2     config/       configuration1/         dependencies/           application1/ --> tags/projects/app/application1/2.3       configuration2/         dependencies/           application1/ --> tags/projects/app/application1/1.6       configuration2/         dependencies/           application2/ --> tags/projects/app/application1/1.6 tags/   projects/     include/       std/         1.2/         1.3/     lib/       library1/         1.4.3/         1.4/         2.1/       library2/         1.5.2/       library3/         1.1/     app/       application1/         1.6/         2.3/ branches/   ... 

remaining questions:

  • is design workable, or see major drawbacks?
  • what happens if copy library tags directory? copy svn:externals property well. cause problems, or behaviour desired?
  • i specify explicit revision externals, tag should not change anyways, wouldn't directory suffice?
  • would repository split development repository , repository uses svn:external better solution? see answer `use cases' in question what's benefits of "svn:externals"?.

i suggest turning taxonomy inside out. in subversion, suggest taxonomy this:

companyname/   include/     trunk/     tags/     branches/   librarya/     trunk/     tags/     branches/   libraryb/     trunk/     tags/     branches/   libraryc     trunk/     tags/     branches/   libraryd/     trunk/     tags/     branches/   application1     trunk/     tags/     branches/   application2     trunk/     tags/     branches/ 

in git, suggest should create separate git repo include, librarya, libraryb, application1, etc...

this structure allow create kind of dependencies between different parts (for example, branch in application1 depend on unstable version of librarya project, while head in application1 depend on stable version of librarya project).

this structure works build tools maven, rake, buildr, ant, etc.

the taxonomy presented looks it's structure deployed version of application, not structure version control. experience, think better off if use structure 1 suggested version control, , use build script (or build tool) create structure listed when comes time package/deploy/ship app.

update: elaborate bit on how work cycle might go:

so, example, let's finished implementing bug fixes application1 (let's call version 1.0.0). latest , greatest changes checked application1/trunk. version of application1 depends on libraryd v0.5.0. update application1/trunk/readme.txt note version depends on libraryd v0.5.0. perhaps, more importantly, build script inside application/trunk knows how checkout libraryd/tags/0.5.0. next, create tag (which copy of trunk in current state) in application1/tags/1.0.0.

now, let's week goes , developer updates libraryd version 1.3.0. need enhance application1. so, make changes in application1/trunk. update application1/trunk/readme.txt depend on libraryd v1.3.0 (and, similarly, new build script application1 v1.3.0 checkout libraryd/tags/1.3.0). copy application1/trunk application1/tags/1.1.0.

now can revert application1/tags/1.0.0 if needed (and confident pull code libraryd/tags/0.5.0. application/tags/1.1.0 use libraryd version 1.3.0.

in both subversion , git, tag reference set of files @ given point in time. means tags don't take space, tag , ;-)


Comments

Popular posts from this blog

java - SNMP4J General Variable Binding Error -

windows - Python Service Installation - "Could not find PythonClass entry" -

Determine if a XmlNode is empty or null in C#? -