[p4] Integrate and Edit - what is good practice and why?

steve at vance.com steve at vance.com
Thu Aug 9 15:09:53 PDT 2007


That covers the technical difference. From a development process
perspective, the only real difference is whether you have an intermediate
submission that may be out of character for its location. For example, if
you are branching a file that contains your version number to a release
branch, do you want to allow a version of the file to have the version
number from your development branch? As another example, if you are
refactoring Java classes or Perl modules, do you want a submitted version
in which the file name is different from the class/module name?

For these things its just a matter of policy. On a developer branch, I
wouldn't care much about either of these examples. For the release branch,
I would absolutely edit the file immediately after integration. For the
refactoring/renaming cases, if the code were being submitted into any
substantially shared branch (e.g. a main hosting 400 developers), I would
also edit immediately after integrating.

Steve

Original Message:
-----------------
From: Shawn Hladky p4shawn at gmail.com
Date: 	Thu, 9 Aug 2007 14:00:19 -0600
To: ilde.web at gmail.com, perforce-user at perforce.com
Subject: Re: [p4] Integrate and Edit - what is good practice and why?


Check out this white-paper, under the section called "dirty branch".  It
explains the distinction in gory detail.  Basically, the difference is when
you merge back, Perforce will pick a different file for the base.
http://perforce.com/perforce/conferences/us/2005/presentations/AntonPaper.pd
f

>From a tracking standpoint, it's sometimes handy to know that #1 of a
branched file is identical to the parent at the point of branch.  This is
the reason I like to submit the branch and then re-open.  The only exception
is for re-names... where often the code has to change at the same time as
the re-name to keep the build from breaking.

On 8/9/07, Ildefonzo Arocha <ilde.web at gmail.com> wrote:
>
> Hi there,
>
> New P4 user here.
>
> If you would to branch a file and then make some changes, what is
> considered best practice and why?:
>
> p4 integrate //depot/main/foo.c //depot/v1/foo.c
> p4 submit
> p4 edit //depot/v1/foo.c
> p4 submit
>
> -or-
>
> p4 integrate //depot/main/foo.c //depot/v1/foo.c
> p4 edit //depot/v1/foo.c
> p4 submit
>
> In the first case p4 filelog reports:
> //depot/v1/foo.c
> ... #2 change 40 edit on 2007/08/09 by iar at iar (text) 'Test 2 '
> ... #1 change 39 branch on 2007/08/09 by iar at iar (text) 'Test '
> ... ... branch from //depot/main/foo.c#1
>
> In the second case p4 fielog indicates:
> //depot/v1/foo.c
> ... #1 change 41 add on 2007/08/09 by iar at iar (text) 'Test 2 '
> ... ... branch from //depot/main/foo.c#1
>
> Funny though, P4V reports in the second case 'add'.
>
> Besides the obvious difference of doing an extra step like on the
> first case.  What are the Pros and Cons of doing it one way or the
> other?  Does it make any difference for p4 interchanges?  Will I have
> any possible problems/restrictions/limitations of I tell my users to
> edit their newly branched files without needing to submit them first
> (like in the second case)?
>
> Thanks,
> Ildefonzo
> _______________________________________________
> 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


--------------------------------------------------------------------
mail2web LIVE – Free email based on Microsoft® Exchange technology -
http://link.mail2web.com/LIVE





More information about the perforce-user mailing list