[p4] Moving Files.

Ganesh Kondal gkondal at modulant.com
Thu Jul 5 14:45:14 PDT 2001


Hi Steve,
	The problem here is ..

products/src/com/a/b> mysource.java
                is going to
products/src/x/y> mysource.java ..
                to a entirely new structure that completely differs from the
exising one

So trying to estimate the necessity/importance of keeping the versions
attached to the file.

Thanks for the insight given,
Ganesh

-----Original Message-----
From: perforce-user-admin at perforce.com
[mailto:perforce-user-admin at perforce.com]On Behalf Of Stephen Vance
Sent: Thursday, July 05, 2001 12:36 PM
To: Ganesh Kondal; perforce-user at perforce.com
Subject: Re: [p4] Moving Files.


At 10:06 AM 7/5/2001 -0700, Ganesh Kondal wrote:
>Hi All,
>
>   We have our product source code in perforce server. Now its planned to
>change the whole directory structure..
>
>         so
>
>         Products
>                 /src
>                /com
>                         ....
>
>
>         is going to get moved to
>
>         Products
>                 /src
>                /newname
>                                         ...
>
>         Facts:
>                 All the files under java is going to get moved to a new
> structure.
>
>         Qn:
>            There is already 4 to 5 revisions for each file. If i move the
> files to
>a new structure, do i have to start them as new revisions or can i do
>something so that perforce can keep track of the earlier revisions.

There are two approaches that you can take.  The first is easy and uses the
regular Perforce commands.  Simply 'p4 integ //Products/com/...
//Products/newname/...' and then 'p4 delete //Products/com/...'.  If the
changes run deeper, you will need additional commands.  The advantage to
this is that it uses completely supported Perforce commands.  The
disadvantage is that you will have to remember to use the -i flag to follow
the version history across integration history, and if you have branches
off of com with files checked out, you may have integration issues.

The second approach is checkpoint surgery.  It is possible to checkpoint
the server, shut it down, perform search and replaces on the checkpoint,
manually move the depot files, restore from the checkpoint, and restart the
server.  The result (if done properly) is the same as if the files had
originally existed in the new location.  The disadvantage is that client
workspaces (physical storage) will have to be altered for correspondence to
the depot structure, which could be awkward if things were checked
out.  The advantage is that you don't have to think about whether the file
was moved when searching its version history.  I recommend contacting
Perforce Support if you want to pursue this option.

Steve


Stephen Vance
mailto:steve at vance.com
http://www.vance.com/

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list