I am new to Perforce.
What would you consider P4 best practices in terms of views/branches.
Would you create 1 view with access to many branches, or would you create 1 view / branch ?
I am not sure switching between views/worspaces is that easy in Perforce.
Thanks,
Thomas
If by "view" you mean workspace (aka client-spec), then I strive to have one client spec for each branch I am working on. I'm assuming by branch you mean you have a typical system where you have mainline, development branches, and maybe release branches too?
The reason for keeping the 1-1 correspondence is it just keeps things simpler. It can also prevent accidents - e.g. when I am in a development client spec, I know I cannot accidentally look at or modify a file of the same name in another branch. This can be a big help when you are down in the depths of a deep source folder hierarchy.
Keeping views "tight" is generally good practice in Peforce - as in anything. It helps server performance, which in turn helps performance of Perforce on your client machine. But beyond performance, I think the concept of only seeing what you need to see - letting the computer do the filtering for you - is just generally a good thing. It lets you concentrate on the job at hand without distraction.
I don't have any difficultly switching workspaces, and there are a number of ways to do this depending on your circumstances and preferences. P4V has a simple drop-down at the top of the left pane, for example. What difficulties are you having switching workspaces?
I am not sure switching between views/worspaces is that easy in
Perforce.
It is easy. Assuming you use the command-line, create a p4config.txt at the root directory of each client-spec (aka view). In each p4config.txt, set the P4CLIENT variable to the name of the client-spec. You can leave the other variables as they are.
Here is my sample p4config.txt:
P4USER=deepaknag
P4PORT=SJCPperforce01:1666
P4CLIENT=deepaknag_fbsd
Then set the P4CONFIG environment variable as follows:
export P4CONFIG=p4config.txt
Now it automatically uses the "correct" client-spec whenever you change client directories. Try issuing:
p4 info
in your client directories to verify.
This is also documented in Perforce Knowledge Base (works with p4 for me).
Here's what Perforce says on the
subject.
Also Eric Sink has a
good discussion.
I create one
view with accesses to many branches.
Since branches appear in everyone's view by default, you want to have a user area off the main line.
Many engineers are more comfortable with the concept of branches, since they exist in all SCM systems. But views may be concerning, if they haven't seen that concept
Related
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.
Summary: Want help to figure out how to setup the depot and my development environment so that I can support multiple, related projects.
Details:
Until now I've had a depot which had in it only one project - ProjectA - robot version A.
I am starting to work on a new version (ProjectB) which has some differences in HW - I/O port mappings and timers have changed. I would like to continue to develop code for both projects.
This means that ProjectB will share some files with the ProjectA and some files will be different.
Since the differences are HW related items what I'm thinking of doing is creating a common area and then project specific areas where the common area is for device independent code and project specific area is for device dependent code.
The differences are big enough that I don't want to do #ifdef within files. Some differences are simple - different I/O port mapping and some are completely new modules.
To make maintainance easier, I would like to be able to compare differences between device dependent code and propagate selected changes.
Finally, to minimize my burden during comparisons, I would like to mark differences that I know are okay so that in future comparisons they don't show up.
Help!
Your instincts are good -- you're trying to Not Duplicate Code. This is the core of good design & engineering.
As for the file layout, it's always annoying to have your directories too deep, but that's MUCH better than too shallow. Maybe:
<root>
main/
projects/
robot1/...
robot2/...
shared1/
shared2/
(Big repositories are much deeper than that, even.)
As for how you make shared code -- you could have different setup.h or constants.h that drive what the various shared libraries do. Alternatively, build your shared libraries so they are parameterized at runtime.
SetupDrivers(0x80020); // address of PIO registers
And lastly -- if the projects really are different, decide if sharing the code really is the right thing. Usually yes, but everything is a choice. If you hope to manually "diff" your files to look for differences, it's really up to you to keep the structures close enough to diff. The "different config.h file for each project" idea mentioned above would help.
If you roll your own diff tool (in python or whatever) you could use special comments to flag "expected different lines".
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
I am looking for a good way to keep a design document up to date with the latest decisions.
We are a small team (two developers, game designer, graphic designer, project manager, sales guy). Most of our projects last a couple of months. At the start of the project a design is made but we generally find ourselves making changes or new decisions throughout the project. Most of these changes are improvements, so we want to keep our process like that. (If the changed design results in more time needed this is generally taken care of, so that part is OK)
However, at the moment we have no nice way of capturing the changes to the initial design document and this results in the initial design quickly being abandoned as a source while coding. This is of course a waste of effort.
Currently our documents are OpenOffice/Word, and the best way to track changes in those documents will probably be adding a changelist to the top of the document and making the changes in the text in parallel — not really an option I'd think as ideal.
I've looked at requirements management software, but that looks way to specialized. The documents could be stored in subversion but I think that is a bit too low level to give insight in the changes.
Does anyone know a good way to track changes like these and keep the design document a valuable resource throughout the project?
EDIT: At the moment we mostly rely on changes to the original design being put in the bugtracker, that way they are at least somewhere.
EDIT: Related question
Is version control (ie. Subversion) applicable in document tracking?
I've found a wiki with revision logging works well as a step-up from Word documents, provided the number of users is relatively small. Finding one that makes it easy to make quick edits is helpful in ensuring it's kept up to date.
Both openoffice and word include capaiblities for showing/hiding edits to your document. Assuming there's resistance to changing, then that's your best option - either that or export to text and put it into any source control software.\
Alternatively, maintain a separate (diffable using the appropriate tool) document for change-description text, and save archive versions at appropriate points in time.
This problem has been a long standing issue in our programming shop too. The funny thing is that programmers tend to look at this from the wrong optimization angle: "keep everything in one place". In my opinion, you have two main issues:
The changes' descriptions must be easy to read ("So what's new?")
The process should be optimized for writing of the specification to agree upon, and then get to work already!
Imagine how this problem is solved in another environment: government law making. The lawbook is not rewritten with "track changes" turned on every time the government adds another law, or changes one...
The best way is to never touch a released document. Don't stuff everything into the same file, you'll get the:
dreaded version history table
eternal status "draft",
scattered inconsistencies,
horribly rushed sentences, and
foul smelling blend of authors' styles
Instead, release an addendum, describing only the changes in detail, and possibly replacing full paragraphs/pages of the original.
With the size of our project, this can never work, can it?
In my biggest project so far, I released one base spec, and 5 consecutive addenda. Each of around 5 pages. Worked like a charm!
I don't know any good, free configuration management tools, but why not place your design under source control? Just add it to SVN, CVS, or whatever you are using. This is good because:
1) It is always up to date (if you check it in, of course)
2) It is centralized
3) You can keep track of changes by using the built-in compare feature, available in almost any source control system
It may not be the 'enterprisish' solution you'd want, but you are a small team of developers anyway, so for that situation, it is more than perfect.
EDIT: I see now that you already mentioned a source control system, my mistake. Still, I think it should work well.
Use Google Docs. Its free, web based, muti-user in real time, you can choose who has access to your documents, and keeps versioning. You can also upload all your word documents and it will transform them for you.
For more information: http://www.google.com/google-d-s/intl/en/tour2.html