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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"