Jump to content

psantosl

Members
  • Posts

    989
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by psantosl

  1. Hey, the team will answer the bigger thread, but regarding the arrows:

    • Some people find it bad, most not, so we are not in a good position to change it, I'm afraid.
    • We have a setting (Windows only) to reverse the arrows and put them Git-like (which I find horrible, all pointing to parent). Maybe Carlos can share how. It is in a release note somewhere.

    Just for the sake of completeness, the link to the explanation of the merge arrows is here: https://www.plasticscm.com/book/#_arrow_direction

  2. I think he's describing a feature like Microsoft Symbol Server, that stores metadata of every binary generated and can later link it to a given set of binaries.

    We don't do that (at least not yet), but it is very easy to embed the cset number (the GUID) to the exe during build 🙂

    • Like 1
  3. Hi,

    Please understand this is not the regular workflow.

    The way to abandon locks is:

    • You checkout 100 files (probably not a common thing to do, anyway).
    • Then you delete your workspace.
    • Then your locks are lost.

    I would say, based on all our other customers, that abandoning a workspace with locks in it is not a common thing to do. Of course it can happen, and yes, of course we can have a better interface for handling that, but we consider this a rather corner case, otherwise we'd be running into it every single day, and fortunately we do not.

    Quote

    This is quite literally the worst source control product I've ever used.

    We are here to try to make our customers happy. If you really think Plastic is the worse version control you ever used, then my recommendation is: "please stop using it". I prefer that you are happy using a competitor than unhappy using us.

  4. Quote

    1. About repositories: I'm an indie dev, so I'm starting a lot of small projects, some for prototype something, some for game jams, some to create a lesson, and so on. Some of those projects I work alone, some in teams/groups, and some with friends. My doubt is: in git, I do this by having multiple directories with different contributors, what works perfect for my case, but here I don't found a similar solution, because if I understand it right all that I can have is different groups inside my organization, but this really does not seem right. Am I don't getting something, how can I organize projects in a more modular way here in plastic?

    Are you sure you use different directories in Git? Or do you mean you use different repositories? When you say Git you mean GitHub or GitLab, correct?

    In Plastic you should achieve this doing the same as in Git, different repositories. It is also possible to achieve it with directories, but AFAIK, this is not really possible in Git.

    While you can do it using permissions in Plastic, I strongly recommend you to use different repositories for your case.

     

    Quote

    2. About flow: In git I normally use git-flow, and there I have a stable branch that is a deployment branch, so I only pull/push to this branch when some features as ready or when sprints end, but in your book, you're suggesting short live branches that will merge all in the main branch and that I can make a label to identify what version is deployableMy doubt is: if I have, for instance, deployed my v1.0 in let's say Monday, and worked all week along with several short live branches in the week, so I have some snapshots that come after v1.0 but is not public yet so I don't update my version yet, and someone has found a bug in v1.0, so I need to work on a hotfix that in my branch need to comes after v1.0 generate a v1.1 but before my week snaps so when I ready to launch v1.2 I'll pull from v1.1 before a push to production. If I only create a snap from v1.0 I can create a label to this hot-fix and deploy it, but I can not merge in the main branch just before v1.2 come to play, and this does not sound right, is I misunderstand something?

    This is a very good question.

    Git-Flow is somehow considered outdated these days because it is an overcomplicated solution. You could implement exactly the same thing with Plastic if you want, no limitations, but I don't recommend it.

    Task branches + trunk based development is a much faster way to work, and much simpler.

    You can keep merging branches back to main during the entire week, then release at the end of the week if needed. OR, you could now release more often.

    Regarding the v1.0 fix: why don't you simply create a new version with the fix at the current stable state and release it? This is entirely possible. Just do the fix based on the latest on main, merge it back, release. Yes, the user will get some improvements too, but that's not an issue 🙂

    In case you really, really want to fix on top of v1.0:

    - You can create a branch out of v1.0
    - Fix it there.
    - Label the cset in that branch accordingly and release it.
    - Merge the fix branch back to main too, so the fix also goes into the next release.

    Hope it helps,

    pablo

  5. Hi Jep,

    I bet you are almost there, but we're failing to explain it correctly. Sorry for that.

    Let me know if this two things help you.

    1. I recorded a video explaining distributed vs centralized: 

     

     

    2. We have a section in the Plastic Book dedicated to this https://www.plasticscm.com/book/#_centralized_distributed

     

    In case none of these make it clear, just let me know, please 🙂

  6. Ok, but you're asking us different things on the same thread, correct??

     

    I mean, what @Tobix wants is a "view changesets of current branch" in the context menu on the status bar. I hear what you say, but unless we can cluster more requests I'm not sure we'll make it. Yes, I know what you want, but I honestly think the BrEx gives you that, because you should always see your current branch quite easily. I can understand this is not your favorite choice, but we need to keep a vision on the product, and BrEx is definitely our way to understand version control. I mean, once I'm on my branch on brex, just clicking on the csets gives me the diff and everything. Also, I don't know if you switch branch every 5 minutes, but since I don't think it is the case, you can always have an open list of csets for the current branch. So, opening a new one will not be probably something you do very often. Maybe we can have a query to show the csets of "current branch".

     

    Regarding Jan's proposal: ok, a home button there, it could be. But it would be the same number of clicks like in the brex, correct? They both have the same menu.

  7. Quote

    Is there a way to list all the repositories where a user has permissions?

    When you list repositories, you can only see the repos where you have list access.

    If you really need to know where you have checkin access, for instance, then you'd need to check the ACLs for each repo.

    So in short: there is no way to know "user has permissions" other than checking ACLs.

    Quote

    Or in general, list all the repositories with their users.

    You mean all the users who have access to a repo? No. Users are obtained from services like LDAP, for instance, so you could have users with access to a repo that never actually touched the repo, and the list of users is outside plastic (except for UP mode, but it is treated consistently as if it was external).

    See what I mean? there is no concept of "users of a repo", but simply there are users, and some of them have access.

    We have LDAP trees with tenths of thousands of users, and Plastic doesn't know about each of them.

     

    My question for you would be: what are you trying to achieve? Maybe we can help you if we understand that.

     

    Thanks,

     

    pablo

  8. Why would you associate a checkin number to an issue tracker instead of the branch?

     

    I'd recommend you taking a look at https://www.plasticscm.com/book/#_a_perfect_workflow

     

    Also, we have integration with some issue trackers that can do this association for you. And, you can always write a trigger to do this association. Or a trigger to pop up a dialog that does this :)

     

    But, popping up a dialog with the cset number is not something we'd like to do, because it would be disruptive for mostly everyone except you 🙂

  9. Hi @tino333

    You should use the date filter. The Branch Explorer is definitely not meant to draw the entire history under normal conditions:

     

    image.thumb.png.4279209c0a995d06f48a66ce1bd5fae4.png

    If I extend the filter back to 2005, when our repo history started, ours is also very slow.

     

    But if you just focus on the last week, everything will go fast.

     

    Now: one thing is redraw, the other refresh. It will probably take you 9 seconds to refresh, but then you can browse the entire graphic quite fast, dragging around. Correct?

×
×
  • Create New...