[p4] Is it OK to manually edit as part of a resolve and "Accept Merged"

[Brad Holt]

Hello All,

I've got a bit of a fine point here that I've thought through before a
few times but would like someone to check my work. I've tested it, but
I can't really tell if my testing is checking everything.

As part of the manual resolve process, a user can manually edit the
resulting file. If they do some of these manual edits, and then do an
"Accept Merged", then will the right things happen in regards to the
integration records and future common ancestors? To be honest, we've
been doing this for years, and I cannot point to any particular
problems. We do get a lot of confusing merges, but that's probably just
par for the course the way we do things. Should the file be "Reopened
for Edit" by the user to let p4 know they are inserting changes that
were not in either version of the merging files?

We got burned on this a few years ago when users had misconfigured their
merge tools (not a perforce problem), and wound up resolving files and
then doing an "Accept Yours". Everything looked fine in the target
files, but files branched from those revisions, lost the edits as the
integration metadata saw the original merge as an "ignore" resolve
action, so it didn't realize that edits had been included because it
didn't even realize they were there.

Does an "Accept Merged" roll the common ancestor, and if so, then
wouldn't in-resolve manual edits mess with this? I would expect that
"Accept Merged" is a dirty merge, and doesn't roll. For some reason, I
find this stuff tricky to test, and I don't trust myself.

Anyway, just wanted to confirm this as I've got some merge training to
give.

Thanks.

-brad

[Peter Stephenson]

Post by Brad Holt
As part of the manual resolve process, a user can manually edit the
resulting file. If they do some of these manual edits, and then do an
"Accept Merged", then will the right things happen in regards to the
integration records and future common ancestors? To be honest, we've
been doing this for years, and I cannot point to any particular
problems. We do get a lot of confusing merges, but that's probably just
par for the course the way we do things. Should the file be "Reopened
for Edit" by the user to let p4 know they are inserting changes that
were not in either version of the merging files?

If the manual edit is done as part of typing "e" (or one of the other
edit options) or "m" when offered the various options by p4 resolve (or
the graphical equivalent), then yes, the file will have a correct
integration record.

What you have to avoid doing is fixing things up after the resolve by
using "p4 edit". That does mess up the integration record. (I'm not
entirely convinced it should, however, since Perforce knows perfectly
well you've done the integrate and resolve, so I think it's being a
little less smart than normal here.)

If you need to fix things up after the resolve when you've already done
some manual editing during the resolve, the procedure (again from the
command line) is
- run "p4 resolve -f <file>"
- type "ey" to edit your file, which is the one that already contains
the edits from the original resolve
- after editing, run "ay" to accept this file.

I'm fairly happy this all works because we do quite a lot of it. For
historical reasons we have a hand-edited change log in each file in some
areas of the archive. This is ghastly to maintain and there's a strong
argument that it's a lot more trouble than it's worth (don't bother
telling me :-)); but it does mean we've done a lot of editing during
merges.