Make the preference "Update and Checkin set files readonly" configurable per-workspace
I prefer the modify-commit scenario, and the majority of the projects and tools I use behave ok like that. However a couple of tools I use absolutely require the checkout-modify-commit (through SCC interface) . It is error-prone and annoying to have to change this option just when switching workspaces.
Ideally perhaps this should be configurable on a repository, ideally on a subtree, or even per file. as the project administrator can then protect the source code from attempts to get the mode wrong. On important binary files that cannot be merged, this could have serious consquences if a developer does not realise they do not have the file exclusively locked.
In fact one IDE I use, Visual Foxpro, requires exclusive checkouts on certain binary files (form ,report designs, class libraries) but simultaneously requires multiple checkouts on project metafiles (.PJM) extension. Perhaps doing this on file extension would work?
Walter Nicholls
shared this idea
Done.
-
Walter Nicholls
commented
HI Fernando .. don't know when you're going to read this, since I've read yours 18 months later!
I am aware of foxbin2prg , I have experimented with it, and you've done a really really good job. The more I looked the more I saw you had anticipated the issues I was encountering.With one exception which caused me to park my planned migration to it - lack of two-way DBF support. I did have a crack at implementing it to submit back to you. Perhaps I should dust that off.
( The other thing that would be useful is a way to hook code into plastic's checkin and export operations, so say a workspace update bringing down a new .sc2 automatically generates the .scx without me having to be aware. But that's asking for quite a bit out of plastic .. .lots of scenarios where it could break one way or another .. )
-
Fernando D. Bozzo
commented
Hi Walter, this is an old post, I know, but if you hopely read this, now you have FoxBin2Prg project on CodePlex, so now you don't need the readonly thing to emulate SourceSafe and now you can merge files like any other language.
-
JesusM
commented
Hi,
Now you can customize the readonly attribute of your workspace files when performing update and checkin operations,
and define exceptions to the main rule:
A) If you enable the "Update and Checkin operations set files as read-only" preference, you can create a file named "writable.conf"
and define file extensions that won't be affected by the preference, so the update and checkin won't set the readonly attribute on matching files.B) If you disable the "Update and Checkin operations set files as read-only" preference, you can create a file named "readonly.conf"
and define file extensions that will override the preference, so the update and checkin operations will set the readonly attribute on matching files.(The preference can be set/reset through PlasticSCM GUI: "Preferences >> Other options >> Update and Checkin operations set files as read-only").
(The location of the "writable.conf" or "readonly.conf" could be either the root of the workspace, the "%LOCALAPPDATA%\plastic4" folder,
or the folder where the cm.exe file is installed, that's it the PlasticSCM client install folder)
Example of writable.conf or readonly.conf file:
------------------------------------------
*.pdb
*.dll
*/obj/*
*/.metadata
------------------------------------------Also, maybe you are looking also for the exclusive checkout / locking feature for PlasticSCM on centralized/distrubuted scenarios. Please,
have a look at the following links:http://www.plasticscm.com/whats-new/checkout.aspx
http://www.plasticscm.net/index.php?/topic/459-exclusive-checkout/ -
There is an issue that the user must take into account: the SCC plugin requieres the preference set to readonly, so there are two possible scenarios to work with readonly.conf + SCC:
--> Set the preference as readonly and use writable.conf exceptions to configure which files you want to preserve protected as readonly. This option does not require readonly.conf at all.
--> Set the preference as non-readonly and configure a readonly.conf to set as readonly those files under your SCC-Plugin IDE project. This is necessary to detect changes. The issue here is that you would get a warning message every time the SCC Plugin starts because it detects that the readonly pref. is not set. -
This is now available in Plastic SCM 4.1.10.445!!
Added new configuration file: "readonly.conf" that follows the same pattern oriented syntax as "ignore.conf" or "writable.conf". When the option in the client GUI "Update and Checkin operations set files as read-only" is disabled, the files specified in "readonly.conf" will be set as readonly. Take into account that if a file is matched by any pattern in both "readonly.conf" and in "writable.conf", the "writable.conf" is preferred, and it will remain writable.
-
Walter Nicholls
commented
Looks like the situation with VFP might be worse than this however.
-
Walter Nicholls
commented
Per-workspace would resolve 90% of the pain. I don't know how easy it would be to slip in, you don't seem to have a workspace preferences system (except for ignored.conf,cloaked.conf).
However ultimately the rule for this surely comes down to filetype? Merging is surely more preferable for the vast majority of files, but every project has some binary files which cannot be merged. You may be able to diff two JPEGs and possible even come up with some image-merging algorithm, but there are always going to be file types for which merge is not an option, and are too important to allow multiple developers to tinker with them.
While Visual Foxpro is theoretically a discontinued product, a huge amount of business-critical software is still being actively maintained and developed using this platform and it won't be gone any time soon.
In the case of Visual Foxpro, we might for example allow text-based files - *.pjm, *.prg, *.h - to be modify-commit, but require exclusive checkout on *.sc*, *.vc*, *.mn* and all graphics files.
Even [the oft-reviled] Visual SourceSafe - about the only SCM tool that VFP behaves perfectly with - was able to do this,
Without this ability, it would seem that Plastic SCM is completely unable to be used with Visual Foxpro where more than one developer (in fact, more than one workspace) accesses the same project.