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

Re: newbie question

From: Talden <talden_at_gmail.com>
Date: 2007-05-08 13:23:47 CEST

If the two apps have different development cycles then I'd opt for an
internal 'core' project that only has internal releases and two
application projects that use a known release of that core code.

You do an internal vendor drop of the current code into each app. If
a change appears in the core and one app is at a point in its
development where it can absorb the change then drop a new internal
release (or merge them).

This lack of dependency allows you to beta release internal branches
of the core for one application to test without interfering with any
maintenance or development efforts in the other application.

Done early and packaged up tidily you'll have little overhead and no
project life-cycle dependancy.

--
Talden
On 5/7/07, Paul <paul@domains.textdriven.com> wrote:
> Hi,
>
> I have a simple newbie question:
>
>  From what I have read and what I have always used is this repo structure:
>
> root
> |-----trunk
> |-----branches
> |--------*
> |-----tags
> |--------*
>
> In one application I am working on I need to  'folk' it and maintain two
> apps that are 95% the same. Any major features will be shared/merged
> between them.
>
> What is the *correct* way to handle this? Should I just branch and
> delete the trunk? Like this:
>
> root
> |-----branches
> |--------app1
> |--------app2
> |--------*
> |-----tags
> |--------*
>
> or:
>
> root
> |-----trunks
> |--------app1
> |--------app2
> |-----branches
> |--------*
> |-----tags
> |--------*
>
> I don't want to create separate repos for them if I don't have to.
>
> What is the correct and easiest way of dealing with this?
>
> Many thanks,
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 8 13:24:04 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.