X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8A836.4DD64840@onstor-exch02.onstor.net>; Sun, 27 Apr 2008 00:14:16 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8A836.4DD64840"
References: <WEBMAILcafI0L2XFGux000005af@mail.onstor.com><BB375AF679D4A34E9CA8DFA650E2B04E04344C66@onstor-exch02.onstor.net> <20080426150504.195c0b39@ripper.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: PERFORCE change 28985 for review
Date: Sun, 27 Apr 2008 00:14:16 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0714BC84@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PERFORCE change 28985 for review
Thread-Index: Acin6ZYVvIhOXPsjS6qnoK7IpCVGeAAS001F
From: "Danqing Jin" <danqing.jin@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>
Cc: "Larry Scheer" <larry.scheer@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8A836.4DD64840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry folks...

I think the fundamental problem is in my workflow where I always (at =
least most of the time) start with the release/maintenance branch to =
simulate the issue and then make and test changes there.  Once checking =
in the changes in the release branch then I integrate them back to dev.  =
I remember I was not so sure initially whether I was doing this the =
right way as the rule was changed to integrate from dev to other =
branches (starting around R98 time frame), so I asked a few people just =
to make sure I wasn't too off, and the impression I got is that it is =
best to follow the rule but it should be ok as long as dev branch is in =
sync with the maintenance branch when it is appropriate for a particular =
change to go into dev.  From now on I will be following the rule =
strictly unless there are real good reasons not to.

Thanks,
-Danqing-

-----Original Message-----
From: Andy Sharp
Sent: Sat 4/26/2008 3:05 PM
To: Tim Gardner
Cc: Danqing Jin; Larry Scheer
Subject: Re: PERFORCE change 28985 for review
=20
As long as there was a common parent in both branches, it doesn't
matter which way you do the integrate.  But if there wasn't, then this
kind of integrate could wipe out the history of a file in dev, so it
should be done carefully and sparingly.

On Fri, 25 Apr 2008 21:41:43 -0700 "Tim Gardner"
<tim.gardner@onstor.com> wrote:

> Why are changes being integrated from a release branch into dev?
> Changes are supposed to be made in dev and pushed out to release
> branches.
>=20
> ________________________________
>=20
> From: Danqing Jin
> Sent: Fri 4/25/2008 5:20 PM
> To: Amit Bothra; Andy Sharp; Chris Vandever; Danqing Jin; Deepak
> Veliath; Eric Barrett; Henry Lau; Ian Brown; Jan Seidel; Jobi
> Ariyamannil; Jonathan Goldick; Larry Scheer; Maxim Kozlovsky; Mike
> Lee; Narain Ramadass; Sandrine Boulanger; Sripal Surendiran (HCL);
> Svati Chandra; Tim Gardner; YiFeng Liu Subject: PERFORCE change 28985
> for review
>=20
>=20
>=20
> Change 28985 by danqingj@danqingj-dev on 2008/04/25 17:15:31
>=20
>         Integrate change 28983 from R3_1_0_rel branch to dev.
>       =20
>         Changes for defect 23447 to close the window in
>         fs_dr_rmcInitiateFS2SSCSession() where rmc_open() succeeds
>         but fs_dr_rmcOpenYield() has not received ack for the open.
>       =20
>         Reviewed by: narainr
>=20
> Affected files ...
>=20
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.c#3 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.h#2 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump.c#18 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-restore.c#4 integrate
>=20
>=20
> http://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10
>=20
>=20


------_=_NextPart_001_01C8A836.4DD64840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: PERFORCE change 28985 for review</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Sorry folks...<BR>
<BR>
I think the fundamental problem is in my workflow where I always (at =
least most of the time) start with the release/maintenance branch to =
simulate the issue and then make and test changes there.&nbsp; Once =
checking in the changes in the release branch then I integrate them back =
to dev.&nbsp; I remember I was not so sure initially whether I was doing =
this the right way as the rule was changed to integrate from dev to =
other branches (starting around R98 time frame), so I asked a few people =
just to make sure I wasn't too off, and the impression I got is that it =
is best to follow the rule but it should be ok as long as dev branch is =
in sync with the maintenance branch when it is appropriate for a =
particular change to go into dev.&nbsp; From now on I will be following =
the rule strictly unless there are real good reasons not to.<BR>
<BR>
Thanks,<BR>
-Danqing-<BR>
<BR>
-----Original Message-----<BR>
From: Andy Sharp<BR>
Sent: Sat 4/26/2008 3:05 PM<BR>
To: Tim Gardner<BR>
Cc: Danqing Jin; Larry Scheer<BR>
Subject: Re: PERFORCE change 28985 for review<BR>
<BR>
As long as there was a common parent in both branches, it doesn't<BR>
matter which way you do the integrate.&nbsp; But if there wasn't, then =
this<BR>
kind of integrate could wipe out the history of a file in dev, so it<BR>
should be done carefully and sparingly.<BR>
<BR>
On Fri, 25 Apr 2008 21:41:43 -0700 &quot;Tim Gardner&quot;<BR>
&lt;tim.gardner@onstor.com&gt; wrote:<BR>
<BR>
&gt; Why are changes being integrated from a release branch into =
dev?<BR>
&gt; Changes are supposed to be made in dev and pushed out to =
release<BR>
&gt; branches.<BR>
&gt;<BR>
&gt; ________________________________<BR>
&gt;<BR>
&gt; From: Danqing Jin<BR>
&gt; Sent: Fri 4/25/2008 5:20 PM<BR>
&gt; To: Amit Bothra; Andy Sharp; Chris Vandever; Danqing Jin; =
Deepak<BR>
&gt; Veliath; Eric Barrett; Henry Lau; Ian Brown; Jan Seidel; Jobi<BR>
&gt; Ariyamannil; Jonathan Goldick; Larry Scheer; Maxim Kozlovsky; =
Mike<BR>
&gt; Lee; Narain Ramadass; Sandrine Boulanger; Sripal Surendiran =
(HCL);<BR>
&gt; Svati Chandra; Tim Gardner; YiFeng Liu Subject: PERFORCE change =
28985<BR>
&gt; for review<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; Change 28985 by danqingj@danqingj-dev on 2008/04/25 17:15:31<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integrate change =
28983 from R3_1_0_rel branch to dev.<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Changes for defect =
23447 to close the window in<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
fs_dr_rmcInitiateFS2SSCSession() where rmc_open() succeeds<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but =
fs_dr_rmcOpenYield() has not received ack for the open.<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by: =
narainr<BR>
&gt;<BR>
&gt; Affected files ...<BR>
&gt;<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.c#3 =
integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.h#2 =
integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump.c#18 integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-restore.c#4 integrate<BR>
&gt;<BR>
&gt;<BR>
&gt; <A =
HREF=3D"http://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10">h=
ttp://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10</A><BR>
&gt;<BR>
&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8A836.4DD64840--
