Jump to content

MikeK

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About MikeK

  • Rank
    Newbie
  1. Hello. I evaluate PlasticSCM. I cannot find a setting in PlasticSCM Visual Studio 2019 integration that sets the Visual Studio to pop-up a confirmation window if I really want to check out the file I am going to modify. The plugin just checks out the file automatically. Does such a setting exist? Just a short explanation to prevent possible questions why would I need it. The PlasticSCM does realize the checkout workflow so I can be sure that I will not change something unexpectedly while jumping through the different source files in the VS debugger for example. But if the VS PlasticSCM plug-in checks out files automatically and silently then it means the plug-in does away with such workflow as if it does not exist. Thank you in advance.
  2. I thank you for your quick replies. I do see the UTF16LE strings “branchexplorer.cfg”, “dag_mergelinks” (the only one that mentions your docs referenced above) and “show_parent_to_child_arrows” in PlasticSCM\client\plasticgui.dll and PlasticSCM\client\plasticnet2.dll, so, I have double checked it that it is branchexplorer.cfg and not branchexplorer.conf, but it does not work. I have put the branchexplorer.cfg into the client directory.
  3. Hello. I evaluate the PlasticSCM and I try to invent a trunk-based development and release management with it. I see the release management and the development as the separate repository for every separately versioned component that I have with top-level branches for the release management. So, I have component AAA trunk (I have to rename the default main branch because the development is trunk-based and not main-based) and AAA1.0 top-level release branch. I do not know if I do it right (as it is expected with the PlasticSCM) but so far, it is good for me. The problem is that I find PlasticSCM workspaces a kind of cumbersome to handle AAA trunk I develop and AAA1.0 I support/maintain. I have gotten used to have separate workspaces to handle such situation in Perforce so I can have and, say, debug XXX/AAA/trunk and XXX/AAA/AAA1.0 simultaneously (I run two debuggers at the same time literally) and I am absolutely sure XXX/AAA/AAA1.0 will never contain trunk and vice versa. PlasticSCM binds the workspace to the repository. And it binds the workspace not to a concrete branch within the repository (it is always trunk indeed). So to be able to repeat the trick with the two debuggers I need to be very attentive while creating two workspaces and then switching them to the appropriate branches. I see that switching the workspace to a different branch may be useful for what you call child-branches but for a top-level branch, personally I would prefer a path on my filesystem that would never coincide with another top-level branch location. But probably there is another, better way for the release management with the PlasticSCM than top-level branches. -- Mike P.S. And your arrows in the branch explorer are almost the blocker for me. I have read your explanation but I do not care if graphs are acyclic or not – I see the arrows as the dataflow and the fact that some of your arrows are the directions of the graph edges and the others (merges) are the dataflows hurts me nearly physically.
×
×
  • Create New...