[p4] Diff for specific changeset?

[Toby Allen]

Changed subject back to what it should have been.

Chuck Karish wrote:

>>>Have you done this?  It's easy to create a sparse private branch into
which a developer can submit a provisional change.  It's not so easy
to make this change available to the reviewer so it can be examined
in the context of the shared code line.  There are other gotchas to
consider, too.  For example, what if a developer has two changes in
review that affect the same file?
>>>

We do this to an extent although our requirements do not exactly match the scenario discussed.  I dont understand however how  it can be difficult to get access to a change.  Every submitted changelist is available on the submitted tab to every other developer who has read access. By passing around a submitted changelist number you can allow people to view the submitted changelist, do a diff against previous revision to get changes (hence two changes to the same file can be seperate changelists).  Viewing it in context of the shared codeline I dont understand, but if anything using non-submitted files makes this harder not easier.  

If you work with a system like this, a reviewer could then integrate the change they have reviewed into the main codeline.

Toby Allen
Development Team Lead QUMAS.

 

 


Date: Tue, 9 Oct 2007 09:16:20 -0700
From: "Chuck Karish" <chuck.karish at gmail.com>
Subject: Re: [p4] perforce-user Digest, Vol 34, Issue 5
To: "Toby Allen" <tallen at qumas.com>
Cc: perforce-user at perforce.com
Message-ID:
        <98be1ea90710090916r32a305afxae870f8d7587a8a6 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 10/9/07, Toby Allen <tallen at qumas.com> wrote:
> If you are doing this kind of thing, it may be much better to set up a
> system of branches that can
> Be used to review code against rather than passing around numbers of
> non-submitted changelists.  One of the
> Really big benefits of perforce is that is makes branching so easy that
> there is no reason not to submit
> Code even if you submit it only against your own personal branch.
>
> Take a look at settin up a system where your developers will submit
> against a dev branch, they then pass the submitted
> Changelist number for someone to review, if it passes it is integrated
> into the mainline.  This does exactly what
> You want but in the way that Perforce intends.

Have you done this?  It's easy to create a sparse private branch into
which a developer can submit a provisional change.  It's not so easy
to make this change available to the reviewer so it can be examined
in the context of the shared code line.  There are other gotchas to
consider, too.  For example, what if a developer has two changes in
review that affect the same file?

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





********************************************************

This email message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, printing, copying or distribution is prohibited.  If you are not, or believe you are not, the intended recipient, please contact our systems administrator immediately at postmaster at qumas.com and destroy all copies of the original message and any attachments.

Any views or opinions presented are solely those of the author and do not necessarily represent those of QUMAS.

QUMAS has a virus detection policy but cannot accept responsibility for any loss or damage arising from the opening or use of this email and/or attachments.


********************************************************