Jump to content

Wolfram

Members
  • Posts

    96
  • Joined

  • Last visited

  • Days Won

    1

Wolfram last won the day on August 5

Wolfram had the most liked content!

Recent Profile Visitors

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

Wolfram's Achievements

Rookie

Rookie (2/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

1

Reputation

  1. Well, we did not have a global filetypes.conf before the update, as the txt/binary detection was working very well then, even for the "uncommon" file extensions *.asset, *.unity, *.prefab used by Unity After the upgrade we did add a global filetypes.conf in the correct location, and it is also being correctly downloaded by the clients. The contents are: # Fichero de extensiones de Plastic SCM. Sintaxis: <expresión>:<tipo>. # Expresiones válidas son: .cpp, myfile.cpp ... Se pueden usar metacaracteres (*, ?) # El tipo puede ser 'txt' o 'bin'. # Ejemplos: # .cpp:txt # .jpg:bin *.anim:txt *.asset:txt *.cginc:txt *.controller:txt *.cs:txt *.csv:txt *.json:txt *.mask:txt *.mat:txt *.meta:txt *.md:txt *.prefab:txt *.preset:txt *.py:txt *.shader:txt *.unity:txt *.xml:txt This may have improved the detection for associated files under version control (I'm not sure, I don't have any negative feedback from this from our team at the moment) - but that file is apparently ignored for "Private" files, or even files already marked as "Added" but not yet checked in. This makes it quite difficult to review your changes before checking them in - especially if it also fails for definitely readable text files such as *.cs or *.json.
  2. Well, we often get changesets for already existing assets which are by themselves NOT modified in that changeset, but the FS permission changes from "NOT_DEFINED" to [...] are still being committed. It is not a bug or causes any problems - but it kindof "spams" the changesets with useless (for us) information, which makes it hard to compare changes. A solution could be to have a repository-wide setting whether to ignore or to use file system permissions.
  3. Hiho! We recently upgraded our server (and simultaneously all clients) from 9.0.16.4392 to 10.0.16.5882, and since then, many of our users report the problem that files in the Pending Changes that are CLEARLY text file are listed as binary, and thus cannot be reviewed. We already tried both the local and global filetypes.conf, but as it seem this does not help (=is ignored) for Private and/or Added files. Granted, these files cannot be diffed, as they are not (yet) in version control - but the User still wants to have these files DISPLAYED in the client, for review before committing them. Also, in the past the detection whether a file was txt or binary was working very reliably (even without filetypes.conf, which overrides auto-detection and forces either text or binary for ALL files with that file extension), so something seems to have changed between these two versions, which is now affecting the detection. As additional info, the files we are having problems with are usually Unity YAML files, such as *.asset, *.unity, *.prefab, and so on. => could you please either fix the regression with the txt/binary auto-detection, or if that is not possible, at least have the filetypes.conf also apply to Private/Added files (as opposed to only files already in version control)? Thank you very much! Cheers, Wolfram
  4. Correct. But it also seems like it does not communicate wth the server about the actual/current license state of the server: As I said, in 26972 it claimed everything was OK, when in fact the server had already revoked the current license (from the token - no plasticd.lic file present at that point!). So it is not possible to discern the current state of the server using the WebAdmin - which makes it rather useless for this task it is designed to do. :-/
  5. Come to think of it, I seem to remember that for ticket 26972, the WebAdmin in fact claimed everything was in order while the server had in fact NO valid license. It's as if it displayed independent info (such as, the presence of the *.lic files or simliar) and then evaluated that incorrectly, as opposed to actually communicating with the running server and checking its ACTUAL license state (which at that point had revoked the subscription license).
  6. Hi Carlos! Thanks for your reply! That's what I thought, and as I said, the server is running smoothly. This post was just to notify you that the state displayed in the WebAdmin is incorrect. In fact, when we had the original problem in July, the first thing I checked was the WebAdmin, and it claimed everything was in order and we had a valid license - this was really confusing! (I'm not entirely sure whether there was both an (old+inactive) plasticd.lic file and a current plasticd.token.lic file in /opt/plasticscm5/server when we had that problem). I now removed the expired+obsolete /opt/plasticscm5/server/plasticd.lic and restarted the server, and now the WebAdmin display matches the server info again, and the displayed expiration date has correctly been updated to 28-Aug-2021. You still might want to fix the WebAdmin display to reflect the actual server state, though - otherwise it is little helpful when trying to check for errors. Cheers, Wolfram
  7. Hiho. The license state shown in the Web Admin Interface does not match the actual state of the server. In July, our server lost the license (despite being configured to auto-renew) due to connection problems on your side (see resolved ticket 26972). I did not mention this then, but the whole time the web interface claimed the license was still valid, even when the server said it was not. As a quick-fix back then, I downloaded the license file manually and installed it on the server. The auto-renewal license token was/is still active at the same time. On July 28th, the manual license file expired. However, the server is still working correctly, recognizing our license subscription, as it apparently uses the auto-renewal token instead, so there was/is no problem in the workflow. HOWEVER, now the web interface shows the reverse situation: it claims the license has expired (which is true for the manual license file, but not for the auto-renewal/subscription), but the server is working correctly. It seems the evaluation order of license file vs. token file is inconsistent between server and web interface. EDIT: I should probably mention that we're currently on a rather old server version, 9.0.16.4392 .NET Core on Debian, but we're planning to upgrade to the current version tomorrow.
  8. Hiho. Apparently you are doing some form of syntax checking when displaying/diffing files. However, it is displaying incorrect errors for Python files (see screenshot). Since Python 3.6, there is a construct called "f-string" or "Literal String Interpolation", and the highlighted line of code is perfectly valid syntax. However, the diff window claims there is something wrong. Using 9.0.16.4392 Windows. Cheers, Wolfram
  9. Sorry, forgot the additional Info: Plastic GUI, Windows, 9.0.16.4392
  10. Hiho. Minor: In the diff window, for image comparison it is possible to zoom in (which is good), but when zoomed in, using the scroll wheel in the main area does not scroll the zoomed image up and down, as one would expect. More relevant: In the diff window, for the "Swipe" mode during image comparison, the swipe slider vanishes (=scrolls off screen) if you are zoomed in and are looking at the lower part of the image using the side scrollbar. Cheers, Wolfram
  11. Update: We recently moved our server to a different url, and since we used non-relative xlinks in our repos, using serveralias.conf is now mandatory for us. When entering the new server url in the preferences, in our team of 17 people, about 5-8 experienced this problem, the globalconfig of the new server was NOT downloaded. Restarting the client se4veral times, or even rebooting, did not help. We did find a reliable workaround that fixed the problem, though: Create a new workspace for an existing repository, and update that workspace so the repo's content is downloaded. After doing this, the globalconfig folder for the new server immediately appeared in the .plastic4 folder. Server version: 9.0.16.4392 .NET Core Client versions: 9.0.16.4392 or newer Connection to new server WITHOUT ssl (the old server used ssl, but we were for some reason unable to configure the ssl connection with the new server).
  12. If a file got deleted and one wants to see the file's history from a previous changeset, many changesets are missing from the diagram (example one: lots of deletes (on different branches) in the list history, but the last entry in the 2D view is changeset 1000. It gets worse: in another case, a file was modified on a subbranch of /main/nard1 (1819 and 1834) (=> note: the merge-back of these changes into /main/nard1 is NOT listed, which might be considered as another bug?), then moved, and finally deleted in 2190 (on a DIFFERENT subbranch of /main/nard1), which was then merged back to /main/nard1 in 2192. However, when looking at the 2D diagram - it is completely empty! NONE of the deletions are shown, and what's worse: not even the changes or moves in 1819 etc.! If the Toggle "Only relevant" is disabled, tons of "U" changesets are shown - but again, none of the deletes, and none of the changes and moves. I also attached my Branch Explorer options, which do not constrain the view in any relevant way. If I explicitly right-click on 1819 in the list history and "View history as 2D revision tree", this particular changeset suddenly appears (screenshot "example2d") - but the change in 1834, as well as others, are still not shown. Using 9.0.16.4078, but this bug has been around a long time. Also note: the list-history-view shows useless informations for deletions and moves in the "Branch" column (i.e., "file was deleted" and "file was moved"), instead of the branch name. This makes the attached lists 1a and 2a essentially unreadable, as there are tons of deletes, but you have no information on which branch they happened, and you cannot get any further with the right-click menu: it has only two entries for these cases, ""History: list of revision" (which just REOPENS the same, current list in another tab), and "View history as 2D revision tree (which is greyed out).
  13. Looking further into this, the description of the "Always select private files" is confusing: "selecting" suggests the square toggle to the left of the file is automatically applied to private files, for example when Plastic auto-selects candidates, or when you click "Check/Clear all", or select a subtree. But these files always get "selected", no matter whether this flag is set or not. The difference seems to be that if that flag is on, selected private files will be automatically ADDED/committed when committing, even when their status is still "Private". When it is off, they are ignored (=the old behaviour). BUT - and here comes the bug: this onyl works when these files are selected with "Check/clear all", or by selecting a parent directory. When you explicitly (or accidentally) select a single (or multiple) Private files, they will ALWAYS be committed, despite "Always select private files" being off.
×
×
  • Create New...