Jump to content

Rhys

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Rhys

  • Rank
    Newbie
  1. Ah, thanks for the clarification, Carlos, these terms help. Now that our workspace definitely appears to be set up for Centralized workflow, is it possible to switch it to a Distributed workflow, or should I set up a new workspace to replace it?
  2. I might be confused about our setup, we don't appear to sync the full repo from remote, but rather our project directory only contains the active branch's content. (Unlike my familiarity with git where the .git directory caches other local branches, our .plastic directory does not appear to have any caching in place). When switching to a different branch, it appears that the diff between the two is downloaded from the server each time, no caching in place. Would Synchronization View assist with this? Also, confirming that the documentation doesn't seem to outline how to get to this view, but I see what appears to be in when clicking Main Actions > Sync to Cloud.
  3. We currently use Plastic SCM with a configuration that keeps our workspace in sync with the remote/cloud server. This appears to require a download of the full diff when switching between changesets. Is it possible to easily change the workspace configuration so that each team member can manage their branches locally, and then push/pull/sync as required? This will greatly reduce bandwidth when bouncing back and forth between in-development branches. This or any other advice is greatly appreciated.
  4. Thanks for the clarification, Carlos. I am still a bit confused as to how the operation would be different to a stash > switch changesets > unstash approach, but I might be missing something in that article. Stashing itself would also be convenient, but from my understanding our Cloud account does not provide this, though I may be mistaken. For the purposes of not committing this in-progress project state, "checkin changes to a different branch" doesn't seem to fit to bill too well for this scenario for us.
  5. When a workspace has pending changes and the branch it is on has newer commits, the GUI provides the View New Changes button, allowing the changes to persist and resolve against the changes made. This is useful, as it doesn't require a new changeset to be created and local changes are retained. Does such functionality exist for branch switching? Often in our workflow, there are a common set of changes that can occur locally that prevent us from discarding if we want to switch to a neighbouring branch. It seems that such a workspace change would follow the similar process of resolving the changes without necessitating a commit, is that correct? Possibly a command line option could resolve this outside of the GUI also.
×
×
  • Create New...