Re: Mergemaster niggle
The real question here is: why is the RCSid changing when the file isn't? Sometimes things get changed and then backed out to their original state, but you cannot keep the original RCSID To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
On Wed, Feb 06, 2002 at 02:13:08PM -0600, David W. Chapman Jr. wrote: What I think mergemaster should do is compere the file with the original checked out one it claims to be and if it's the same, it should just update silently.. i.e. if the user didn't change anything in th old one he's unlikely to want to change anything in the new one (maybe a datafile that contains cksum outputs for each version of each file) I think part of the problem(from what I'm hearing on irc), someone made a lot of commits to etc which weren't supposed to happen, but I cannot confirm all the facts at the moment. *Raises hand.* I had a botched cvs(1) command line run away and did some forced commits on /etc files. You would only have seen it if you updated over a few hour stretch; the Repo Lords fixed it. You lucked out and must have updated during the window. ;) Note that if you look at your diff, the revision number went _backwards._ -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mergemaster niggle
Take a look ath this diff: --- /etc/nsmb.conf Wed Jan 30 05:31:21 2002 +++ ./etc/nsmb.conf Wed Feb 6 16:20:55 2002 @@ -1,4 +1,4 @@ -# $FreeBSD: src/etc/nsmb.conf,v 1.4 2002/01/29 00:23:34 cjc Exp $ +# $FreeBSD: src/etc/nsmb.conf,v 1.3 2002/01/07 08:41:55 sheldonh Exp $ # # smbfs lookups configuration files in next order: # 1. ~/.nsmbrc [and then, the wise mergemaster asks...] Use 'd' to delete the temporary ./etc/nsmb.conf Use 'i' to install the temporary ./etc/nsmb.conf Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again [urkkk... how many more to go?] Diffs like there show up for COUNTLESS times in mergemaster. In fact, nothing changed except the cvs id. Why am I asked about these in mergemaster? Is there a way to ignore files that only have the cvsid changed? This would speed up the mergemaster run considerably... Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
Diffs like there show up for COUNTLESS times in mergemaster. In fact, nothing changed except the cvs id. Why am I asked about these in mergemaster? Is there a way to ignore files that only have the cvsid changed? This would speed up the mergemaster run considerably... mergemaster only checks to see if RCSID's are different by default, I forget which option, but there is one to actually diff the two files when doing its inital compare, but the RCSID's would be different so I'm not sure it would help you. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
David == David W Chapman [EMAIL PROTECTED] writes: David mergemaster only checks to see if RCSID's are different by David default, I forget which option, but there is one to actually David diff the two files when doing its inital compare, but the David RCSID's would be different so I'm not sure it would help you. The real question here is: why is the RCSid changing when the file isn't? While it's not the end of the world, dealing with these noop merges gets annoying when you're updating large numbers of machines. If there's a simple fix to the problem (at the source), let's work on it. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
The real question here is: why is the RCSid changing when the file isn't? Sometimes things get changed and then backed out to their original state, but you cannot keep the original RCSID To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
David == David W Chapman [EMAIL PROTECTED] writes: David Sometimes things get changed and then backed out to their David original state, but you cannot keep the original RCSID I can see that happening on the head, but this also happens on stable ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
I can see that happening on the head, but this also happens on stable ... One example of it happening to -stable was the addittion of www to master.passwd, www has been added and removed a few times from -stable. I'm not trying to say that this explains all the times that it happens, just that it happens more than you might think. I think we need to keep track of the RCSID's of the new and old files that exhibit this problem to better be able to keep track of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
At 11:34 AM -0700 2/6/02, Lyndon Nerenberg wrote: David == David W Chapman [EMAIL PROTECTED] writes: David mergemaster only checks to see if RCSID's are different by David default, I forget which option, but there is one to actually David diff the two files when doing its inital compare, but the David RCSID's would be different so I'm not sure it would help you. The real question here is: why is the RCSid changing when the file isn't? While it's not the end of the world, dealing with these noop merges gets annoying when you're updating large numbers of machines. If there's a simple fix to the problem (at the source), let's work on it. I've seen this problem in the past. It occurs when you cvsup the repository down to a local copy contained within another CVSROOT. The $FreeBSD$ tags don't get expanded during checkout and will contain the previous revision tag. I believe the file to check is the CVSROOT/options file from the FreeBSD tree. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
What I think mergemaster should do is compere the file with the original checked out one it claims to be and if it's the same, it should just update silently.. i.e. if the user didn't change anything in th old one he's unlikely to want to change anything in the new one (maybe a datafile that contains cksum outputs for each version of each file) On Wed, 6 Feb 2002, David W. Chapman Jr. wrote: I can see that happening on the head, but this also happens on stable ... One example of it happening to -stable was the addittion of www to master.passwd, www has been added and removed a few times from -stable. I'm not trying to say that this explains all the times that it happens, just that it happens more than you might think. I think we need to keep track of the RCSID's of the new and old files that exhibit this problem to better be able to keep track of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
What I think mergemaster should do is compere the file with the original checked out one it claims to be and if it's the same, it should just update silently.. i.e. if the user didn't change anything in th old one he's unlikely to want to change anything in the new one (maybe a datafile that contains cksum outputs for each version of each file) I think part of the problem(from what I'm hearing on irc), someone made a lot of commits to etc which weren't supposed to happen, but I cannot confirm all the facts at the moment. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
