M-Pixel

@calbzam changing xlink metadata (adding expansion rules, changing target cs) doesn't force an empty changeset to be created on the target repo. Thereby, it should not be unreasonable for us to expect that merging metadata changes will also not force an empty changeset to be created. As I point out in the linked uservoice post, these empty changesets can lead to situations that the Plastic client was simply not meant to handle, leading users to an endless-loop scenario in the GUI. You have described the reason that Plastic is creating empty changesets in one of Mikael's scenarios - whether or not this is a correct description of the current behavior, it is a poor way for the software to behave and it should be changed if you intend to describe Plastic as intuitive. @Mikael Kalms I have just run into this very thing that you described: I made changes to the contents of an XLink from a task branch. Before doing so, I modified the expansion rules so that the task branch and the mainline both expand to the same branch of the XLink's target repo, in an active effort to avoid creating any branch on the XLink's target repo. This worked, but upon merging my task branch to the main one, despite the fact that the CS of the "theirs" XLink was a direct ancestor on the same branch of the "mine" XLink, I was required to merge them, creating an empty changeset. Ever since, new task-branches appear to automatically create empty commits on new branches on the XLink's target repo. I'll try to put together a video of the various issues that I'm having with XLink merges and empty changesets, as I expect the Plastic staff will not be convinced otherwise that we have any idea what we're talking about.

Although you're past your issue, I figure I might as well mention this for anybody else that comes across this thread looking for a solution in a similar situation: in a scenario where you have hundreds of moves, the least-effort solution is probably to check-in the moves that were correct, then turn off auto-detect and check-in the other ones in a separate changeset. While it might sound messy to have two commits where you could have one, ideally, these moves are being performed on a task-branch, so you would still have a single commit on your main-line. Of course, this is still a work-around. While I can understand from a software architecture perspective why Plastic does not allow you to selectively undo auto-moves (because the auto-moves are transient), it would be much better if Plastic SCM allowed auto-moves to be "staged" (or "locked-in"), just like how you can change items from Private to Added.

Oops! Good catch. The post has been fixed. The difference is merge vs merge-to. I've consistently seen this behavior when doing merge-to, but not from regular merges. Is anybody on your team using the merge-to feature? Sometimes I do notice xlink appear in normal merges, but if no changes were made, then the diff window shows that the target changeset is the same and only other metadata is different (such as addition of an expansion rule). In cases like that, the XLink does not receive a new commit. If I don't like the expansion rule that was automatically added, I just go to the workspace explorer and change it before committing (while the merge is pending).

I agree - why make it a full page? How about a simple dropdown menu, similar to the style of right-click menus, when you click on the new tab button. I have the same thought about the "home" screen - you could just fit all of that into a "hamburger menu". Recently Closed tabs sounds nice. +1 I agree that the order of the three main tabs should be changed, or configurable. Logically, I start with files (workspace explorer) - creating deleting opening changing and moving them. Then, after I do that, I review the changes I have made. After I do that, I have changes to visualize and perhaps merge together. Consolidating from sidebar + tabs to just one or the other is good. I'd prefer left-side tabs, though (or swappable like in the Vivaldi web browser) for the vertical space concerns. Even better yet, use the same layout you came up with for GMaster. That GUI looks so much easier to use than Plastic, and it's by the same company. Plastic and Git are more similar than they are different in terms of the information that users need to get from a GUI and the actions they need to perform through that GUI, so it seems wasteful that this Plastic update is happening seemingly independently instead of just riding on the good decisions that were already made and hard work that was already invested for GMaster. That said, and this is true for GMaster as well, the new GUI's visual style looks "Fisher Price" to me, like a child's toy with all the big margins and round corners that take up extra space. Have you ever used SmartGit? It is uuuuugly... but it's my favorite VCS interface. I don't have to flip around different tabs, everything is all in one place (branch explorer, pending-changes/workspace-explorer combo, diff view, full hierarchical workspace listing) because it's dense enough that it can show in a single screen what Plastic has to spread across several tabs. This visual redesign makes me worry that I will have to waste more effort scrolling and clicking around because the bigger buttons and tabs mean that I will have even less room for relevant information on screen at once. I'm not saying it has to be ugly, but don't sacrifice information density for prettiness in the developer-focused GUI - that's what Gluon is for.

