I have a 4 gig plastic repository that I'd like to delete. Is there a way I can see what's in the repository without having to download all 4 gigs? Like the "Depot View" in Perforce?
You can do the following:
From the Plastic "Branch explorer" view --> right-click the desired branch/changeset --> "Browse repository on this changeset".
This way, you are able to navigate into the project tree and even download files if necessary (avoiding to perform a full workspace update).
You may also find useful the Plastic SCM Drive feature: http://blog.plasticscm.com/2015/02/plasticdrive-dynamic-readonly.html
You are able to access repositories from the WebUI that PlasticSCM made recently.
https://www.plasticscm.com/orgs/[YOUR ORG NAME]/repos
Read more about it here:
https://blog.plasticscm.com/2021/07/announcing-webui-v2.html
Related
I am developer and work with TFS for a while but never have the responsibility of TFS admin. We have a user that was let go and now his userId has been revoked so we cannot use his id anymore.
He has so many files checked out in TFS and a lot of stuff done, we don't want to lose these checked out files if possible. Is there a way to transfer all his checked out files to me or someone else? Or what is the best way to recover these files?
NOTE: we still have his laptop with all the files, we just cant login to it with his username.
Thank you for your help in advanced
Download TFS Sidekicks (get the right version for your TFS)
They have a Visual Studio Add-in if that is what you are using as your IDE
Backup his files that you want to keep
Use the Workspace Sidekick of TFS Sidekicks to delete his workspace(s)
(this won't delete his files).
This will release any exclusive locks that he has effectively undoing all his checkouts.
You can also use the Status Sidekick to see what files he has checked out.
Get latest source and copy his files over yours
If you are using TFS2012 or later, you can use a 'local' workspace and simply copy his files over. Team Explorer will create your pending changes for you. If you are using a 'server' workspace or a version of TFS prior to 2012, you will need to full check-out everything and THEN copy his files over.
It's not a great solution but it should work for you
The changes to the developer's files that are checked out will be stored locally on the developers machine (specifically in their workspace directories) - transferring "check out status" would seemingly not accomplish what you hope.
You would need to obtain access to the developer's workspace (perhaps via an admin account on the dev's machine), copy out all the contents to a new workspace you own to consolidate differences between "source" and "new workspace".
Once you've copied the developer's workspace to a new workspace you own, you can simply compare "source" to "workspace" to find all the changed files and which are needed vs. not needed. Note, this should be done sooner rather than later as the longer you wait the more differences there will be between the two, making it harder to identify what is actually needed.
We have a Visual Studio solution containing about a dozen class library projects. They're our team's main internal framework. In Jenkins we would like to automate the building of these projects as soon as a check-in is made, and also publish a new version to our local NuGet repo.
The problem: We would like to trigger the build by polling SVN at the class library level, e.g. ..trunk/OurSolution/OurCoreProject. Changes in one project should not trigger a build on all the other projects. But the checkout needs to be done one level higher, e.g. at ..trunk/OurSolution, and I cannot figure out how this can be done.
We've tried and contemplated a few solutions already:
Checking out at project level and then send the .csproj file to
MsBuild.exe instead of the .sln file. This fails because the project
expects a sibling folder named .nuget.
Looking into the Multiple SCMs
plugin, but it seems to mainly add the ability to use different SCM
providers in the same project(?) I would like to avoid adding this
plugin until I know it solves this.
Splitting all the projects up into separate solutions. Doesn't feel very optimal...
Is there a way to solve this in Jenkins? Have a missed any viable solution?
Yes you have missed something... the Advanced... button on the Subversion checkout configuration.
Do your SVN checkout on ..trunk/OurSolution
Click Advanced...
Under Included Regions, type ..trunk/OurSolution/OurCoreProject/*
For more info, click the ? icon next to relevant text area on the UI
If set, and Jenkins is set to poll for changes, Jenkins will ignore any files and/or folders that are not in this list when determining if a build needs to be triggered.
I have a collection of scripts among with some executables on a network share folder.
From time to time I change these scripts, add new ones along with some new executables.
In order to be able to roll-back some inadvertent changes I would like to keep track of my changes.
The rest of my code sits in a Team Foundation Server repository and it would be best if I could just sync the network share with a folder in that repository.
I tried to use tf.exe for this purpose, but as far as I understood I first need to create a workspace, map it to this folder etc -- that seems to be too complicated.
Is there any simple solution here?
Check-in the scripts to TFS, setup a simple build which copies the script files and replaces them on network share.
Map your shared drive and create a TFS workspace to the mapped drive. Add all the files in the shared drive to TFS.
Every time you are doing a change, checked out your file using
tf checkout "fileName"
do the changes and then check-in the file using
tf checkin "filename"
Make sure to execute tf.exe on the mapped folder.
I am attempting to implemtent a way to deploy my compiled assemblies to QA for testing. I have a number of repositories, each of which contain folders with projects and source code, and also a folder that contains the compiled assemblies produced from those projects. The image below is representative of my source repository workspaces.
I also have a Development user group and a QA user group. The Development user group has full permissions to the source repositories.
I have tried a couple different ways to accomplish my goal, but have had little to no success:
I have tried creating a new repository called Assemblies, and adding Xlinks to my source repositories, and then denying all permissions to the QA user group for all folders and files in the source repository, with the exception of the Assemblies folder. However, when logged into Plastic as a member of the QA user group, I can still download all of the source files.
I also tried directly accessing the source repositories as a member of the QA user group, but I still have access to files that shouldn't be available.
I am considering a check-in trigger. The trigger would add/check-in .exe's and .dll's into the Assemblies repository whenever they are checked into the main branch of a source repository. However, I'm not sure if I'm heading in the right direction. I don't want to 'reinvent the wheel' if there is already preferred method or best practice that I should be employing.
Any suggestions or references would be greatly appreciated.
This is my suggestion,
Create a new repository in order to place all your binaries at output artifacts. In your central repository, the one that xlinks to the external 'Third party' repository, create a new xlink to the new brand new "Binaries" repository.
Now you will need to change your build system to copy all the binaries and artifact to this xlinked repository. A (cm ci -a) command will commit all the changed binaries, finally label the changeset with the "cm label" command, this label will help the QA team to test certain releases.
Remove the view permission for the QA Plastic SCM group at the central repository and the "Third party" repository. Now the QA group will never know that there's even a source code repository. The QA group will have a workspace working with the "Binaries" repository and your source code/repositories will be safely hidden and not accesible by this QA group.
You can even have the "Binaries" repository in a external server/machine. So the source code is in devMachine:8087 and the binaries are in a different Plastic SCM server, for example "qaMachine:8087". Using this methodology the QA Plastic users will be using a dedicated server.
I have a TFS Build Server where the CI and Release builds occur. The build process runs under some domain account and all the build activity happens under this user's temp directory. Unfortunately, the \Users directory is on the C: drive which turns out to have not much space. Although the build retention policy is quite strict, there are enough builds configured that this space has become quite scarce.
There are other volumes on the machine that have plenty of space.
Can anyone suggest a straightforward way to change the root build directory? I've looked for a TFS property without much success so far.
Thanks.
For TFS 2008 right click on the Builds node and chose "Manage Build Agents". Select the agent of choice and then press "Edit..." and change the working directory. My personal preference is to change it to something like:
c:\bw\$(BuildDefinitionId)
As that will give it a short working folder for your builds (the .NET API's have a 260 character limit for file paths so using as few of those characters as possible for your working folder gives you mor eto play with during your build).
For TFS 2005 edit the TFSBuild.proj file of the relevant build(s) and change the working property to point to where you want it for each build.
Hope that helps,
Martin.
In Team Explorer View,
Right-click Builds -> Manage Build Agents,
Select the build agent and hit 'Edit...'
Set 'Working directory' to
<New Build Root>\$(BuildDefinitionPath)
This works for all projects using that build agent.
My TFS proj files have a property called BuildDirectoryPath
<BuildDirectoryPath>c:\build</BuildDirectoryPath>
This is where all of my source code gets put and where the binaries are built.
Providing an answer for VS2012 / TFS2012 Server.
This will update the working directory on an agent-by-agent basis
- Team Explorer window
- Click Builds
- Click Actions and select Manage Build Controllers
- For each Agent, click Properties and click inside the working directory field and change it, clicking OK when you are done
Note: the OP talked about a domain account and the temp folder. Therefore, this solution may not work for the OP but it did work in my case to move from the System (C) drive to an alternative volume (D in our case).