Add diff_from(self, other) method to CfgNode

[Zeltserj]

I needed this in my work and thought it would be cool to incorporate:

Given 2 CfgNodes:

Cfg1:

SYSTEM:
  NUM_GPUS: 2
TRAIN:
  SCALES: (1, 2)
DATASETS:
  train_2017:
    17: 1
    18: 1

Cfg2:

SYSTEM:
  NUM_GPUS: 2
TRAIN:
  SCALES: (4, 5, 8)
DATASETS:
  train_2017:
    17: 1
    18: 1

calling cfg1.diff_from(cfg2) returns another CfgNode instance, which is the following:

add:
  
change:
  TRAIN:
    SCALES: (8, 16, 32)
minus:
  

[luowyang]

Cool idea, but how are the following cases handled:

1. cfg1 has additional key/value mapping than cfg2
2. cfg1 has missing key/value mapping that is present in cfg2

[Zeltserj]

Thanks for responding quickly.

1. they won't be in the new config
2. they will be in the new config.

While this suits my use case (only changes in values, no additional keys), it is not consistent, so I'll change it.
I can either:

1. Throw an error that diff_from requires same keys
2. add all additional keys to the output

WDYT?

[luowyang]

I believe the intuitive semantics for cfg1.diff_from(cfg2) is cfg1 - cfg2 , meaning "how cfg1 differs from cfg2". In other words, the method should give us the change from cfg2 to cfg1.

Personally I recommend the solution that the method produces a new CfgNode which contains tree sub-nodes, add, minus and change. It is up to the users to decide what they want to do with each sub-node. Such behavior is more consistent with git diff.

Besides, it should be made clear whether the key/value mappings in the new CfgNode are shallow or deep copies of the original ones. Those mappings in cfg1 and cfg2 may change after diff_from returns.

[Zeltserj]

I agree. Good idea. Changed accordingly