Jump to content

Stephen Taylor

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Stephen Taylor

  • Rank

Recent Profile Visitors

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

  1. Thanks, I give it a try next time. It seamed to me that the dialog boxes that continue to pop up couldn't be cancelled but perhaps if I can get focus and cancel the whole merge it will stop them, I'm not sure until I see the dialogs again though.
  2. Thanks, often if you are not paying too much attention it can be too late to do this as you have already embarked on processing all the merges. Then there is no way to cancel and go back to do this process as you are faced with a never ending list of dialog pop ups asking which version you want to take.
  3. Currently when resolving a merge we might have hundreds of files which all need to be reolved the same way, e.g always take source. Once you start processing the merge we currently keep getting lots of pop up dialogs for each instance. Please can we have a button or tick box on the dialog to do this action of all the cases? Thanks.
  4. If she does as suggested above the file appears locally as a private file. It still doesn't register it already being under plaster source control. Different Artists aren't getting this issue. Thanks, Stephen.
  5. Hi, They are using Plastic SCM not Gluon. Is there a plastic SCM equivalent? What else could cause this in Plastic SCM?
  6. Hi, One of our artists has created a new work space and in one folder a particular .mb file isn't present, all the other .mb file are present. t's there if they browse the repository at the latest changeset submitted to main. There is no mention of this file in any ignore, cloaked of hidden_files file. If we look at the history of the file from the browse repository then non of the file changeslist numbers are in bold. There is nothing in their pending chnages. I.e no deletes. Updating the workspace doesn't fix it. Adding a new file to this folder and merging from main and it appears fine. What could be causing this? Thanks, Stephen.
  7. If some reverts a file it only shows the CL number in bold that it's been reverted to in the file history. This is confusing and it should dhow the CL number as the operation does have a CL which you can see in the branch view. This makes it difficult to look through the history and see someone has done a reversion. It is also not entirely obvious that the reversion is going to stick when merged in from another branch. The same can be said for a subtractive merge. We have just had a case where so changes were being reverted when merging from main and we couldn't understand why. It turns out that someone had done an accidental subtractive merge in another branch and subbed it to main. When looking in the file in questions history that operation wasn't visible so it was really hard to track. Please can subtractive merges and revertions be listed with a CL number just like any other operation to make tracking down this sort of thing easier. Thanks, Stephen.
  8. Maybe as a quick workaround for this problem you could you make sure a merge deletes any cloaked files on your machine if you have a cloaked.conf? This has already been shown to be a good work around as on a similar support tracker we have: https://plasticscmsupport.zendesk.com/hc/en-us/requests/16662 If this was done automatically it would greatly help us as we have had to turn off cloaking at the moment due to it is causing too many issues.
  9. Hi Pablo, Thank you for your reply but this doesn't really help. Even if merges to main are only done by CI/mergebot there are other situations that these fat branches occurs in other non-main branches. Do you have any plan to fix their creation or suggestion as to how to prevent them? If they occur we can no longer back out one change set as they all become atomically linked. Cheers, Stephen.
  10. Hi, It seems we are getting this fairly often. I'm sure if it is from exactly the same scenario you describe above though. Is there any fix in the works for this? It seems to me that since the file is cloaked (i.e shouldn't be there) you should be able to determine that we don't need to rename any files? At the very least you should get a dialog warning you of a name conflict rather than just renaming the file, as the out-come is that the original file is getting lost. Which file does it rename? The one from the server or your local file? Cheers, Stephen.
  11. Do you think it would it be better to bring up a different warning dialog though rather than silently create this private.0 file?
  12. Hi, So we have a folder cloaked: /art When merging from main to get latest in creates a pending change set ready to submit to my local branch. I can then sub this just fine. If however, I want to undo the merge instead we get an error (non specific) with some folders under /art which can't be undo. If we don't have the cloak then it all works just fine. Cheers, Stephen.
  13. Hi, There appears to be a few different ways to create something we call a fat branch (see attached image). This is when you are trying to merge your branch into another branch and it gets combined with a merge from another changeset in that branch since you weren't synced with the head of the branch when you merged. e.g 1. You are in main but not at the head. You do a merge from a different branch then checkin. You will see a dialog which will tell you there have been changes main to the branch you are in and do you want to merge with them. If you say OK then it will merge them in and submit to create a fat branch. 2. This can also happen if you do a merge to a branch and someone else does this at the exact same times. This is a server side merge but also creates a fat branch. 3. It will even happen if you are in a branch but not at the head and get latest from the same branch and submit. This happens a lot when people thing they are in their branch and get latest from main but were actually already in main. The problem this presents is should the merge to main break the build then we need to do a subtractive merge. This will effectively revert the changeset we merged to main and also revert the other merge changes that ended up getting combined into the fat branch (we didn't want it to do this). So my question is, what is that best way to handle this situation? Cheers, Stephen.
  14. Hi, We are using a cloaked.conf and Plastic GUI. My guess is the phantom files are the result of what we call fat branches. That is if you have submitted something into a branch but weren't at the head and you choose to merge in the latest changes with your submit then the changeset you submit is atomically linked with the merging of some other files. If you then had a conflicted in another branch with one of the files you submitted then could files which were combined via the merge also get listed as needing merging? Cheers, Stephen.
  15. Hi, If I merge from a branch which has the same file in it that I also have locally but not added, then the file from the branch I am merging from takes precedence and my local file gets renamed to myfile.private.0. Why doesn't this just create an evil twin conflict like it does if my local file had been submitted to my branch? Or at least pop up a dialog to get you to choose which file you want. Creating a private.0 file is not a very intuitive way of explaining what has happened. Cheers, Stephen.
  • Create New...