really thanks for you help, I have worked with your suggestion
in a small test example. It works very good. And I have now also
read some parts from the svn-book, and the interesting part is
this about the MERGE command.
The best paragraph was, that: the main problem for the MERGE command
is the name, a better description is "diff-and-apply".
My first mistake was, that:
I try to "MERGE" the /branches/DEV/code to /branches/TEST/code
like DEV --> TEST :-(
The other way is exact what I need :-)
As "memory hook" I see a parallel to programming languages:
y = x mean, copy x into y
so, I memorize it for me like
TEST = DEV (in the work directory TEST)
svn merge /branches/TEST/code /branches/DEV/code
BUT I don't understand, who can I realize my original problem (a.pl and
in the same directory. As you describe it, there is no elegant way to do
it with svn.
With your example this mean, a.pl must open the cfg file from a parallel
e.g: open (CFG, "../config/a.cfg")
OK, it's a good concept to structure a "project" directory like:
From: Lieven Govaerts [mailto:firstname.lastname@example.org]
Sent: Donnerstag, 13. Oktober 2005 20:45
To: Langjahr, Uwe; email@example.com
Subject: RE: How to overlay files?
I think you are using two types of branch structuring patterns here:
1. Parallel release & development lines: you develop on one branch,
from time to time to test and then to production.
2. Platform lines: permanent branches for a variant of your project
must run on different platforms.
I'd set up a structure like this:
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
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
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,
> -----Original Message-----
> From: Langjahr, Uwe [mailto:firstname.lastname@example.org]
> Sent: woensdag 5 oktober 2005 8:07
> To: email@example.com
> Subject: How to overlay files?
> A newbie question or not? I'm a newbie ;-)
> Assuming you have three systems (development(D), testing(T),
> 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.
> The script a.pl is modified in D, and should be transported to T for
> (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.
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
> 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:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Oct 21 08:40:09 2005