Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by psantosl

  1. 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
  2. psantosl

    sync bug

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

    sync bug

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

    sync bug

    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:
  5. psantosl

    sync bug

    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
  6. 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.
  7. 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?
  8. 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?
  9. 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.
  10. 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.
  11. Sorry for this, I'll try to get this configured properly.
  12. 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
  13. Hi Fpf6fUVROGDdA4TCp, Can you update and use a more real name? 🙂
  14. Hi! You just have to use cm history filename And you are done!
  15. 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 🙂
  16. Do you mean something like the cm log command?
  17. 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.
  18. 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?
  19. Hi! You mean when you create a new workspace go directly to the configuration mode?
  20. 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.
  21. 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?
  22. Thanks Mikael! We don't store owl data on the server, probably we should, to avoid these situations.
  23. 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.
  • Create New...