Jump to content

Search the Community

Showing results for tags 'locks'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Plastic SCM
    • General
    • Installation and configuration
    • Unity 3D
    • Unreal Engine
    • 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
  • PlasticX Early Adopter Program's General Feedback
  • PlasticX Early Adopter Program's Issue Reporting
  • PlasticX Early Adopter Program's Feature Requests
  • PlasticX Early Adopter Program's Announcements

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. Hi We are currently working on a project in UE4 using Plastic as our main (and only) source control solution. Since files from Unreal Engine cannot be merged, we are using exclusive checkouts most files. It happens quite often that we want to test some features or create a slightly divergent version of the project for a demo. The issue we experience is that doing version control for these branches gets quite annoying. Even though the exclusive checkouts work on a branch basis to check if you have the latest version, it's impossible to checkout or push a file that's already checked out on another branch. This behavior feels weird because the checkout/checkin on the other branch will not affect your current branch in any way. Once it's checked in again on the other branch, your options are exactly the same as before the file was checked out on the other branch. I may understand something wrong here, but it feels weird to me at least. So the issue is that branches are never completely separated in terms of checkouts. So making a child branch for a different release or demo with it's own history and locks is not possible as far as I know. Specifically for our use case, a one-way child branch that's excluded from locking would be enough. Since this is basically a fork, a way to set up forks would also solve this issue. If this behavior is designed like this on purpose or we simply missed an existing feature, we're open for suggestions on how to set up source control in situations like these. Thanks in advance! Wouter
  2. We are using PlasticSCM as our VCS, where all of our interactions are done programmatically using cm commands (or, in some cases, the REST API). We are enforcing the exclusive checkout (locks) feature with the checkout-edit-checkin workflow. However, users are not directly interacting with the console, so we are running code that does this in the background as they interact with a GUI we have developed. When a user needs to see information about a branch, we want to list for them which of its files are locked and by whom. Thus, we need a programmatic way to determine what files are locked and by whom on any given branch, and we must be able to perform this operation outside of any workspace environment (this eliminates options like cm status and cm ls). We have tried cm lock ls, but the problem is that the returned information is insufficient. Each line is formatted like so: {Item GUID} {User Name} {Workspace Name} {Relative Filepath} Since we handle workspace creation and enforce that the workspace names are the same as repo names, we can say for our purposes that the third field gives us the repository name; however, we can't determine what branch the item belongs to. Performing potentially expensive operations/lookups to determine this by referencing the item's path/GUID is something we'd like to avoid; this would require us to first filter through all the results to the branch/repo we want, which leads to our next concern: we are unsure of the performance of cm lock ls and the subsequent filtering/search operations on a larger scale where there would be hundreds of repositories and thousands of files on the server. It would be nice to be able to perform a more focused search and/or obtain more information when using cm lock ls. There is an option to specify a revision object spec, but we are unable to find a way to wildcard this parameter in such a way to return files within only one specific repository or branch spec; instead, it will search the file path wildcard across all repositories in the server, ignoring whatever repo/branch object spec we give. Here is an example of a wildcard we tried that has this behavior: cm lock ls rev:/*#br:main@test_repo So we have two questions we are hoping to find answers for: Are we missing something with the cm lock ls command that would actually solve our specificity and performance concerns? Is there an entirely different way to get information about what files are locked by whom -- perhaps some server functionality or another cm command that we are missing?
  3. I am using Plastic Cloud and have recently moved from connecting directly to the cloud to a local replication. There are times when I am working when I don't have internet (I commute a good portion some days and usually catch up on work) or when my internet connection is spotty. It's something I have wanted to do for a while but help off on due to reliance on exclusive locks. However, I decided to investigate if there was a solution to this and came across this blog post and how the lock.conf file can be placed beside the server executable to redirect lock requests and checks to another server. I've created the lock.conf file but am unsure how to point it to our cloud. I have tried rep:[out_repo] lockserver:[our_org]@cloud:8084 but it does not work as I'm not sure if the server will automatically expand the @cloud shortcut. I've also tried port 8086 as it was mentioned in the Cloud guide. Though the guide mentions lock.conf being hot-reloaded, I restarted the service just in case to make sure that wasn't the issue as well. What would be the appropriate way to setup my local lock.conf to use plastic cloud as the lockserver? Is this not currently possible? If not I will likely move back to a centralized system (which had no issues other than needing that pesky internet connection). I'm aware the locks won't work if I am working without an internet connection but as I am usually connected and really just want the distribution for the odd time I'm not, I'm okay with this. Bonus question: if I am redirecting my locks to a different server, do I still need to list all the patterns in my local server? I have them in the file currently but wasn't sure if it was necessary. Andrew
×
×
  • Create New...