[p4] Moving Files.
Kevin McWhirter
kmcwhirter at us.gaussinterprise.com
Fri Jul 6 00:31:25 PDT 2001
The p4 integ -n option works wonders here. You can see what p4 would do
without it really doing anything. It is modeled after the make -n option.
-Kevin
-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com]
Sent: Friday, July 06, 2001 4:58 AM
To: Ganesh Kondal; perforce-user at perforce.com
Subject: RE: [p4] Moving Files.
If you choose to use the integ/delete method, a branch spec for the integ
can simplify and codify a complicated set of integrations. You just need
to be particularly careful of overlapping regions in the source or the
target. For example, if you are splitting up a directory or combining two
directories.
Steve
At 02:45 PM 7/5/2001 -0700, Ganesh Kondal wrote:
>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
>
>_______________________________________________
>perforce-user mailing list - perforce-user at perforce.com
>http://maillist.perforce.com/mailman/listinfo/perforce-user
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