How different are my two code bases? - diff

I have two sets of source code that should be very similar. I need to find where they are different and address that.
These files are not in any SCM. Is there some way to get a report like this:
dir/file1 -- exists only in version A
dir/file2 -- exists only in version B
dir/file3 -- B includes 5 additions, 2 deletions
dir2 -- exists only in version A

diff -ru -x '.DS_Store' dirA dirB | diffstat

Meld can open two folders and then gives you an overview over missing/added/different files.

Any decent diff tool (e.g. WinMerge, DiffMerge, etc.) will be able to report on the differences between two folder structures.
Just put version A in a folder called VersionA, and version B in a folder called Version B and run the diff tool on them.
To generate a report in WinMerge select "Tools" -> "Generate Report".

I have used this tool and it is very handy for us to use.
It has additional PMD scanning too
Check this out.
http://sourceforge.net/projects/diffreport/

Related

How do I integrate Beyond Compare with ClearCase?

I would like to integrate Beyond Compare with ClearCase so that I can use it for diffing and merging files, instead of the awful tools provided by ClearCase.
Does anyone have instructions for performing this integration?
As mentioned in my previous answer, just modify the map file located in:
# up to ClearCase 7.0
c:\program files\rational\ClearCase\lib\mgrs
or
# ClearCase 7.1 and more
c:\program files\IBM\RationalSDLC\ClearCase\lib\mgrs
Each map line has 3 parts: the CC filetype, the CC action, and the application.
In your case, find the section in the map file for text_file_delta file types.
There you will find lines for CC actions compare, xcompare, merge, and xmerge.
Use BeyondCompare:
text_file_delta xcompare C:\Progra~1\Beyond~1\bc2.exe
Beyond Compare 3 support all CC actions:
text_file_delta compare C:\Program Files\Beyond Compare 3\BComp.exe
text_file_delta xcompare C:\Program Files\Beyond Compare 3\BComp.exe
text_file_delta merge C:\Program Files\Beyond Compare 3\BComp.exe
text_file_delta xmerge C:\Program Files\Beyond Compare 3\BComp.exe
Note: For Beyond Compare 2, this page clearly mentions
To use Beyond Compare 2, only change the xcompare line of the map file.
Overriding compare, merge, and xmerge is not supported.
A helper that improves BC2's support is available here.
Note that what precedes is for ClearCase only, not CCRC (ClearCase Remote Client)
This technote illustrates how to change the XML diff/Merge tool for CCRC (KDiff3 but you can adapt it to BeyondCompare):
Change directories to the CCRC installation location > plugins > com.ibm.rational.clearcase.compare_merge.<os>_<ccrc ver>,
Where <os> is the name of the operating system bits used and <ccrc ver> is the latest version of the CCRC update applied on the client.
On Windows
CCRC 7.1 Default: C:\Program Files\IBM\IMShared\plugins
CCRC 7.0 Default: C:\Program Files\IBM\Rational\ClearCase\CCRC\plugins\
Example:
com.ibm.rational.clearcase.compare_merge.win32x86_7.0.1.CU02
Copy the KDiff3 executable from its installation path to the com.ibm.rational.clearcase.compare_merge.<os>_<ccrc ver> directory
Rename the ccrc_xmldiffmrg.exe to ccrc_xmldiffmrg_orig.exe
Rename KDiff3.exe to ccrc_xmldiffmrg.exe
Close and reopen CCRC
CCRC Issue:
When updating CCRC, the plug-in directory com.ibm.rational.clearcase.compare_merge.<os>_<ccrc ver> will change.
The steps above will need to be run again in the new plug-in directory.
Note: You can control when the updates occur by preventing CCRC from looking for updates automatically.
Click Window > Preferences > Install/Update > Automatic Updates and disable automatic updates.
An alternative to Beyond Compare is KDiff3, which integrates very nicely with clearcase. Just tick off for clearcase integration when installing, and you're done.
Just to piggy back on Von's answer if you're lazy like me.
if you can search and replace with regex (like notepad++)
Find What:((text_file_delta|_html|_xml|html2|xml2)[ \t]+(compare|xcompare|merge|xmerge)[ \t]+).*
Replace with: \1C:\\Program Files\\Beyond Compare 3\\BCompare.exe
does all of the lines VonC mentioned for regular clearcase.
(assuming you have beyond compare installed at the above location, otherwise point to your path).
I also found it interesting, I put "'s around the path (due to the spaces) and it didn't work, removing them solved that problem.
There's also the 'official' way on the BC support page:
Ofiicial Tip by Scooter
1. Locate the plugins folder, which will contain a specific version named subfolder. Examples:
C:\Program Files\IBM\Rational\ClearCase701\CCRC\plugins\com.ibm.rational.clearcase.compare_merge.win32.x86_7.0.1.D061004
C:\Program Files\IBM\IMShared\plugins\com.ibm.rational.clearcase.compare_merge.win32.x86_7.1.1.v201007070751
Note that the version number in path is subject to change.
2. Copy "C:\Program Files\Beyond Compare 3\bcomp.exe" into the folder.
3. Move ccrc_cleardiff.exe, ccrc_cleardiffmrg.exe, ccrc_worddiffmrg.exe and ccrc_xmldiffmrg.exe to a backup folder.
4. Make 4 copies of bcomp.exe and rename them to ccrc_cleardiff.exe, ccrc_cleardiffmrg.exe, ccrc_worddiffmrg.exe and ccrc_xmldiffmrg.exe.
5. Change "CCRC Integrated (UTF-8)" to "ClearCase External" under Preferences | CCRC | Integration | Compare_Merge.
BUT there's something else you should do.
When setting the merge tool, you should override the comparison to the original 'CCRC Integrated', like so:
BC does not yet handle Clear Case Directory Comparison.

