[p4] rollback changes with integ? (long)

Shackelford, John-Mason john-mason.shackelford at pearson.com
Tue Jun 8 19:49:53 PDT 2004


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. 
****************************************************************************



More information about the perforce-user mailing list