Perforce questions w.r.t. task-oriented change manipulation

[NahtMy ReelName]

From the thread on scm multi-site tools came a brief dialog on improved
change management features and Perforce.
Chuck Karish wrote: NotMy RealName wrote:
For example, backing out a change that that altered content of 10 files, added one file, and removed another. This should be easy, but most
solutions fall down here, regardless of whether they use atomic database
commits or not.

It works fine in Perforce, as long as there have not been subsequent
modifications to the files that depend on what's being backed out.

--- and later ---
Which basically says you can't back out the change weeks or months
later. This unfortunate restriction tends to be an artifact of
delta-based file version management.

No, it doesn't say that. The deltas can be backed out at any
time.

-----------------------------------------

So what I want to know is if there's really a full task-based
or cset-like effect in Perforce change management.

Given a "initial implementation of the X feature", which we'll
abbreviate as "X" for the cset name, that changes 10 files, adds 1 file,
removes another file, and renames a third, consider the following questions:

(1) In Perforce, can I checkin X without promoting into any branches?

The discussion didn't hint at this. This is a useful property
of some cset-based systems that avoids branch proliferation.
Csets can be placed into the repository and used at will in
private sandboxes as well as shared branches.

(2) In Perforce, can I turn X on and off AT ANY TIME in any branch I choose?

The discussion says the answer is yes, I just want to affirm.

(3) In Perforce, can I ask, for any branch at any time, whether change
"X" was active?

Meaning that all entities impacted by X would have that impact reflected
in the branch, notwithstanding other changes that dilute X by deleting
it's inserted records, removing added files, etc.

This is an important reporting issue.

(4) Does Perforce changes capture file adds, removals, and content type
reinterpretations (text->binary, etc)?

So if I add change X to some branch and X adds one file and removes
another, the new branch will see this impact? The discussion suggests yes.

---------------------------------

Thanks for any info. I'm trying to understand if Perforce goes all the
way in task based change management from the perspective of change
manipulation, or if it's an also-ran.

Suggestion for any systems for which the answer is yes to all of the
above questions are welcome.

I'm also curious about BitKeeper and Clearcase "change-sets".

For BitKeeper what little I've gleaned suggests the answer is no to most
questions. Particularly since it *seems* like removing a cset in
BitKeeper really generates a set of anti-deltas,
which would seem to make the reporting on whether change X is active
somewhat ambiguous. (Enlighten me if my guess is wrong!).

Thanks for any informed information.

[Robert Cowham]

NahtMy ReelName <ergo@notavalidaddress.com> wrote in
news:ijUSa.102576$sY2.46874@rwcrnsc51.ops.asp.att.net:
From the thread on scm multi-site tools came a brief dialog on improved change management features and Perforce. ----------------------------------------- So what I want to know is if there's really a full task-based or cset-like effect in Perforce change management. Given a "initial implementation of the X feature", which we'll abbreviate as "X" for the cset name, that changes 10 files, adds 1 file, removes another file, and renames a third, consider the following questions: (1) In Perforce, can I checkin X without promoting into any branches? The discussion didn't hint at this. This is a useful property of some cset-based systems that avoids branch proliferation. Csets can be placed into the repository and used at will in private sandboxes as well as shared branches.

Absolutely. A submission to one branch does not affect any others
(without special scripting).
(2) In Perforce, can I turn X on and off AT ANY TIME in any branch I choose? The discussion says the answer is yes, I just want to affirm.

You can propagate X at any time to another branch (turning it on).
However, once you have done that, if you want to "turn it off" you have
to backout the propagation. This is OK. However, if you then want to
"turn it on" again, you can either undo the backout, or propagate again
explicitly redoing the original propagate (requires knowledge of the
changeset number). Turning on or off multiple times is not something to
be encouraged....
(3) In Perforce, can I ask, for any branch at any time, whether change "X" was active? Meaning that all entities impacted by X would have that impact reflected in the branch, notwithstanding other changes that dilute X by deleting it's inserted records, removing added files, etc. This is an important reporting issue.

In the basic form, this is a very nice feature of Perforce. You can find
out which changelists have been propagated between branches quickly and
easily.

Even nicer is the way jobs are handled. A job is in its simplest form a
textual description of a unit of work (e.g. a bug fix, or a new
feature). You can associate a job with multiple changelists (or vice
versa). There are simple commands which then show you whether the job
(ie the underlying changelists) have been propagated (although this
assumes you propagate entire changelists).
(4) Does Perforce changes capture file adds, removals, and content type reinterpretations (text->binary, etc)? So if I add change X to some branch and X adds one file and removes another, the new branch will see this impact? The discussion suggests yes.

Yes.

--
Robert Cowham
Perforce Consulting Partner

[Chuck Karish]

NahtMy ReelName wrote: Robert Cowham wrote:
This sounds similar to what appears to be BitKeeper's approach, that 'turning off' is basically generating a set of anti-deltas that cancel the prior deltas. Is that correct?

Yes.
If so, it lacks some of the elegance of a pure changeset approach, but very few vendors seem to offer that. In a pure cset approach, turning a cset on or off doesn't create any deltas, it just marks the cset as active or not in a 'version' that is basically a cset status event log.

Perforce tracks a change as an identifiable entity before it's
submitted, while it's being submitted, and with respect to whether
it has been merged to the parent and/or the child branch of the one to
which it was submitted. A change is not a persistent database object
that can easily be tracked as its effects propagate through the tree.
Still, it's a step up from traditional offerings. Do I understand the 'anti-delta' approach in Perforce correctly? I can see where that could get messy over time with repeated status changes if it's using the deltas-cancelling-deltas approach.

That's not really supported. A change loses its unique identity when
you back out and re-apply its deltas.
From the end-user perspective, it's nice to be able to test changes by turning them on and off (if you suspect a particular change is the cause of a problem).

A Perforce user would do that by backing out the change in a client
workspace without submitting the changes.