18 messages in com.perforce.perforce-userlack of a rename command [was Re: [p4...
FromSent OnAttachments
Martin Ellison19 Oct 2000 23:16 
Peter Friberg20 Oct 2000 00:40 
Martin Ellison23 Oct 2000 00:20 
Jeff A. Bowles23 Oct 2000 01:01 
Vora, Rajul23 Oct 2000 12:12 
Daniel Neades24 Oct 2000 06:35 
andy nguyen24 Oct 2000 09:28 
Martin Ellison24 Oct 2000 15:43 
Daniel Neades11 Jan 2001 02:13 
John Bridges11 Jan 2001 07:00 
Diane Holt11 Jan 2001 10:26 
Jeff A. Bowles11 Jan 2001 10:39 
Arnt Gulbrandsen11 Jan 2001 11:09 
Rick Macdonald11 Jan 2001 11:11 
Diane Holt11 Jan 2001 11:23 
Rick Macdonald11 Jan 2001 11:55 
Steve Bennett11 Jan 2001 13:39 
Diane Holt11 Jan 2001 19:24 
Subject:lack of a rename command [was Re: [p4] How to change case of filenames of files stored on a Windows 2000 server?]
From:Diane Holt (hol@yahoo.com)
Date:01/11/2001 11:23:09 AM
List:com.perforce.perforce-user

But it seems like all of that could be handled by Perforce. If the file is open'd, and someone tries to do a rename on it, p4 could just deny the submit, letting them know it was open'd and by whom, then just do the usual now-it-has-a-change-number-so-submit-it-later routine. Once a file has some internal data attached to it about the fact that it's been renamed, the sync could certainly handle deleting then adding the file to any client (the way things are now, if I change the case of a file, in order to get the newly-cased file to really be on my client on NT, I have to sync #none the old-casing file first, then sync the new-casing file).

It just seems to me that Perforce could "version" the filename (or even a directory name) as easily as it could actual files. But I suppose I could just be naive about how complicated it would actually turn out to be to do that.

Diane

--- Rick Macdonald <rickm at vsl.com> wrote:

On Thu, 11 Jan 2001, Diane Holt wrote:

--- John Bridges <jbridges at gmedia.com> wrote:

On Thu, 11 Jan 2001 10:13:31 -0000, Daniel Neades wrote:

So, how does one change just the case of a file or directory name in Perforce whilst preserving the file revision history?

I'd also love an answer for this, since I had the exact same problem when moving a set of source from Windows to Unix. I couldn't find any way to fix it except obliterating all the files that needed to be renamed, and then resubmitting them after renaming them locally.

I use the delete/re-add method -- but it suuuure would be nice if Perforce offered a real 'p4 rename' command. (I really don't understand why they don't, since I can't see why it would be all that difficult to do -- but maybe there's some compelling reason that I just don't know about.)

When I added a Rename option to TkP4 (which just does the delete/add steps for you), I found that I had to add a ton of checks to make sure the rename would succeed when finally submitted. For example, the source file can't be open already, the target file cannot exist, etc. I'm sure there are still checks that I missed (the target name being in the client view comes to mind).

In the case of tkp4 (and the manual delete/add sequence), there are race conditions where somebody could open a file between my checks and when the user submits the "rename" changelist, causing the rename to fail.

What started out as a simple delete/add sequence got large and messy. I've wondered if the reasons for not having a proper rename go beyond the issues such as what I've encountered above?

...RickM...

===== (holtdl at yahoo.com)