You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Joachim Armbruster <jo...@gmx.de> on 2008/02/17 10:03:14 UTC
Migration from Clearcase to SVN / organizing projects
Hello,
we want to migrate from CC to SVN, since SVN is cheaper (and cooler...)
In clearcase our projects (embedded software development) are organized as followed:
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.
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.
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.
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.
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?
--
mfg,
Joachim A
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Migration from Clearcase to SVN / organizing projects
Posted by Joachim Armbruster <jo...@gmx.de>.
Mark Phippard schrieb:
>
>>
>> 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?
>>
>
>
> I think you would need to do something like this:
>
> 1) When you have customer mods to make, create a branch by copying
> trunk (or a release branch).
> 2) Make customizations on this branch and give to customer.
>
> A new release comes out, and you need to update the customer branch.
> The easiest way to do this would be:
>
> 1) Create new customer branch from new release branch
> 2) Merge changes from previous customer branch to the new customer branch
>
> Because the number of customizations is much smaller than the number
> of changes between releases, this is the easier way to do it
>
> I am sure it will not be as easy to do as ClearCase, but it should be
> manageable. You might also maintain a patch for each customers
> customizations so that you can just apply that to a release branch as
> needed.
>
how can I create something you called "patch". I know the patch thing
which is in unix a way to apply changes to a file set. Is there
something with subversion support as well? The only thing what I need is
identifying file revisions deltas from a base revision to a newer
revision and the same file revision again on another branch (or tag).
--
mit freundlichen Grüßen,
Joachim Armbruster
Re: Migration from Clearcase to SVN / organizing projects
Posted by Mark Phippard <ma...@gmail.com>.
On Feb 17, 2008 5:03 AM, Joachim Armbruster <jo...@gmx.de> wrote:
> we want to migrate from CC to SVN, since SVN is cheaper (and cooler...)
>
> In clearcase our projects (embedded software development) are organized as followed:
>
> 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.
>
> 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.
> 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.
>
> 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.
>
> 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?
I think you would need to do something like this:
1) When you have customer mods to make, create a branch by copying
trunk (or a release branch).
2) Make customizations on this branch and give to customer.
A new release comes out, and you need to update the customer branch.
The easiest way to do this would be:
1) Create new customer branch from new release branch
2) Merge changes from previous customer branch to the new customer branch
Because the number of customizations is much smaller than the number
of changes between releases, this is the easier way to do it.
I am sure it will not be as easy to do as ClearCase, but it should be
manageable. You might also maintain a patch for each customers
customizations so that you can just apply that to a release branch as
needed.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Migration from Clearcase to SVN / organizing projects
Posted by Joachim Armbruster <jo...@gmx.de>.
Reedick, Andrew schrieb:
>> -----Original Message-----
>> From: Joachim Armbruster [mailto:joachima1@gmx.de]
>> Sent: Sunday, February 17, 2008 5:03 AM
>> To: users@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?
>
Some merging is needed as well, but should not be the majority of all
the files.
>
>
>
> 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.
We use the first CC strathegy to include the corrosponding labels.
> 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 ...
>
>
>
The CUSTOMER_WIDGETS_INC label can "delete" files, does the shown script
the same?
As I recently discovered, some of our project make files just draw all
*.c files... Arghl.
--
mit freundlichen Grüßen,
Joachim Armbruster
RE: Migration from Clearcase to SVN / organizing projects
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Joachim Armbruster [mailto:joachima1@gmx.de]
> Sent: Sunday, February 17, 2008 5:03 AM
> To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Migration from Clearcase to SVN / organizing projects
Posted by Mark Reibert <sv...@reibert.com>.
On Sun, 2008-02-17 at 11:03 +0100, Joachim Armbruster wrote:
> Hello,
>
> we want to migrate from CC to SVN, since SVN is cheaper (and cooler...)
Well, I am a big SVN user and fan, but even so I have always thought
MVFS (and hence, dynamic views) is pretty cool!
;-)
--
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org