subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pacco <pa...@tropezien.de>
Subject Re: SCM, Content-Management and cherry-picking in big project
Date Mon, 01 Mar 2010 19:35:58 GMT
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.

Mime
View raw message