> -----Original Message-----
> From: Joachim Armbruster [mailto:joachima1_at_gmx.de]
> Sent: Sunday, February 17, 2008 5:03 AM
> To: users_at_subversion.tigris.org
> Subject: Migration from Clearcase to SVN / organizing projects
>
>
> We have on a typical file tree structure like the linux kernel source
> about 200-300 variants, one for each customer.
> Basically we maintain it that we have a label (tag) for the base
> platform. Because each customer gets for example a own user interface,
> we have customer labels as well.
> Now, it is quite easy in clearcase to have a config_spec which
contains
> the base label and the customer label. Since the customer label has a
> higher priority than the base label it accumulates all customer files.
This sounds additive and/or an overwrite. No merging is needed?
>
> Now, the most easy thing is, when we have a new base platform release
> and want to update a customer, we just have to change the base
platform
> label. No more work is neccessary normally. The easy thing here is
that
> we do not have to do a file by file comparison when we want to update
> the base platform.
> It is always the concept of putting 10 customer files into 10000 base
> files.
> We do not know how we can translate this workflow into the SVN trunk/
> branch/ tag/ tree.
I'm assuming that your config spec for a 2.0 release for Widgets Inc.
would look like:
element * CUSTOMER_WIDGETS_INC
element * REL2.0_BASELINE
or
mkbranch rel2.0_widgets_inc
element * CUSTOMER_WIDGETS_INC
element * REL2.0_BASELINE
If it's the former (no -mkbranch rule) then you should be able use
svn:externals to combine the two filesets. Or just have your build or
packaging scripts copy/tar/add the customer files over the baseline
files:
Svn co rel2.0 workspace
svn export /customer/$CUSTOMER /tmp/build.$$
cp -pr /tmp/build.$$ workspace
cd workspace
make
cd ..
tar rel2.0_$CUSTOMER.tar ...
If you have a -mkbranch in the config spec, then you can do a 'copy
merge':
mkbranch: svn copy tags/rel2.0_baseline
branches/rel2.0_widgets_inc
merge custom/widgets_inc into /branches/rel2.0_widgets_inc
copy customer.dat.rNEWREV to customer.dat
svn resolved customer.dat
Instead of merging, you just overwrite the baseline files with the
customer versions.
> As far as I can see, in SVN it is always that after doing a branch, we
> have to merge the update of the base platform (which often contains
> hundreds of files) to the customer branch.
Go the other way. Create a new rel2.0_widgets_inc branch from
baseline. Then merge the tiny customer branch in.
>
> We cannot structure our repository this way, that we put sources which
> might be changed for a customer into a special folder, because we do
> not know in advance what we will modify for a customer.
Who cares? Just copy the entire customer directory tree on top of the
baseline tree.
/branches/custom/widgets_inc
/branches/custom/gizmos_inc
/tags/rel2.0
Either your build script copies '/branches/custom/widgets_inc' into the
rel2.0 workspace to create a rel2.0_widgets_inc build/package, or you
just create a rel2.0_widgets_inc branch and copy-merge
/branches/custom/widgets_inc in.
>
> Does anybody already had similar problems and got a solution for this?
> Has anybody a suggestion of how a copy/branch/tag workflow has to be
> when we want to work a little bit like CC?
The following config spec (with or without a -mkbranch rule)
element * WIDGETS_INC
element * REL2.0
translates into subversion as
svn copy /tags/rel2.0_baseline
/branches/rel2.0_baseline_widgets_inc
merge or copymerge /branches/widgets_inc into
rel2.0_baseline_widgets_inc
CC's config spec will lets you 'copy-merge' two directories at once
using labels without having to manually create a branch and run a copy
merge. With SVN, you have to merge/copy or otherwise combine the two
sets of files into a branch or workspace yourself. Conceptually, it's
not that big of a difference.
Personally, I would just have the build process copy the customer dir
tree into the workspace.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-18 22:18:36 CET