What is the difference between merge any and merge down in Perforce P4V?. when I try to create a stream in Perforce I am seeing these two options in Advanced settings/options.
The "merge any" option allows a merge operation to be done in either direction (up or down), whereas the default "merge down" requires that you only merge down (and must copy up instead of merging up).
https://www.perforce.com/perforce/doc.current/user/relnotes.txt:
#963443 (Bug #65298, #74627) **
The new 'mergeany' stream option allows flow rules for 'p4 merge'
to be ignored for a particular stream. The default option of
'mergedown' preserves the previously existing flow rules. Streams
created by 'p4 switch' on a personal server use 'mergeany'.
Related
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.
using p4 change, I can create a new changelist but it requires a 'form' to be filled.
Is there a way for me to create a job with a particular template, get that job number and attach it to a new changelist with a particular template?
No, unfortunately you have to use the forms, i.e. temp files, or cmdline I/O redirection.
The alternative is to use a P4 API (e.g. P4Perl, P4Python, etc.) which gives you a way to specify all the change's details (the ones you would fill into the form) as structured data.
I have created feature branch for one of our projects, and deleted all documentation files there in one changelist. (I know, bad idea).
I want to integrate back everything except given changelist, I tried following to ignore it:
p4 integrate //branch/...#CL,CL //main/...
p4 resolve -at //main/...
However, the files still remain marked for deletion - the resolve ends with
//main/... - no file(s) to resolver.
Is there any way how to tell perforce that given CL is already integrated and ignore it in subsequent integrations?
Note that you need at least a 2011.1 server to do this (if your server is older you'll get an error message on the integrate):
p4 integrate -Rd //branch/...#CL,CL //main/...
p4 resolve -ay
The "-Rd" flag says that files which would normally be opened for delete automatically should be opened for integrate and scheduled for resolve instead. In turn, the "p4 resolve -ay" will say that you want to keep what's in your workspace (an "integrate" with no content change) and submit that as the final result.
The submitted "integrate" revisions will record that you have done this integration (the history will show an "ignore" of the deleted revisions in your branch), but without actually changing the contents of the submitted files.
If you use the "p4 merge" command instead of the "p4 integrate" command (with a more current server version, I think 2013.1 or thereabouts), all files are scheduled for resolve automatically (i.e. including those that would previously have been automatically opened for branch or delete), so with "p4 merge" you always must resolve (and may optionally ignore) any source change.
Relevant p4 blog entries:
http://www.perforce.com/blog/110620/ignoring-branches-deletes
http://www.perforce.com/blog/130812/resolve-face-adversity
It seems like you wanted 'resolve -ay' here, not 'resolve -at'. When integrating back to main, I think that "theirs" is the branch, while "yours" is main.
From 'p4 help resolve':
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
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.
I have two branches _trunk and _dev.
There is a folder (actually it's config) where intensive work is performed in both branches.
Now I need to merge from _trunk to _dev. But I need to merge only the code.
The config should be REPLACED. I'm not sure that replacing it manually is right way. How this operation is called? How do you do similair things?
It's an integration as usual, but during resolve you'll accept the source files without trying to merge them into the destination. This will replace the destination files' content with the source content.
Edit: If there are adds and deletes in the source, make sure you let Perforce propagate those with the appropriate options checked.
You can do an "Integrate/Merge" from _trunk to _dev. Any conflicts will set up in your pending changelist as a "Resolve" for each file.
For code you can let P4V attempt to merge it for you and make changes / do the merge manually. For the config files, in the resolve window do "Accept Source" - this overrides the target with the source regardless.
Likewise, if there's any where you know you don't want to bring your changes forward but still want it to recognise you've checked and accomodated for the changes, use "Accept Target"