Re: Consolidating Projects

The model I'm going with has similar requirements. A core project and
some dependent projects. All of their life-cycles are independent.

dev/
   common/
      branches/...
      tags/...
      trunk/
        ...
   project1/
      branches/...
      tags/...
      trunk/
        ext/
          common/... (Copy of common/trunk at a release time)
        ...
   project2/
      branches/...
      tags/...
      trunk/
        ext/
          common/... (Copy of common/trunk at a release time)
        ...

'ext' is an umbrella for references to snapshots of other projects.
These can be build materials or source snapshots. This allows the two
sub projects and the parent to operate independently. The sub
projects can choose when to absorb a new common release (it might be
an internal release of course - IE just a milestone). Also, each
project is self-contained so a project1 developer need only checkout
/dev/project1/trunk (or a branch) - no relative references outside of
the project space.

As far as getting the existing projects into Subversion....
migrate/import them into the tree somewhere and then massage them into
shape using subversion rename/copy/move commands. In this way the new
app can be a sort of 'branch' just one with a very complex root.

Of course I'm only prototyping myself at the moment - having only
recently converted CVS and run a number of cleanup and reorganisation
passes to refine this layout and the management practices prior to a
full team change-over. It's possible this is an awful design and
someone more familiar with Subversion could be laughing at the end of
one these interweb pipe-things.

With any luck they'll jump with their $0.10+GST.

--
Talden
On 7/4/07, LUKE PLAMANN <laplamann@nglic.com> wrote:
>
>
> Greetings!
>
> We are starting a project to consolidate two web applications into one. They
> have become very similar, and the decision was made to make them one
> application. We also don't have any type of source management system.
>
> Enter Subversion.
>
> Coincidentally, I'm implementing Subversion as this is starting up, and have
> the luxury(?) of designing the repository with this project in mind.
>
> Normally, Each of the existing applications would be their own projects with
> their own trunks, branches, and tags. However, this new application will be
> inheriting a lot of the existing code from the current applications. Also,
> development will be continuing on the existing applications, and those
> changes will need to be brought forward to the new application. Once the new
> application goes live, the old applications will die.
>
> Basically, the new application will be a compilation of the best the
> existing applications have to offer.
>
> Does anyone have any suggestions on how to manage this without making my
> head explode?
>
> Having the new application as some sort of branch of BOTH existing
> applications would be great, but would never work. The underlying structures
> of the existing applications are extremely different. I'm pretty sure that
> isn't possible anyway.
>
> My current "best idea" is to have the new application be a branch of one of
> the existing applications. That will, at least, allow ongoing development to
> be merged from one of the applications. Then I'll just have to suck it up
> and manually handle any merges of new development from the other
> application. Then, once the new application goes live, move it to its own
> trunk.
>
> Thoughts?
>
> -Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org