Jump to content

Mikael Kalms

  • Content Count

  • Joined

  • Last visited

  • Days Won


Mikael Kalms last won the day on June 7

Mikael Kalms had the most liked content!

Community Reputation

6 Neutral

About Mikael Kalms

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes. Your proposal would give the behaviour that I desire: it mimics the result that I would get, if I used only read-only xlinks, made changes to the parent and Xlinked repo separately, and manually updated the Xlink target when necessary. (I haven't thought much about the traceability and the question "does the wxlinked repo structure make sense when viewed in relation to the parent repo structure?". I have only thought about whether the wxlinked repo structure makes sense on its own. I think the former results in empty changesets being good, and the latter results in empty changesets being bad.)
  2. I tried following your repro steps. Using merge-to rather than merge-from does not result in any extra changesets for me. This is what my A repo looks like at the end: and this is what my B repo looks like at the end: However -- I suspect that we are both seeing problems caused by the same root behaviour (any merge that involves a wxlink change results in a commit via the wxlink). We are both surprised because we think "hey, this case could be solved without touching the child repo -- after all, that's how it is handled with read-only xlinks, and without requiring manual conflict resolution". Right?
  3. Ok. So, my desired behaviour, summarized even shorter. During a merge, when there is a wxlink change involved: - if the corresponding read-only xlink change would have resulted in an automatic merge, then I would expect the wxlink to be handled the same way: the wxlink is updated, but no changes are made within the wxlinked repo. - If the corresponding read-only xlink change would have resulted in a merge conflict that required manual resolution, then I would expect the wxlink to be handled by automatic branch creation + a merge performed within the wxlinked repo. The above logic fulfils two key criteria: 1) Merges will no longer produce branches with empty changesets in the wxlinked repo 2) Any merges that were handled by the current Plastic SCM logic, will continue to be handled by the proposed logic. (For the time being, we will convert all our shared plug-in repos to be referenced via read-only xlinks. The wxlinks were nice but the extra "noise" in the wxlinked repos isn't worth it.)
  4. Thanks for the explanation Carlos. I understand the reasoning. I have a problem with how plastic handles the wxlink merge (item nr 3 & 4). If the B2 link had been a read-only xlink, then people would have done the work manually within the B2 workspace. The B2-related changes within the A2 workspace would only be changes to xlink's csetid. This would result in an xlink change first committed in cs:4@A2; this would get merged back to /main in cs:5@A2, and that same change would propagate to /main/A2_1_task001 in cs:6@A2. Since no extra branches/csets are being created in to B2, there would be no change to the xlink in cs:8@A2. This changes when we use a wxlink for the B2 link. As soon as _anyone_ changes the csetid which B2 points to and there is at least one more active branch in parallel, then there will be at least one extra set of branches (and corresponding null commits) created when people begin to merge their branches. If people manage to always have overlapping branches, the extra branches and null commits will continue to occur on B2 until the end of time. This is my desired behaviour: During a merge, where either the source, or the target, but not both, contain an update to the wxlinked csetid, I want: - No new branch created in the wxlinked repo - No empty cset created in the wxlinked repo - The wxlinked csetid should be updated in the parent repo, just as if it had been a read-only xlink. I want this behaviour during branch merges. I want this behaviour during cset cherry-picks. I think I am missing something here. Will get back to this tomorrow, need to think more about it.
  5. Okay, I have a short repro case of my problem (which may or may not be related to M-Pixel's problem). It involves concurrent branches. When someone changes something within a wxlinked repo on one task branch, and then merges that up to /main, then, under certain circumstances, this results -- a couple of steps further away -- in a merge operation from /main to another task branch resulting in a wxlink update _and_ an empty task branch in the wxlinked repo. This keeps perpetuating itself as long as there are overlapping task branches. Here is the first situation where it becomes obvious that there is a problem: Screenshot 1 shows, that I am on /main/A2_2_task003, with no local changes. I am about to merge from /main to my branch, using the "Merge from this branch..." feature. Screenshot 2 shows, that the pending merge is about to update the cset for the wxlink. It is also going to change the branch expansion rule, despite there being no pending changes listed within the wxlinked repo. Screenshot 3 shows, that an additional branch has been created within the wxlinked repo. This branch is created when I start the "Merge from this branch..." operation. If I undo the merge changes, and delete the additional branch within the wxlinked repo, then I can recreate the problem over again. I will provide a snapshot of the two test repos to Codice via a support ticket.
  6. @M-Pixel I have tried following the repro steps that you posted in the Uservoice to see whether it really is the same problem as I have been seeing. However, from what I can tell, the "good" and the "bad" case in the uservoice are identical procedures. There's a numbering mistake in the "bad" case and the wording for the xlink creation step is different -- but, again, I can't tell any functional difference between "good" and "bad". Can you please clarify this?
  7. All the commits in the Xlinked repo are empty. I will file a support ticket for further troubleshooting.
  8. Hi, you should be aware that GitSync (synchronization directly between a Git repo and a Plastic repo) has some surprising limitations: , For your use case, GitServer (allows you to use a Git client to work against a Plastic repo) sounds more like what you want to use. I haven't tried it myself. You may however find that you are happy working directly with the Plastic SCM client. You get light-weight branches, you get a reasonable GUI client, you get good diff views, you get a good history view. People who want to rewrite their commit history before pushing may find Plastic limiting. Personally I'm happy with Plastic's model; strong GUI client + lightweight branches covers most of my (and my colleagues') needs. There are indeed locks. Be aware that Plastic doesn't support travelling locks yet ( https://plasticscm.uservoice.com/forums/15467-general/suggestions/37148053-go-ahead-and-implement-traveling-locks ) but as long as your artists stay on /main all the time and work "mostly like P4" they should be good. Our art staff use branches, do not use locking, and manage to avoid stepping on each others toes for the most part... but it is not for everyone. We keep dumping stuff into Plastic Cloud perpetually, and haven't really considered doing anything else, because the pricing for extra GBs of cloud storage (https://www.plasticscm.com/cloud/pricing) is relatively cheap for a commercial operation. How much space do we use? I don't know, 300-500GB I guess?
  9. You can do it with the current UI: First, use click + shift-click to mark a range of files. (You get a blue box type mark over each of the marked files.) Then, click in the checked/unchecked-boxes next to one of the marked files. All files the marked files will change their checked/unchecked-status to match that of the file whose checked/unchecked-box you just changed.
  10. Carlos, you misunderstand me. What you describe above makes total sense. However, my situation is different: I never change any files that belong to the Xlinked repo, yet Plastic (sometimes, not always) creates commits within the xlinked repo. This seems to happen either in none of the xlinked repos, or in all 5 xlinked repos - never 1,2,3 or 4 of them. I do not have a good repro case for this either; I suspect it is something that happens when many people are working concurrently (and make good use of branches) within the same main repository. Perhaps our main repo and/or sub-repos have ended up in a bad state? I do not know.
  11. What you describe does not match my experience. 1. I created a "/main/task001" branch in my parent repo. 2. I made changes in my parent repo. 3. I probably merged from "/main" to "/main/task001" while working in my parent repo. At this point, sometimes I see updates to the xlinked sub-repositories. 4. I was done with my task, so I merged from "/main/task001" to "/main" in my parent repo. At this point, sometimes I see updates to the xlinked sub-repositories. I never made any intentional changes to anything in a sub-repo. This is still resulting in new branches & changesets within sub-repos.
  12. Hi, we have a repository which the entire team works within, and then we have 5 sub-repos that are wxlinked within the parent repository. People are normally working within the parent repository only -- changes within the sub-repos are very rare. For some reason which we do not understand, when people work normally in the parent repository, corresponding branches are being created with empty changesets within the sub-repos. This pollutes history within the sub-repos, causes confusion ("what are these extra 5 items in this merge?"), and makes the Incoming Changes view fail (it doesn't handle merges in sub-repos). If possible, we would like to find out why these empty changesets & extra branches appear in the sub-repos -- and, if possible, stop them from appearing in the future. I'm not sure exactly about the conditions under which this happens. I find it difficult to reproduce on my own, when there is no activity from others in the repository. For example, I tried this just now, and it did not happen: I created a child branch, checked in a change into that child branch, merged up from child to parent, checked in a change into the parent branch, merged from parent to child. I think it is much more likely to show up if there is concurrent activity from users. (Not necessarily two operations running at the same time, but perhaps two branches need to exist with partial overlap in time.) One thing that I have noticed is that whenever this happens, all 5 sub-repos will end up with branches & blank commits, and during subsequent merges all 5 wxlinks will then get updated. If I look back through history there doesn't seem to be any cases where 1, 2, 3 or 4 sub-repos are affected; it's either all or nothing. If I look at the Branch Explorer within one of these sub-repos, it becomes evident that the empty changesets are strictly related to merge operations (see attached image). To put some numbers on this, there are ~20 developers working within the parent repository. Between Feb 11th and today there have been about 650 branches in the parent repository, and about 430 branches in each of those sub-repos (out of which 99% are unintentional and contain empty changesets).
  13. We are in a similar situation. We have chosen to put data into different repositories with names like 'OurGame.UnityProject', 'OurGame.SourceAssets' etc. Then we use the Plastic SCM against the game project, and Gluon against the source assets repo. Gluon allows partial workspaces (choose which folders to sync). We do not use replication & distributed workflows at all, so I don't know how that would fare together with partial workspaces.
  14. I like a lot of the changes that you are planning. Here is one thing that I have noticed with the current design, which I'm not sure whether the new design improves upon: I have found it strange that all tab-views have to exist within the context of a workspace. Whenever I work with Plastic I often end up with a tab list like this: The first three tabs are related to the current workspace. So far so good. The last three tabs are entirely unrelated to the current workspace. I wanted to browse the history of an unrelated repository - but the only way for me to do so, is to open a "Cloud repositories" tab, and subsequent detail views for the cloud-side repository, within the current workspace's view. I keep doing this a lot. I keep cleaning up my tab list (carefully) a lot. The first thing that feels unnatural to me is that "Cloud repositories" opens as a tab within a Workspace view. The second thing that feels unnatural to me is that if I begin to drill down into another repository, the additional tabs continue to open up within a Workspace view. If there was a way for me to get a new view - possibly in the top-left workspace selector - which is tied to the (serverside) repository I have chosen, and not to any workspace, then I would set up a couple of tabs within that view, I would keep that view around for a long time. ========================================================= Summary: I would like to be able to create workspace-less views. For example, imagine that there was an "Open repository" alternative at the bottom of this dropdown: The "Open repository" option would ask me to choose a repository, either on my local server or on the cloud side. After choosing a repository, I would then have access to a subset of tabs within that view (only the tabs that make sense when browsing without an associated workspace). I would set up a couple of these workspace-less views, for projects that I don't actively work on but follow discussions on, and keep those views for a long time. This would reduce the amount of time I spend creating & cleaning up tabs.
  15. Branch, upgrade, merge back to /main. You want to keep check-in history past the upgrade point.
  • Create New...