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

RE: How to overlay files?

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2005-10-13 20:45:15 CEST

Uwe,

I think you are using two types of branch structuring patterns here:
 1. Parallel release & development lines: you develop on one branch, copy
    from time to time to test and then to production.
 2. Platform lines: permanent branches for a variant of your project that
    must run on different platforms.

I'd set up a structure like this:

/
/branches/DEV/code/
/branches/DEV/config/
/branches/TEST/code/
/branches/TEST/config/
/branches/PROD/code/
/branches/PROD/config/

For your code,
you have three branches concerning the state of the project. You can assign
different policies to each of these branches, eg. limit user access ( all
devs
on DEV/code, only bugfixers on TEST/code, only release managers on PROD/code

etc. ) You typically develop on the DEV branch, use "svn merge" to copy
changes
from the DEV branch to TEST and from TEST to PROD etc. You create the TEST &

PROD branches by copying them from branches/DEV. ( svn cp )

You have a full copy of the whole project in each of the three YYY/code
branches.

For your configuration files,
you also have three separate branches for each of the platforms you need
configuration for, but these you don't have to merge then.

If you want a dump of both the code and config for the production
environment, you can
do: "svn export" /branches/PROD.

There are some alternatives:
1. You could use the name "trunk" instead of "branches/DEV" as it's more
common
to use trunk for the latest development code.
2. Make code & config your top level folders, under which you have
branches/DEV...
Similar setup as a above, but I think the first proposal is best.

One note (again), if you want to transfer changes from one branch to
another,
use "svn merge" instead of update.
You also should not branch only one file, subversion is folder-oriented (
best practice
is to use project branches anyway ).

hope this helps,

Lieven.

> -----Original Message-----
> From: Langjahr, Uwe [mailto:uwe.langjahr@hp.com]
> Sent: woensdag 5 oktober 2005 8:07
> To: users@subversion.tigris.org
> Subject: How to overlay files?
>
> A newbie question or not? I'm a newbie ;-)
>
> Assuming you have three systems (development(D), testing(T),
> production(P))
>
> for a small scripting environment. A simple script "a.pl" reads a
>
> config file "a.cfg", which contains environment specific informations
>
> (e.g. db connect, hostnames)
>
> I'm looking for ideas, how to organize the SVN repository project
>
> structure to handle the following situation or how I have to work
>
> with SVN itself.
>
> Assuming:
>
> The script a.pl is modified in D, and should be transported
> to T for testing
>
> (executing "svn update" in T for the whole directory/project).
>
> But the config file "a.cfg" should not be overwritten.
>
> Additionally "a.cfg" must be also under version control in
>
> all three environments.
>
> I found a way how I can do this:
>
> - Instanciate the following environments (T, P) from the master (D)
>
> - Only branch the config file "a.cfg" in (T, P) specific folders
>
> - "switch" to the branch only for config file "a.cfg" to the specific
>
> working copy in the specific environment
>
> - The rest of the files ("a.pl") is derived from D.
>
>
>
> Is this the best way, how I can handle this problem?
>
> I think, this is a typical problem for all developers, who
>
> have to support this three stages.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.10/119 - Release
> Date: 4/10/2005
>
>

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/131 - Release Date: 12/10/2005
 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 13 20:48:09 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.