Rules or best practices for branching/merging scenarios

Hi there,

(and sorry, if this mail is sent twice - I *think* my mail client
crashed while sending the firest mail...)

we are about to switch from Ration ClearC*se to a new SCM. As I used
CVS a lot, I want to switch to something "similar, but better". Right
now we are discussing just two options:

  - Subversion (SVN)
  - Perforce (P4)

For some reasons (simpler UI, smart, user base, open source, ... and of
course simply emotion ;-) I'd prefer SVN. As "counterpart", I have a
colleague of mine who worked with and loves P4.

We have investigated both systems now, and there are only a few things
to note:

  - P4 seems to be little faster
  - The P4 UI is more complex (of course, it has more complicat^Wpowerful
    concepts, it is very easy to start with SVN (and TortoiseSVN)
  - Integration into Java IDEs is given for both systems, and both have
    problems with VS.NET, although SVN has probably a better workaround.
  - Both systems do exactly what we want regarding standard operations
    (update, "checkout", checkin). It is just a matter of personal style
    if you prefer the P4 approach (you can always see what others do) or
    SVN (server does not know anyting).

So far, I think we _could_ go with SVN, but there is one open issue: I
have read the SVN Book twice, I have read many mailings, web sites, the
TortoiseSVN docs etc. but I can not say I really understood the issues
one might have with the merging capabilities of SVN, but on the other
hand I can not assure that the SVN concepts are ok for us.

So what I need (and hope to get on this mailing list) is a short
overview how _you_ do branching/merging in your projects, especially if
you are also working for a software company that has clients, versions,
maintenance contracts, etc. So let me briefly describe what we do and
where we have had problems before.

Normally, we have teams of about 5-10 developers work on the same code
base. We have "ownerships" for parts of the sourcecode, so normally
people do not work with the same files. Of course, sometimes this
happens - with CC it was always a mess because of the locking - and we
have ways to deal with it, normally. often we develop software for our
clients and the go into a maintenance process where we ship bugfixes,
enhancements etc. These are developed in either "bugfix" or "feature"
branches that were started from the main (integration) branch ("trunk"
in SVN terminology) after a release and merged back after the bug is
fixed ot the feature is ready. So far, so good.

There are some situations we ran into before where I can not see if SVN
would be a good choice - this has normally something to do with the fact
that we activeley develop in more than one branch at a time (hey, that's
what branches are for ;-) .

1) Urgent bugfix need to be released
Suppose three branches: the trunk (T), a bugfix branch (B) and a feature
branch (F). Many people are working in F doing many changes. Now a
critical issue is fixed in (B), checked, merged into (T), and released
to the client. Now, to have the fix in (F) too, (T) is merged into (F).
This might happen various times. Later, development in (F) is finshed -
(F) has everything that is in (B) and (T) and additional changes and
needs to be merged into (T). How can I prevent that fixes already in
(B) and (T) are merged back again? Or is there no issue with it, since
SVN simply normally recognizes that there is nothing to do?

2) Branch with different features need to be merged partially
Suppose you have two branches: The trunk (T) and a feature branch (F).
For some reasons, not only one feature A is developed in (F), but
another one B. After quite a while of hacking, the clients wants us to
relase feature A, but _not_ feature B. So I have to merge parts of (F)
into (T): exactly those changes that were part of feature A. Any
chance? Later, also B is to be released, so I have to merge "the rest"
of (F) into (T). How is this done?

3) Changs need to be spread over active branches
Sometimes we do some refactoring, which is done in a separate branch
(R), which, after everything is finished, needs to be merged to all
other branches (say (B), (F1), (F2)) that are currently used, and later
into the trunk (T). So the first "working branch" merged into (T) will
incorporate the refactoring there. What about later merges? Will they
fail? Will SVN recognize what happens?

Actually, one might ask why I do not simply try everything I describe.
There are two reasons for it: Building such scenarios if quite a lot of
effort (I do not speak about one line changes, but of many files with
many many changes in every case), and - which is much more complicated -
I need to organize a meeting very soon where we compare both systems, so
I am simply looking for every information I can get.

Thanks for listening! Any help is appreciated.

   Jonas

-- 
   Note: 96.31% of all statistics are fiction.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org