In our development environment, we have certain files that are autogenerated by some parsing tools, and they should never be merged from one branch to another. We do have them under source control, however, so that only one user needs to run the generation tool for any given branch; all other users will get the generated files automatically.
Is there a way to tell "findmerge" to skip these files when it traverses the VOB? If findmerge cannot resolve the differences in a file, it loads the default diff tool so the user can resolve the differences manually. For these autogenerated files, this is a waste of time; the user just has to cancel it and then run the autogeneration tool when the findmerge is complete.
If it matters, we use dynamic views.
You might consider the same approach as with binary files
Your project manager can overcome this problem by creating a special element type for the binary file type and specifying one of the following mergetypes:
never: A merge or findmerge operation ignores versions whose element type has never as a mergetype.
So, as in this page, something like:
cleartool mkeltype -supertype file -mergetype never -nc FILE_NEVER_MERGE
And then, in the folder with your generated files (here for instance for XML files):
ct find path/to/generated -type f -ele "{eltype(xml)}" -exec "cleartool chtype -force FILE_NEVER_MERGE %CLEARCASE
Related
I need to replace a library in a perforce depot. The library is checked in in the form of source files which are all managed by perforce.
Now the problem is that in the new version of the library there may be
unchanged files
changed files
new files and
some files may have been deleted
Of course I can just mark the whole source tree for delete, submit, copy the new version of the library to the directory in question, mark for add and submit again, but that would create a short interval of time in which no one should synchronize in order to not break his next build -- maybe that's the best option but I'd like to know whether there is a better approach.
A second solution is to copy the new version of the library to some other directory, update all references in order to reflect the new location, and then just delete the old library and mark the new one for add. This can be done in one change list. The unpleasant and error prone part here is to update the references. Also a change in the directory names is not really desired.
Does anyone know a way to do this in one step with one changelist? I experimented with a single file example. It actually is possible to mark a file for delete and then immediately create a file with the same name and mark that for add. If you do that and submit, then the result is exactly what I want for that single file. This procedure, however, seems to require touching each file manually. I could not figure out how to do that for a whole directory or directory tree.
One possibility is to use p4 reconcile to do the majority of the work, using a process such as:
In your workspace, remove the current copy of the source tree entirely: rm -rf top-directory-name (or del /s /q if you're on Windows).
copy the entire new copy of the source tree for the library into that location.
Run p4 reconcile and let it figure out what files to open for add, for edit, and for delete. CAREFULLY inspect the results by looking closely at p4 opened, p4 diff, etc.
Submit the new changelist.
I'm working in a Windows dynamic view.
I am trying to create a tool shortcut using the ClearCase Menu Editor to automatically perform a 'mkelem' on all private files in my view.
I'm aware of 'cleartool lsprivate -other' to get a full path listing of all private files but I don't know how to feed that resulting list into the 'mkelem' command.
I'm also aware of the 'find' command and that at the end you can specific '-exec' to cause it to perform the additional action to be performed on the resulting list but once again I don't know what arguments to give to 'find' in order for it to only find view private files.
Can anyone help me with this?
Another approach I would consider/test is one I mentioned in "How can I use ClearCase to “add to source control …” recursively?", with clearfsimport.
I suspect clearfsimporting the view folder into the view itself should automatically add the private files, while keeping the existing files untouched. But, as commented, you would need to import in a new dynamic view (with same config spec) for that to work.
The problem with cleartool find is that it find versioned elements.
It can use %CLEARCASE_PN% or %CLEARCASE_XPN% as argument in its exec clause: that reference the pathname or extended pathname of already versioned element.
Well, it's complicated, because you would need to check out the parent directories before creating the elements.
Have you tried a command similar to this:
for /f "delims==" %x ('cleartool lsprivate -other') do #cleartool co -nc "%~px" & cleartool mkelem -mkpath -ci -c "autoadd" "%x" & cleartool ci -nc "%~px"
-mkpath makes any missing parts of the path to the elements at the same time the element is created. That should -- with appropriate massaging to make it work in a "cmd /c" or batch job do the basics... Of course, this also goves you 1 new version of the parent directory per new element.
If you're not averse to Perl, you can expand upon this by taking that list, making any needed directories, and them making the elements.
I have an issue with the clearmake command in IBM ClearCase,
I use clearmake command to run my own makefile so i can build my program from the 'C' sourse code.
I want to put a command in make file, like shell cleartool -some-command to ignore all checkouts and all private files.
The disadvantage is that in config spec, i must include the command element * CHECKEDOUT.
But in my use case i want to working with files and the same time i could make a compile/build with the old files, so i could work faster and i shouldn't change views or edit configspecs.
But my contemplation is, if i can ignore the checked outed files with a command, without to lose it.
Could you give me a solution ?
I want to working with files and the same time i could make a compile/build with the old files,
It would be easier to use two different snapshot views loaded on the disk at two different places.
In one (where no checkout has ever been done), you can set all files writables (through Windows, not ClearCase): all the files becomes hijacked, but modifiable, host for compilation/testing purposes.
In the other view, you keep your checked out files and your work in progress (but do not run your clearmake).
I found what appears to be an old source repository for some source code that I need to resurrect. But I have no idea what source control tools were used to generate and manage this source repository. In the directory, all of the files have a "s." prefixed to the file name. Without knowing the format in these files, I cannot manually extract the source code with any degree of accuracy. And even if I did, manually extracting the source code would be very time consuming and error prone.
What source/version control system prefixes its source files with "s." when it stores the source file in its repository directory?
How can I effectively extract the latest source code from this repository directory?
The s. prefix is characteristic of SCCS, the Source Code Control System. The code for that is probably still proprietary, but GNU has the CSSC project which can manipulate SCCS files. It tracks changes per-file in revisions, known as 'deltas'.
SCCS is the official revision control system for POSIX; you can find the commands documented on the Open Group site (but the file format is not specified there, AFAICT):
admin
delta
get
prs
rmdel
sact
unget
val
what
The file format is not specified by POSIX. The manual page for get says:
The SCCS files shall be files of an unspecified format.
The original SCCS command set included some extras not recorded by POSIX:
cdc — change delta commentary (for changing the checkin comments for a delta)
comb — combine, effectively for merging deltas
help — no prefix; the wasn't any other help program at the time. Commands generate error codes such as cm3 and help interpreted them.
sccsdiff — difference between two deltas of a file
Most systems now have a single command, sccs, which takes the operation name and then options. Often, the files were placed into an ./SCCS/ subdirectory and extracted from that as required, and the sccs front-end would handle name expansion, adding s. or SCCS/s. to the start of the file names.
For extracting the latest version of the source code, use get.
get s.*
sccs get s.*
These will get the default version of each file, and the default default is the latest version of the file.
If you need to make changes, use:
get -e s.filename.c
...make changes...
delta -y'Why you made the changes' s.filename.c
get s.filename.c
Note that the files 'lose' the s. prefix for the working file names, rather like RCS (Revision Control System) files lose the ,v suffix for the working file names. If you've not come across that, accept that it was different when SCCS and RCS were created, back in the late 70s or early 80s.
SCCS uses an s. prefix. But it might not be the only one!
I never knew this knowledge would come in useful some day!
I want to generate a summary of the files that are in one tree that are also in the other, that have been modified in the second.
The use case is this: I have a product distribution, which contains web content files. Those files are then imported into a client-specific project, and may be modified from there. I now want to see all the files in the client-specific project that have changed since the prduct was imported, so I can update the product, and keep the client-specific changes.
I'm thinking something like this might work
diff -r productDistribution/WebContent clientProject/WebContent
However, there are a number of files that are in the client specific project that are not in the product distribution, that I am not concerned with in this process. Essentially, I want an 'outer join', in SQL parlance.
Ideally, I want to be able to create a patch that contains all the client-specific changes. Then, I can just overlay the new product files, and apply the patch, and I should be all set.
Any ideas?
By default diff only prints a single line for each file that is in only one of the trees, so it's easy to filter these out:
diff -r productDistribution/WebContent clientProject/WebContent | \
grep -v 'Only in clientProject'