[p4] view code from multiple branches
matt.janulewicz at lucasfilm.com
Tue Aug 4 10:22:06 PDT 2009
It looks like the right decision has been made :), but I wanted to add
something about sparse branching just so others in the future might find
it in this thread.
One thing I have come across when people have attempted to do sparse
branching is that trying to re-assemble a build from the parts when
every developer that worked on it was not diligent in recording their
workspace layout, labels, etc., is a nightmare.
Say I'm the new CM Guy at a company and I'm tasked with digging up the
source code from a customer released build from two years ago. Can I be
certain that the workspace reference I find is correct? Or that the
label is correct? Or that either of these even exist? Perhaps I find a
branch I think is correct and it only has five files in it, and the app
it's supposed to build is a binary that's 3 megs in size. It might take
me days to figure that one out, if I can figure it out at all. Sparse
branching just leaves too many factors to chance. No matter how diligent
your users claim they will be about recording their build process, they
Personally, I'm weary of labels after they reach a certain age, anyway.
Since labels can be changed by the owner you never really know 100% what
you're going to get. It's interesting when I come across a label named
something like 'FINAL_BUILD_2007-02-15' and it's been updated two days ago.
Perhaps you also don't have a spec depot (or did not have one at the
time of the build two years ago) and someone has deleted the workspace
As someone else said on this thread, don't fight the tool. If I were to
come across a directory structure like this:
That's much more obvious. You have a good chance that folks planned
things out and followed that plan. You're not relying on labels or
special workspace arrangements to reproduce a build. It's easier on the
developers because they just need to find the directory and sync it.
Integrating between branches is easy because you know exactly where
you're going to and coming from.
In the absence of any other data about a build/project (label name,
workspace template, release notes) this type of structure can tell you
everything you need to know about the life of the product, and it took
zero effort on your part to dig up.
From the perspective of the developer, you really should do all you can
to de-mystify the integration process. It's not really that difficult. I
did a one hour class on it internally here just last week and the
overwhelming response was 'That's it? Really? Well, when you put it on
the screen and walk through it, it's pretty easy.' And it is. Once
everyone is exposed to it, learns the terminology and physical process
of doing an integration, it's not bad at all. The main problem you'll
run into is people not following the plan/schedule, then branches
diverge for too long. You want to try to do the smallest, most frequent
integrations you can and remain comfortable with instead of thinking you
can leave a product branch open for two months and merge it all back
together at the end. The longer you go, the harder the merge will be.
Drifting a little bit off subject, but Anders Johnson from Nvidia gave a
great talk at the User Conference this year about 'Visualizing the Cost
of Divergence'. A lot of the math was over my head but he had pretty
charts that were rather convincing. His presentation and whitepaper can
be found along with the rest of the presentations from the conference
Kamlesh Mutha wrote:
> Thank you all for your comments. I guess, integrating periodically
> seems to
> be the best possible way to handle this issue. I will follow that.
> Thanks and Regards,
> On Tue, Aug 4, 2009 at 8:34 AM, <rickmacd at shaw.ca> wrote:
> > I think this idea breaks down quite easily. For example, consider if you
> > modify file "A" in your private branch and somebody updates file "A" and
> > file "B" in main with dependent changes such that the changes to file A
> > and B in main are needed together. You're saying you want only the
> file B
> > change from main in your workspace because you've changed file A
> in your
> > branch. Your file A with his file B is not going to be correct. Then
> > what? Assuming the policy of the main branch is that everything is
> > and correct, the programmer might waste time thinking he made a mistake
> > in his branch.
> > I do one of two things depending on the nature of the code and the
> > changes in the private branch and how long the private branch task takes
> > to complete. Either I completely finish the private task branch before
> > integrating "down" from main, or I constantly merge in changes from main
> > as I go along. Or, something between these two extremes such as "points
> > of completion" in the private branch (where I'm not done the whole task,
> > but things are in a good state and everything done so far is working
> > well).
> > It seems to me that what you are wanting to do is much harder than
> > integrating from main, and your only motivation seems to be to protect
> > people from integrating.
> > Rick
> > Kamlesh Mutha wrote:
> > > Just to clarify, let me correct the typo first:
> > >
> > > My requirement is:
> > >
> > > 1. I have a branch //depot/main/...
> > > 2. I fork off a new branch //depot/itr/... from //depot/main
> > > 3. I want to have a workspace in which I should be able to see
> > files
> > > a. All files modified on //depot/itr branch
> > > b. For a file which is not modified on //depot/itr/..., the latest
> > > revision from //depot/main/... branch.
> > >
> > > Why is it needed ?
> > >
> > > /itr branch is a private branch and developer is working on some
> > development. While he is working on private branch and main branch is
> > changing (for the planned development). The developer should be able to
> > see those changes in a workspace along with his own changes to ensure
> > that both changes together still build/function fine. Intention is to
> > avoid major surprise just after integrating private branch in main.
> > >
> > > I know, perforce recommends that you keep on rebasing your private
> > branch by integrating changes from main to private but that involves
> > "integration" and people sometimes find it pretty difficult. Hence I
> > wanted to check if this can be handled through some special purpose
> > workspace.
> > >
> > > Thanks and Regards,
> > > Kamlesh
> > >
> Faith waiting in the heart of a seed promises a miracle of life which
> it can
> not prove!
> -Ravindranath Tagore
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user