I have created a Perforce workspace definition with which I will be able to "run the latest demo" on a PC.
Then I wanted to try and check out the same workspace on another PC in order to run the same demo. I found that I could not do this because the workspace is somehow tied to the first PC where I created it.
I ended up copying the workspace by
inspecting the textual definition of the workspace and copying it to a text editor,
searching and replacing "WantedWorkspaceName" with "WantedWorkspaceName_NewHostname",
creating a new workspace with a new name ("WantedWorkspaceName_NewHostname"),
giving the new workspace the same workspace root path ("D:\Demo") as the original workspace,
pasting the modified textual representation into the textual representation of the new workspace.
Surely there must be a better way to achieve what I want? (Use the same workspace mapping on different hosts.)
Just use the -t template option to p4 client:
p4 client -t WantedWorkspaceName WantedWorkspaceName_NewHostname
You may also want to look at streams, which are an alternative way of setting up client/branch mappings. Rather than configuring each client individually, you define a single "stream" which encapsulates a set of depot mappings and branching relationships to other streams. Then a client can be defined simply in terms of what stream it's associated with, and the views are auto-generated whenever the stream is changed.
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 am using Data Factory V2 and have a dataset created that is located in a third-party SFTP. The SFTP uses a SSH key and password. I was successful with creating the connection to the SFTP with the key and password. I can now browse the SFTP within Data Factory, see the only folder on the service and see all the TSV files in that folder.
Naturally, Azure Data Factory asked for the location of the file(s) to import. I use the "Browse" option to select the folder I need, but not the files. I want to use a wildcard for the files.
When I opt to do a *.tsv option after the folder, I get errors on previewing the data. When I go back and specify the file name, I can preview the data. So, I know Azure can connect, read, and preview the data if I don't use a wildcard.
Looking over the documentation from Azure, I see they recommend not specifying the folder or the wildcard in the dataset properties. I skip over that and move right to a new pipeline. Using Copy, I set the copy activity to use the SFTP dataset, specify the wildcard folder name "MyFolder*" and wildcard file name like in the documentation as "*.tsv".
I get errors saying I need to specify the folder and wild card in the dataset when I publish. Thus, I go back to the dataset, specify the folder and *.tsv as the wildcard.
In all cases: this is the error I receive when previewing the data in the pipeline or in the dataset.
Can't find SFTP path '/MyFolder/*.tsv'. Please check if the path exists. If the path you configured does not start with '/', note it is a relative path under the given user's default folder ''. No such file .
Why is this that complicated? What am I missing here? The dataset can connect and see individual files as:
/MyFolder/MyFile_20200104.tsv
But fails when you set it up as
/MyFolder/*.tsv
I use Copy frequently to pull data from SFTP sources. You mentioned in your question that the documentation says to NOT specify the wildcards in the DataSet, but your example does just that. Instead, you should specify them in the Copy Activity Source settings.
In my implementations, the DataSet has no parameters and no values specified in the Directory and File boxes:
In the Copy activity's Source tab, I specify the wildcard values. Those can be text, parameters, variables, or expressions. I've highlighted the options I use most frequently below.
You can specify till the base folder here and then on the Source Tab select Wildcard Path specify the subfolder in first block (if there as in some activity like delete its not present) and *.tsv in the second block.
enter image description here
I have setup a new Perforce server via docker. I have an admin user and I can connect to it successfully.
It is of course an empty server, so I created a new workspace called foo with the following view:
//depot/... //foo/depot/...
Adding any new file fails in:
/Users/test/workspace_foo/file - file(s) not in client view.
I found this problem hundreds of times, but I am beyond the step of missing to create a workspace view, still it does not work. Any idea what I am missing here?
I struggled hard on this. And I'm not sure if I finally understood the real cause why it's working now.
To me, it looks like you need to create the mapping with the three dots as expression in order to be able to create a more specific one.
Example Here
However, after I added the 'three-dot-mapping' I could finally add all my files without any trouble. What doubts me a little is that after I opened the Mapping again, my 'three-dot-mapping' disappeared, and it just showed me a mapping to the folder I added.
As I understood, you need the
//depot/... <-> /Users/test/workspace_foo/...
mapping in order to be able to create a
//depot/anotherFolder <-> /Users/test/workspace_foo/anotherFolder
mapping. Also make sure, that first you add a file / folder directly under /Users/test/workspace_foo/....
If anyone has further explanations for this, I look forward hearing them.
I'm going to assume that your workspace's root is /Users/test/workspace_foo. That's what //foo in your client view corresponds to:
Client: foo
Root: /Users/test/workspace_foo
View:
//depot/... //foo/depot/...
right? So that means that:
//depot/... <-> /Users/test/workspace_foo/depot/...
Sidebar: The p4 where command will show you the depot-syntax, client-syntax, and local-syntax version of any given path; use p4 where //... to see your entire client mapping with overlapping view entries disambiguated and client paths expanded to local syntax.
The local file you're trying to add is not within the local path of the client view you've defined, which is why you're getting the error file(s) not in client view. If you want to leave your view mapping the way it is, you'll need to move file into a path under /Users/test/workspace_foo/depot in order to be able to add it. Whatever path you create on the client relative to /Users/test/workspace_foo/depot will be created on the server relative to //depot.
If you want /Users/test/workspace_foo/file to map to //depot/file, then change your View like this:
Client: foo
Root: /Users/test/workspace_foo
View:
//depot/... //foo/...
which means that:
//depot/... <-> /Users/test/workspace_foo/...
and therefore:
/Users/test/workspace_foo/file <-> //depot/file
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.