[p4] rollback changes with integ? (long)

Stephen Vance steve at vance.com
Tue Jun 8 21:55:14 PDT 2004


I agree that integrating from the previous has a natural ring to it, but it 
just doesn't work.  Technote #14 is the answer.

Steve

At 10:49 PM 6/8/2004, Shackelford, John-Mason wrote:

>Yes, I've read technote #14. :)
>
>Q: Does it ever make sense to use integ to do a roll back?
>
>Scenario:
>
>Development groups a. and b. are making changes in branch a. subsequent to a
>known start of development change @101. Group b experiences delays and will
>their change with group a's code. These two should have been in two separate
>branches to begin with, but... (poor communication, bad planning, etc.,
>etc.) So we create a new branch b. from branch a at 101, and then integrate
>changes from the directories in which the b. group was working (see fig.
>1.1). (Happily, group a. and b. work in different areas of the depot and did
>not edit the same files.) Branch b. now contains nothing but b's work.
>
>figure 1.1
>--------------------------------------------
>1. a at 101 --> b
>2. a/dir1/... at 901,  a/dir2/... at 901 --> b
>--------------------------------------------
>
>Now we need to roll back b's changes in branch a. Technote #14 suggests we
>sync a. to @101, edit files, add deleted files, sync to @701, resolve -ay,
>sync, resolve again, delete files, and then submit. But can't we leverage
>the power of integ to help us figure out which files to add, edit, and
>delete? (If we have a large number of files to deal with the technote #14
>solution could be painful, furthermore we don't have integ history to help
>us where the revisions came from.)
>
>What I tried first:
>
>Being fairly green my first thought was to use the branch spec. I created in
>
>figure 1.1 to create a new one which mapped group b's the files to
>themselves (fig 1.2). I then attempted to do the integrate specifying that I
>want to force re-integration only through change @101 (fig 1.3).
>
>figure 1.2
>--------------------------------------------
>//depot/a/dir1/... //depot/a/dir1/...
>//depot/a/dir2/... //depot/a/dir2/...
>--------------------------------------------
>
>figure 1.3
>--------------------------------------------
>p4 integ -d -t -f -n -b rollback_branch_spec //... at 101
>--------------------------------------------
>
>Intead of integrating the specified files forward from @101 as I had
>expected, I get the message: "no permission for operation on file(s)." Since
>I have write access to everything in every depot, I take this message to
>mean that I am going about this all wrong. Though having read everything I
>could find on integ, I couldn't decide why exactly this is the case.
>
>What I am thinking about now:
>
>Being too stubborn for my own good, I think to myself: "Why not integrate
>from b?" (fig 1.4).
>
>figure 1.4
>--------------------------------------------
>@1001   a/... at 101 --> b
>@1002   a/dir1/... at 901,  a/dir2/... at 901 --> b
>@1003   b/dir1/... at 1001, b/dir2/... at 1001 --> a
>--------------------------------------------
>
>Then later, after b's work is complete and ready to be reintegrated with
>a's:
>
>--------------------------------------------
>@1017   b/dir1/..., b/dir2/... --> a
>--------------------------------------------
>
>I am thinking that this will buy me two things:
>
>1. History as to the orgin of the revisions submitted as part of the
>rollback of b's code in a.
>2. The ability to let integ do the work of handling all of the adds,
>deletes, and edits required for the rollback instead of my having to compile
>a long list and manually working through them.
>
>Have I got it all wrong? If so, please explain--I'd like to understand. If
>not, perhaps I should lobby for an updated technote 14?
>
>
>
>John-Mason Shackelford
>
>Software Developer
>Pearson Educational Measurement - eMeasurement Group
>
>2510 North Dodge St.
>Iowa City, IA 52245
>ph. 319-354-9200x6214
>john-mason.shackelford at pearson.com
>http://etest.ncspearson.com
>
>****************************************************************************
>This email may contain confidential material.
>If you were not an intended recipient,
>Please notify the sender and delete all copies.
>We may monitor email to and from our network.
>****************************************************************************
>_______________________________________________
>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/




More information about the perforce-user mailing list