(A) ------- (B) ----------- (C)
| | |
Trunk ReleaseBranch DeveloperBranch
Developers work in the C branch and check-in all the files. The modified files are then labeled in the C branch. The binaries that get deployed are built from B branch
and labeled. Currently all this is manual.
In Perforce, is there a simple way to accomplish this like merging Branches based on labels etc?
It's not immediately clear how much automation you already have, or how much automation you seek. Perforce itself provides the tools to keep track of integration and branching, but if you want to do things like automated builds and labeling you'll need to look outside the source code control world into the release management/automation world.
I'm going to assume you have two branches:
(B) //depot/yourcode/rel/...
(C) //depot/yourcode/dev/...
Inside these branches the code layout is roughly similar, though dev will be newer (and possibly buggier) than rel. (Your text doesn't explain what you're doing with trunk, so I'm ignoring it.)
Let's say you're devloping in dev and you want to release code. You create a label (let's call it MYCODE_DEV.1.0) with the files you want to release. You can integrate it into rel with:
p4 integrate //depot/yourcode/dev/...#MYCODE_DEV.1.0 //depot/yourcode/rel/...
That integrates from the MYCODE_DEV.1.0 label to the release branch. Perforce keeps track of which file revisions you've merged and which file revisions you haven't merged, so it'll only merge new code. If you've made changes to rel that weren't in dev, you'll need to resolve the changes (either automatically, or by hand). You can then check the changes into rel, create a new label, and release from there.
(Since Perforce keeps track of what you've merged, if you try to integrate the same label again, Perforce will politely decline to do anything, though you can override it if you think you know better.)
(If you read the Perforce documentation, you'll find references to "branch specs", which let you declare a named branch as a shorthand for specifying both the source and destination branches in your integration command. Branch specs are especially useful for maintaining complicated branches with source files scattered across multiple directories, but don't really add value to the simple example here.)
Perforce gives you the tools you need to set up your branches and releases to meet your goals, which can be easily scripted, but doesn't directly do automated releases.
Related
So we have a project where there are multiple "main" branches being worked on at once. So there is 1.0.0, 2.0.0, and 3.0.0. Things that go into 2.0.0 cannot go into 1.0.0, etc. Each branch gets merged forward, 1.0.0 > 2.0.0 > 3.0.0.
I don't think we can use the normal stream flow because if we setup release branches, you cant get feature branches off of them, plus these aren't "releases" just yet, they are still in active development. If we go below, then everything has to go through one main branch to get to releases and there's no way to segregate files.
So I guess my question is, is there a proper way to set up streams for something like this?
thanks
A lot of the assumptions around use of the mainline model come from an environment where releases are being cut relatively infrequently (twice a year), and only patched for critical bugs -- so changes that need to go from one release to another tend to be the exception rather than the rule. In this model, the vast majority of merges are simply from the newest release (e.g. while the release is being stabilized, which comes at a point in the cycle where there's very little activity in the release prior to that one) or from a dev branch back to the mainline, and from the mainline back to dev branches (since dev branches are mostly working on new features that are destined for the mainline but not any release branches). Changes only go from the mainline to a release branch if they're being manually cherry-picked to address a critical bug (which is rare), and never straight from a dev branch to a release branch. It's slightly awkward to cherry-pick a fix from an old release branch up to a bunch of later release branches, but it's very infrequent in this model so the awkwardness doesn't matter that much.
If you're very actively working on multiple releases simultaneously, the mainline model has less value since you need to either:
merge between sibling/cousin branches (which mostly works okay but can get awkward if there's been a lot of refactoring)
carefully cherry-pick changes to and from the mainline to enforce correct flow of change (which makes for cleaner merges but a bit more manual tracking)
The orthodox recommendation here would likely be to rethink your release methodology/policy to not require so much "waterfalling", but I'm assuming you have business reasons for requiring it to work this way. Given that constraint, I think you probably don't want to use the concept of different stream "types" and "flow" at all since those have assumptions about the mainline model built in, and what you're doing is fundamentally not a mainline development model.
To implement a non-mainline model in streams (which does still have some value without the flow-management guides since it'll help you manage your client views and whatnot) you'll probably want to use some combination of:
make every stream after the initial mainline a development stream (that's the most permissive I think)
set the mergeany option in every stream (that allows merging in all directions rather than trying to enforce "firmness" which is a mainline model concept)
use the -F option when merging to ignore flow direction (I think mergeany makes this unnecessary if you use it consistently)
We have a large code base in Perforce. I would like to do the following nightly, automatically.
- Copy some view of "latest" into two (or more) workspaces, streams, or even just into some other folders not under perforce control.
- Check everything out (if p4 used) and "compile it", (where "compile" may include changing most files, thus the need to have them be writable.
- Rinse repeat the following "night" with a fresh "latest".
I know how to do this via simple copying things out, but would like the nightly modified code to be able to be "seen" from other machines, by other people, thus maybe the stuffing of things back into perforce.
I know how to do this with P4 workspaces.
Just wondering if p4 streams (tasks?) are a better approach, or for any other alternate recommendations.
Using workspaces is indeed what you want to do. The benefit of using streams would mostly be in simplifying the task of generating and managing these workspaces.
Do you want to keep the changes made by the build machine isolated from the mainline that everyone else uses? Should those changes also be isolated from other builds? Or do you want to make sure that everyone gets the changes ASAP and that they make their way into all other variants of the code? These are good questions to ask as you're setting this up and the answers should influence what you do.
When using Team Foundation Server, is there a generally accepted way to approach branching when you need to test certain approaches to issues that come up (bugs, feature requests, etc)?
Say, for example, that you are on a team with a few other developers and one developer says that he just cannot figure out how to solve this problem and asks you for assistance. You have some ideas but you want to make sure that you don't accidentally make changes to his main branch of code in case your ideas don't work.
At this point you could either:
Make a local copy and unbind it from source control to ensure you do not accidentally check in any changes in the future.
Create a branch from his branch and call it "Testing" or something, and delete the branch once you are done with it.
Check out a copy of his branch and simply "undo pending changes" when you decide your approaches don't work (this seems dangerous).
I know you could probably approach it a few other ways but I was just curious as to whether or not there was a popular way to approach making "test changes" to code thats under source control.
Branching is best kept for multiple simultaneous, independent changes.
Use a Shelveset for the purposes you're discussing. That's how the "Suspend" feature of "My Work" works, and it's how code reviews work. They shelve the changes, attach them to the Code Review work item, and inform the reviewers. The reviewers can unshelve the changes, look at them and make comments, and possibly even edit them. They can then shelve their version of the changes and send them back to you.
There's a lot of flexibility there, without creating branches, which are permanent artifacts.
Update: You can additionally execute a build and set the Shelveset name in the version to build property to create a custom build from your shelveset.
Our project is based on another studio's technology, which we have modified to fit our needs. We use TFS, they use Perforce. They have just shipped their product and as a result, they have a lot of new finished features we want to pick up for our project. I am tasked with integrating over this new code drop into our codebase.
I am very familiar with Perforce as I have been using it for years, but I am much less experienced with TFS (which is where all the work will take place) so I am pretty sure my approach will be brute force, tedious, and extremely time consuming. Hopefully some of you will be able to suggest "the right way" to do this. :)
Here's what I am doing:
Check out the entire project in TFS
Copy the entire new code drop over the old code
Merge all the changes we have made to their codebase into this new vanilla code drop (YIKES!)
Check in
Folder diff between the checked in codebase and the vanilla drop I sycned from Perforce and delete any files no longer in the project
Check in
Profit
As you can tell, this is going to be "fun". I'm up to step 3 and I am realizing that I don't know how to actually do this merge in a way that doesn't require diffing every single friggin file in the project (approaching 3000). I was hoping to get a window of all the conflicts I need to resolve like you do after syncing.
Furthermore, I just don't have confidence that this is going to work out well even if I did brute force diff every single file. :) Files moved, added, removed, etc are just going to be a nightmare. Much of the work we want to pick up is refactoring their old messy early code from a much earlier state in the project when we last synced.
I have to believe that TFS can make this task much cleaner since what I am trying to do is not uncommon. What would you guys suggest?
Thanks!
My suggestion is to have 2 branches in TFS, one that is the unmodified code from the other team (lets call this DEFAULT). Then make a branch off that (lets call this CUSTOM). You would make your changes in CUSTOM.
This way when the other team release new code you just Get Latest on DEFAULT, delete the local workspace files, copy over the new code, then let the local workspace feature do it's thing and detect all the necessary pending changes (adds, deletes, edits), then check-in the changes. Then you can merge DEFAULT->CUSTOM and resolve any conflicts.
Since you don't have this structure setup now, setting it up the first time will be a little painful, but in the future it should make life easier.
Assuming you have a copy of the unmodified code from the previous release, you can create the DEFAULT branch and check that in. Then branch off a CUSTOM branch. Then Get Latest on CUSTOM, delete all the local workspace files, and copy in your current modified code. VS should detect all the necessary pending changes, then check those in.
Now you can do the process to update DEFAULT, and merge down to CUSTOM for the new version. Because TFS will track the history, you should only have to deal with actual conflicts rather than going through every single change. You will of course have to do sufficient testing to ensure that the new code and your customizations still work well together.
I have read through the documentation on perforce and the "branching strategy" advice as well.
One thing thats left me baffled, is how a simple concern is does not seem to adequtely adressed.
When I am working on a project that touches many parts of our code base , I cannot checkin my code at the end of the day without checking into the trunk. So do I need to branch in this situation? I want to be able to have the ability to have a history of my changes in a long and hard project, so I can go back when I I make a wrong turn..
The problem with branching I see is that I will be creating copies of almost the entire codebase .. Am I missing an obvious solution here?
thanks
From the standpoint of the Perforce server, branches aren't actually copies of the files. Perforce uses a mechanism called "lazy copy" to minimize disc consumption. From their website, here is the definition of the term:
A method used by Perforce to make
internal copies of files without
duplicating file content in the depot.
Lazy copies minimize the consumption
of disk space by storing references to
the original file instead of copies of
the file.
Best approach to working with perforce is to work in a user/feature branch then you can avoid checking into the trunk whilst still pushing your changes into the depot.
When creating a branch, you don't have to branch the entire trunk or source branch - you only need to branch the files you're working on - you can map the rest of the files into your branch via your client spec.
TBH - just buy & read 'Practical Perforce', it has heaps of useful info on how to do this and is very much worth the money if you're using perforce on a daily basis.
Another very useful feature of perforce is 'jobs' - often described only for bug tracking - it's much flexible and allows you to store a changelist history attached to a tag so allowing you to create 'metatags' and attach revisions to it i.e 'NightlyBuild' or 'BreakingChanges or whatever you want.
HTH.
The closest I know of is shelving, in which you can "shelve" your work in progress, saving a copy on the server. I typically do this to essentially checkpoint my work. I think this comes closest to addressing your need, where you can save your progress at the end of the day.
See here for a tutorial on shelving in p4v.
Or type p4 help shelve for help with the command line.
Evaluate using PDB - Sparse branches. More information here http://www.releng.com/p5layer.html