I work with Synergy 7.1 (web interface only).
For one of my project, it will be necessary to show the version of all files or a lot of files inside the work area. With the GUI, it's possible to modify the option to see the "project-specific in work area path". But, does it possible to make the same for all files?
Thank you for your help.
Frédéric
Hi Frédéric,
The project-specific part of the work area path is a setting called [i]project_subdir_template[/i] and this is a work area property. Only projects use work area properties.
The Synergy GUI shows the versions of objects in projects by default. You can list the files and their versions in a work area path using the [i]ccm ls[/i] or [i]ccm dir[/i] command.
Regards,
David.
Ok, thank you.
But, for a compiler, it's nessary to see the version file in the work area. The compiler is not connected to synergy and wants to know the version of each file.
Hi Frédéric,
I don't understand why a compiler cares about an attribute such as version stored in a separate CM tool. If you want to include some identification so that you can later determine which version of a source file was used to compile or build a library, DLL, or executable, you can use Synergy keywords in the header of that source code file.
If you have a build script that wants to pass in the version string as some kind of parameter to a build tool, then a build script using Unix shell script could do something like:
version=`ccm attr -s version pathOfSourceFileInMaintainedWorkArea`
and then pass in the contents of that shell variable into the tool's command line.
Regards,
David.
Thank you David,
I discuss with the developer’s team to see how their tools work and the possibility to changes it.
For information, these Java development made by several teams and each uses the other libraries. They use the version to implement backward compatibility.
Unfortunately, the development was without configuration management and I try to correct this
Regard,
Frédéric
Hmm, then it is not the file version(s) you need to compile into the library.
We use to compile a baseline name into our binaries. How it is done:
A perl script is called from the build job. If we are building in a prep project, a version string is derived from the current baseline (somthing-1104.3 is followed by something-1104.4) and compiled in. If that kit passes build and test, a baseline with the same name is created, and the binaries can be distributed. - If it fails, the build manager is responsible, that it goes nowhere.
When building inside a working project, the project name and version is used as version string.
Hi Frédéric,
There are several problems with using CM tool version identifier in the way you describe.
A change of version does not necessarily imply a change of its contractual interface. A later version that solely changes the private implementation of a class or method but keeps the same interface usually would not have any incompatibility issues.
Given solely an arbitrary version id, you can say nothing about whether that version is earlier, later or compatible with another version without understanding its history. For example, is version "5.1.1" earlier or later than "7"? The answer is it could be either, and simply knowing those two version strings doesn't allow you to determine it.
You cannot differentiate compile-time compatility from run-time binary compatibility. The use of serialVersionUID[ is the standard mechanism for serialization compatibility checking in Java.[
A common approach taken by APIs is to introduce an api version. That may be in addition to the serialVersionUID used on each class. Another technique sometimes used in Java is to use "reflection" to determine which contractual interface is in use in some other package.
Regards,
David.
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.