tucny
-
Posts
31 -
Joined
-
Last visited
-
Days Won
5
Posts posted by tucny
-
-
…and some 9 years later in Plastic version 11 this bug is still around and causing headaches:
Issues in particular:
-
No way to actually diff — I can't choose the resolution method without diffing first. Did anyone do any UX design here?
-
-
Wrong defaults — again, the workflow is (1st) diff, (2nd) choose resolution and you offer (1) choose resolution and that's it. The diff is burried in the righ-click menu, and for the evil twin only.
-
-
No show of what is source and destination — would it be possible to explicitly show the source and destination branch path and changeset number in the UI (see the red rectangle)? I did submit these suggestions some years before, but apparently, no one understood why it is a good thing.
-
- Bad contrast — please fix the dark gray text on light gray text, see screenshot above. Did anyone do any UX design here?
Please, please, fix this 🙏, @manu, @calbzam.
Note: Yes, I know there's the new GUI. It's so buggy and functionally behind the old one, that we can't use it in production. I did it a try, and sent some 30+ bug reports and UX hints, but can't use it as long as I get the following error twice a day:
And this one when trying to do the same merge as above with the old GUI, so I even physically cannot do the same merge with the new GUI:
I am using version 11.0.16.8077, so the latest. And no, I can't upgrade the client every week, unless there is a significant step forward in quality and feature-parity.
-
No way to actually diff — I can't choose the resolution method without diffing first. Did anyone do any UX design here?
-
I can only support this feature request. We use Azure AD to login to JIRA (cloud) as well as (naturally) Visual Studio, and I'd love to see the ability to authenticate to PlasticSCM (on-premises) with an AzureAD account and use these credentials to authenticate to JIRA (cloud) in the JIRA plugin. Currently, we can't use the JIRA plugin at all. I was considering developing a custom one myself, but never had the free week I could spend for it.
-
1
-
-
Each of them having a branch for the task they work on and their own workspace on their own computer.
This is the very basics of development team collaboration. Maybe you should rephrase your question, so we better understand what you are truly asking about.
-
2
-
-
Can you provide the sources for both versions, or links for them? Looks like a public thing.
-
Ben, in respect to the other discussion, why do you open a merge tool for each file, when updating from the parent branch? This is typically completely unnecessary, unless Plastic shows a merge conflict.
Let me suggest an alternate workflow:
- Switch to the feature branch (/main/somefeature)
- …work on changes in the feature branch, commiting them… meanwhile some changes arrive into the /main branch…
- Right-click on /main's latest changeset (or any changeset you want since your last update from /main) and choose "Merge from this branch" (without "to…")
- Checkin merge.
- Done.
- …continue working on changes in the feature branch, e.g. change the file that were just merged or whatever needed…
No manual merging needed almost ever.
-
1
-
I second to @KristofMorva and @Marc S. I perfectly understand Unity's focus on games and 3D. However: Plastic was and hopefuly will keep being a general-purpose version control system.
Our main business is enterprise software in a regulated area — banking. Running on-premise and running only those things we want and use is quite crucial. Consider having to go through audits and certifications such as PCI DSS. I can't have stuff like "Distribution portal" or "My Games" on the screen
Where I would really love to see Unity taking PlasticSCM is a source control and management platform on-par with GitHub, which can run both in the cloud as well as on-premises (or at least as dedicated instances in a private cloud).
-
1
-
-
That sounds very strange. What type of files are you merging? Are they standard source code in some normal programming language, e.g. C#, Java, TypeScript whatever else like that? Are they properly formatted with lines indented? Manually written or auto-generated by a tool?
Plastic's merge is semantic-aware. It identifies related portions of code and can detect e.g. moves of methods within the same file etc. Normally, when a merge conflict is detected, i.e. Plastic is unable to merge the update automatically, a conflict resolution editor pops up, where you can select which version of each change you want to keep.
What IMO greatly influences the quality of your experience is whether you keep using Plastic as it was designed to be used in respect to the information it needs in its repository history:
- use branching, ideally stick to the branch-per-task usage pattern, very useful in daily life
- do not delete, commit, add same file, commit (breaks file history)
- when moving a file, prevent a delete & add scenario in a commit, use "Search for matches" to turn it into a rename scenario (preserves file history)
- when doing large refactorings over a long period of time consider updating from the parent branch, ingesting changes that happened meanwhile
The following is helpful in understanding the bigger picture: https://www.plasticscm.com/mergemachine and an in-depth here: https://www.plasticscm.com/book/#_merge_and_conflict_resolution
Regarding the NDA: To my experience Plastic's support team is very helpful and open to communicate on whatever comm platform you have. I'd suggest doing a screen sharing session on you own communication tool, e.g. Teams, and have one of their support personnel look at the problem.
-
1
-
PlasticSCM has its own merge tool. No need to manually edit anything outside that merge environment. Besides, manual merge conflict resolution is really rare.
What's your specific use-case or concern?
-
1
-
-
Thanks to a roughly weekly cadence of PlasticSCM releases, there's almost always a newer version avaiable
Hence an icon or a notification would add an extra distraction.
In managing our Plastic environment, I tend to do server updates 3 – 4 times a year. And thanks to great backwards compatibility, I rarely increase the minimum client build number to enforce updates in all DEV VMs. However, I am considering to automate this and push new versions more frequently, ideally with a monthly cadence to our server and all VMs.
-
Is this focused on graphics development only? The questionnaire suggest that. I'd love to provide feedback and a couple ideas how to evolve Plastic in order to enable further developer productivity automations.
-
On 7/9/2019 at 11:11 AM, tucny said:
Well my issuer is my local custom certification authority (Active Directory CA) which is up and running and its certificate is valid till the year 2108.
In my case, it turned out the certificate was expired. It would be nice if Plastic server reported this somehow, at least in its log file.
-
36 minutes ago, Sam said:
Your certificate is valid, but your issuer's is not, perhaps your issuer stopped its services like our did 3 months ago.
Well my issuer is my local custom certification authority (Active Directory CA) which is up and running and its certificate is valid till the year 2108.
-
Same issue here. Our cert is issued by a local CA (AD CS). So far it worked but stopped now. The CA's cert is valid and published to all machines via AD. OpenSSL show the following validation errors:
depth=0 /CN=kara.corp.boldbrick.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=kara.corp.boldbrick.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=kara.corp.boldbrick.com verify error:num=21:unable to verify the first certificate verify return:1
-
Well, that's a good point. However, numbers as names are far less user-friendly for database maintenance tasks than repository names. Plus, when I rename a repository, it creates a handful of issues with all workspaces around, so one more database maintenance task is of a negligible concern in that situation.
-
I'm planning a reinstall of our Plastic server on new OS a SQL versions (I know, I know, Jet… but…). What's annoying me is that the databased in SQL Server (have 100+ of them) are named according to some repository number.
What I'd like to have are database files "repo_boldbrick-framework.mdf", where "boldbrick-framework" is a sample repository name. All our repos are named according to the "<customer>-<project>" pattern. I read in the documentation about the database creation command. However, there's no variable for the repository name.
Can I, somehow, customize database names like above? What can I do about the existing database file names during server migration?
-
Ah cool! Thanks a lot, I didn't notice the item in the Advanced menu.
-
I have this scenario:
- quite an old reference changeset (like 100 revisions back, even a lot more), representing a version used by the customer
- several branches with new features and fixes, newer that the reference changeset
- request for a patch release, which would include a few of the fixes and new features
Obviously, I'd start a new branch for the patch release from the reference changeset. However, the issue is how to merge the selected fixes and features? Cherry picking individual changesets is not an option — I'd have to do this over like 20–30 changeset. On the other hand, the fixes and features are located in like 3 branches.
What I'd like to be able to do, is cherry pick a whole branch, i.e. all changes done in a particular branch. This way, in my situation I'd cherry pick three times instead of thirty. Quite a big difference.
From my perspective, the atomic changeset concept, while otherwise logical, is quite failing to support real-world scenarios like this case.
-
Living in the same repo is fine. However, if I create a top-level branch, I have to create it from some other branch anyway, right? In that case, the new top-level branch for the new version will implicitly inherit all content from the old version. I'd rather prefer picking files into the new version one-by-one. Is this possible?
Or do I have to approach it the opposite way and delete files that I won't need in the new version? The reason why I don't like this approach is that a) I can't tell now which files I will need, b) this doesn't match the development workflow, where the new version is going to be developed module after module.
-
I have a sort of advanced scenario regarding 'continuation of repositories' and I'm looking for a reasonable strategy.
I have a repository for a product, version 1, with the latest changeset number, say, 2000. I am going to start development of a new version 2 of the same product. A portion (like 50 %) of the source code from version 1 will be reused and largely refactored. However, version 2 will be primarily a green-field development with a completely new architecture (from the C# source code perspective, different structure of the solution, layering, decomposition into projects, etc.).
It makes no sense to start with the existing codebase at changeset 2000, and start changing it from changeset 2001. On the other hand, there is continuity, version 1 will have to be maintained (more changesets to come) and for the the reused portion of code versioning history is desirable.
Normally, I'd start a new repository and go from changeset 1. However, that provides no link to the old (but reused) code, no versioning history, and no changeset number continuity.
Is there any to solve this in Plastic? Something like
- Create a top-level branch in the original repository, which would be somehow forced to be empty at first. Start version 2 development there, and then selectively merge the reused files. Not sure if there's a way to create a new top-level but empty branch?
- Start a new repository and use xlinks to bring in the original code to be reused. Not sure if xlinked content can be modified and become a local copy, having the original xlink for version history only?
- In case of the new repository, it there an option to force it starting from a given revision number, e.g. 3000?
New Plastic SCM web experience open beta now live on the Unity Dashboard!
in General
Posted
I hope Unity will keep its word. PlasticSCM is a superb version control product, and both on-premises and cloud general-purpose use cases are legitimate and long-term.