Mikael, I have the same problem and I have posted about it on Uservoice. It's absolutely a bug that causes other problems and needs to be fixed. It might help if you add your own experience and votes to that Uservoice post.

Aki, it looks like Carlos is having trouble understanding what you're asking for some reason. It's possible and very simple to do exactly what you asked. From Pending Changes, click "Options", then un-check "Find moved and renamed files and directories". You can still use Search Matches to turn them into moves. Here's a video. Unity does have built-in support for Plastic SCM, such that it creates the proper moves from the moment of moving. So does JetBrains Rider. When I move files in either Unity or JetBrains Rider (with Plastic & Unity support turned on), they move the meta files on disk and via `cm`. I generally don't bother moving files in the Workspace Explorer like we're supposed to because it's very inconvenient compared to other methods: You have to use cut-and-paste because drag-and-drop is not supported.

Yes, in fact I have a link to that blog post in the article

I recently worked on bi-directional SVN <--> Plastic sync, and wrote about it here. In short, it's very possible using `git2svn` + `git svn dcommit` + Plastic's Git Sync.

Thanks for confirming. I'll keep an eye out for the fix in the release notes.

Thanks, and I'm sorry for not making those connections myself - it's certainly easier to see it all listed concisely. I can see how the SQL table implementation detail could be significant to RDBMS backend users. For Jet, is there any practical difference, or is it simply a restriction that carries over from the need to support RDBMS? It seems like there wouldn't be any practical difference if they're still being stored in different top-level folders just as top-level repos are (apart from the naming convention of those folders). Is this also true of Jet? Am I going to waste disk space if I create and delete repositories that are nested instead of top-level?

Unfortunately, that's not the issue here. I can confirm that the submodule is 100% successfully synced with Git, yet the "parent" repository still refuses to sync. If that were the problem, I would hope that the error message would say so ("The equivalent commit for [changesetspec] does not exist in [gitspec]"). Were you unable to reproduce the error using the provided files?

From a technical perspective, what are the differences between "repositories" and "modules"? This still hasn't been answered in the above thread. As the makers of the software, you should be able to fully enumerate this, and I can't think of why you would want to withhold that information by only giving advice for particular use cases. From a practical perspective, I understand that this feature allows me to use a tree view instead of a list view in the list of repositories. What else? That can't possibly be the extent of the practical implications. If it were, then everything is really just a repo with a different name, and I should be able to rename "A/B" into "C", but it doesn't sound like that's the case given that modules can't be moved into different repos.

Yes, this is open-source so I can share it. I've attached replication packages for the Plastic repos. I could invite you to the GitHub ones if you let me know your GitHub usernames. Perhaps this is the problem then. Am I right that you're saying this is not supported? Add commit to Plastic repo A that xlinks-in Plastic repo B Configure gitsync.conf with matching Git repos Run Git Sync ... and that only the following is supported? Add commit to Git repo A that submodules-in Git repo B Configure gitsync.conf with matching Plastic repos Sync Plastic & Git repos I created XLinks in Plastic before creating submodules in Git. Given that I can create submodules in Git and they become XLinks in Plastic (with the correct configuration), I expect for this to also work the other way around, too. If it's not supported, then is it now impossible for me to sync this with Git unless I start over, recreating all commits and making sure to only add submodules on the Git side first? CrashSpace donation receipt generator.replicationpackage MigraDoc Fluent.replicationpackage

