Search the Community

Hi, I am looking at breaking up an existing project in to a couple of repositories so that we can make use of xlinks to share code between the original project repo and a repo for a new project. Whilst looking in to this I came across some issues that I have not been able to resolve and was hoping someone could provide some help. Our team has a mix of people creating their repos in a centralised way with @cactus@cloud and others that set up a local repository and use a sync view to push/pull to the repo in the cloud. For the new setup I have broken up functionality in to a couple of new repositories, "Tech" and "Tools" which contains common cross-project functionality. In the original project repository (in my local repository) I created an xlink to the new Tech repository as follows: cm xlink -w Source/Tech / cs:1@Tech@cactus@cloud I have committed and pushed those changes to the cloud repo. I have a second workspace for this project that is setup to track the cloud repo directly. In that workspace I am able to update the workspace as normal and i can see that the Source/Tech folder is populated with the contents as in changeset 1 of the new repo as expected. However in my other workspace which is set up as a local repo tracking the cloud repo that Source/Tech folder is empty. According to your documentation here you should update the workspace by clocking "update woekspace" in the GUI but as far as I'm aware this button is not available when creating local repos and updating via a sync view. I came across another forum post here which seems to be discussing something similar but in their case their xlink appears to be to a local repo whereas I want to set up my xlink to the cloud repo. Do I still need to adjust my sync view or create a new sync view to get this working? What is the process for syncing with an xlink at a cloud repo on a workspace for a local repository or is this not supported? Thanks Tom

Hi, I'm trying to update a plastic SCM client to version 4421 within Ubuntu 14.04, every time I'll get errors as follows when doing the apt-get update, I am following the instructions from this link:https://www.plasticscm.com/plastic-for-linux W: Failed to fetch https://www.plasticscm.com/plasticrepo/plasticscm-common/Ubuntu_14.04/./Packages Bad header line W: Failed to fetch https://www.plasticscm.com/plasticrepo/plasticscm-latest/Ubuntu_14.04/./Packages Bad header line W: Failed to fetch https://www.plasticscm.com/plasticrepo/plasticscm-stable/Ubuntu_14.04/./Packages HttpError404 W: Failed to fetch https://www.plasticscm.com/plasticrepo/stable/ubuntu/./Packages Bad header line W: Failed to fetch http://www.plasticscm.com/plasticrepo/5.0/Ubuntu_14.04/./Packages HttpError404 W: Failed to fetch http://www.plasticscm.com/plasticrepo/5.4/Ubuntu_14.04/./Packages HttpError404 Then after : # apt-get install plasticscm-complete Reading package lists... Done Building dependency tree Reading state information... Done plasticscm-complete is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 575 not upgraded. W: Ignoring Provides line with DepCompareOp for package gdb-minimal W: Ignoring Provides line with DepCompareOp for package gdb-minimal W: You may want to run apt-get update to correct these problems Even when it mentions it is already set to the latest when I try to open it I get the following error: "The client version (1912) doesn't match the server version (4421). Please update your client accordingly." Any suggestions?

We found a strange behavior in Plastic recently: Somebody deletes a directory and check-in this change. Others update their workspace, but the deleted folder and all its content is not deleted but rather left in their workspaces as private items. Why is that? It brings more work for everybody – all need to delete the already deleted folder too (and make sure not to delete any other private items, they might have). I understand that there can be more complex situation: somebody have some private items in a folder which was under version control but which was deleted now. It would not be right to delete that folder during update with the private items of that user in it. Plastic should delete only the files which was deleted under version control system and folders which contain these files only. However if there are no private items, it seems to me to be OK to delete the whole folder, when it was the checked-in change.