how can I have eclipse auto insert subversion revision number into my code

I'm interested in displaying the version number of my code in a help page. Ideally I'd use a Major.Minor.SVNrevision format, where the SVNrevision number was pulled automatically. I hope? Suspect there's a variable I can access somewhere, but have no idea what it may be.
Any hints?
You can do this by adding so-called SVN Keywords into your working files. This chapter contains standard SVN keywords. Then you have two options:
set property for each folder svn:keywords to make this substitution available for all who works with this repository: svn propset svn:keywords "Date Author Revision" help.html
modify svn configuration file (on Windows: %USERPROFILE%\Application Data\Subversion\config, on Linux: ~/.subversion/config) to enable automatic properties for all repositories and files (according to pattern) you're working with: set enable-auto-props to yes and then add to [auto-props] section: *.html = svn:keywords=Date Author Revision
If your help files are versioned, I would add an external script as an Eclipse builder in order to make some keyword substitution (using for instance svnversion)
But if your help files are generated, may be this kind of script can help (also based on svnversion to get back the "GlobalRev").
Major and Minor version information need to be stored and retrieved from another souce though: they are not "svn-related" informations.

Are subversion conflicts in project.pbxproj normal?

If I add files to my project, and my co-worker adds files to his project, and we both check our files in, should we expect to have conflicts? What's the best way to handle this?
This happens often enough to me that I have a shell script to fix these things - almost all the time merge conflicts are just because you and another person have both added new files to the project, and so you just want to keep both sides of the merge. Run this script in the main project directory (where the build and Classes directory is) any time you have a merge conflict, go to XCode to make sure it can load the merged project before you commit the fixed merge!
Note that I use this with git, you may want to check whatever merge conflict markers there are in your code use the characters below to show sections in conflict (==== is the middle divider).
mergeproj.sh
#!/bin/sh
projectfile=`find -d . -name 'project.pbxproj'`
projectdir=`echo *.xcodeproj`
projectfile="${projectdir}/project.pbxproj"
tempfile="${projectdir}/project.pbxproj.out"
savefile="${projectdir}/project.pbxproj.mergesave"
cat $projectfile | grep -v "<<<<<<< HEAD" | grep -v "=======" | grep -v "^>>>>>>> " > $tempfile
cp $projectfile $savefile
mv $tempfile $projectfile
Yes, this is common.
I usually just resolve the conflicts by hand in a text editor; the project format isn't actually that hard to read. If the changes are small (just adding or removing a few files) you could just reappy the change through the Xcode UI if you prefer.
Yes there will be conflicts. The best way to fix this is to open the .prxproj in a text editor like TextMate, and search for the lines with >>>. Just remove the svn merge stuff (the lines with arrows and the line telling you which branch it came from). Then save the file and mark it as resolved. You're done!
You could use FileMerge which comes with XCode. You can find it under the developer folder under Applications and then Utilities.
When you open FileMerge drag the 2 files you need to compare one into the left and one into the right. Go through and select the arrows indicating differences and choose left, right or both on the bottom right.
After you have completed this do a save as and save the file with the changes to the original file name.

