The sorcery branching structure looks kinda like this:
proj/proj_x -------------------
/ / / / / / / / / / \\
devel -------------------------------------------
\\ / / \\ / /
test ------------------------------------
\\ \\ / \\
stable ----------------------
\\ \\ \\
release/1.x.x --- \\ \\
\\ \\
release/1.y.y ---- \\
\\
release/1.z.z ------As you can see 'devel' is our main line of development. The \\ down from devel is code being 'pulled' into test. The / from test up to devel is code being pushed back into devel.
(I'll get to proj/proj_x later)
You can also see that at certain points test gets pulled into stable then pulled into a release/x.x.x branch.
Whats happening is we've neared release time, and devel code is made to equal test. Test is then built into a release candidate for a period of testing. The two /'s back to devel before the \\ down into stable are fixes being "backported" from test into devel. After the testing is over we push down to stable, then immediatly branch off the release, which is frozen in time (because we say so).
So what you'll need to know that you dont already know from basic p4 edit/submit's on devel is how to push/pull these branches. You do so with p4 integ, and p4 resolve.
When I want all the code in devel pushed into test I do this:
cd sgl/sorcery
p4 integ devel/... test/...
p4 resolve -at
That will override any changes in test with stuff from devel. Essentially making them the same. I also do an md5sum verification to be sure: cd devel; find|sort|xargs cat|md5sum; cd .. cd test; find|sort|xargs cat|md5sum; cd .. Those should be the same.
After that I p4 submit. Of course you shouldn't be doing that unless your me around release time. But now you know how I do it.
More likely you'll be fixing a problem in test, so the stable release doesn't have the problem (thats the point of this test thing). Then you want to backport the fix. If you don't want to attempt the perforce-fu I can probably do it for you a couple times. I'd rather do it for you if you're uncomfortable with it, rather than have you mess up and break the build.
The first thing to determine is if the relavent code in devel has already been changed and/or a better solution can be found using newer devel code which we specifically wont want to move to a release for a while.
If you've determined that theres a better way in the new devel, fix it again using the new devel way. Yes thats lame, but thats what happens when you have seperate lines of development. The only other alternative is to pull the new untested devel code into test and use that for the solution. Unfortunatly doing that ruins the whole process as soon as test/stable start regressing due to the new unmature devel code. SO you get to fix it twice in this case. Oh well.
On the other hand since sorcery isn't too active the fix is the same for test and devel. So you push your test code up to devel: for each file you touched: do your p4 submit with test code (remember what files you've touched). for each file: p4 integ test/<file> devel/<file> after all the integs: p4 resolve you may or may not have resolution conflicts. Chances are the only one will be the Changelog. You did modify the changelog right? So rather than being dumb and ignoring conflicts, you type 'e' to edit the file.
You'll get an "ORIGINAL" "THEIRS" and "YOURS" block of code with some <<<<< and >>>>> things spread around to help. Whats happened is you've put in a changelog message at the top in test, and other people have put one in for devel. The problem is, perforce can't merge them together. So... dont remove any code in the YOURS section (i might get it backwards), but its the section with the devel changes. In the other section (THEIRS) you'll have either just your message, or a couple others along with it. Odds are you haven't pulled up those other fixes because they aren't backportable. So delete those entries leaving yours, and get everything in the right chronological order. Also remove the <<<<, >>>>, ORIGINAL etc. headers when your done. Save and exit.
You should have the default option to 'ae' or accept edited file.
Other files will prompt you about merging. Be sure to make sure only your code changes get in, not other ones that weren't backported for whatever reason. Work on your code only. Most of the time this will be the case, but if not, edit away, or something...the dy and dt commands can help.
After you've resolved do a p4 diff to see whats changed. It should be your changes only. In fact that diff should be the same what you'd get from a p4 describe <test submit change number> If it isn't you've either missed something or moved too much, p4 revert is your friend. Ask me for help. You should of course make sure you've not broken devel before submitting, and the bug you were trying to fix in test is also fixed in devel. If you've gotten everything right, p4 submit.
Now for this project stuff. You decide to re-code a whole bunch of stuff, and rather than a) crawling into a whole by yourself to do it, or b) breaking devel for everyone while you work, you branch off into a project branch. You routinely pull in changes from devel (the numerous '/'s) that way you dont get out of date with other work and making pushing back a nightmare.
You make your new project branch with either a p4 integ devel/... proj/new_proj/... p4 submit for a new project directory. Or you want to use a pre-existing one. For that do the same thing I'd do for pushing all of devel into test, but instead of test, use proc/proj_pre-existing.
Pulling in is just p4 integ devel/... proj/my_proj/... p4 resolve (fix conflicts) p4 submit
merging back is as simple as pulling all the changes in, then either pushing them all back like you would with devel into test. (so the two are equal). To do this you must make sure that all the changes in devel have been put into your project branch, otherwise you'll overwrite them (although using p4 resolve without -at can avoid that). Or you can have me do it, which is probably easier.After the resolve, you'll need to do a lot of sanity checking before submitting.