[p4] Diffing renamed files before submitting (Glidden, Richard)

[Toby Allen]

hi Alen,
 
I think I would have to suggest that the renaming action should be atomic. I think the desired action would be that you would rename the file, submit and then checkout again to make further changes.  Down the line I think this will give you least problems.  Its easy to re-checkout files submited by checking the box in the submit form.
 
Toby.


Message: 2
Date: Wed, 10 Oct 2007 11:50:03 +0200
From: Alen Ladavac <alenl-ml at croteam.com>
Subject: [p4] Diffing renamed files before submitting
To: perforce-user at perforce.com
Message-ID: <319084848.20071010115003 at croteam.com>
Content-Type: text/plain; charset=us-ascii

A curious problem came up by one of my colleagues and I was certain
that p4 could handle that nicely even in p4win, but even resolving to
manual command line option wizardry didn't help.

The scenario is:

1) open a file for rename, which turns out as a delete and an add
(branch)
2) reopen it for edit (because you need to change the #include
filenames in it, if you are to submit e.g. .h and .cpp both renamed in
one go.)
3) now try to check the diffs you did in this edit.

It is weird that once you submit this, the history is very easy to
access and the diffs work normally, but we'd like to see the diffs
before submition - to be sure what was done. Somehow seems that there
is no way to force p4 to compare one file in depot with another file
on client. The only way around it we've found was to use another
client to sync the deleted file and manually compare two files on the
disk using BeyondCompare.

Is there something we are missing here? Is there some reason why this
should be so complicated?

Thanks,
Alen







********************************************************

This email message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, printing, copying or distribution is prohibited.  If you are not, or believe you are not, the intended recipient, please contact our systems administrator immediately at postmaster at qumas.com and destroy all copies of the original message and any attachments.

Any views or opinions presented are solely those of the author and do not necessarily represent those of QUMAS.

QUMAS has a virus detection policy but cannot accept responsibility for any loss or damage arising from the opening or use of this email and/or attachments.


********************************************************