2012-01-28 02:04 AEST by Glen Starrett - Currently if the user has:
* Done in initial import of existing ENG / DEV / STAGE / PROD promotion levels
* Using BugID's to manage changesets

The can end up in a situation where the initial differences are missed:

- Do initial import to PROD, branch
- Do initial import to STAGE, branch
- Do initial import to DEV, branch
- Do initial import to ENG
- Do some change in HEAD (ENG) marked as bug 123
- Promote bug 123 to STAGE

-> The initial difference between STAGE and DEV will be skipped and only bug 123
change will be promoted in this scenario.

The problem is that they are bringing in 4 revisions during migrate then making
a change and promoting only that change:
PROD (1.1), STAGE (1.2), DEV (1.3), ENG (1.4), BUG1234 (1.5)
 
If you promote the changeset 1234 to DEV then you 'miss' revision 1.4.


The most practical workarounds to this seem to be to import with a BugID and
ALWAYS include that BugID with all merges to ensure that the initial difference
gets promoted on every file (even seldom changed ones).

* Could have a server setting or a default setting that says "bug 1 is the
initial import identifier and is automatically included in all merges"

* Could set up a process where CVS warns the user (useful for the more generic
case of 'fogotten' changesets or unmarked changesets):
- is this the first merge between B1 and B2
- is the range of the change different to the range B2-B1
- warn user - this merge does not contain all the changes made on B1