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

Re: Yet another repository layout question

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2005-04-04 14:40:08 CEST

On Mon, 04 Apr 2005 21:15:24 +1000, Mike Dewhirst
<miked@dewhirst.com.au> wrote :

>I'm just starting a legacy app rewrite in python on Windows. And I'm
>just starting to use subversion/tortoise hosted on my linux box's
>Apache. I haven't previously used subversion or similar.
>
>I'm having trouble deciding on a repository layout because it is really
>four apps not one.
>
>There is a core app in its own root directory which is where most of the
>development takes place. The other three have their own root directories
>with physical copies of the absolutely common code. All four have their
>own unique modules on top of the common stuff.
>
>You could think of it as all four sharing the same accounts receivable
>but with separate market specific front-ends.
>
>In the past I have moved them forward in sequence. The core app gets out
>of beta first and when stable I copy the common code to another app root
>then get that working and so on.
>
>I'd like to keep the common stuff separately but I have to maintain
>older versions of it in the other apps at least until I roll all the
>users forward one app at a time.
>
>What might be a useful repository layout? I think I'm stumped.
>
>trunk
> coreApp (lots of common stuff plus unique bits)
> nextApp (ditto)
> thirdApp (ditto)
> lastApp (ditto)
>branches
> ?
>tags
> ?

I would think of this as 4 separate projects, and organize it like
this:

coreApp
  trunk
  branches
    nextAppbranch
    thirdAppbranch
    lastAppbranch
  tags
nextApp
  trunk
  branches
  tags
thirdApp
  trunk
  branches
  tags
lastApp
  trunk
  branches
  tags

Then when you check out nextApp, thirdApp or lastApp, you also check
out the relevant branch of coreApp to work with it. This is what
externals definitions (see Ch 7) are for.

Most development would occur in coreApp/trunk, with bug fixes
(perhaps) propagated to the branches. When you are finished testing
the new coreApp version, you merge all the changes into the branches,
and fix up the subsidiary apps to be compatible.

It's possible you don't really need three separate branches below
coreApp: if you update all the subsidiaries at once, then one would
be enough.

Duncan Murdoch

>I have read Chapter 5, Adding Projects (Choosing a repository layout)
>
>Any ideas gratefully accepted.
>
>TIA
>
>Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 4 14:44:35 2005

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.