I know about that documentation. It doesn't mention anything about spaces in repo specs, which is the thing that I said I hoped could be documented. It doesn't contain any examples of repo specs with spaces, either. Plastic does not seem to know how to invoke the Git Credential Manager, and I have 2FA set up on my GitHub account, so it always fails when trying to sync using the HTTPS scheme. I had multiple successful syncs before introducing the XLink using the SSH scheme, so I'm certain that isn't the problem. Just now, I successfully sync'd MigraDoc Fluent using the exact "git@" address I provided above. Anyways, it doesn't try to push until it has succeeded in pulling, and it doesn't show that error until it fails to push. And it were a problem with finding the Git repository, I would expect to see an error message saying "could not be reached" instead of "has not been defined". To be clear, the XLink is introduced on the Plastic side. Perhaps that's the issue? All of the documentation seems to talk about converting subrepos to xlinks, but not the other way around. Is it supported? This is the entire gitsync.conf file: [email-mapping] Max Pixel = git@m-pixel.com [submodules] git@github.com:M-Pixel/MigraDoc_Fluent.git -> "MigraDoc Fluent@localhost:8087" writable:true relativeserver:true I'll send logs via a support ticket, so that they're not available to the general public.

I'm running into the exact same symptoms. I've synced two repositories to Git, successfully. After XLinking in Plastic, I am unable to sync. In my case, I wonder if it has to do with the fact that my repository name has a space in it? I have tried all of the following (one at a time, with client GUI restarts in-between): git@github.com:M-Pixel/MigraDoc_Fluent.git -> "MigraDoc Fluent@localhost:8087" writable:true relativeserver:true git@github.com:M-Pixel/MigraDoc_Fluent.git -> 'MigraDoc Fluent@localhost:8087' writable:true relativeserver:true git@github.com:M-Pixel/MigraDoc_Fluent.git -> MigraDoc Fluent@localhost:8087 writable:true relativeserver:true git@github.com:M-Pixel/MigraDoc_Fluent.git -> "MigraDoc Fluent"@localhost:8087 writable:true relativeserver:true git@github.com:M-Pixel/MigraDoc_Fluent.git -> 'MigraDoc Fluent'@localhost:8087 writable:true relativeserver:true I have also tried some of those combinations without the writable & relative parts. Whenever I try to sync it with Git, I get The equivalent Git repository for 'MigraDoc Fluent@localhost:8087' has not been defined. The xlink cannot be pushed. Please add the equivalence inside the submodules section in the configuration file... It would be really nice if the GUI just asked "there's a new submodule, which repo should it be linked to?" with a repo selector. At least there should be some documentation on how to deal with spaces in repository specification (it's obvious on command line, but not for config files like this). What is wrong with my syntax?

Thanks. I didn't realize that there's additional documentation on Zendesk (it's not linked to from the Doc or Support pages).

Is there a full list of all relevant configuration files to copy from server to server, anywhere in your official documentation?

That's the gist of it. I need to be able to hire a subcontractor, send them a script, and say "run this - then you will have a complete development environment", so that I'm not paying people to waste time pushing GUI buttons. I need to be able to start a new computer, or re-image an existing computer that needed reimaging for whatever reason, and click my "set up computer for business operations" program, instead of having to waste time pushing GUI buttons the same way every time. I am going to eventually need to be able to set up continuous integration processes, and I suspect that not being able to change server settings automatically would make certain aspects of that unnecessarily difficult. That doesn't require there to be command-line tools for modifying all the properties. It's plenty easy to set values in XML, JSON, and INI files from a script. I'm surprised this is being questioned at all. Git, SVN, Mercurial, Perforce, Docker, and the list goes on, are all configurable entirely from a script. Heck, most of the Windows operating system, which is gargantuan, is almost entirely configurable from PowerShell. As I'm working to automate more and more of my business, I'm finding that even if the other programs don't have console programs for configuring, they at least have documentation on their config files. Even programs without proper documentation at least have a full enumeration of properties in their config files (and a consistent schema across config files). Plastic has an odd mix of key-space-value, key-colon-value, key-equals-value, XML, etc, almost none of it is documented, a small subset of it is covered by the included "example configs", and only some of it is configurable without a human actively waving a mouse around. I did just figure out that `clconfigureserver` can be used non-interactively, when I came across an example in a forum post. Too bad that feature isn't documented. Here's another way of looking at it. Why are they text files? If they're not supposed to be modified by the user, then why not use binary serialization? You have probably needed to modify the files by hand yourself from time to time. Your users need to just as much (I find myself having to do that every month or two to work around issues or lack of features). But we lack the information to do so accurately, without having to reverse-engineer the puzzle that you created. The original intent of this post was to find out where the documentation is, since I didn't find it easily by myself. Since it's been clarified in this discussion that the documentation does not exist at all, I've gone ahead and created a request on Uservoice.

That's not what I'm looking for, but I did eventually find it: https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide#Serverconfiguration This section describes steps for using clconfigureserver . https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide#Authenticationconfiguration This section describes steps for using umtool . Unfortunately, some of these commands are interactive, making them unnecessarily difficult to script. It looks like I'll have to just reverse-engineer the HTTP API, or else the XML and other files, and write my own tools for Configuring Plastic Server.

Is there a command-line configuration utility? I'm aiming for 100% scripted setup. I suppose I could use whatever HTTP API that WebAdmin is using, but I doubt that's documented.

Where can I find documentation on the various XML tags in server.conf?

As long as `/main` is included, for most projects, there's very little to be saved by omitting unused branches. Squashing old history would definitely address this pain point, moreso if it could be done per client repo, instead of forcing everybody to lose that history permanently.

In that case, I'll still need a way to replicate from computer to computer (and, of course, replication package files are a bit too inconvenient for this purpose). I looked into replicating directly between my laptop and desktop by opening port 8084, but it seems that the Cloud installation configures the server to only listen to localhost, and doesn't contain any of the server configuration utilities that I would need to change that. Should I use the Personal Edition installer to get the more robust server features, and then log in with my Cloud credentials?

A repository has become very large. I need to work with the repository on a laptop, so I need distributed, and I need to use as little disk space as I can. It is likely that I will want to reference recent history. It is unlikely that I will have any need to reference ancient history. This is a situation I've found myself in more than once before, and I'd like to find a solution. Nodata is a good start, but not feasible. With Nodata, I can make new commits without an internet connection, but that's it. Better than centralized, but far from distributed. Replicating the data needed to populate all commits on the main branch is excessive, when less than half as much data could sufficiently "hydrate" the last month of commits (e.g. repo is 40gb, workspace is 5gb, there is only ~100MB increase in repo size over the past month, seems like I should be able to have 1 month of fully navigable history with only 5.1GB data). Does anything like this exist, or am I describing functionality that would need to be added?

Freeform Labs has been using Plastic Cloud for years now. It's been great. So great, that I'd like to use Plastic for some personal projects. I could use my existing installation, taking care to replicate only between my computers (and not to the company cloud), but that still leaves me with commits labeled with my company account. That's tolerable, but becomes undesirable should I ever want to graduate a personal project to OSS. I got a Personal license already... But I don't know how to use it. I can't install Personal edition alongside Cloud edition (I have the option to replace or cancel). "Can't have multiple installations" is easily solved with a VM. But VirtualBox + Windows + Plastic is too heavy to run on a laptop, and unnecessarily expensive. So then there's Docker... But the Plastic installer doesn't work in Docker for Windows. So, option 1 is to use Docker, but thay requires figuring out how to get it to install properly in that environment. Option 2: I could use Linux containers, which don't have the installer problem because Codice has already QA'd Plastic in Linux Docker. Ubuntu-on-Windows is heavier than Windows-on-Windows, though, and presents potential filesystem mapping issues. Option 3: I could use Git as my backend, using Git Sync, and a username mapping rule to keep the company name out of the equation. But Git Sync is S L O W compared to a simple replicate. And what other features am I missing out on by passing the changesets through Git? Surely something. Finally, I could write some scripts that shut down Plastic Server, change the credentials, then re-start, whenever I want to switch between personal & company. That sounds like far too much work, though, and wouldn't allow me to use both at once, so I'd hardly consider it a viable option. ... And that's all I could come up with. So, Any other suggestions? To any of the Codice staff, if you wanted to do a hobby project with Plastic, how would you approach this problem? If Docker sounds like an agreeable solution, could I get some help with the installer? Or is there a way to get it in ZIP or MSI form instead? Or do you suggest I go with Git Sync after all?