[p4] Commiting partial-files

[Evgeny]

Jeff,
I was actually just talking about the "your-workspace-is-a-branch" concept,
and not trying to turn Perforce into a full-fledged DVCS :)

In my new company I am advocating a move from Synergy/CVS to Perforce
and tutoring the admins regarding how to use it and how it works.

Several times I was asked if it is possible to divide a file into two different
changelists where in each some other part of the file was changed.

When I read the article I mention in the first e-mail - it suddenly seems so
easy, so I had to question my previous answer to my collegues :
"No it cant, it sounds too complicated and cant be done with any tool I know"

Well, now I know it can be done. In git, bazaar and probably several others.

Why not Perforce?


On Wed, Apr 16, 2008 at 7:35 AM, Jeff Younker <jeff at drinktomi.com> wrote:
>
> > 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 -
>
>
>