[p4] Issue with edit on integrate

[Albrecht, Matt]

> First, a couple of questions. In (1) was there a submit at 
> the end? In 
> (5) when you say the file was modified, was this after a 'p4 edit' of 
> the file or outside of any Perforce knowledge? Also, what version of 
> client and server are you using?

Yes, step (1) was an integrate + submit.  (2) was a submit in a separate
changelist from (1).  For (5), the user essentially did this:

$ p4 change
(creates empty changelist # 1234)
$ p4 integrate -c 1234 //depot/branchB/... //depot/branchA/...
$ vi /home/user/workspace/branchB/foo.txt
(make some edits and save, and most probably ignoring the read-only
flag)
$ p4 submit -c 1234

> Files that are open for integrate but have not been re-opened for edit

> (whether add or merge) should be read-only on disk. The user or editor

> would have to make the file writable to make changes without
> performing a 'p4 edit'.

That's what I figured.  I've been forgetting the ability to run 'p4
edit' after integrate, prior to submit.

Thanks for the help!

--Matt

> -----Original Message-----
> From: Stephen Vance [mailto:steve at vance.com] 
> Sent: Thursday, January 04, 2007 1:40 PM
> To: Albrecht, Matt
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Issue with edit on integrate
> 
> Matt --
> 
> First, a couple of questions. In (1) was there a submit at 
> the end? In 
> (5) when you say the file was modified, was this after a 'p4 edit' of 
> the file or outside of any Perforce knowledge? Also, what version of 
> client and server are you using?
> 
> The records for integrate with add (branch) and integrate for 
> edit (copy 
> or merge) only differ by a field value in the database. This 
> value can 
> affect the integration algorithm
> 
> If Perforce knew the file was edited, then Perforce should 
> have used the 
> file contents from the disk. To do this, you should do a 'p4 edit' on 
> the file after the integrate operation while it is still 
> opened. If you 
> did not do the 'p4 edit' then Perforce had no reason to copy the file 
> from the disk. It would simply perform a lazy copy on the 
> server which 
> only uses a reference to the source file for the contents. Files that 
> are open for integrate but have not been re-opened for edit 
> (whether add 
> or merge) should be read-only on disk. The user or editor 
> would have to 
> make the file writable to make changes without performing a 'p4 edit'.
> 
> Steve
> 
> Albrecht, Matt wrote:
> > One of my users reported a problem when they did an edit on 
> a file that
> > was also marked for integrate.  I've walked through the 
> steps he made to
> > get a clear picture of what happened, and I think I have a good
> > understanding of the user's mistake, and what Perforce was 
> doing to make
> > it look like Perforce screwed up.
> >
> > 1. integrated from "//depot/branchA/" to "//depot/branchB/", which
> > worked fine.
> > 2. created file "//depot/branchB/foo.txt" and submitted it for add.
> > 3. performed several edits on this file in branchB, 
> bringing it up to
> > revision #5.
> > 4. integrated "//depot/branchB/..." to 
> "//depot/branchA/..." into a new
> > changelist.  This marked "//depot/branchA/foo.txt" as integrate with
> > add.
> > 5. modified "//depot/branchA/foo.txt" on his hard drive 
> (adding several
> > lines)
> > 6. submitted the changelist.
> >
> > At this point, his hard drive contained a different version of
> > "//depot/branchA/foo.txt" than what Perforce reports as the depot
> > version of "//depot/branchA/foo.txt".
> >
> > He had done similar operations where 
> "//depot/branchA/foo.txt" existed
> > in step 1, and Perforce did the right thing.
> >
> > My only guess is that Perforce uses a different record in 
> the db files
> > to mark a file as "integrate for add" and "integrate for 
> edit," and so
> > the server only put an entry linking to "//depot/branchB/foo.txt#5"
> > without also marking the edits that were made before integrate.
> >
> > So, besides slapping my users around with a limp salami, does anyone
> > know of a way to force users to "do the right thing," or is 
> this bring
> > up a potential issue in how Perforce performs integrations?
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >   
>