Jump to content

psantosl

Members
  • Content Count

    927
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by psantosl

  1. But you don't need a workspace for cm ls. You can pass it "server side" paths. Use the --tree option. That's the key.
  2. Hi Mikael, I'm not sure if this will totally help, but why don't you try the cm ls --tree command? It lets you browse a given tree, even a given path or file on a tree, and you can find what was loaded on a given changeset. Run cm ls --help, here goes one of the examples: cm ls /code --tree=ae1390ed-7ce9-4ec3-a155-e5a61de0dc77@myrep@denver:7070 Let me know if it helps (I activated notification of replies this time, so it won't take that long to reply, sorry for that) pablo
  3. You can do a cm find revision and then filter by path with the item field, if I’m not mistaken. you can also check the history of the directory since the directory changes each time its children change, the result is quite easy to obtain
  4. But main always have an initial changeset with the root dir. also, if you create a branch from another one, they share the same location (like Git) but it is not dynamic or anything. So, not sure why you need the intermediate changeset πŸ˜‰
  5. Thanks for the details, Aaron. It is a real pleasure and privilege to learn more about version control from experienced users. Regarding this: What would be your desired behavior? We changed how branches worked in Plastic eons ago, and I'm always eager to know about other options. We used to have some sort of branch inheritance where you could make a change to a parent branch and then changes were dynamically propagated to children if they didn't collide, and I used to love it, but it was extremely confusing for mostly everyone. So, please, share what your ideal behavior would be. pablo
  6. Branches start from a changeset. That’s why an empty branch behaves this way. you can play with permissions to deny people creating child branches, or you can create triggers to control the branch hierarchy That being said: do you have a Perforce background? And, why do you need this complex branch hierarchy? Have you read about our recommended branching pattern? https://www.plasticscm.com/book/#_a_perfect_workflow
  7. Hi Aaron, A top level branch is just a namespace convention. You can create "develop" starting from "main", and it will be called "develop" if it is a top-level branch while it would be "main/develop" if it was an ordinary branch. Other than that, their behavior is EXACTLY the same. Please share more about what you would like to achieve so we can find a better solution. From here it sounds a little bit like "git flow" πŸ˜‰ and it is probably too many structure branches to me, but that's just an opinion πŸ˜‰ pablo
  8. Hi Fleer, Well, this is a pretty interesting topic. In fact, it is worth a blogpost and a chapter in the Plastic book. I just feel dumb I didn't write it. There are different possible options: a) An after-update trigger that launches the update under projects behind the scenes for them each time they update something. b) Force them to work with Plastic and work on the main branch => then they must update. But probably not a good choice. There are other options but they are more in the structure side of things, not really in "forcing users to update". Let me know if a) makes sense, and I'll share this with the team. pablo
  9. Hi Milan! Thank you for your kind words πŸ™‚
  10. Well, we *should* be good detecting moves, but we are better with code because then we can calculate similarity. We have a way to use the NTFS underlying logs to detect moves more precisely, but we never made it public.
  11. That's what you can customize: How do you move the pngs? Using some tool? Or directly in Explorer? If the latter, you can always use the Plastic Workspace Explorer for the moves
  12. Wow, this is a weird one. Check the server logs. Maybe plastic.errors.log.txt gives us a hint.
  13. 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
  14. 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?
  15. 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
  16. 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
  17. 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.
  18. psantosl

    sync bug

    Hey, No, no worries. Underneath Xlinks use GUIDs πŸ˜‰
  19. 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:
  20. 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
  21. 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.
  22. Yes, it is doable πŸ™‚
×
×
  • Create New...