Thank you all for your recommendations. Though I have reservations about
frequent merges, maintaining separate branches (a la Reinelt) seems the
most flexible and resilient approach in this particular case.
Using a separate repository would work well for config files, I agree,
but not so well for core code modules. And the externals approach only
supports folders, not individual files, an unfortunate limitation.
Nathaniel
On Fri, 25 Jan 2008 08:46:45 -0600, "Jim Thompson"
<jim.thompson_at_doit.wisc.edu> said:
> 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
>
>
---------------------------------------------------------------------
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-28 23:07:39 CET