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

[Alen Ladavac]

Hi Toby,

On the contrary - what you suggest seems less atomic to me. It goes
against the notion that a branch should always be in a compileable
state - otherwise you wouldn't need atomic changelists anyway.

Why? Consider a standard example of class Foo declared in
ModuleA/Foo.h and implemented in ModuleA/Foo.cpp. Let's say I want to
move this class to ModuleB. I need to change the fact that
ModuleA/Foo.cpp says "#include <ModuleA/Foo.h>" into "#include
<ModuleB/Foo.h>. If I do this as rename-first-edit-second, then in the
mean time, the branch in question is in an uncompileable state, which
is a no-no.

Does this make sense?

Alen


Toby wrote:

> 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