[p4] view code from multiple branches

Matt Janulewicz 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 
won't.

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

As someone else said on this thread, don't fight the tool. If I were to 
come across a directory structure like this:

//project_foo/main/...
//project_foo/releases/1.00/...
//project_foo/releases/1.01/...
//project_foo/releases/1.10/...
//project_foo/releases/1.20/...
//project_foo/releases/1.21/...
//project_foo/releases/1.22/...
...

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 
here: http://perforce.com/perforce/conferences/us/2009/index.html


-Matt




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,
> Kamlesh.
>
>
>
> 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  
> tested
> > 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 
> following
> > 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
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



More information about the perforce-user mailing list