On May 8, 2007, at 08:36, John Blumel wrote:
> 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.
The tool to bring all these versions into Subversion could be
svn_load_dirs.pl. It's described in the chapter in the book on vendor
branches. [1] I used this to bring a project of mine into Subversion
initially. Though for me it was easier, since all existing versions
were a linear history of releases where each release was based on the
previous release, so each release just got imported into the trunk
and then tagged. This project was also used for various different
(sometimes significantly differing) situations, like yours, but in my
case everything was still within the same source code base, and there
was just a config file which specified which behavior a particular
installation should have. For your situation, you may have to draw
out a tree diagram and figure out which of your versions is based on
which other versions, to see in which order and to which branch you
should load them. Branches are probably how you should handle this,
with each significantly different version being its own branch, for
now. Perhaps you can gradually combine them into a single version in
the trunk, if that's better for you. You probably do want to have a
trunk; which of your versions becomes the trunk depends on which
version you think has the best chance of being a general-purpose
stable version into which the features from the other versions can be
merged.
Or, rather than merging all features into the trunk, you could retain
your separate versions as branches, and keep the trunk as just a
"plain" version. Then when you make changes on the trunk from which
each version should benefit, you can merge them out to the branches.
And when you make a change on a branch that's supposed to be unique
to the branch, well, then you leave it right there on the branch and
don't merge it anywhere else.
[1] http://svnbook.red-bean.com/en/1.2/svn.advanced.vendorbr.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 8 19:15:31 2007