Michael Reinelt wrote:
> Hi there,
>
>
> Srilakshmanan, Lakshman schrieb:
>> Refer to external
>> http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
> I don't think that this is was Nathaniel was asking for...
>
>>> I'm managing a single project for several clients. The software should
>>> function identically for each client, but a few code modules must be
>>> implemented differently for each client's database environment.
>
> That's exactly what I am doing here.
>
> I keep all the "common" files in trunk, and I have a branch for every
> customer, which contains the files from trunk plus the
> customer-specific extension.
>
> I have a lot of duplicate files (every file from trunk is duplicated
> in every branch), but as this are "cheap copies", this doesn't hurt
> too much. OTOH, this has the advantage of having the possibility to
> change a common file in a branch, test it in the customer environment,
> and decide if the change should be backportet to trunk (and in a 2nd
> step to every branch).
>
> SOmetimes I decide that a customer-specific file should no longer
> customer-specific but common, so I simply copy it to trunk. Sometimes
> I decide it has to be the other way round (a former common file
> becomes customer-specific): I simply delete it from trunk.
>
> To maintain all this stuff, I wrote several scripts that compare the
> common files from trunk with all branches, and suggests diffs and/or
> merges (based on 'svn diff --summarize')
>
> One drawback is that every change to trunk results in a diff for every
> branch (and I got about 20 branches), so the commits (and the
> repository itself) becomes quite big. A proper solution would be a
> "svn replace" instead of a "svn merge", but I couldn't find the time
> to improve my scripts to to this (apart from the fact that there is no
> "svn replace" command)
>
>
> HTH, Michael
>
Greetings,
We have not implemented yet, but we're facing a related issue and are
considering yet another approach.
We'll have a number of config files which often have different contents
for each environment (e.g., development, test, QA, production, etc.) and
each environment will typically connect to different DBs - so the config
files may have stuff like IDs and passwords. We're expecting to use two
svn repositories (or at least separate sections) with tighter access
restrictions for the config files.
Since these config files may be found in directories that already have
"regular" (not environment-specific) files, it doesn't seem like
defining externals will work in this case. We'll likely use a script
that will run two main phases:
1) svn checkout/export/switch/update (choose the desired command when
running the script) - from the "regular" repo
2) svn export --force - from the config repo
The default for step 2 is to export the "template" configs (vs. dev,
test, qa, prod, etc.) which should be "sanitized" (e.g., contain no
actual passwords), so we can share our code (when the spirit moves us)
without compromising (or having to manually scrub) any sensitive data.
We could also easily identify the location of all the config files that
another user of our (open source) code would need to modify.
The script might also help with automation of our deployment process,
although much of that might be moving toward Maven.
Regards,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-25 15:47:24 CET