Re: Build Tag Naming Conventions

Matt Small wrote:
> Thanks, I'll try getting the release33 branch and see how that works. 
> 
> As for the instabilities, it will take quite a lot of explanation to go
> through them, so if you dont have time to read this, thats fine, I will put
> it all down anyway because maybe it will help you out. Also, my
> characterizations of these problems are not very clear or easily
> reproducible so I dont know if there is anything you can do.
> 
> Basically we are using CVS as the repository for all of the content in a
> content management system. I have a wrapper class around the cvsclient API
> that handles reading/writing files to CVS. We pool up connections, so a
> given connection may be used for many different operations. Connections are
> recycled from time to time however. For the most part everything works
> pretty well, I would say about once or twice a week something chokes pretty
> bad though.

even though it seems that executing multiple commands using one 
connection is supported by cvs, I would not recommend it. I've been 
sceptical since the beginning, Thomas did use the feature but quit after 
  some time. That might be the root of the problem.

The thing with unknown responses seems familiar to me, I'm sure we've 
been fixing it in the past. It might be connected with the reuse of the 
connections. What's the version of your server?


The other thing with some FileInfoContainer not being fired is known to 
me that happens under specific conditions within update. make sure you 
don't have any of the global options set: -q -Q -n. For the Q+q the 
building of objects fails generally, since there's not enough info to 
construct... for -n there's one little problem with Merged files I 
believe.. for these files it's not possible to figure out the whole path 
of the file that's being merged from the textual output only and we help 
outselves out with  passing some other info to the builder. However such 
info is not passed when the -n switch is on.

I haven't checked the code closely since it's quite unreadabel within my 
mail client (the wrapping of lines is adding quite a log ot chaos for 
me), next time please attach the code as attachement..

Generally I suggest you check the content of the global switches, 
version of the server and try not to reuse the connections..

Hope that helps..

Milos

