[p4] Commiting partial-files

[Jeff A. Bowles]

"Why not Perforce?"

Ultimately, I think that the answer revolves around granularity - what is
tracked, at what level of granularity in the server.


(That does not mean that this functionality is a good thing or a bad thing,
and does not mean that Perforce will never have this functionality or that
it will add it tomorrow.)


I admit that I'm having a bit of a time wrapping my brain around the notion
of multiple librarians with their own copies, but with no formally "correct"
copy. From a development point of view, that's the greatest way to have
individual developers working-up-a-storm but the integration effort must be
quite a dance.


"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."

If the reason driving the request is to "table / shelve / suspend" one of
the units of work until the other's done, there will be ways to script it.


If the reason is to do separate check-ins for separate parts of the code,
then the question of how-to-build comes back. How do you know that you
haven't checked in a partial-change and so things won't compile from the
"reference copy on the server" until your second check-in is done?  (Of
course, it's perfectly okay to respond "we considered that, and for our
groups - we know that there will be moments like this and don't think it's a
large concern".  Just publicize that decision and what-to-do, and perhaps
revisit a half-year later to see how it's holding up.)


-Jeff Bowles


On Wed, Apr 16, 2008 at 12:20 AM, Evgeny <evgeny.zislis at gmail.com> wrote:

> 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 -
> >
> >
> >
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com