Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Apr 2008 10:34:48 -0700
From:      Julian Elischer <julian@elischer.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Ed Schouten <ed@80386.nl>
Subject:   Re: Perforce and `p4 diff2' against the origin
Message-ID:  <47FBACB8.4080304@elischer.org>
In-Reply-To: <200804081007.17874.jhb@freebsd.org>
References:  <20080405145038.GE5934@hoeg.nl> <20080407183159.GP5934@hoeg.nl> <200804081007.17874.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Monday 07 April 2008 02:31:59 pm Ed Schouten wrote:
>> Thanks everyone for your replies. I think I should spend some time at
>> the office trying the solutions to see what's the easiest way.
>>
>> I'm just a little bit disappointed by the fact that p4 doesn't have some
>> kind of switch for diff2 to do this by default. It should already keep a
>> list of such relations internally to make integrations and such work.
>>
>> Is there a way for us to submit feature requests at Perforce?
> 
> Well, it's not quite that simple because p4 lets you do things like cherry 
> pick revisions (I want to merge revisions 1-4 and 7 into foo.c but not 5 and 
> 6 yet.. in that case, what should it diff against, #4?  #7?  #7 with #5 and 
> #6 backed out somehow (what if that has conflicts?)?) and merge from 
> different paths into the same file.  So for example if I had this:
> 
> //depot/foo.c
> //depot/bar.c
> //depot/baz.c
> 
> and I merged foo.c#1-#2 into bar.c and foo.c#1 into baz.c.  Then suppose I 
> merge bar.c into baz.c (thus carrying the changes in foo.c#2 into baz.c).  If 
> I diff foo.c against baz.c should it diff against #1 or #2?
> 
> The reason you have a good answer for what to merge in your case is because it 
> is a degenerate case and while that one may seem obvious a general purpose 
> solution is not as obvious.  The other thing to recall is that if you were 
> just using p4 w/o HEAD in CVS you wouldn't generate patches in the first 
> place.  Instead, you would use 'p4 integ -r' to merge changes from your 
> branches up into HEAD.  I do this at work where all out stuff lives in p4 and 
> don't really use patches much anymore except to review before a submit (so I 
> would do 'p4 integ -r -b foo_feature; p4 resolve -a; p4 diff -du ... | less; 
> p4 submit').  Thus, we use p4 in a bit of an odd way since HEAD is in CVS and 
> if you use it as it is designed to be used patches aren't all that important, 
> hence they aren't going to focus as much effort on it.
> 

the new p4 interchanges command may be relaqvent to this discussion...

I haven't used it yet but it seems relevant.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47FBACB8.4080304>