Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


psantosl last won the day on February 26

psantosl had the most liked content!

Community Reputation

35 Excellent

About psantosl

  • Rank
    CTO - Plastic SCM

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Interests
    plastic plastic plastic...

Recent Profile Visitors

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

  1. Hi! You just have to use cm history filename And you are done!
  2. This is what cm status gives: > cm status /main/refactor03@quake@localhost:6060 (cs:962 - head) Update to latest Plastic because we recently changed cm status 🙂
  3. Do you mean something like the cm log command?
  4. My question is: why do you checkin the lightmap if it can be rebaked? Because it is easier to share it through Plastic SCM than actually using other mechanism, correct? Understood. Of course this means you are in single branch, right. How would this work with multiple branches? The "super changeset" can be simply a labelled one. You know, you can label changesets. So the rule would be something like: Keep only 3 versions of LightingData.asset. Keep only N versions of files > that size except if they are labelled. I'm actually very interested on this topic, because it makes a lot of sense for us to add extra features for teams using Unity. I'll add more people to the conversation.
  5. Hi Marc, Thanks for the suggestion. What you says is: Your working copy size is smaller than repo size. Well, this is normal, as you pointed, the repo contains ALL revisions, while you only have a working copy. Repo stores revisions compressed, that's why initially it weighted less. You'd like to have a way to "discard history and keep only last N revisions" for certain files, correct?
  6. Hi! You mean when you create a new workspace go directly to the configuration mode?
  7. Hi, So, you want to discard BranchA, but you want to keep its name, correct? Well, simply rename BranchA to BranchA-abandoned, and then rename BranchB to BranchA. Does this help? I've experienced this a few times.
  8. Hi @AKB The reason is that Plastic Cloud uses a write-only storage for changeset trees, and then unlike on-premise, we can't delete them. We'd like to change it in the near future. That being said, deleting changesets *should* be something you don't have to do very often 🙂 Can you tell me more about why you find it so useful?
  9. Thanks Mikael! We don't store owl data on the server, probably we should, to avoid these situations.
  10. Well, it all comes down to how Plastic and Perforce differ internally. P4 does per-file merge tracking, we do per-changeset merge tracking. I explained it here in lot of detail here: https://www.plasticscm.com/book/#_merge_tracking The point is: per-file gives you the freedom to checkin a file even when the workspace is totally out of date and still merge. You pay a price for that: creating labels is super slow, creating branches is slow too, and merging is nowhere close as powerful. And distributed mode suffers from lack of efficiency too. We used to be per-file until 2011, for the first 5 years, and then we changed it. We are going to introduce some changes so you'll be able to do the same thing you do in Gluon inside regular plastic: merge only the files in conflict during checkin without having to update first (and without creating merge links). But it will still take a few months till we get there, because we have a ton of other things in the queue.
  11. Hello! I wrote a full book on Plastic a few months ago and I added a specific area exactly about this 🙂 I'd recommend you to take a look at this: https://www.plasticscm.com/book/#_partial_workspaces And also the intro to the chapter here: https://www.plasticscm.com/book/#_full_workspaces_vs_partial_workspaces In short: in "developer mode" (regular Plastic) you need to work in "changeset coherence mode", because otherwise you can't merge. It means when you checkin it asks you to basically update first: http://blog.plasticscm.com/2018/02/why-checkin-asks-to-update-first.html But you can achieve this behavior in Gluon: http://blog.plasticscm.com/2018/06/gluon-can-now-merge-story-of-version-control-for-games.html Sorry for all the links, but I really think they will give you the full picture. Please let me know if you still need help or need me to clarify things. pablo
  12. Hi Mikael, There is one thing you maybe didn't notice: When the dynamic help shows up, there is always a "got it, don't show again" button that will never show this specific message back to you. Can you share which are the messages that are not relevant for you? I ask this because we made the help system be context sensitive, so if you are not new to Plastic, it will not show you some basic messages, but it could be that we made some mistake or didn't tune it correctly. That being said: owls are not just to help newcomers. Look at this: This happens when I repeatedly click refresh. It is called "frustration detection" and figures out if there something wrong going on, and helps you solve the situation. It is also extremely helpful while doing merges and under many other circumstances. Please share which help messages do you find irrelevant, and we'll try to improve that area 🙂 Thanks!
  13. Hi David, Well, this thread now should be a good basis for a entire blogpost on the topic 🙂 This is what we do: For super small things, just a task that gets fixed and released asap. Nothing fancy. This is true for many of the tasks that enter our releases on a weekly basis. For big things we try to keep a full list of what needs to be done, and, we don't use the issue tracker for that. I was never comfortable with that approach. We create a list of everything that needs to be done (in a text file, an excel, whatever) and then start assigning a task number (enters the issue tracker) to each line as soon as we know we are going to really implement it. (This avoids wishful thinking and creating things that at the beginning sounded good but then never get implemented). Probably using an external list for this is pretty cheap, and we'd enter everything in Jira if we used Jira... but since our issue tracker is so simple, we simply don't do that. We toyed with the idea of implementing a way to group tasks, but to list things to be done... well, a list is better. That being said, last September we switched from Scrum to Kanban. We've been on Scrum for 13 years. It was sort of pure at first and then it decayed into something different. And then we decided to switch. And it has probed to work since: cycle-time (time from task open to merged and ready to deploy) was cut in half (from 9 days to 4.5 average), and everybody gained a more "team centric" vision. The contrary wasn't an issue with Scrum but us (or me). But the reality is that we changed. We were very, very focused on individual efficacy: avoid noise, avoid interruptions, everyone working on his list of tasks for the sprint (2 weeks each). But it had a downside: you prefer to "finish your list" instead of helping someone else. We changed that. We introduced a kanban board with work in progress limits (WIP limits, to me, the actual reason to use kanban, better than the panel): We use realtimeboard, so no, we don't use a tool that automates stuff or anything, we simply put stickers on a wall as we'd do manualy on a physical board. So, we can only have 13 tasks in implement (except lock, that doesn't count), 2 in review, 3 in validation. If you can't enter a new task because the panel reached the limit (13), then you have to review or validate. And this is good, because you don't focus on "your list" but on team progress. Of course, our hard-earned efficacy skills mean we try to be as good as possible on avoiding interruptions (we almost ditched Slack in favor of Basecamp, we don't use email for internal stuff but record everything in Basecamp, etc), and distractions and so on, but now with a sense of achievement when we move work forward. Now, onto your question: how to keep an eye on the big thing? This is what *I* do: 1. You can have a column with things to do for a big project (check the "unity" column on our kanban board). 2. You can have a cheap list. 3. It is the product manager or project manager job to make sure what we are doing is really adding value. 4. Frequent messages and communications to make sure we are on the same page (with a clear roadmap document, vision docu imagining the short term future, etc). I assume next question will be: how do you know N given tasks belong to the same project or big feature? I'm afraid my answer is going to disappoint you: just put a prefix. Look: And And this is how we do it. I don't mean this is the perfect way for everyone, but it works pretty well for a team our size 🙂
  14. Hi David, Why don't you give a try to the hosted Jira? You don't have to setup anything, which I believe is a great burden you can avoid 🙂 Regarding the issue tracker use, I'm going to share my own experience (I should write a blogpost). I think I am some sort of issue tracker hermit 😄 I normally don't even use the issue tracker integration in Plastic. What I do is to go to my issue tracker, pick up the task, then create a branch manually as follows: The only link I normally use is the "naming convention". You know SCM24074 is task 24074. That's all. We have done +24k tasks this way over the years 😄 I mean, I know it is an extremely simplistic approach, but what I love is that it is so vanilla, so simple, so bare, that it always works and you don't force anyone to go through integrations or anything. I mean, I do my checkins from the GUI, not from a plugin, so I might be a weird kind of programmer or something, but I really, really like to keep things super simple.
  15. Exactly, all delta implementations I'm aware of implement some sort of window schema, so you don't have to walk back a huge history. That's something we have in mind, and we did quite a good amount of research and study of Xdelta to apply it to binaries, but it is not in the top of the prio list, I'm afraid. 🙂
  • Create New...