You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nathaniel Wingfield <nw...@ufl.edu> on 2008/01/24 23:38:23 UTC
partial branching?
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.
Can anyone offer suggestions on structuring the repository to maintain
parallel versions only of select files (those differing by client)
within the project? I'm imagining something like "partial branches" that
share a core codebase. My goal is to avoid merging files that needn't be
branched to begin with.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: partial branching?
Posted by Nathaniel Wingfield <nw...@ufl.edu>.
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"
<ji...@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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: partial branching?
Posted by Jim Thompson <ji...@doit.wisc.edu>.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: partial branching?
Posted by Michael Reinelt <mi...@reinelt.co.at>.
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
--
Michael Reinelt <mi...@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: partial branching?
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
Hi Nathaniel,
Refer to external
http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
Thanks
Lakshman
-----Original Message-----
From: Nathaniel Wingfield [mailto:nw@ufl.edu]
Sent: Friday, 25 January 2008 10:38 AM
To: users@subversion.tigris.org
Subject: partial branching?
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.
Can anyone offer suggestions on structuring the repository to maintain
parallel versions only of select files (those differing by client)
within the project? I'm imagining something like "partial branches" that
share a core codebase. My goal is to avoid merging files that needn't be
branched to begin with.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org