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

Re: Development / Production / releases

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-09-27 01:40:50 CEST

On Mon, 2005-09-26 at 18:58 -0300, Esteban Pizzini wrote:
> Project:
> ---> devel
> --> subproject_a
> --> subproject_b
> --> subproject_c
> --> releases
> ----> subproject_a
> --->release_1
> --->release_2
> ----> subproject_b
> --->release_1
> ----> subproject_c
> --->release_1
>
> I have some users that only have to "update" files for production
> use... so today they have to update the last release for each
> subproject...
> I'm looking for another structure where users only have to update from
> only one folder (for instance, "production"), but I want to mantain
> the releases too...
> I was thinking about another structure like this:
>
> ---> devel
> --> subproject_a
> --> subproject_b
> --> subproject_c
>
> ---> production
> --> subproject_a
> --> subproject_b
> --> subproject_c
>
> ---> releases
> --> production_01
> --> production_02 (where production_xx contains all the
> subproject folders for that release)..
>
> What do you think about this???

Makes sense.

If I understand correctly, your releases sub-dirs are snapshots of your
code base at a milestone.

Production is the latest supported version and devel is the latest and
greatest work on the project.

I think you just re-invented the (trunk,branches,tags) idea where:
  devel -> trunk
  releases -> tags
  production -> branches

But the production to branches mapping is a weak one because - as I
understand it - you are attempting do what looks like a vendor branch of
your own code. :)

Enjoy!
Chris

-- 
http://www.nesser.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 27 01:42:20 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.