[p4] Commiting partial-files
Jeff Younker
jeff at drinktomi.com
Tue Apr 15 21:35:40 PDT 2008
> 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.
There's a risk of that even with discrete files. A change is made in
function
A that's dependent on something in function B, but B gets changed in
another
changelist, and that changelist gets submitted.
> I have to ask - am I overlooking a benefit here?
Consider it a mechanism for doing n-way merge from k repositories.
Git and distributed version control systems work in environments where
there
is not a single source of truth. There is a network of people who
have their
own local sources of truth. Some may have one set of patches
applied, some
may have another. All these independent sources of truth are making
their
own modifications locally, but at some point they may want to send these
modification to another source of truth, with or without the layered
patches.
E.g. Redhat maintains a repository in house with the linux kernel.
They make
changes in house, apply the patches they need, and at some point
they'll send
them back to the linux kernel, quite possibly sans patches.
Somewhere down
the line they pick up recent kernel changes and roll them into their
own, but they
may get them from some other group's repository (say unbuntu or sun's.)
> So, my question is, what's the benefit when compared against these
> engineering / process concerns?
It allows multiple organizations to have their own repositories for
projects
that also exist outside their authority, yet still allows these
projects to interoperate.
It allows them to accept and reject partial patches, or to layer them
on top of each
other. It allows the work of work from hundreds or thousands of
contributors
which *will* be overwriting each other and working off of different/
older/out of
date versions and in different source code repositories.
- Jeff Younker - jeff at drinktomi.com -
More information about the perforce-user
mailing list