Jump to content

Stephen Taylor

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Stephen Taylor

  • Rank
    Member

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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.
  4. Do you think it would it be better to bring up a different warning dialog though rather than silently create this private.0 file?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Hi, We are using a cloaked.conf. If these files are cloaked by someone can you explain how this name_conflict might arise please? I know that even cloaked files can get download for client side comparison reasons I'm not fully aware off. Could this explain it in some way? Cheers, Stephen.
  10. We are seeing quite a lot of phantom files appearing in our merged changesets. That is when we do a merge there are files listed which haven't been touched at all in the branch we are merging into. They are legitimate files though. This ends up causing lots of problems where artists have to merge lots of code related files etc.. If binary files show up it can take a long time to process them, one at a time even though they haven't changed at all. Do you have any idea why this is happening? Cheers, Stephen.
  11. On merging from our main branch into a user branch the changelist lists some files with name_conflict in the file name. I've used 'Browse repository in this changeset' to look at the contents of the user branch before merging from main and the files in question don't already exist. I also look at the changeset in main and they are named correctly. After the merge and submit to the user branch the files have been changed to have name_conflict in them and the originals are no longer present. The name_conflict files are listed under Added (files added in the merge source) My question is how is this possible? I tried creating another changeset from our user branch before the merge was done and re did the merge to try and reproduce this issue. This time it was all fine, so I'm not sure what went wrong the first time? I have explored a few possibly explanations. 1. What happens if the file was already submitted to the other branch (which it wasn't). In this case I get an evil twin conflict. 2. What happens if the files that I would be getting in the merge were already on my machine but not submitted? I tried this with a txt file and I didn't get any warning conflict or renaming to name_conflict. What did happen though was the file I had locally disappeared in the merge and the contents were lost. When I submitted the merge the file contained what ever was coming down from main. There was .txt.private.0 file left on my machine though which contained the local txt I would have wanted to merge. So this also went wrong but in a different way. Cheers, Stephen.
×
×
  • Create New...