How can I use ClearCase to "add to source control ..." recursively?

I unpacked a zip-file delivery into a clearcase view. Now I want to add the complete file tree to the repository. The GUI only provides an "Add to source control ..." for individual files/directories. Do you know how to recursively add the whole tree?
(I'm on a Windows system, but have Cygwin installed.)
I would rather go with the clearfsimport script, better equipped to import multiple times the same set of files, and automatically:
add new files,
make new version of existing files previously imported (but modified in the source set of files re-imported)
remove files already imported but no longer present in the source set of files.
make a clear log of all operations made during the import process.
So if your 'zip-file delivery needs to be updated on a regularly basis, clearfsimport is the way to go, but with the following options:
clearfsimport -preview -rec -nset c:\sourceDir\* m:\MyView\MyVob\MyDestinationDirectory
Note the :
-preview option: it will allow to check what would happen without actually doing anything.
'*' used only in Windows environment, in order to import the content of a directory
-nset option.
From CMWiki, about that 'nset' option:
By default, clearfsimport is meant to be used by the vob owner or a privileged user, but users often overlook the -nsetevent option, with which it may be used by any user.
This option drives clearfsimport not to set the time stamps of elements to this of the source file object outside the vob (which requires privileged access).
There is a minor non-obvious side-effect with this: once a version will have been created with a current time stamp, even the vob owner will not be able to import on top of it a version with an older (as it would be) time stamp, without this -nsetevent option. I.e. once you use this option, normal or privileged user, you are more or less bound to use it in the continuation.
Here is one other way I found by using the Windows Explorer:
Select Search... from the context menu on the target directory.
Search for *.
Select all (Ctrl-A) files/directories in the result list.
Select ClearCase > Add to source control... from the context menu on an item in the result list.
There you go ...
Since I did not have access to clearfsimport , I added the files/directories in a two step process:
1.) find . ! -path . -type d | xargs cleartool mkelem -mkpath -nc
This will create nodes for all new directories recursively
2.) find ./ -type f | xargs cleartool mkelem -nc
This will create nodes for all new files recursively
ClearTeam Explorer, version 8 (maybe earlier as well), has recursive add of subdirectories/files when you select "Add to Source Control". When the "Add to Source Control" dialog box appears, check the "Include descendant artifacts of the selected directories" checkbox and uncheck the "Checkout descendant files only, do not checkout descendant directories" checkbox.
You have to use the commandline. The Context menu in Explorer doesnt do this recursively!
clearfsimport –recurse /usr/src/projectx /vobs/projectx/src
Heres a script to do it
And tips to integrate the script from Explorer
http://www.ibm.com/developerworks/rational/library/4687.html
Had a similar requirement to add a directory recursively to ClearCase. Since I did not have access to clearfsimport tool nor do I have ClearCase integrated with Windows Explorer, found an easy solution within ClearCase GUI.
1) Add the root directory using "Add to Source Control" menu option.
2) Click on this directory and then use "ClearCase Search" to search for all Private Files in this directory.
3) Select all from the Search Results and "Add to Source Control"
There you go ! The entire directory is recursively added from within ClearCase GUI
you can get a fix at
http://www-01.ibm.com/support/docview.wss?ratlid=cctocbody&rs=984&uid=swg21117629
You can also add this command to your context menu with a small script...
Ten best Triggers
edit: oh, sorry. didn't saw that this was already suggested...
I agree,
find+select+add-to-source-control from Windows explorer is not a good option if the number of files to be version controlled is huge. As already mentioned above, explorer.exe crashes if we try to add a large number of files.
clearfsimport is the best and the most hassle free utility for this task.
-GP

