Sorry, it has taken a while to find the time to look at this again ... One solution appears to be to use the -kk flag with cvs update; this will leave the tags as $Revision$ etc.
However, there is a slight catch, as the current version of CVS does not handle the -kk flag properly for binary files - CVS ought still to take notice of -kb, but it does not (this was fixed in CVS 1.12.2; we are using an 1.11 version. I've asked on infrastructure if there are plans to update.) To avoid possibly mangling binary files (I assume this will only happen if the file contains what looks like an expanded CVS tag), one can use the -I (ignore) flag: e.g. -I '*.gif' -I '*.jar' -I '*.png' -I '*.jpg' should ignore all the binary file types at present in the jmeter respository. Now most of the binary files are outside the src tree, but unfortunately there are some binary files in it (I think they are all .gif), so one would still need the -I flag to be sure. [Note: it appears that the -kk flag can be used against a working copy that contains the expanded versions; it seems that CVS fetches the two revisions anew from the repository to do the merge.] Alternatively, I suppose one could use the cvs -kk flag to create separate working copies for the head and rel-2_0 branches, and then use a difference tool to do the comparisons. This might be easier than using CVS, especially if one has a visual difference tool that can compare directories (I've used WinMerge and found it quite good, but YMMV. Eclipse could also be used). BTW, some of the comparison tools (e.g. CSDiff, WinMerge) can cope with white space changes. Sebastian ----- Original Message ----- From: "Sebastian Bazley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "JMeter Developers List" <[EMAIL PROTECTED]> Sent: Sunday, June 20, 2004 3:14 AM Subject: Re: ban on code formatting when release branch is active > I was thinking partly of Javadoc, also when source files are packaged up in > jars etc. It can be useful to know which version of a source file is present > (e.g. if one knows that a bug was fixed in version x); without the version > number this is tricky. > > It is vital for build.xml, as it can otherwise be very difficult to tell > what version Gump has used. > > I'm -1 on removing these tags in the short term, at least until alternatives > have been investigated. > [Apart from anything else, it will take a while to remove them all, and we > might then find it was not necessary.] > > I'll try and do some investigation tomorrow - surely there must be a > solution to this. > > Sebastian > ----- Original Message ----- > From: "Michael Stover" <[EMAIL PROTECTED]> > To: "JMeter Developers List" <[EMAIL PROTECTED]> > Sent: Sunday, June 20, 2004 2:30 AM > Subject: Re: ban on code formatting when release branch is active > > > Yes, $Header$ and $Version$. I can't imagine why we need version > information inside the file. Can you explain why? > > I don't know how I'd filter it. I use cvs to do the merge. > > -Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
