Maybe some Perforce gurus could provide some advice.
We have a depot, with a setting.xml file in central folder:
///depot/central/config/setting.xml
and would like it to be instanced in several locations, like:
///depot/projectA/tool1/config/setting.xml
///depot/customerB/tool2/config/setting.xml
The benefit is for maintenance. the setting.xml file only has to be updated once in //depot/central, then all files in the other places get updated as well, so we don't have to get into each place, duplicate it again and again.
AlienBrain has a feature called 'shortcuts', does Perforce have something similar?
We've tried use the OS' symbolic links feature, but it didn't behave the way expected -- cloned files still need to be checked-out first, then check them in again -- this makes the cloned files own their own revisions against the original one.
It's better to just keep the original and cloned files have the same revisions. so if submitting a new revision to setting.xml(5/5)(which makes it to be setting.xml(6/6)), the cloned files as this point still remains setting.xml(5/6). Thus, people on projectA & customerB can simply sync to the latest version.
Thanks.
You can use the Perforce client spec to map files from the depot into your workspaces, which should do almost exactly what you're looking for.
For example, your client spec for tool 1 would be something like:
//depot/projectA/tool1/... //workspace_for_tool1/...
//depot/central/config/setting.xml //workspace_for_tool1/config/setting.xml
And your client spec for tool 2 would be something like:
//depot/customerB/tool2/... //workspace_for_tool2/...
//depot/central/config/setting.xml //workspace_for_tool2/config/setting.xml
The main downside of this approach is that you need to make this change in every client spec, and you need some infrastructure dedicated to propagating client specs to new workspaces.
Related
Typically, we have a depot root for every different product that we work on. For e.g.:
//products/productX
/productY
As the common files in the 2 products increase, I would like to put them into a top level folder of it's own
//products/productX
/productY
/common
Now to ensure that this works for all the users who have existing workspace, we would need to update all their workspaces. Is there an alternative? Can we put some markers in the depot to create a link it to a different folder? Any other option?
What you're describing is essentially the reason that streams were created -- the idea of a stream is that you definition the structure of a codeline in one place (e.g. "product X lives in //products/productX"), multiple people base their workspaces on that, and when you change it (e.g. "product X lives in //products/productX + //products/common), every workspace based on that definition updates automatically.
So if you're using streams, all you need to do is update the stream definitions that need to include the new //products/common directory. Easy!
If you're using "classic" workspaces, users who are using the default //products/... mapping will get the common directory automatically regardless. For users with custom views, my suggestion would be to alert them of the refactor and then let them make their own adjustments as appropriate; if they're familiar enough with Perforce to have built a custom client view, they may not appreciate having it changed underneath them.
I'm looking for a way to embed file attachments (like screenshots) inside a Perforce changelist. I'm hoping (but not optimistic) that there's a way inside P4 to actually do this, possibly via a plugin.
If not, I'll either have to look into writing a plugin myself (any pointers?), or I have to cook up a wrapper for P4 checkins that also uploads/submits the attachment, then links that attachment to the CL via an identifier inside the CL. (And then I need a tool to correlate and display both).
To add a bit more information: I'm interfacing with the P4 server via a P4API bot that I'm writing. That bots crawls over every checkin and harvests the data it gets to generate reports. I.e. it correlates submissions with the actual feature spec that informed the task, generates a history of progress for that task etc. Within that context, attaching additional meta data to a CL (like a screenshot) is useful because those attachments can then be used in the data mining - they can enhance the reports that I'm generating.
I can guard against bad/rampant metadata attachments via a wrapper program that is used to make 95% of all our P4 submissions, anyway (it has its own dialog). But I gotta figure out how to present all the data inside P4 when the P4 CL spec only seems to have text available.
I don't think there is any (easy) way to do what you're requesting. A changelist is "an atomic change transaction". There is very little meta-data with them. The P4 command reference for p4 change lists everything you're allowed to do, and adding an arbitrary attachment isn't there.
You could always open a feature request in the Perforce forums.
In Response to Edits
It looks like this is actually just one instance of a larger problem you're facing: managing meta-data around your depot's projects and its changelists. I would suggest you use this requirement as a driving force behind making some larger process changes at your organization. If you have a lot of data being generated based on automated analysis of your projects, it would be better to create a proper database to organize it all. Your submission wrapper could handle putting screenshots (or any other meta data) in a database and annotating the change list description with tags that indicate where to find attachments in the database.
A comprehensive database solution would allow you to associate attachments, changelists and other data with each other and other project resources in a more organized fashion than you currently have.
Original Response
If you decide to write a plugin to handle just this task without a database, my suggested approach would be the following:
Designate a shared network drive or directory that is accessible to all team members as the "perforce attachment dump". Users should have write access to this area.
Use the changelist description field to create a tag to name a file that should be attached. For example, "Attach: file_name.jpg".
Your users use the plugin to navigate to the file(s) locally and the plugin will copy it to the dump drive and add the tag to the description. The plugin should enforce some naming scheme to make the files easy to find. Perhaps append the changelist number to the file base name? Or create a folder for each changelist?
Use a server side pre-submit trigger and script to scan submitted changelist descriptions for tags and retrieve this file from the attachment dump. It should probably reject changelists with the tag if it can't find the file.
The server side script should move the file to a share drive that is read-only to users. This is so that if you want to look at an attachment for a changelist that is five months old, you can be sure it will still be available.
Give your plugin the ability to open the attachments on the read-only share drive from your developer's local machines, from within P4 and P4V.
I have following perforce streams structure: main branch and 2 development branches linked to it dev_v1 and dev_v2. Both development streams has some build control files where version specific variables are located. Any change in these files will be reflected in Perforce Streams Graph and the system will ask me to merge them into main and then from main into other development branch.
How to exclude specific set of files in Perforce so that in case of any change the system will no show any difference between streams and will not ask to merge/copy them.
If those build files should never be integrated you should set that path in the stream view to be 'isolate' instead of public. That will add the files to client views for that stream, but will exclude them from any generate branch maps. That will cause them to fall out of the integration calculation and Perforce will stop trying to integrate them.
Isolate was specifically put in streams to handle build files that are unique to each stream, so this is the perfect use.
When you merge you can select which change lists you want to include in the merge, and which you want to exclude. If you are using P4V when you get into the merge window you can choose which changelists to merge into the other code line. Most of our items are set up as streams...if you are a using a standard depot the functionality to should be similar...if you have troubles let me know I can set up another depot on my dev server.
At work we are using Perforce and I wonder if it's possible to do submodules with it with versioning.
For example I have library A used by projects B and C.
I want to make it so that when I get revision of B I also get A in subfolder:
B
---=> A(v1)
Same goes for project C, but it would need newer version of library.
C
---=> A(v1.2)
I know this kind of thing is possible with Git, but could not find anything on it for Perforce.
Thanks,
Leonty
Perforce really handles this sort of thing with views and paths. These let you assemble the right set of files to put into a workspace (or branch or label). Since a Perforce repository can contain all of the components or modules for all your products, you just select which ones you want in a working data set. You don't need the submodule (or SVN external) concept to pull in data from another repository.
You can use template workspaces to make sure that developers get the right set of files to work on. You can be a little more rigorous and write some custom tools (possibly in the Perforce broker) to provide some structure.
The closest equivalent to using submodules is found in Perforce streams, where the paths define what goes into a stream. Stream paths are inherited by child streams. This isn't a direct equivalent though.
I am trying to integrate a change list from one branch of code to another branch.For this I do
1)p4 integ old_branch#cl,cl new_branch
2)p4 resolve -am
3)p4 change.
Now when I am doing the last part(p4 change ) I see this error :-
The document “tmp.BLAH BLAH” could not be opened. You don’t have
permission.
Has anyone seen this before and can help me correct this?I do have the config file under the branch's root
I was using P4V with Perforce when I had to use it. Drastically helped me with merges considering P4 is not quite like using SVN or Git.
Also I think that if the file can be removed from your filesystem you can revert to the latest from the repository if in fact it is a file from the repository. Then you can retry your merge.
I know in other merge programs the tmp files are generated during the conflict resolution process so you may be facing a similar issue.