-
Posts
989 -
Joined
-
Last visited
-
Days Won
26
Everything posted by psantosl
-
Wow! Quite detailed. Could you draw (by hand if needed) how do you imagine the resulting Branch Explorer? I'm super interested @gweronimo
-
Can you use branches? Will they help? Or do you really need something else? The other option (I don't love it, though) would be to shelve changes instead of checkin, then validate, and only apply if approved. Even another option: * Work on a single branch (dev). * Cherry pick validated changes to main.
-
But what you propose is basically reinventing branches without branches π Make every person work on a task branch (super short ones), then someone validates, and the merge happens only if the task is validated.
-
No, I mean this @S_Luis The relayout config, where you can manually move branches, if this can be shared with all users.
-
@SWSBB how would you like to enter weights in branch attributes? Would that make sense? We could also use some file to give weights, but then people would complaint about GUI support. If we end up implementing custom weights, we could simply use a brex_weight special attribute that you can use for this. @mig any other idea you'd like better? I'm not sure it would be a widespread feature, anyway, because users need to configure their stuff. @jwvanderbeck this would also fix your "main" issue, I believe. But, in your case, you can easily move develop up with the relayout, right? @S_Luis can we put the relayout in global config already? Or is that yet in the wish list?
-
Just as a reminder to anyone visiting this: this is no longer an issue. If it was ever a problem (we are not even sure), it is no longer an issue. We tested wildcard certificates on our servers again today, and weren't able to repro any issues. No questions are asked to the user and everything seems to work fine.
-
Definitely not normal. I mean, we upgrade ALL the time and settings are not lost. Settings are stored under appdata/local/plastic4, and this folder is not touched by the upgrade. That being said, we can look into your case specifically, because this is definitely not what everyone else is experiencing.
-
Hi @Fauns What you describe sounds similar to what we explain here in detail: https://www.plasticscm.com/book/#_a_perfect_workflow Take a look, let me know if it rings a bell, and let's follow the conversation from there π pablo
-
Pending Changes is your friend, and cm status in command line.
-
Preventing locking across branches / forking
psantosl replied to Wouter's topic in Branching and merging
Hi @wouter, There are two things here: regarding the locks that get wrongly applied between repos, we are currently checking this. I think you also requested this in Zendesk. We are on it. Regarding your suggestion about keeping locks per branch: yes, it makes a lot of sense. I mean, it is not our final goal, we'd like to have locks applied between branches and released only when the file reaches a given branch in a given repo, but so far being able to keep locks per branch makes a lot of sense. Not sure, though, if we'll be able to develop it asap.- 21 replies
-
- exclusive checkout
- locks
-
(and 1 more)
Tagged with:
-
-
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
-
Top level branch from top level branch
psantosl replied to AaronV_NMR's topic in Branching and merging
Yes, I wanted to say changeset π -
Top level branch from top level branch
psantosl replied to AaronV_NMR's topic in Branching and merging
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 π -
Top level branch from top level branch
psantosl replied to AaronV_NMR's topic in Branching and merging
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 -
Top level branch from top level branch
psantosl replied to AaronV_NMR's topic in Branching and merging
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 -
Top level branch from top level branch
psantosl replied to AaronV_NMR's topic in Branching and merging
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 -
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
-
Hi Milan! Thank you for your kind words π
-
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.
-
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