[p4] Commiting partial-files
Jeff A. Bowles
jab at pobox.com
Wed Apr 9 12:45:21 PDT 2008
I have to ask - am I overlooking a benefit here?
(I'm not talking about "shelve", which is the notion that you can set aside
work for a while since "something more important" came along. Ultimately,
"shelve" is a serialization of the work.)
There's a risk that you are developing something (function A) that is
mutually dependent on something else that you're developing (function B),
that I would worry about an unrelated user retrieving one-not-both of these
functions and ending up with something broken. It's a large risk to the
notion of [relatively] stable check-ins.
In fact, it's such a risk that I would start asking very pesky questions
about your build system. Are these changes really independent and can be
committed / submitted separately?
So, my question is, what's the benefit when compared against these
engineering / process concerns?
On Wed, Apr 9, 2008 at 11:16 AM, Evgeny <evgeny.zislis at gmail.com> wrote:
> Hello perforce users,
> I recently read about how git allows to send partial files in a
> commit, using a staging area.
> (Like explained here: http://tomayko.com/writings/the-thing-about-git)
> and in bazaar there is a feature called "shelve"
> that can be used for a similar thing.
> These two techniques come to address the "The Tangled Working Copy
> >From using Perforce I know that I can separate the files I intend to
> commit into separate changelists, and commit these changelists at
> different times and unrelated to one another. But is there a way to
> have a single file appear in two different changelists? -- while in
> one changelist the file has a certain change (function A added), and
> in the other it's a different change (function B, but in the same
> I doubt it exists with perforce, but I'd love to hear it if I am mistaken.
> perforce-user mailing list - perforce-user at perforce.com
Jeff Bowles - jeff.a.bowles at gmail.com
More information about the perforce-user