[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