I am new to Accurev. I am working on a workspace and I see a problem which I need help from a team member to look at the issue. what is the easiest way to let the other team member to access my files in my workspace through Accurev?
Using Subversion, anyone could checkout my branch and see my changes, build the code and reproduce the issue., But with Accurev I am not sure how to do the same.
Reading the Accurev documents, it looks like a workspace acts as a stream but cannot be shared between developers.
It's been a few months since I've used Accurev, but if I recall correctly, your team members can browse your workspace. If you're browsing your available streams using the GUI tool, there should be a setting at the bottom to show workspaces from all users. This will allow them to at least browse your workspace. If you want other developers to be able to change these files, you'll have to push them up into a stream. If necessary, you can always create a new stream and re-parent your workspace.
If you have kept any files in your workspace, another user can look at the "Version Browser" of that element in their workspace and see your kept version and look at your changes.
Or, you could create a new stream, reparent your workspace to this stream and promote your changes into the stream.
Related
We have 30 User's and 26 of them are Artists, and all of their workspaces were created manually with their username and a project alias. Now we want to add some new view's to the user's workspace, is there a way to do a bulk-edit on that with a perforce command?
Can I, as an admin modify a workspaces view and that would be reflected, next time the Artist opens up perforce?
Perforce's built-in solution for this is called streams.
With a "stream-based" workflow, each project (and each codeline for each project, if applicable) is defined by a "stream" specification that defines which paths the project contains, and its relation to other streams, if any.
When a workspace is associated with a stream, the view is automatically generated based on the stream specification, and modifications to the stream specification are automatically propagated to all workspaces associated with that stream.
With a "classic" client specification, each workspace has its own independently created view, which is not tied to any other workspace or any other object. As an admin you can modify an other user's client spec via the p4 client -f command, and you could potentially script this command to automate that modification across multiple client specs.
However, I'd recommend looking at streams as an easier solution; it might be a bit of work up front to migrate from manual views to stream views, but if you anticipate the need to make changes like this frequently, using streams will be quite a bit easier than maintaining your own tooling.
I am trying to create workspace into perforce so it will be available to other person who would like to add or submit file. I was following link which suggest to create new workspace
https://www.perforce.com/perforce/doc.current/manuals/p4v-gs/01_p4v-gs.html#1060773
I got one question, why perforce is looking into my local directory which can be deleted at any time.
The local directory that you mention is the root of the workspace. That's how Perforce knows where to put files when you tell it to get files from it.
You have a couple of options. One is to create a workspace and put /dev/null (or some other non-existent directory) and ask the eventual owner to change it before using the workspace. They should also change ownership to themselves. It is important that you don't "lock" the workspace when you create it, otherwise they won't be able to modify it, take ownership, or even use it.
Another option would be for you to create a workspace (for yourself), and then ask the other user to create a workspace, using yours as a template. The command line way is p4 client -t . Doing this via P4V, you would ask the user to find your workspace from the workspaces view, right click, and then from the contextual menu choose "Create/update Client using Clientname as Template..." (the wording might be slightly different, I don't have P4V open right now).
I recommend you go with option two. Doing so will automatically set ownership to the correct user, and the user will also be prompted to choose a local directory for the workspace root.
I have deleted the workspace from accurev. Now when I am again creating the workspace. It's giving error that workspace already exists. How can I resolve this?
update: Is there any accurev plugin through which i can directly promote the code to accurev strean using IBM RSA.
Workspaces and streams are never really removed due to the time-safe architecture; they are deactivated and can later be reactivated. This also means that a workspace or stream owns every name it's ever had. You will need to create the new workspace with a new, unique name.
Via the command line, "accurev reactivate wspace workspaceName"
Where I work, our marketing team is looking for a "quick and easy" method up periodically updating some files on a website of ours. I opened my mouth and said "We can use Azure Websites with DropBox!". It all works fine, except that with DropBox, files only deploy if I log into the Azure Portal and click Sync. Needless to say, this is a deal breaker, because the users want to save a file and have everything appear magically.
Is there a way to setup continuous deployments via DropBox on Azure? I don't mind setting up a job to run every 15 minutes to perform a file upload if needed.. but would prefer to avoid that if possible
Thanks In Advance
Currently we don't support the continuous sync with Dropbox. The challenge is the noise and the reliability of the site given those changes. Imagine users naturally modify file by file and Dropbox sync them one at time. You can get into the situation where your site is in transient bad state.
This is not currently possible using the Dropbox integration in Azure Websites. Best option for this is the local git integration, where Azure will provide you a remote git location that you can push to that causes an update.
So that gives you behavior, but not the dropbox behavior you want, as someone would still need to commit and push.
To get that you could look into implement a Git hook to mimick the behavior, where you would auto commit and push when a file changes.
Something like this would give you that behavior, but you'd need to translate to a server-based model.
Git Repo Auto-commit and Push
Alternatively, you can host the site in GitHub or Visual Studio Online and I beleive you get that hook automatically.
I have a team that will be using CruiseControl for continuous integration, and CC will be running on a Linux server. More than one team member may need to access the CC configuration itself: changing how tests are run, changing notification rules, etc.
What is the best practice for this?
My first thought was to set up a cc-users group, then make a shared directory somewhere (such as /usr/local, I suppose, or a new directory like /projects), where the directory has r/w for the group.
Am I missing any complications with this plan? Obviously, I've never been in charge of such a project before, otherwise I wouldn't ask such a question.
FWIW, my intention is to have all the cc configuration files under mercurial so we can roll back in case of breakage.
I have version-controlled the whole of cruisecontrol configuration, along with the project specific config files underneath it.This way, the write-access can be controlled per requirement, using your source control tool's access control method (in our case subversion) thus providing tracking as well. Whomsoever needs to make a change can checkout the file config.xml in their own workspace and make their changes and then commit. You may want to consider the same approach.