while testing the performance of PTC integrity via script using CLI calls, we do the following.
We are trying to create different versions of the project and gather the time taken to do so. For this the different versions of the project (contents) is available in seperate folders.
The script does the following
- Does a lock of the project
si lock --yes --recurse --cpid=:bypass
delete the contents of the sandbox, except the .pj file
copy the next version contents from the corresponding local copy to the sandbox. This simulates changes made to some artifacts in the sandbox.
Find Missing files , collect it in an array
si viewsandbox --batch --yes --recurse --sandbox= path\project.pj --filter=changed:missing --fields=name
Loop through the array above and drop each member
si drop --cpid=:bypass --yes --batch --sandbox=path\project.pj each_member
Check in all "changed" members/files
"si ci --recurse --nocheckinUnchanged --filter=changed:working ––nounexpand --cpid=:bypass --sandbox=path\project.pj --description="test"
Find non-members, collect it in arrat
si viewnonmembers --batch --yes --recurse --fields=absolutepath --sandbox= path\project.pj --cwd=path
Loop through the array and add each non-member
si add --createSubprojects --nounexpand --batch --cpid=:bypass --sandbox=path\project.pj each_non-member
unlock
si unlock --action=remove --yes --recurse
Create Check point.
si checkpoint --yes --sandbox=\project.pj --label=LabelName --description="test"
Above Steps are done for the number of such project versions that i need to create.
In the project policies, "Store text by Reference=true" is set.
Integrity version is 10.
Now my problem. : For each version of the project i am creating by the above steps, it is creating a new version for all files, irrespective it is changed or not. When member history is viewed for such files, it does not show any difference between 2 versions created. Have you faced this problem?
this is 'cause you delete all your files in the sandbox. The new files have a different time stamp and therefore PTC regards them as new. There is no real DIFF made by PTC, afaik it checks only the timestamp(last change).
All i can think of is, only delete files that have changed.
You can configure your sandbox to check diff by checksum.
This can/shall be set by default for all Sandboxes by your Admin.
Related
Is there a way to update the member revision of a big list of files via command line?
I can't use :working or :head but have to specify a different revision for each file.
As far as I know --selectionFile only takes paths as input, but not the revision numbers.
edit: I wanted to set member a very big list of files and I wanted to avoid writing the command si updaterevision ... for every file, as it takes ages to complete for that many files. Instead I wanted to know if there is a more advanced method to specify a list of files and their revisions to be able to run the updaterevision only once (like it is with :working) for the whole list of files.
But as it is said in the comment there is no such possibility.
edit2: I use MKS for a couple of years now and as I now know, there is no such possibility (at least up to MKS 11.6) to update many files to different revisions with one single command line call. But using one call per member, as was proposed, made the whole operation take up to several hours as I had many thousands of members in the sandbox and MKS needs some time to complete each sicommand.
Some time already passed since you asked for this question, here is my comment in case it could still be useful for you in the future.
First, It is not completely clear what you want to achieve. Please be more descriptive and if possible provide example.
What I understand as of now is you need to set bunch of files listed as member revision thru the command line. This is fairly simple, the most complicated is actually to have the list of files to be updated to member and the revision that you want to set as member.
I recommend you to create a batch file with the commands to make each file member. You can use Regex to do it very quick and without much trouble.
Here is an example for updating one file member revision:
si updaterevision --hostname=servername --port=portnumber --user=username --changepackageid=5873763:2 --revision=:working myfile_a1.c
where
servername = the name of the server where your sandbox is located
portnumber = the port that provides access to the server for your sandbox
username = your login user id
changepackageid = here you change the number to use your defined TASK:ChangePackage for this changes
revision = if you have a working revision that you want now to become member, just use "working" as revision, otherwise you can define specific revision number, e.g. revision=1.2
At the end you define the name of the file you want to update.
Go to you sandbox root folder, open CMD window, and run the batch file. It will execute each line applying your changes.
If you have a list of files with the revision you want as member, you can use REGEX to convert it into a batch file.
Example list of files in text file:
file1.c 1.10
file3.c 1.19
sec_file1.c 1.1.2.1
support.h 1.7
Use notepad++ or other text editor with regex support and run this search:
Once you know which regex apply, you can now use it in the notepad++ to do a simple search and replace:
Search = ([\w].[\D])\s+([\d.]+).*
Replace = si updaterevision --hostname=servername --port=portnum --user=userid --changepackageid=6123933:4 --revision=\2 \1
\1 => FileName
\2 => File revision
See image below as example:
Finally just save doc as batch file and run it.
Just speculating that if you have a large list of members along with the member revision you want to update to, then you also have an sandbox that served you to generate this list.
If so my approach would be
c:\MySandbox> si updaterevision --recurse --revision=:working
If your member/revision list come from a development path you could first have a sandbox targeting that devpath, resync, (close thesandbox if opened in gui), retarget the sandbox to the destination devpath (or mainline) you want and then issue the command above.
For an single member approach I would use 'si rlog' to generate a list of si-commands directly
si rlog -R --noheaderformat --notrailerformat --revision=:working --format="si updaterevision {membername} --revision={revision}\r\n" > updaterevs.bat.txt
Review updaterevs.bat.txt rename it to updaterevs.bat and ecxecute it.
(Be careful if using it on other sandboxes)
Other interesting readings here might be the "snapshot sandbox" feature,
checkpointing in general and variants rsp. devpaths.
Using only these features might be politically more correct in the philosophy of Integrity.
I know that I can use the CLI command si viewrevision to get the content of a versioned file. Downside is that this file must not be dropped.
Does anyone know a way (other than addfromarchive) to get the content when knowing the archive?
I don't believe this is possible
si projectco is documented as "checks out members of a project into working files". If you drop the member from the project, it is no longer part of the project.
At first blush, si viewrevision doesn't explicitly state in the documentation that it requires a project, but if you try to run the command without a project (or a sandbox, which implies a project), you will be prompted for one. Failing to provide one at the prompt exits the command with the message 'A value for "--project" is required.' I tried doing this specifying a change package ID which the member was part of, and that still doesn't work.
Your si addfromarchive option is the only published way to do this.
Disclosure: I am a PTC employee.
Why not use add from archive?
You could also use a temporary server location (S:/Server/prj_tmp/project.pj)
as destination and the member will stay dropped in the original project.
(Ok, ok, someone could create a sandbox from S:/Server/prj_tmp/project.pj and generate new versions in the archive of the dropped member, ad/delete labels ...)
There might be another possibility if your project has a checkpoint where the file was not yet dropped.
Just create a build sandbox with the project revision of that checkpoint and then:
C:\BuildSandboxes\prjA\src> si viewrevision ..... :)
.
You might also use something like
C:\Sandboxes\prjA\src> si configuresubproject --subprojectRevision=1.2 --type=build project.pj
view your revision and then go back with
C:\Sandboxes\prjA\src> si configuresubproject --type=default project.pj
but this might affect user that are currently working on the project. (eg. they would not be able to check in while the subproject is configured as build)
I'm using autotools to package my software and compile. The problem I'm having is that during the installation process, I'm creating a folder in /etc/myapp and in that folder I'm placing several files that I need. In addition, when my software is running, I'm generating files and storing them in that same location (/etc/myapp). When I execute "sudo make uninstall", all of the files that were initially installed by using "sudo make install" are removed from /etc/myapp. However, the files that are generated by the software and store in that same spot are not removed and now I have left over files.
Where in the Makefile.am files would I specify to remove the entire /etc/myapp folder during the uninstall process?
FYI, I'm using Ubuntu 12.
Thank you
D
In your Makefile.am, you can create a target named uninstall-hook which will delete your generated files:
uninstall-hook:
rm -f $(DESTDIR)$(datadir)/my_generated_file $(DESTDIR)$(datadir)/my_other_generated_file
Or even:
uninstall-hook:
rm -rf $(DESTDIR)$(datadir)
Your question involves more than just tooling; it involves policy. What type of files are you creating? If they can be lost over a reboot, they (probably) belong under /var/run/myapp. If they are data files, they probably belong in $(prefix)/share/myapp. I say "probably" because it depends on the platform, and the user. Most debian users will want such files in the locations I mention above, but they may have reasons for putting them elsewhere. The important point is that it is the user's choice, not yours. As the package maintainer, you don't get to choose /etc/myapp. You need to configure your package to make those choices available to the user. The typical way to do that is to use automake's _DATA primaries and the 'sysconfdir', 'sharedstatedir', 'localstatedir', and 'pkgdatadir' family of variables.
I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.
I am distributing one of my applications using a .deb package, but have a problem relating to one of the files.
The distribution includes a database file which is constantly updated by the app, on a fresh install I want the installer to copy a new, empty db file onto the users system, but on an upgrade I want the installer to leave the existing copy in place (overwriting it would result in all the users data getting lost).
Currently I have included the file in the 'conffiles' file, so the installer always asks the user whether to overwrite the existing file or not, but this isn't the behaviour I want - overwriting the file is never the right thing to do and I'm concerned that a user may pick the wrong option during an upgrade and hose their data.
Is there any way to tell the installer that if the db file already exists just leave it alone and don't ask the user what to do?
Yes, use a preinst/postinst script. The usual method is to name the file in the package with a special name ending with dpkg-new, for instance /var/lib/myapp/mydb.data.dpkg-new. Then write a 'postinst' script to put in the DEBIAN directory of your package to check for the existence of the database, and rename or delete the dpkg-new file accordingly, something like:
#!/bin/bash
if [ -f /var/lib/myapp/mydb.data ]; then
rm /var/lib/myapp/mydb.data.dpkg-new
else
mv /var/lib/myapp/mydb.data.dpkg-new /var/lib/myapp/mydb.data
fi