On Sat, Aug 16, 2008 at 01:11:48PM +0100, zakshurst_at_googlemail.com wrote:
> Hi
Hello.
> I am the Configuration administrator for my company and I am looking to
> migrate our configuration management from PVCS to Subversion.
>
>
>
> Question: How do you manage multiple versions (streams) of a products ?
>
>
>
> In reading Subversion documentation I can see how it works great on the
> Current Stream of a product but I don*t see how people manage different
> streams of the same application other than first looking at the history
> and manually checking which is the current version for a specific file as
> a support release on a stream may have moved , making it tedious and error
> prone. I am sure this is not the case, but it is just my impression.
How far have you read in the documentation?
Have you read the chapter about branching yet?
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
> The issues I have is around Product release Stream versioning. We use PVCS
> to manage multiple streams of our product.
Such a stream would be a branch in Subversion.
> To put it in perspective we
> have a medium term system that has around 5 main streams (Version6,
> Version7 .. ) , these tends created as the result of technology changes,
> but we have some 30 streams ( Verson 6.5.1, Version 8.0.1*) for various
> functionality changes, on each stream we provide then support releases
> 8.0.1.n. We use this the same configuration management system and policy
> on Source code, database, docs and tests results. Some 10 products with
> some 200 projects and holding about 10000 files/archives. We are able to
> extract all the relevant current versions of code, database, documents for
> any stream in a single extract.
You can create branches of branches in Subversion quite easily.
Note though that the current merge tracking functionality is
geared mostly towards the use case of a single mainline of development,
with stable and feature branches forked off that.
So while you can branch off branches without problems, the merge
tracking might still have some rough corners in those use cases.
See also the Subversion 1.5 release notes:
http://subversion.tigris.org/svn_1.5_releasenotes.html#merge-tracking
> We use PVCS , but its performance over the WAN makes it unusable ,
> especially now as we move to contiguous integration. Whilst version
> numbers and labelling of those versions is important we make use PVCS
> feature called promotion groups. Most use it to track status of files
> through being in Development , Testing and Release. We use it for that,
> though have found that using it to manage streams makes it invaluable.
You might want to do performance tests before deciding to
switch to Subversion for good. Consider git, too, if performance
is very important to you. It has much better performance than
Subversion for many use cases, yet has other disadvantages (e.g. steep
learning curve for developers, might not be able to integrate into
your IDE, strong focus on UNIX-like operating systems).
> A promotion group is hierarchical so for a stream we have a promotion
> group like this Rel_8.2.0,Test_8.2.0 and Dev_8.2.0.
>
>
>
> Basically when we create a new stream we baseline the artifacts (code,docs
> etc..) , by assigning a new release promotion group. A developer ( or any
> PVCS user ) has to select a promotion group the file gets assigned the
> promotion group Dev_8.2.0, if they check out the same file again then the
> Dev promotion group moves to new version.
Stop thinking file-based. Seriously. That's the first thing you
need to do, or you will very often end up scratching your head when
using Subversion.
Subversion versions *trees*. Keep that in mind while reading the
documentation.
> This might not sound very important but forgetting all the other benefits
> that come with a promotion groups what it means is that the developer when
> working on a Release only has to remember the stream he is working on and
> he is guaranteed to always to pull out the correct version from PVCS of a
> file. When he checks in then it may branch and warning is duely
> dispalayed.
In Subversion, developers just have to remember the right name of
the branch they're working on. Than they just checkout that branch,
for example:
svn checkout https://example.com/svn/branches/mybranch
> We actually create temporary projects for streams that are just views onto
> a master PVCS projects , sharing the same archives across all temporary
> projects, these temporary project just have the one promotion group for
> that stream. A developer then changes his default project in his IDE to
> point from one stream to another by changing the temporary project he is
> using.
That sounds much like in Subversion-land your developers would be
using multiple working copies, with each working copy checked out
from a different branch.
Subversion has great integration into various IDEs. I'm not sure
what you are using, but you will likely find something that makes
Subversion accessible from within your IDE.
> Our build process then labels all the files and Shared files ( including
> common files , data base scripts) with the same build label which starts
> with the promotion group name, if a new version of a binary is created
> this build number is stored in the help about box for the product, making
> it a doodle on a support calls. Anyway*
That's just making up some name, stashing it into the binary and
also creating a tag of the corresponding branch based on that name.
That's trivial, see the chapter on tagging:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
> In reading Subversion documentation I can see how it works great on the
> Current Stream of a product but I don*t see how people manage different
> streams of the same application other than first looking at the history
> and manually checking which is the current version for a specific file as
> a support release on a stream may have moved
You create branches corresponding to your streams.
Again: You don't *ever* check out versions of specific files in Subversion.
You just check out some version of a tree.
I hope these pointers help to clarify things for you,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-16 18:10:22 CEST