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?