psantosl

Wow, this is a weird one. Check the server logs. Maybe plastic.errors.log.txt gives us a hint.

Hi, You can achieve that using the command line, where you can do "cm mv" even after the move was actually done. From the GUI, you can do the moves "beforehand" using CTRL-X/CTRL-V in the Workspace Explorer. Now, would you mind sharing why the move detection didn't work fine for you? Thanks, pablo

Hi, We don't allow to do that, but it is certainly doable removing the creds entry from client.conf. Maybe you can create a small script that removes that config part every few minutes. BUT, you'd have to close the GUI. Makes sense?

Hi Marc, First, very sorry for this issue. I take full responsibility on this because this is a known bug that I personally decided not to fix yet. Now, here goes a workaround. Go to your workspace. Go into the hidden directory .plastic. Show me your plastic.selector. It must be a branch, not a changeset. Does it look like this? >type plastic.selector rep "quake@localhost:6060" path "/" smartbranch "/main" If it does, you are good to go. If not, remove the "changeset" part and leave the branch. Close your GUIs. Delete (or backup) the plastic.wktree file inside this plastic hidden directory. This is the workspace metadata, and the one causing the problem. Now open the GUI, go to workspace explorer and click "update". Plastic will rehash your files, won't download much, and you'll be good to go. Let me know if it helps. pablo

Hi Elite PopCorn, Unfortunately no, we don't have an amend option. But, yes, more and more people is asking for it. In fact, I'd like to track somehow how many are really interested: why don't you vote here? https://plasticscm.uservoice.com/forums/15467-general/suggestions/5221214-amend-commits

Thanks for the kind words. It is extremely encouraging for the entire team that you take a minute to share such kind words. Thanks.

Hey, No, no worries. Underneath Xlinks use GUIDs 😉

Are you using Jet as backend? (I bet you do). If so, it is possible to simply "copy" the repo. That being said: you are better served by GUIDs than changeset ids for embedding the number in the executable. We should rethink the clone to preserve the numbers (no reason not to, initially) but it would be a major redesign. I'm not saying it is not worth (it is, you are right in your points), but I'm not sure we'll be able to deal with it shortly. Would it be possible for you to embed the GUIDs instead of the csetid? This is what we do ourselves:

Hi, Is this second diagram the result of a single replica? Or many? It is not usual to see newer csets having older numbers, but it is not impossible. Now, if you use a single repo, then changeset numbers are relevant. BUT, if you are in a distributed scenario, you should only care about GUIDs. Why? Because it is not possible to preserve the sequence, so we don't even try. Suppose you start with changesets 0, 1, 2. You push to a different repo. Now both have 0,1,2. Now both create a new changeset on each side. It would be 3 on both. When you replicate again, the "3" in one of the sides will be "4" in the other. There is no way to keep the same number. That's why we fallback to GUIDs (which are in fact the real IDs used by replica behind the scenes). We certainly could do a bigger effort to try to preserve the same changeset ids when possible (replica to a clean repo) but our algorithm is not taking that into account for various (non-trivial) reasons. During sync, branches are replicated one by one, with no particular order. It means a newer branch could be pushed first, taking some changeset numbers, and then later an older one is pushed, and it will use newer cset ids. That's why the cset ids while unique, are not very relevant. Thanks, pablo

What if you rename the repo? That's the reason why we used ids instead of names. Renaming a database is an extra step (and extra permission) you need. So, at this point, there is no way to replace ids by names, I'm afraid.

Yes, it is doable 🙂

Should be fixed now.

You are right! The check should be in bar.c, not foo.c Hey! Thanks for reading and sharing. Send me an email to pablo@plasticscm.com and I'll send you a printed copy once we finally go for print (still fixing a few bugs). Also, I'm so glad to find you are reading it :P. How much did you like it so far?

There is another option: yes, you can create top level branches: To achieve what you want (although, it is more a naming convention than anything else, since the branch will still start from a given point). But then both projects will live in the same repo (which is not such a big issue anyway). I wouldn't go for Xlinks to achieve what you want. Does it help?

Hi, You should write a blogpost once you figure out the solution 🙂 Coincidentally, I wrote something similar for a customer yesterday. Similar, not exactly the same. You can create an empty branch, then push this empty branch to a second repo. And continue devel from there. You'll be able to access most of the history (not the individual branches, though, since you are not replicating them). And you'd be able to push/pull changes if needed. But, I'm sorry, your desired "changeset 3000" wouldn't be there because cset number would go back to zero. Honestly, cset numbers are not so important these days for many now that GUIDs and SHA are there.

This is totally possible if you create "submodules" or simply repos inside repos. Try creating repo main, then main/subrepo and this will happen by default. That being said: we are recommending all our customers to move away from SQL-xxx into Jet, our ad-hoc highly optimized backend.

Sorry for this, I'll try to get this configured properly.

Hi FpffUVROGDdATCp, Yes, I greatly appreciate when our forum users take the time to show up as real persons, instead of hiding names. We have to prioritize answers, and we normally skip handles with weird names since they tend to be spam. That being said: we never ended implementing binary deltas. It has been in the backlog for a long time but, well, we always have more important things in the list, it seems. So, we still split big files in 4MB chunks and store these separately. What is your actual concern with this? Thanks! pablo

Hi Fpf6fUVROGDdA4TCp, Can you update and use a more real name? 🙂

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.

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?

Thanks Mikael! We don't store owl data on the server, probably we should, to avoid these situations.

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!

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 🙂

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.