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'
Related
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
I have temporary files created in separate folders inside my source tree which I would like to ignore. Something like:
project/
|--component/
|--.jazzignore
|--file.src
|--file-9df29e29373e66caef72/
|--file.src.tmp
I already ignore file.src.tmp by extension using .jazzignore, but I would also like to ignore the file-9df29e29373e66caef72/. The folder looks empty in the "Unresolved" category for the component, but since its name changes over time, I cannot ignore it by name.
since its name changes over time, I cannot ignore it by name.
Still, if you know its naming convention, you might consider an ignore pattern:
core.ignore= \
file-*
Note it is non-recursive, you that would ignore any file, folder or symlink named file-... anywhere under component.
Here, that would ignore only file-... directly under component.
Eclipse workspaces often include files or folders, such as compiler output, log files, and so on, that you do not want to place under source control.
You can specify resources or classes of resources to be ignored by Rational Team Concert™ source control. Ignored resources are never checked in.
A .jazzignore file is used to prevent items from being checked into change sets.
A .jazzignore file consists of a series of patterns. Any file, folder, or symbolic link whose name matches a pattern cannot be committed to a change set.
There are two types of patterns in a .jazzignore file:
core.ignore patterns, that are effective in the same directory as the ignore file; and
core.ignore.recursive patterns that affect items in all of the directories below the .jazzignore file.
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 referring to TAGS file generated by ctags or etags in order to have some code navigation in Emacs with M-..
The typical project looks like this:
Large standard library (more than 100 files, but rarely updated).
Project-specific library (updated on the daily basis).
I would like the project to be able to use two (or maybe more TAGS files), but regenerate only the portion of them, only the ones used inside the particular project. How would I approach this problem?
etags --help:
-i FILE, --include=FILE
Include a note in tag file indicating that, when searching for
a tag, one should also consult the tags file FILE after
checking the current file.
I am doing a refactoring of my C++ project containing many source files.
The current refactoring step includes joining two files (say, x.cpp and y.cpp) into a bigger one (say, xy.cpp) with some code being thrown out, and some more code added to it.
I would like to tell my version control system (Perforce, in my case) that the resulting file is based on two previous files, so in future, when i look at the revision history of xy.cpp, i also see all the changes ever done to x.cpp and y.cpp.
Perforce supports renaming files, so if y.cpp didn't exist i would know exactly what to do. Perforce also supports merging, so if i had 2 different versions of xy.cpp it could create one version from it. From this, i figure out that joining two different files is possible (not sure about it); however, i searched through some documentation on Perforce and other source control systems and didn't find anything useful.
Is what i am trying to do possible at all?
Does it have a conventional name (searching the documentation on "merging" or "joining" was unsuccessful)?
You could try integrating with baseless merges (-i on the command line). If I understand the documentation correctly (and I've never used it myself), this will force the integration of two files. You would then need to resolve the integration however you choose, resulting in something close to the file you are envisioning.
After doing this, I assume the Perforce history would show the integration from the unrelated file in it's integration history, allowing you to track back to that file when desired.
I don't think it can be done in a classic VCS.
Those versioning systems come in two flavors (slide 50+ of Getting git by Scott Chacon):
delta-based history: you take one file, and record its delta. In this case, the unit being the file, you cannot associate its history with another file.
DAG-based history: you take one content and record its patches. In this case, the file itself can vary (it can be renamed/moved at will), and it can be the result of two other contents (so it is close of what you want)... but still within the history of one file (the contents coming from different branches of its DAG).
The easy part would be this:
p4 edit x.cpp y.cpp
p4 move x.cpp xy.cpp
p4 move y.cpp xy.cpp
Then the tricky part becomes resolving the move of y.cpp and doing your refactoring. But this will tell Perforce that the files are combined.