Can you "ignore" a file in Perforce?

I sometimes use the feature 'Reconcile Offline Work...' found in Perforce's P4V IDE to sync up any files that I have been working on while disconnected from the P4 depot. It launches another window that performs a 'Folder Diff'.
I have files I never want to check in to source control (like ones found in bin folder such as DLLs, code generated output, etc.) Is there a way to filter those files/folders out from appearing as "new" that might be added. They tend to clutter up the list of files that I am actually interested in. Does P4 have the equivalent of Subversion's 'ignore file' feature?
As of version 2012.1, Perforce supports the P4IGNORE environment variable. I updated my answer to this question about ignoring directories with an explanation of how it works. Then I noticed this answer, which is now superfluous I guess.
Assuming you have a client named "CLIENT", a directory named "foo" (located at your project root), and you wish to ignore all .dll files in that directory tree, you can add the following lines to your workspace view to accomplish this:
-//depot/foo/*.dll //CLIENT/foo/*.dll
-//depot/foo/.../*.dll //CLIENT/foo/.../*.dll
The first line removes them from the directory "foo" and the second line removes them from all sub directories. Now, when you 'Reconcile Offline Work...', all the .dll files will be moved into "Excluded Files" folders at the bottom of the folder diff display. They will be out of your way, but can still view and manipulate them if you really need to.
You can also do it another way, which will reduce your "Excluded Files" folder to just one, but you won't be able to manipulate any of the files it contains because the path will be corrupt (but if you just want them out of your way, it doesn't matter).
-//depot/foo.../*.dll //CLIENT/foo.../*.dll
Yes, But.
Perforce version 2012.1 added a feature known as p4ignore, inspired by Git. However the Perforce developers made a change to the behaviour, without justification, that happens to make the feature a lot less useful.
Whilst Git takes rules from all .gitignore files, Perforce doesn't know where to look until you specify a filename in an environment variable P4IGNORE. This freedom is a curse. You can't hack on two repositories that use different names for their ignore files.
Also, Perforce's ignore feature doesn't work out the box. You can set it up easily enough for yourself, but others don't benefit unless they explicitly opt-in. A contributor who hasn't may accidentally commit unwelcome files (eg. a bin folder created by a build script).
Git's ignore feature is great because it works out the box. If the .gitignore files are added to the repository (everyone does this), they'll work out the box for everyone. No-one will accidentally publish their private key.
Amusingly, the Perforce docs shows '.p4ignore' as an example ignore rule, which is backwards! If the rules are useful, they should be shared as part of the repository.
Perforce could still make good on the feature. Choose a convention for the file names, say p4ignore.txt, so the feature works out the box. Drop the P4IGNORE environment variable, it's counterproductive. Edit the docs, to encourage developers to share useful rules. Let users write personal rules in a file in their home folder, as Git does.
If you know anyone at Perforce, please email them this post.
This works as of Perforce 2013.1, the new P4IGNORE mechanism was first added in release, 2012.1, described on the Perforce blog here:
https://www.perforce.com/blog/new-20121-p4ignore
As it's currently described, you set an environment variable "P4IGNORE" to a filename which contains a list of the files to ignore.
So you can check it out to see how you like it.
If you want a solution that will apply to all work-spaces without needing to be copied around, you (or your sysadmin) can refuse submission of those file-types through using lines like the below in the p4 protect table:
write user * * -//.../*.suo
write user * * -//.../*.obj
write user * * -//.../*.ccscc
I remember doing this before, but I don't have the necessary permissions to test this here. Check out Perforce's Sysadmin guide and try it out
Perforce Streams makes ignoring files much easier, as of version 2011.1. According to the documentation, you can ignore certain extensions or certain paths in your directory.
From p4 help stream
Ignored: Optional; a list of file or directory names to be ignored in
client views. For example:
/tmp # ignores files named 'tmp'
/tmp/... # ignores dirs named 'tmp'
.tmp # ignores file names ending in '.tmp'
Lines in the Ignored field may appear in any order. Ignored
names are inherited by child stream client views.
This essentially does what #raven's answer specifies, but is done easier with streams, as it automatically propagates to every work-space using that stream. It also applies to any streams inheriting from the stream in which you specify the ignore types.
You can edit the stream via p4 stream //stream_depot/stream_name or right-clicking the stream in p4v's stream view.
And as #svec noted, the ability to specify ignore files per workspace is coming soon, and is in fact in P4 2012.1 beta.
Will's suggestion of using .p4ignore only seems to work with the WebSphere Studio (P4WSAD) plugin. I just tried it on my local windows box and any files and directories that I listed were not ignored.
Raven's suggestion of modifying your client spec is the correct way under Perforce. Proper organization of your code/data/executables and generated output files will make the process of excluding files from being checked in much easier.
As a more draconian approach, you can always write a submit trigger which will reject submission of change-lists if they contain a certain file or files with a certain extension, etc.
HISTORICAL ANSWER - no longer correct. At the time this was written originally it was true;
You can not write and check in a file that the server will use to make ignore rules; general glob or regexp file pattern ignore in perforce.
Other answers have global server configurations that are global (and not per folder).
The other answers show things that might work for you, if you want one line in your view per folder times number of extensions you want to ignore in that single folder, or that provide this capability in WebSphere Studio plugins only, or provide capability for server administrators, but not available to users.
In short, I find Perforce really weak in this area. While I appreciate that those who use the Eclipse Plugin can use .p4ignore, and I think that's great, it leaves those of us that don't, out in the dark.
UPDATE: See accepted answer for new P4IGNORE capability added mid-2012.
I have found it easiest to reconcile offline work using a BASH script like this one:
#!/bin/bash
# reconcile P4 offline work, assuming P4CLIENT is set
if [ -z "$P4CLIENT" ] ; then echo "P4CLIENT is not set"; exit 1; fi
unset PWD # confuses P4 on Windows/CYGWIN
# delete filew that are no longer present
p4 diff -sd ... | p4 -x - delete
# checkout files that have been changed.
# I don't run this step. Instead I just checkout everything,
# then revert unchanged files before committing.
p4 diff -se ... | pr -x - edit
# Add new files, ignoring subversion info, EMACS backups, log files
# Filter output to see only added files and real errors
find . -type f \
| grep -v -E '(\.svn)|(/build.*/)|(/\.settings)|~|#|(\.log)' \
| p4 -x - add \
| grep -v -E '(currently opened for add)|(existing file)|(already opened for edit)'
I adapted this from this Perforce Knowledge Base article.
I'm looking for a .p4ignore like solution as well (and not one tied to a particular IDE). Thus far, the closest thing I've found is p4delta. It sounds like it will do exactly what the original poster was asking, albeit through another layer of indirection.
http://p4delta.sourceforge.net
Unfortunately, while this does seem to produce the proper list of files, I can't get "p4delta --execute" to work ("Can't modify a frozen string") and the project has not been updated in year. Perhaps others will have better luck.
If you are using the Eclipse Perforce plugin, then the plugin documentation lists several ways to ignore files.