Conference smurf::buildhelp

Date Of Receipt: 	 2-FEB-1994 11:13:00.16
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE  02-Feb-1994 1112"
To: 	Mike Thomas <[email protected]>
CC: 	[email protected], decwet::odestaff
Subj: 	Re: Proposed merge ancestor information in change history

Mike, here are some first impressions... 

I don't really get the purpose of saving the command line, as long as you
have the ancestral information.

As long as you do save the command line, I don't see the need to have
saved the full path to the command - it chews up a whole line of space,
and I don't think it represents important information.

I'm concerned that you could get some VERY long comment lines.  Something
I do, and others may do, is to use file lists or wildcards instead of -all
in a bsubmit or bmerge, eg:
    bsubmit -auto_out -defect goldos-123-jmf `cat long-list-of-files`
which could yield many, MANY lines of files wrapped into one long line.

Perhaps, if it seems useful for some reason to know how the merge was
invoked, along with the ancestor info, if it were just recorded what
command was used "bmerge" or "bsubmit" -- not the whole path or the
whole command line - that would be less clutter...

eg:
 *	{:cmd=bmerge:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}
or:
 *	{:cmd=bsubmit:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}

Of course, you recognize that the "user_rev" will probably no longer exist,
after the submit is done.

-josh

--------
Return-Path: [email protected] 
Delivery-Date: Tue, 01 Feb 94 12:16:33 -0500
Return-Path: [email protected]
Received: from n7oxx.zso.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/20Jan94-0322PM)
	id AA29850; Tue, 1 Feb 1994 12:16:13 -0500
Received: by n7oxx.zso.dec.com (5.57/DECwest-WS-cjf-16Dec92)
	id AA06053; Tue, 1 Feb 94 09:15:55 -0800
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Proposed merge ancestor information in change history
Date: Tue, 01 Feb 94 09:15:54 -0800
From: Mike Thomas <[email protected]>
X-Mts: smtp

The DECode II team has identified the need to log certain information when a
merge occurs as a result of running either bmerge or bsubmit (but *not*
'bco -j'). The information will be enclosed within delimiters that we expect
will be relatively easy to parse and close to unique within the change
history.

The information recorded will be :

	The command line
	The user revision of the file
	The ancestor revision of the file
	The merge revision of the file

Having this information available will better enable us to track down problems
that occur when merging.

In the case of a bsubmit that results in a merge, the information will be
prepended to the log information provided by the user. For example :

 * HISTORY
 * $Log: test999.h,v $
 * Revision 1.1.2.8  1994/01/31  23:20:44  Mike_Thomas
 *	{:cmd_line=/usr/sde/ode2.0/tools/alpha_OSF1/bin/bsubmit
-auto_out -auto -fn Testing -all:}
 *	{:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}
 *	This is whatever comment the user provided
 *	[1994/01/31  23:11:17  Mike_Thomas]

In the case of a bmerge, the information will be inserted into the user's file
after the HISTORY keyword. For example :

 * HISTORY
 * {:cmd_line=/usr/sde/ode2.0/tools/alpha_OSF1/bin/bsubmit -auto_out
-auto -fn Testing -all:}
 * {:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}
 * $Log: test999.h,v $

The change to bmerge is dependant upon the fixing of PTT ODE-00264, regarding
'bci -m'. Even so, the information in the file is still at risk of modification
or removal by the user.

Comments are welcome.

	Mike

Date Of Receipt: 	 2-FEB-1994 12:07:01.47
From: 	ALPHA::"[email protected]" "Jim McGinness"
To: 	[email protected]
CC: 	[email protected]
Subj: 	Re: Proposed merge ancestor information in change history

I didn't think I was going to step into this, but I have a few comments
after all.

Are you purposely trying to make this hard to read?  The stuff is already
inside a comment, so a very simple text format ought to suffice.  And when
the user has used a symbolic label, you probably need to show the Rev that
resolved to at the time of the merge/bsubmit, since the label doesn't
necessarily continue point to the same Rev as the project proceeds.

