[p4] Revision confusion

Chuck Karish chuck.karish at gmail.com
Fri Aug 31 07:22:23 PDT 2007


On 8/30/07, Dave Lewis <dlewis78731 at gmail.com> wrote:
> Now I'm curious.  If you edit an old revision, then submit, it will
> fail saying you must resolve  with the head revision.  does the act of
> submitting sort of force a sync to head for all the files in the
> changelist?

The message says "sync and resolve".  When a file is open,
"p4 sync" schedules a resolve, so that "p4 resolve" will give the
user the opportunity to decide which changes to accept.  The
result of the resolve is that the open file's base revision is moved
up to the revision to which the sync was done.

"p4 submit" fails unless the base revision is the same as the head
revision.

>  I would make sense that it does, so when the submit
> fails, the have list should now show the latest revisions for the
> files that are are being submitted.
>
> On the other hand, if you decide to revert when the submit fails, will
> it go back to the revisions you originally had synced to?  I could see
> it doing that because you didn't explicitly do the sync to head...

When you revert the file goes back to the base revision.

> dave
>
> On 8/30/07, Dave Lewis <dlewis78731 at gmail.com> wrote:
> > On 8/30/07, Ivey, William <william_ivey at bmc.com> wrote:
> > > > It makes sense because that is what you synced to.
> > >
> > > It would make sense if sync completed, but it didn't. The
> > > first half fails, but the implicit p4 flush is unaffected
> > > by that. I assume it set the stage for a potential resolve,
> > > but I'd feel better if what it were doing were made more
> > > explicit. (Or if I had to explicitly issue a p4 flush to
> > > put it into that state.)
> >
> > Well, the sync completes just the way it does when you edit an old
> > revision, then sync to head to schedule a resolve.
> >
> > > > Some would think on revert it syncs to the latest
> > > > revision
> > >
> > > No, my assumption would have been that it reverted the file
> > > to the same revsion it was at when you opened it for edit.
> > > That's what it usually does. I tend to think of edit/revert
> > > as a do/undo pair, but that's not the case now that I know
> > > a command seemingly unrelated to editing can affect the
> > > outcome.
> >
> > Well, since the old revision was synced to, then when you revert, it
> > gives you that old revision instead of the one you originally opened
> > for edit.  consider the outcome if it did not do this.  "p4 have"
> > would list the wrong file, and there would be no extenuating
> > circumstance to explain why it was wrong. (such as, its open for edit)
> >  By giving you what "p4 have" says is right, sync maintains its
> > consistency.
> >
> > I thought of edit/revert as sort of do/undo too, but we can see the
> > situation is actually more subtle than that.  It *looks* that way if
> > you don't reset the "target" revisions with sync.
> >
> > sync, in effect, sort of sets up the set of target revisions you want
> > to operate against.  In the case of editing an old revision, then
> > resolving up to the head revision, you can be much more specific in
> > the revisions you wish to skip by using sync to schedule the various
> > resolves necessary.  Like edit #1, sync to #2, accept yours, then sync
> > to head and resolve. This filters out #2 but keeps any other changes,
> > such as #3, #4.
> >
> > In this case, its doing the same sorts of stuff, just in a direction
> > that people hardly ever go!
> >
> > dave
> >
> > >
> > > -Wm
> > >
> > >
> >
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
Chuck Karish   karish at well.com   (415) 317-0182



More information about the perforce-user mailing list