Jump to content

Search the Community

Showing results for tags 'new'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Plastic SCM
    • General
    • Installation and configuration
    • Unity 3D
    • Plastic SCM on Mac
    • Plastic SCM on Linux
    • Gluon
    • Git interop
    • Integrations
    • Community Edition
    • Branching and merging
    • Announcements
  • Plastic SCM 4.0 Beta (Closed)
  • Plastic Cloud
    • General
    • Configuration
  • SemanticMerge
    • General
    • License
    • SCM's configuration
    • Share your experience!
    • External Parsers
  • GitJungle
  • Method History for Subversion

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 4 results

  1. d0mokun

    Unable to create new workspace

    Hello everyone, I'm having a bit of a bother with Plastic when it comes to creating a new local workspace. I have created a cloud repo with no issues whatsoever. When I try to create a new local workspace, Plastic tells me that the 'workspace already' exists.. but for my existing workspace and not the new one. Plastic happily creates a new local folder and the same issue occurs if I choose an already existing local source folder. I've only got a single pre-existing workspace also linked to a cloud repo. The new one has nothing to do with the existing one. Perhaps someone could advise me as to a solution? Thanks Dan.
  2. I'm quite new to Plastic and finding my way so will probably look to this forum for help in doing that. So my question is this; in the free lessons on the Plastic website, the example sets up a new Repository and it is named after the project (something like Dokan). Does this mean that it is good practice to create a new Repository for each project? e.g. I have many clients/websites - should each client site/project have its own Repository or can I create one Repository and just make a separate Workspace for each project?
  3. on your mark, get set, go!!! #mergebegins www.plasticscm.com/sm/index.html
  4. Hey there! A new release is published! Check the details here: http://codicesoftware.blogspot.com/2012/08/a-new-release-of-4.html And here the release notes: External Release (Aug 14th 2012) ==================================================== New RSS view: Now, the avatars are stored in the plastic4 local folder instead of the Temp local folder. Also, the image file resource is immediately released after it's loaded in memory. Finally, a better mechanism for non-available images has been implemented. Bug The locally moved operations could not be applied when a directory was renamed to its old name plus some new characters and it contained other directory inside. Fixed. Bug The recent items list might became a mess if it stored more than 5 items because the separators were taken into account as normal items, and when restarting the GUI new separators were introduced every 5 items... Fixed. Known issues: * The merge-to feature does not expand branches in xlinks. * Changes in file permissions of directories that are placed directly inside the root of the workspace are not saved. This only affects directories that are DIRECTLY inside the root, not subdirs, and does not affect files either. * Xlink renaming is not supported. Xlinks can't be moved or renamed. You will see a warning message if you try to do it. cm xlink xxx / 1@CmdRunnerGitHub@localhost:8084 -w cm ci cm mv xxx yyy -> Xlinks cannot be moved * Restore operation is not implemented yet. The restore operation for deleted items is not available yet. You can, however, use the subtractive merge in order to recover a removed item. * Undo changes does not update the workspace inside xlinks after a merge operation. The changes done inside a xlinked path are not updated after an undo changes operation if the changes comes from a merge proccess. You can have missing or outdated files, a simple update operation will recover all the files. cm mkbranch br:/main/scm001 cm stb scm001 cm co XlinkPath/FileUnderSlink.txt cm co XlinkPath/FileUnderSlink2.txt cm co XlinkPath/FileUnderSlink3.txt -> Edit files cm ci -> Created changeset cs:5@br:/main/scm001@rep:xlinkMergeTest@repserver:TIZONA:8084 cm stb main cm merge br:/main/scm001 --merge cm unco -> c:\xlinkMerge\XlinkPath\FileUnderSlink.txt unchecked out correctly -> c:\xlinkMerge\XlinkPath\FileUnderSlink2.txt unchecked out correctly -> c:\xlinkMerge\XlinkPath\FileUnderSlink2.txt unchecked out correctly cm update . -> Copied XlinkPath/FileUnderSlink.txt -> Copied XlinkPath/FileUnderSlink2.txt -> Copied XlinkPath/FileUnderSlink3.txt * When (re)opening the advanced search in the Branches view, the default query no longer displays. To work around this, simply type in the default query ("find branches") or type in your own custom query to suit your needs. * A new attribute applied to an item is not shown in the Attributes list. When you are adding a new attribute to a branch, for example, the new attribute created is not immediately shown in the attribute list. If you refresh the view after creating the attribute you will be able to see the new attribute. * If you're reviewing branch attributes in the Branch view, and you use the branch filter, the attributes view is not updated. Instead, it shows the attributes for the last selected branch, which may or may not be a part of the query. To update the attributes view, simply click on the branch you're interested in. * Writable XLinks Merge does not support the xlink edition (cm xlink -e) to a conected changeset, an ancestor changeset. Merge operations having xlinks in a source contributor targeting an older and already connected changeset are not finding conflicts. The changesets in the external repository are already connected. * Scenario: create two xlinks pointing to the same rep. When trying to perform an update, it fails. It's not possible for PlasticSCM to perform an update operation having two or more xlinks pointing to the same repository. It's not allowed to load the same item in multiple workspace paths. * The check-in between several repositories should be atomic. Currently, the check-in is done and committed from the deeper repositories to the root repository. If something fails in the higher mounted repos, the check-in done in the deeper repos is still committed, so, the operation is not atomic between repos. A check-in operation that affects several repositories is not atomic. The check-in operation iterates over each xlinked repository with changes and performs a commit one by one. If one of these steps' "commit" fails, the operation is cancelled but the commits already done are not rolled back. cm stb br:/main/scm002 cm co fileInLocalRep.txt cm co xlink\fileInExternalRep.txt //edit both files cm acl -user=manu -denied=+ci br:/main/scm002 cm ci You don't have permissions for operation ci. * Support xlink evil twin rename resolution Plastic SCM is not able to handle evil twin conflicts with a rename resolution. Only "Keep source" and "Keep destination" options are valid for this kind of conflict. mkdir SecretProject cm xlink SecretProject / 1@CmdRunnerGitHub@localhost:8084 -w cm ci cm mkbranch scm001 --changeset=1 cm stb scm001 mkdir SecretProject cm xlink SecretProject / 1@CmdRunnerGitHub@localhost:8084 -w cm ci cm merge main Please enter a new name for the destination: xlink-dst Item -1 could not be found in the tree. The new tree cannot be built.