[p4] Commiting partial-files

[Ivey, William]

I've effectively done this several times by simply using two
workspaces. I've also done it by creating a sparse branch for
the file where I could park it. (This requires some care to
make sure you are referencing the correct file at any given
time, and works best from the command line.)

Whenever possible, though, I just use multiple workspaces
if I need to stop in the middle of a long-term change to
fix something. It's simple, obvious and not very error prone.
(A lot of my developers, though, seem to have an aversion to
more than one workspace - like it's somehow cheating.)

-Wm


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Evgeny
Sent: Wednesday, April 16, 2008 2:20 AM
To: Jeff Younker
Cc: Jeff A. Bowles; perforce-user at perforce.com
Subject: Re: [p4] Commiting partial-files

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 -
>
>
>
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user