> 
> One problem we noticed was that the request to the CVS server seemed to get
> out of synch. So we got a whole slew of exceptions where it looked like the
> cvsclient was taking lines from the file as request headers.  Take a look at
> these events that the cvsclient kicked out. Notice that the values in the
> unrec. request are js lines from html files checked into our CVS
> repositories. This happened I believe when committing a file (but it could
> have been and update before a commit.)
> 
> ERROR [11:12:43,502] LoggerListener -  unrecognized request `    var
> oas='http://ads.clickability.com/RealMedia/ads/';'
> ERROR [11:12:43,503] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@1aa8e8]
> ERROR [11:13:17,823] LoggerListener -  unrecognized request `    var
> sitepage = "some page";'
> ERROR [11:13:17,823] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@47339b]
> ERROR [11:13:17,837] LoggerListener -  unrecognized request `    var RN =
> new String (Math.random());'
> ERROR [11:13:17,837] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@8d2177]
> 
> ERROR [11:14:14,587] LoggerListener -  unrecognized request `    var RNS =
> RN.substring (2, 11);'
> ERROR [11:14:14,588] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@ea1573]
> 
> ERROR [11:16:20,439] LoggerListener -  unrecognized request `    function
> DisplayAds (position, width, height) {'
> ERROR [11:16:20,439] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@b4bff]
> ERROR [11:16:38,709] LoggerListener -  unrecognized request `        var
> oaspage= sitepage + '/1' + RNS + '@' + position;'
> ERROR [11:16:38,709] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@665191]
> ERROR [11:17:35,260] LoggerListener -  unrecognized request `'
> ERROR [11:17:35,261] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@e378f2]
> ERROR [11:19:26,847] LoggerListener -  unrecognized request `        if
> (_version <11) {'
> ERROR [11:19:26,848] LoggerListener - TerminationEvent Occurred.
> org.netbeans.lib.cvsclient.event.TerminationEvent[source=org.netbeans.lib.cv
> sclient.response.ErrorResponse@5c26b4]
> 
> 
> I also had some trouble getting files out of the system. My logic for
> reading files is to just get the latest version from the file system if that
> is the requested version. If an older version is requested, I check that
> file out to standard out and grab it from that. Take a look at these stack
> traces I found, I couldn't really make much sense of them. I have no idea
> what o and kok mean.
> 
> ERROR [18:20:48,512] CVSHandle - CommandException updating file:
> /var/local/tomcat/cmswork/cms/cvsDir/cmpublish/Fair_Oaks_Gazette_Interactive
> /content/News_Article/White_House_ready_to_delay_strike_at_United_-783085341
> .xml
> java.lang.IllegalArgumentException: Unhandled response: o.
> 	at
> org.netbeans.lib.cvsclient.response.ResponseFactory.createResponse(ResponseF
> actory.java:107)
> 	at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:477)
> 	at
> org.netbeans.lib.cvsclient.Client.processRequests(Client.java:442)
> 	at
> org.netbeans.lib.cvsclient.command.update.UpdateCommand.execute(UpdateComman
> d.java:294)
> 	at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:521)
> 	at com.clickability.cvsclient.CVSHandle.getFile(CVSHandle.java:606)
> 
> ERROR [18:20:48,521] CVSHandle - CommandException updating file:
> /var/local/tomcat/cmswork/cms/cvsDir/cmpublish/Fair_Oaks_Gazette_Interactive
> /content/News_Article/Study_links_bad_air_and_birth_defects_-782153351.xml
> java.lang.IllegalArgumentException: Unhandled response: kok.
> 	at
> org.netbeans.lib.cvsclient.response.ResponseFactory.createResponse(ResponseF
> actory.java:107)
> 	at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:477)
> 	at
> org.netbeans.lib.cvsclient.Client.processRequests(Client.java:442)
> 	at
> org.netbeans.lib.cvsclient.command.update.UpdateCommand.execute(UpdateComman
> d.java:294)
> 	at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:521)
> 	at com.clickability.cvsclient.CVSHandle.getFile(CVSHandle.java:606)
> 
> ERROR [18:20:48,611] CVSHandle - CommandException updating file:
> /var/local/tomcat/cmswork/cms/cvsDir/cmpublish/Fair_Oaks_Gazette_Interactive
> /content/News_Article/Teen's_triple_transplant_canceled_-782383134.xml
> java.lang.IllegalArgumentException: Unhandled response: o.
> 	at
> org.netbeans.lib.cvsclient.response.ResponseFactory.createResponse(ResponseF
> actory.java:107)
> 	at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:477)
> 	at
> org.netbeans.lib.cvsclient.Client.processRequests(Client.java:442)
> 	at
> org.netbeans.lib.cvsclient.command.update.UpdateCommand.execute(UpdateComman
> d.java:294)
> 	at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:521)
> 	at com.clickability.cvsclient.CVSHandle.getFile(CVSHandle.java:606)
> 
> WARN  [18:20:48,618] CMSContext - Error loading target content instance
> while publishing hub. InstID:18. Details: Unable to read xml file from cvs:
> content/News_Article/Teen's_triple_transplant_canceled_-782383134.xml
> ERROR [18:20:48,622] CVSHandle - CommandException updating file:
> /var/local/tomcat/cmswork/cms/cvsDir/cmpublish/Fair_Oaks_Gazette_Interactive
> /content/News_Article/Report__Vivendi,_Diller_reach_$10_billion_deal_-783804
> 242.xml
> java.lang.IllegalArgumentException: Unhandled response: kok.
> 	at
> org.netbeans.lib.cvsclient.response.ResponseFactory.createResponse(ResponseF
> actory.java:107)
> 	at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:477)
> 	at
> org.netbeans.lib.cvsclient.Client.processRequests(Client.java:442)
> 	at
> org.netbeans.lib.cvsclient.command.update.UpdateCommand.execute(UpdateComman
> d.java:294)
> 	at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:521)
> 	at com.clickability.cvsclient.CVSHandle.getFile(CVSHandle.java:606)
> 
> Another thing I am finding is that sometimes it seems like the
> FileInfoContainer is returned when it shouldn't be and is not returned when
> it should be. This has happens when commiting a new version of a file to
> CVS. Below is the method we use to commit changes to files in the system,
> maybe my usage is wrong here. Note that it has gotten somewhat complex as I
> am trying to handle every possible eventuality. It seems to me that when the
> file has not been modified, a file info container may or may not be
> returned. I think I might have also had some problems with the CommitInfo
> object as well.
> 
> 	/**
> 	 * Adds a new version of a file to CVS. This actually does a CVS
> commit command.
> 	 *
> 	 * @param file The file to be updated in CVS
> 	 * @throws CVSException If the file could not be updated
> 	 */
> 	public int updateFile (File file) throws
> CVSException,ObjectModifiedExternallyException {
> 		int version = -1;
> 		FileInfoContainer fileInfo1 = null;
> 		try{
> 			//Need to update the file first to make sure that it
> wasn't modified 
> 			//by another user or JVM
> 			UpdateCommand command = new UpdateCommand();
> 			if (logger.isDebugEnabled()) logger.debug("Updating
> File: " + file + " before doing commit.");
> 			command.setFiles(new File[] {file});
> 			infoListener.clearFileInfo();
> 	
> client.executeCommand(command,serverInfo.getGlobalOptions());
> 			fileInfo1 = infoListener.getFileInfo();
> 			if (fileInfo1 != null && fileInfo1 instanceof
> DefaultFileInfoContainer){
> 				if (logger.isDebugEnabled())
> logger.debug("Getting fileInfo1 from update file before commit.");
> 				//We should be able to get a version.
> 				DefaultFileInfoContainer updateInfo =
> (DefaultFileInfoContainer)fileInfo1;
> 				String type = updateInfo.getType();
> 				if (type.equals("M")){
> 					if (logger.isDebugEnabled())
> logger.debug("File has been modified locally, proceeding with commit.");
> 				}else if (type.equals("C") ||
> type.equals(DefaultFileInfoContainer.MERGED_FILE)){
> 					//File was merged and thus modified
> by another process. We cannot deal with this
> 					//in the CMS System, so we just have
> to error out of this condition.
> 					//Make sure the get the clean copy
> and then error out
> 					logger.warn("Merge or conflict
> detected while attempting to commit a new version of the file: " + file);
> 					try{
> 						UpdateCommand command2 = new
> UpdateCommand();
> 						if (logger.isDebugEnabled())
> logger.debug("Getting clean copy of file: " + file);
> 						command2.setCleanCopy(true);
> 						command2.setFiles(new File[]
> {file});
> 	
> infoListener.clearFileInfo();
> 	
> client.executeCommand(command2,serverInfo.getGlobalOptions());
> 					}catch(CommandException e){
> 						if
> (e.getUnderlyingException() != null && e.getUnderlyingException() instanceof
> IOException){
> 	
> pool.failover(e.getUnderlyingException());
> 						}
> 	
> logger.error("CommandException getting clean copy of file after merge: " +
> file, e);
> 					}
> 					throw new
> ObjectModifiedExternallyException("The item specified has been modified by
> another user since it was last updated. You must reload the item before
> modifications can be made.");
> 				}else{
> 					logger.warn("Unexpected update type
> updating file: " + file);
> 					logger.warn("Update type was: " +
> type);
> 				}
> 			}else{
> 				//This happens when the file has not been
> modified locally. 
> 				if (logger.isDebugEnabled())
> logger.debug("File is unmodified locally, returning version from Entries
> file.");
> 				try{
> 					Entry entry = client.getEntry(file);
> 					if (entry != null){
> 						if (entry.hadConflicts() ||
> (entry.getConflict() != null &&
> entry.getConflict().startsWith(Entry.MERGE_TIMESTAMP))){
> 							//The file was
> modified by someone else since it was last updated.
> 							throw new
> CVSException("Entry indicates file was merged or had a conflict.");
> 						}else{
> 							version =
> parseRevision(entry.getRevision());
> 						}
> 					}else{
> 						//Entry should not be null.
> 						throw new
> CVSException("Entry was null after update.");
> 					}
> 				}catch(IOException ioe){
> 					//This is not a failover condition
> because its just reading a local file.
> 					//I guess just assume that its ok
> even though we couldn't read the entry file.
> 					logger.error("IOException reading
> entries file for file: " + file,ioe);
> 					throw new CVSException("Error
> reading entry after update.",ioe);
> 				}
> 				return version;
> 			}			
> 		}catch(CommandException e){
> 			logger.error("CommandException updating file before
> commit: ", e);
> 			if (e.getUnderlyingException() != null &&
> e.getUnderlyingException() instanceof IOException){
> 				pool.failover(e.getUnderlyingException());
> 			}
> 			throw new CVSException("Error updating file before
> commit.", e);
> 		}
> 		
> 		try{
> 			CommitCommand command = new CommitCommand();
> 			command.setFiles(new File[] {file});
> 			infoListener.clearFileInfo();
> 	
> client.executeCommand(command,serverInfo.getGlobalOptions());
> 			FileInfoContainer fileInfo2 =
> infoListener.getFileInfo();
> 			if (fileInfo2 != null && fileInfo2 instanceof
> CommitInformation){
> 				if (logger.isDebugEnabled())
> logger.debug("Getting commitInfo from update file commit.");
> 				//We should be able to get a version.
> 				CommitInformation commitInfo =
> (CommitInformation)fileInfo2;
> 				version =
> parseRevision(commitInfo.getRevision());
> 				//MS: 3/25/02 
> 				//I have a hypothesis that
> commitInfo.getRevision() may be returning jacked up information.
> 				//This may slow things down a little bit,
> but I'm going to check the entries file
> 				//to make sure everything is Kosher. Once we
> know this is not a problem, we should be
> 				//able to take this out again.
> 				
> 				try{
> 					Entry entry = client.getEntry(file);
> 					if (entry != null){
> 						if (entry.hadConflicts() ||
> (entry.getConflict() != null &&
> entry.getConflict().startsWith(Entry.MERGE_TIMESTAMP))){
> 							//The file was
> modified by someone else since it was last updated.
> 							throw new
> CVSException("Entry indicates file was merged or had a conflict.");
> 						}else{
> 							int entriesVersion =
> parseRevision(entry.getRevision());
> 							if (version !=
> entriesVersion){
> 	
> logger.fatal("File version for commit info does not equal file version in
> Entries file for file: " + file);
> 	
> logger.fatal("CommitInfo version: " + version);
> 	
> logger.fatal("Entries version: " + entriesVersion);
> 								throw new
> CVSException("File version for commit info does not equal file version in
> Entries file.");
> 							}
> 						}
> 					}else{
> 						//Entry should not be null.
> 						throw new
> CVSException("Entry was null after commit.");
> 					}
> 				}catch(IOException ioe){
> 					//Not a failover condition because
> its just a local file.
> 					//I guess just assume that its ok
> even though we couldn't read the entry file.
> 					logger.error("IOException reading
> entries file for file: " + file,ioe);
> 				}
> 				
> 				if (logger.isDebugEnabled())
> logger.debug("New file version: " + version);
> 			}else{
> 			
> 				//4/22/02 Somehow this exception got thrown.
> That means fileInfo1 was not null. I'm going to 
> 				// put the Entry code back in. 
> 				logger.warn("No file info from commit, I
> suspect that the update file info was available but fell throught somehow. "
> + fileInfo1);
> 				if (fileInfo1 != null && fileInfo1
> instanceof DefaultFileInfoContainer){
> 					DefaultFileInfoContainer updateInfo
> = (DefaultFileInfoContainer)fileInfo1;
> 					String type = updateInfo.getType();
> 					logger.warn("Type was: " + type);
> 				}
> 
> 				//Now this should never happen. It is always
> an error. We detect above whether
> 				//The file was modified or not.
> 				//throw new CVSException("Attempted Commit
> on Unmodified File.");
> 			
> 				/*
> 				This can happen in the following cases:
> 				
> 				(1) Unmodified File was checked in.
> 				(2) File was commited on another JVM with
> different work dir after the 
> 					version on this local directory was
> last updated (getFile() called).
> 				    This can happen if content-type is
> opened and edited in two zones.
> 				    
> 				So (1) is ok, we can just return the current
> version but (2) is very bad.
> 				
> 				Now (2) is taken care of by the update above
> (I hope) so we should just be able to get
> 				the version out of the Entries file and
> return that.
> 				*/
> 				try{
> 					Entry entry = client.getEntry(file);
> 					if (entry != null){
> 						if (entry.hadConflicts() ||
> (entry.getConflict() != null &&
> entry.getConflict().startsWith(Entry.MERGE_TIMESTAMP))){
> 							//The file was
> modified by someone else since it was last updated.
> 							throw new
> CVSException("Entry indicates file was merged or had a conflict, after
> commit with no file info.");
> 						}else{
> 							version =
> parseRevision(entry.getRevision());
> 						}
> 					}else{
> 						//Entry should not be null.
> 						throw new
> CVSException("Entry was null after commit.");
> 					}
> 				}catch(IOException ioe){
> 					//I guess just assume that its ok
> even though we couldn't read the entry file.
> 					logger.error("IOException reading
> entries file for file: " + file,ioe);
> 					throw new CVSException("IOException
> reading entries file for file: " + file);
> 				}
> 				//version = getFileVersion(file); 
> 				//logger.info("Got version from status: " +
> version);				
> 				//throw new CVSException("Error commiting
> updated file: Could not get version information for file " +
> file.getAbsolutePath());
> 			}
> 			
> 		}catch(CommandException e){
> 			logger.error("CommandException committing file: ",
> e);
> 			if (e.getUnderlyingException() != null &&
> e.getUnderlyingException() instanceof IOException){
> 				pool.failover(e.getUnderlyingException());
> 			}
> 			throw new CVSException("Error commiting updated
> file: " + file.getAbsolutePath(), e);
> 		}
> 		return version;
> 	}
> 
> 
> I hope you are not too overwhelmed with all this. Thanks for taking a look.
> Also, I didn't send this to the main list because I dont think all this
> stuff would really concern the community, but if you want to forward it to
> the list, thats fine.
> 
> Regards,
> 
> Matt
> 
> -----Original Message-----
> From: Milos Kleint [mailto:[email protected]]
> Sent: Monday, April 29, 2002 11:41 PM
> To: [email protected]
> Subject: Re: [javacvs-dev] Build Tag Naming Conventions
> 
> 
> Matt Small wrote:
> 
>>I have been noticing some instabilities of late in release33 version of
> 
> the
> 
>>cvsclient. I'm hoping that 3.3.1 will take care of it, so I got that jar
> 
> off
> 
>>the downloads page. Now I am trying to get the source, but I'm a little
>>confused about which tag to check out is BLD200203040100 the one I want or
>>should I get QBE200203010100-BLD200203041529. Can you all let me in on the
>>naming convention of the tags/builds for future reference (what does QBE
>>mean)? Also, is 3.3.1 the best version to go with for a production system?
>>Release 33 has all the features I need so I am really looking for the most
>>stable.
>>
>>Thanks alot, great product. 
>>
>>Matt
>>
> 
> 
> The most stable branch is probably the release33 branch which currently 
> contains the code for 3.3.1 release (I think just today there were 
> merged changes that contain 3.3.2 fixes)
> 
> the QBE branches are created when a Q-build is not approved by our QA. 
> The qhole code base is thatn branched and the showstoppers are then 
> fixed. the format is QBEYYYYMMDDHHMM (year, month,day...) the same 
> format goes for the tags. each daily build is tagged with the BLD tag.. 
> that way everyone can recreate the any particular build.
> 
> BTW what are these "instabilities?"
> 
> Milos
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]