Hello all,
For some time, I've been encountering a spurious conflict behavior which I
don't understand so I thought I'd finally see if anyone can explain it to me.
I'm using aegis 4.11.D002 with fhist as my history tool; I used the fhist
config example as-is from aegis 4.11.D002.
My procedure is that I have an original change, say 10, which I realize
has gotten too big and should be split into 2 parts. Then I clone this
change, yielding, say, change 11. I clean up change 10 and integrate it.
Then in change 11 I run aed, and my hope and expectation is that all of
the now-integrated parts from change 10, which are out-of-date but
identical in content in change 11, would be recognized by the history tool
as being "identical" (thus allowing an aecpu on these identical files), but
instead, these out-of-date but identical-in-content files in change 11 are
flagged as being different, forcing a merge. Examination of the auto-merged
files reveals large numbers of "conflicts" where the original and new versions
are identical in content. I can understand how this can in some sense be
seen to be a conflict (the change 11 content is "older" than the integrated
change 10 content), but the content is the _same_, so I just want aegis
and/or fhist to recognize this and not flag these as conflicts, so that I
can focus my attention on the actual changes in content between change 10
and change 11 without chasing down all these "identical" conflicts.
Is there some flag to aegis or fhist (or fmerge or fcomp) that can give
this desired behavior? It's really tiring to hunt down and fixing hundreds
of "identical" changes, with the danger that I might miss an actual
difference-in-content change.
Thanks,
Norman
|