Something more like (example from src/Makefile):

 * Revision 4.3.12.4  1993/04/01  19:55:21  Michael_Fairbrother
 *	Merge Information
 *	  Command used: bsubmit
 *	  Ancestor: 4.3.2.1
 *	  From: AG_BL5 (resolved to 4.3.2.2)
 *	  To: AG_NIGHTLY (resolved to 4.3.2.4)
 *	ODE-II suggests ... [remainder is the users' comment]
 *	.
 *	.

Date Of Receipt: 	 2-FEB-1994 12:50:13.25
From: 	US2RMC::"[email protected]" "Grant Van Dyck"
To: 	[email protected] (Jim McGinness)
CC: 	[email protected], [email protected]
Subj: 	Re: Proposed merge ancestor information in change history

That looks nice - even if it does take 6 lines.


	-Grant

| I didn't think I was going to step into this, but I have a few comments
| after all.
| 
| Are you purposely trying to make this hard to read?  The stuff is already
| inside a comment, so a very simple text format ought to suffice.  And when
| the user has used a symbolic label, you probably need to show the Rev that
| resolved to at the time of the merge/bsubmit, since the label doesn't
| necessarily continue point to the same Rev as the project proceeds.
| 
| Something more like (example from src/Makefile):
| 
|  * Revision 4.3.12.4  1993/04/01  19:55:21  Michael_Fairbrother
|  *	Merge Information
|  *	  Command used: bsubmit
|  *	  Ancestor: 4.3.2.1
|  *	  From: AG_BL5 (resolved to 4.3.2.2)
|  *	  To: AG_NIGHTLY (resolved to 4.3.2.4)
|  *	ODE-II suggests ... [remainder is the users' comment]
|  *	.
|  *	.
| 

% Received: 	by us2rmc.bb.dec.com; id AA10927; Wed, 2 Feb 94 12:47:25 -0500
	from localhost by cardinal.zk3.dec.com; (5.65/1.1.8.2/01Nov93-1038AM) id AA17059; Wed, 2 Feb 1994 12:50:04 -050
% Message-Id: 	<[email protected]>
% To: 	[email protected] (Jim McGinness)
% Cc: 	[email protected], [email protected]
% Subject: 	Re: Proposed merge ancestor information in change history
% In-Reply-To: 	Your message of "Wed, 02 Feb 94 12:06:56 EST." <[email protected]>
% Date: 	Wed, 02 Feb 94 12:50:04 -0500
% From: 	Grant Van Dyck <[email protected]>
% X-Mts: 	smtp

Date Of Receipt: 	 2-FEB-1994 14:59:57.59
From: 	ALPHA::"[email protected]" "Jim McGinness"
To: 	[email protected]
CC: 	[email protected]
Subj: 	Re: Proposed merge ancestor information in change history

I guess I don't understand the aim very well....

I hope you've thought hard about fixing RCS to store the relevant
information about merges in a way that makes more sense than the
current method--where the changes are essentially stored twice--if
you're really concerned about saving bytes.

[The whole point of merges is to apply logically identical deltas
along different branches, but RCS ties the deltas to physical line
numbers.  After a merge, the line numbers of the two deltas end up
being different while the *content* of the deltas is the same.]

	-- jmcg

Date Of Receipt: 	 3-FEB-1994 12:03:11.04
From: 	ALPHA::"[email protected]" "02-Feb-1994 1010"
To: 	[email protected]
CC: 	[email protected], decwet::odestaff, [email protected]
Subj: 	Re: Proposed merge ancestor information in change history

No, not purposefully, but it wasn't our intent for it to be easily human
readable.

The intent was to have something with a fairly strict syntax so that a tool
could reliably parse it out. We were also concerned that those few extra
characters of comment leader, tab, and newline, when multiplied by many files,
would eat up too much disk space.

However, if the overall preference is for better human readability, we can do
that.

Thanks ... Mike

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-Ultrix/4.3)
	id AA24211; Wed, 2 Feb 1994 12:06:56 -0500
Date: Wed, 2 Feb 1994 12:06:56 -0500
From: [email protected] (Jim McGinness)
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: Proposed merge ancestor information in change history
Cc: [email protected]

I didn't think I was going to step into this, but I have a few comments
after all.

Are you purposely trying to make this hard to read?  The stuff is already
inside a comment, so a very simple text format ought to suffice.  And when
the user has used a symbolic label, you probably need to show the Rev that
resolved to at the time of the merge/bsubmit, since the label doesn't
necessarily continue point to the same Rev as the project proceeds.

Something more like (example from src/Makefile):

 * Revision 4.3.12.4  1993/04/01  19:55:21  Michael_Fairbrother
 *	Merge Information
 *	  Command used: bsubmit
 *	  Ancestor: 4.3.2.1
 *	  From: AG_BL5 (resolved to 4.3.2.2)
 *	  To: AG_NIGHTLY (resolved to 4.3.2.4)
 *	ODE-II suggests ... [remainder is the users' comment]
 *	.
 *	.

Date Of Receipt: 	 3-FEB-1994 12:06:21.57
From: 	ALPHA::"[email protected]" "02-Feb-1994 0838"
To: 	WASTED::jmf
CC: 	[email protected], decwet::odestaff, [email protected]
Subj: 	Re: Proposed merge ancestor information in change history

Josh,

Good point about the length of the command line. The intent was to record
what revisions (if any) were specified by the user, expecially if labels are
used rather than numeric values.

How about reducing the command line portion to just the name of the command and
any revisions specified?

I think we could then put the abbreviated command line information on the same
line as the ancestor information. For example :

 *	{:cmd=bmerge
-jREV1:REV2:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}

Hmmm, seeing this makes me think that the colon is not the best choice for a
separator of these fields if all the information is on one line. How about '{:'
for the beginning of the information, ':}' for the end, and '|' for the
separator? For example :

 *	{:cmd=bmerge
-jREV1:REV2|user_rev=1.1.4.2|ancestor_rev=1.1.2.6|merge_rev=1.1.2.7:}

Thanks ... Mike

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Return-Path: OLEUM::"WASTED::[email protected]"
Date: Wed, 2 Feb 94 08:13:08 -0800
From: OLEUM::"WASTED::[email protected]" (02-Feb-1994 0811 -0700)
To: Mike Thomas <[email protected]>
Cc: [email protected], decwet::odestaff
Subject: Re: Proposed merge ancestor information in change history

Mike, here are some first impressions... 

I don't really get the purpose of saving the command line, as long as you
have the ancestral information.

As long as you do save the command line, I don't see the need to have
saved the full path to the command - it chews up a whole line of space,
and I don't think it represents important information.

I'm concerned that you could get some VERY long comment lines.  Something
I do, and others may do, is to use file lists or wildcards instead of -all
in a bsubmit or bmerge, eg:
    bsubmit -auto_out -defect goldos-123-jmf `cat long-list-of-files`
which could yield many, MANY lines of files wrapped into one long line.

Perhaps, if it seems useful for some reason to know how the merge was
invoked, along with the ancestor info, if it were just recorded what
command was used "bmerge" or "bsubmit" -- not the whole path or the
whole command line - that would be less clutter...

eg:
 *	{:cmd=bmerge:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}
or:
 *	{:cmd=bsubmit:user_rev=1.1.4.2:ancestor_rev=1.1.2.6:merge_rev=1.1.2.7:}

Of course, you recognize that the "user_rev" will probably no longer exist,
after the submit is done.

-josh