Hi David,
I'm very thankful about your brief response and the many ideas and
thoughts you provided. In many cases you mentioned about choosing better
ways I absolutely agree with you. But unfortunately it is not up to me
to decide things like selecting the VCS or the underlying tools. There
are management decisions and you have to live with them and try to make
the very best out of it.
I already have seen a very fast, reliable and productive SCM-system
using ClearCase (multi-sited), self-made Content Mangement, integrated
Dependency Management and having a simple but easy to understand Release
Management.
But not in this company - things are different here.
And to make things even worse I come to this SCM-task like the virgin to
the baby. My roots are in development - not in SCM. Therefore I often
only spot problems in a specific attitude and don't get them in the full
way.
I want to describe some of my typical problems I have to deal with. My
initial intention might become much more clearer with that. During
writing these examples I already thought about possible solutions and
that I have to drop some of my ideas as they will indeed complicate my
intention of having a valid SCM with content-, dependency-, and
release-management.
1) Content management
---------------------
Simply not exitent. There are bug-fixes, new-features and other changes
that have to be implemented. Currently this was done in a more or less
anarchic way: everybody modifies and commits, runs the regression
testing and at the end the release was done on the latest version of the
release-branch. Stupidely sometimes the customers request only dedicated
changes, bug-fixes, or new features and not the whole bunch. Then I run
into the problem how to sort them out and provide a valid
release-version. Or the whole package fails at the end on one of the
dedicated platforms it has to run.
IMHO, the problem is the uncontrolled and free commitment of simply
every change that makes every new release to a hazardous game.
There were many intentions to fix these problems with more regression
testing, with additional intermediate steps, but at then end the problem
is still there.
The basic problem might be that it is not allowed for the developers to
use their own branches. They either have to use separate VCS for their
own purpose or directly do it into the main repository.
IMHO the policy of non-branching should be abandoned, then the
developers have the chance to hold their changes in their "back-hand"
until it is requested.
2) Version-stacking and rollbacks
---------------------------------
Developer A modifies file1.c and commits changes for bug#1 and in a new
file-version for bug#2. file1.c comes into release#1 and will be tested
in integration-test. There it is pointed out that bug#1 was not fixed
but bug#2 passed the test.
Now, rollback is necessary, but bug-fix#2 should stay in new version of
file1.c.
The basic problem is that the complete release could not be tested in
integration before releasing. There is simply no hard-/software
available. And if the release is made - there's no point crying over
spilt milk.
My idea was to simply select tags to make some cherry-picking of the
changes I could assume won't make the way over the integration hurdle.
But after having read your exposé I have to admit that my
rollback-problem must be fixed in the process itself and not by abusing
the VCS.
3) Version dependencies and rollbacks
-------------------------------------
In parallel developer B has modified file2.c that relies on changes of
developer A in file1.c (bug#1 version). Both changes has come into
common release#1. With rollback of bug-fix#1 the base of developer B's
changes have gone and file2.c must be rollbacked, too.
Seems nearly the same issue as before.
> So, the short answer is: No, what you want to do isn't easy to do in
> Subversion, but would pretty much be a mess in any version control
> system. You shouldn't pick and choose bug fixes and hope they create a
> releasable project. It's messy and it rarely works well. You're much
> better off prioritizing defects and features before your developers
> work on them than afterwards.
Yes, it looks like that it seems to be much more essential to have the
process and organization made in a way to achieve valid and stable software.
