MikeK

> But it is also possible to checkout a file without locking feature enable, but I do not understand why this would be interesting? I find this feature extremely useful at least in following scenarios: 1) When you debug a big project with an IDE (like Visual Studio) its debugger jumps across different source files that are opened in the IDS's editor. You may occasionally hit a wrong button and change a file unintentionally. The IDE will save it on the next debugger "step" command, patch the executable (if edit-and-continue feature is available in the IDE) and continue to work as if nothing has happened. During the check out workflow the IDE will ask you if you really want to check out and modify the file. Unfortunately this scenario does not work for Plastic VS integration -- they check out files automatically and silently and are not interested in fair supporting the scenario. 2) With the check out workflow your server will report you if a file is opened for editing by someone else. In some cases you may care and this is just a little helper. 3) The client software can quickly report you what file was changed. You need some file system watching facilities otherwise and they are not that common. Or was not common recently. I believe one can invent a lot of other useful applications of the feature.

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.

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.

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.