Jump to content

nqramjets

Members
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by nqramjets

  1. Well this certainly would have helped!
  2. This is still an issue in 7.0.16.2637. Is this going to be addressed?? I cannot comment on new code.
  3. Hi @psantosl, I agree that there are lots of circles, but that's the portion which doesn't bother me so much. The one that bothers me is that the color of merge links have changed to a pastel cyan which is much more difficult to see. Ideally you guys would add this stuff to preferences, and we could customize the colors ourselves (like we can for 3-way merge highlighting). On a related note, I have changesets colored by team, and branches by deployment stage. For both of these cases when I highlight a branch or changeset it turns green. This interrupts my actual decision to color the
  4. @Smirov Are you using Active Directory authentication by chance? I tried to get our TFS to sync with Git a couldn't even get the cm sync command to run.
  5. Any ideas when it will get fixed? I have to currently disable triggers in order to allow users to approve code reviews without any comments (because it cannot be commented) This is an issue for our security audit, but is the only workaround I know of. I can also send a support request (we're an enterprise client) if that helps raise the priority at all.
  6. @manuThis feature has been voted all the way up to the first page on your UserVoice. It's time to get started!! ;-)
  7. Thanks for the reply Manu, the "cm ls" workaround might be another option we could use. We have a system which automatically applies the scripts and dynamically generates the file names. When the developer does not use the exact casing the cm getfile obviously can't find it. I also have to correct my statement that it was permanently broken, as I was able to rename the file through the Plastic UI, changing the casing of the file to match the filename exactly, and Plastic did pick this up as a Move and allowed me to check it in. So, it is at least fixable if/when this happens again,
  8. # Works :: cm getfile 'C:\build\scripts\Script\SqlScript_1.sql' # Works :: cm getfile 'C:\build\Scripts\Script\SqlScript_1.sql' # Broken :: cm getfile 'serverpath:/scripts/Script/SqlScript_1.sql#br:/main/ATO 1' # Broken :: cm getfile 'serverpath:/Scripts/Script/SQLScript_1.sql#br:/main/ATO 1' # Works :: cm getfile 'serverpath:/scripts/Script/SQLScript_1.sql#br:/main/ATO 1' PlasticSCM- In a Windows system using "cm getfile serverpath:/path/to/the.file" work only if the path is precisely that case. On a windows system both folder and file names are not case-sensitive, but this is not
  9. I have a personal license which just expired, so I logged into try and renew it, but there is nowhere in the "my licenses" area to request a new one, they just say "expired." I clicked through the "Buy a new license -> Free & Community" but I can only apply for a new one, which doesn't make sense since I've had one for ages. I guess I'm just saying, there's no apparent way to request a renewed license so I'm stuck! It's really a bummer too because I'm right in the middle of something at work, and can't sync with my home machine (we use Plastic at work) to get stuff done! Bah!
  10. Hi Manu, You know what would be another slick URL path, would be a showcodereview, but I don't know how you would specify it... There nothing obvious displayed in the UI. :-( Thanks, Ryan
  11. It's very handy for us to be able to send links to each other at my work which lead to a particular diff. Based on some old blog posts I tried to implement this the best I could but was having issues using the syntax indicated. (see this post: http://www.plasticscm.net/index.php?/topic/2491-jira-interactive-link-to-changeset/?hl=%2Bjira+%2Bplastic) To launch a diff use the following URLs (On Windows) Branch Diff: plastic://showbranch=br:<BranchPath>@<RepoName>@<Server:Port> Changeset Diff: plastic://showchangeset=cs:<Cset Number>@br:<Branch Path>
  12. Added this to UserVoice here: https://plasticscm.uservoice.com/forums/15467-general/suggestions/7072603-improve-checkin-trigger-information-to-include-pen Thanks, Ryan
  13. What we want to do is know where a commit came from (when merging). To say it another way, we want to know what the pending merge links are. We can't use the cset_id because this is not necessarily from the branch which was the source of the merge. I've read this post, but would prefer not to do this (partly because this would be a client-side trigger): http://www.plasticscm.net/index.php?/topic/1132-permissions-to-enforce-integration-rules/?hl=%2Bpending+%2Bmerge#entry6608 An alternative would be to use something like "cm status" to get the (Merge from 1234) and parse this, but ag
  14. Manu- How long does this application process usually take? I use PlasticSCM at work (love it by the way) and want to use it at home for my personal projects. I applied for a personal license a few days ago but haven't heard anything back. So, I'm just curious! I'm anxious to get started! Thanks, Ryan
  15. Some feedback on this would be very helpful. We have rules based on the owner of the branch which contains the changeset that I indicate in my previous comment. We are having problems, however, as the changeset that it provides does not always appear to come from the branch that was merged just before the commit. Thanks, Ryan
  16. Hi Carlos, a follow-up question: How is rev_id determined? We have a before-checkin trigger which is firing after a merge into our integration branch happens. It was my impression that the rev_id would be the changeset # that signified the most recent changeset in the history. My question is this: Does the changeset # that is provided always come from the most recent change to the file, or does it come from the changeset that is being committed? Thanks, Ryan
  17. For know we have a workaround by placing INSTEAD OF DELETE triggers on the object and review tables in SQL Server. This is obviously a kludge workaround, but perhaps we can remove them if reviews are ever secured.
  18. Hi Carlos, When editing a review that trigger works as I expect, but my problem is the developer *deleting* the review. It seems that the before-editreview trigger is not fired when the user deletes a code review. All I need to do is prevent user from deleting code reviews; the information in them is very valuable, but I can't figure out a way to prevent this using security, triggers, or any other means. Am I missing something? Thanks, Ryan
  19. Is there any way to secure code reviews? We had a developer accidentally delete a review and all information appears to be lost. I see no mechanism to prevent this from happening; it appears that the editreview trigger is not fired when deleting a code review. Does anyone have a workaround for this?? -Ryan
  20. Okay, thanks Manu. I just wanted to make sure I wasn't doing something completely wrong with the "i3" theme. Also, I guess it makes sense that changing the theme in VS simply causes the colors to change appropriately in the plugin. Okay, one final note: Id there a document anywhere which says what pieces of the GUI each color.conf item affects? Some of them are obvious, but some are not. I really love getting everything colored just right on my machine (and dark at that) so it would be really cool to be able to set one up exactly as I wanted. So far I keep setting things to bright
  21. Once again, sorry to hitchhike on an old thread, but I'm trying to try out the i3-blue theme, but receiving a popup that says "An error occurred processing your request" I'm attempting to launch it through the command line like so: plastic.exe --theme=i3-blue The only ones that I can get to work are i3 and windowsnative. Furthermore, does it not just look in the themes directory for a match? I copied the i3 directory and named it 'test', but attempting to launch plastic with this command results in the same error I mentioned earlier: plastic.exe --theme=test Is this not how this wo
  22. I see. It appears that the "branch of the revision" is the destination branch, not the branch the which contains the original changes. Is this simply always the same for every line in the stdin then? I guess it must be. I'm asking because I'd like to know if it's safe to only look at the first line to see if we're trying to check in to a particular branch. Thank you!
×
×
  • Create New...