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

Repository design - Dealing with common modules

From: Daniel F Garcia <dgarcia_at_kobold.com.au>
Date: 2004-03-27 01:10:07 CET

Background
 
I do C#/ASP.Net web development with MS Visual Studio
As part of my solution I usually have a number of projects (code models)
that are share between many projects. eg

* Sentinel: Authentication framework
* Husk: Database access layer

At any time there are 2-3 systems that are undergoing development and
sevearl more that are close/hibernating.
Framework items tend to get updated whilst we are working on a project that
uses them.
 
So where do we put these items in the repository ?
 
Possible Solutions
 
Solution 1:
 

/framework/sentinel
/framework/husk
/products/product1

/products/product2

/products/product3
 
When you work on a product you would check out the framework items into a
framework are on the local machine, then checkout the product into it's own
folder. The product solution file would reference the framework from the
framework section of the local machine.
 
Problems:
 
Note sure if Visual Studio Solutions support relative pathnames
Assumes that everyone keeps everything in the same place (ie the relative or
absolution path to the framework items need to be the same)

Solution 2:
 

Same as above, but checkout framework and product items into one folder (ie
have a mixed worked folder)
 
eg.
 
c:\product\product1\solutionfile
c:\product\product1\component1\

c:\product\product1\component2\
c:\product\product1\sentinel
c:\product\product1\husk
 
Problem:
 
checkout is messy
if the user works on many projects, increasethe probablity of clashes on
comitt (ie has the effect of muliplying the number of working copies)

Solution 3:

/framework/sentinel
/framework/husk
/products/product1/component1
/products/product1/component2
/products/product1/sentinel
/products/product1/husk

/products/product2/component1
/products/product2/component2
/products/product2/sentinel
/products/product2/husk
 
Advantages:
 
Easy to checkout
In the short term don't have to worry about impact on other systems
 
Problems:
 
Lots of work to merge all the code back into the trunk
 

Now for the question:
 
Are there any possible solutions that I have missed ? is there another way
of look at the problem ? Do any of you have similar requirements ? How have
you dealt with it ?
 
 
Daniel F Garcia
Project manager

  <http://www.kobold.com.au/ksys-ani.gif>
Mobile: 0438 670 947
Phone: 07 5461 1120
Email: dgarcia@kobold.com.au
Address: 4 Lloyd George Street, Eastern Heights QLD 4305
 

ksys-ani.gif
Received on Sat Mar 27 01:11:45 2004

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