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

repository structure question...

From: John Blumel <jb-lists_at_medikin.com>
Date: 2007-05-08 15:36:04 CEST


We have a code base that we are just planning to import to subversion.
It has not been under any version control/SCM system previously, and it
has, over time, diverged into a few different versions, running on as
many different servers, each with slight, and sometimes significant,
differences, and even some minor database differences between the versions.

The goal is to eventually reintegrate these versions and eliminate the
differences as much as possible -- entirely if that proves feasible --
but it will take some time to do that. I should mention that I'm
relatively unfamiliar with the source at this point, so don't know the
full extent of the variations.

So, I'm looking for some advice on what sort of repository organization
might best support both the maintenance of these divergent source trees,
and their reintegration over time, and also on what the best way might
be to bring these sources into subversion, whether we should simply
import them as separate trunks (treating them as separate products, I
guess) or as branches, or if perhaps some sort of multi-step process
(e.g., importing the "primary" source to a trunk, importing the
"secondary" variants as branches, creating additional branches (or
trunks) off the "primary", merging the "secondaries" to these new
branches (or trunks) to create a record of the differences... or
something like that.) would be best.

Well, any recommendations would be greatly appreciated.

John Blumel

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 8 15:47:16 2007

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.