X-Sylpheed-Account-Id:1
S:andy.sharp@onstor.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E04FA7766@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 13 Aug 2007 14:03:23 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Ken Renshaw" <ken.renshaw@onstor.com>
Cc: "dl-Cougar" <dl-Cougar@onstor.com>, "Paul Hammer"
 <paul.hammer@onstor.com>
Subject: Re: dev branch missing all history
Message-ID: <20070813140323.478a170e@ripper.onstor.net>
References: <20070810111746.0b005e43@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E04FA7766@onstor-exch02.onstor.net>
Organization: Onstor
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Fine, Ken, if you want to air our dirty laundry in front of everyone,
then so be it.

It was not my intention to accost you or insult you.  So first off let
me apologize about that.

My tone speaks more about my general frustration than anything else. I
tried to come talk to you about this maybe ten times, maybe more,
over a period of more than a week, and could not find you on any of
those occassions. That makes it very difficult to have a discussion.

The frustration mounts additionally because I'm pretty sure you know
what I'm talking about, probably better than I do, but I never seem to
quite be able to get a complete explanation of the things I'm trying to
understand.  At least not when we are confined to email.  Without the
back and forth, it seems like we're just not understanding one another.

The integrate -i is about integrating changes from a branch back to
main, so that the changes aren't lost from the branch. Apparently I
didn't explain myself properly about that.  A person has to use the -i
in cases where integrations have been done branch-to-branch and there is
no common history of changes, hence the histories are lost.  That's
my understanding of the documention which I did read to the best of
my abilities.  It's probably infantile compared to your understanding
and maybe that's why you're not understanding me.  You are right that
the data isn't lost, because the integration histories are there But
that doesn't really help an engineer doing his/her job, once the number
of integrations goes past a certain number.

I realize that the information can be found if you are an advanced
enough user, which your explanation of how to do it demonstrates.  But
most of the users of this tool just aren't advanced enough and never
will be.  So I'm trying to figure out how us l-users can get the
benefit of the tool without having to become perforce power users.

I guess I will just give up, because I can never seem to find you when
I want to discuss this, and whenever I send an email it's after some
frustration has compounded and I come off like a bully, and I don't
want that either.  I think you said in one of your emails that we will
now start to build up a history of changes to files.  I'm not really
sure what you meant but I will just take it to mean what I hope it
means.

Again, I offer my apologies for offending or insulting.

a

On Mon, 13 Aug 2007 12:14:45 -0700 "Ken Renshaw"
<ken.renshaw@onstor.com> wrote:

> I'm putting your response back on dl-cougar Andy, both to make sure
> people do not get the wrong information and to make sure I am not
> misrepresented.
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Friday, August 10, 2007 11:18 AM
> To: Ken Renshaw
> Subject: Re: dev branch missing all history
> 
> On Mon, 6 Aug 2007 12:20:38 -0700 "Ken Renshaw"
> <ken.renshaw@onstor.com> wrote:
> 
> > Nothing is 'lost' Andy so there's nothing to harp about. Creating a
> > new branch obviously starts over at revision #1 for a given file,
> > plain and simple. In the 2 meetings we had we all talked about the
> > fact that in going to a new single branch the local histories would
> > be reset for the reason just stated, and would be less important
> > over time.
> 
> AS> As our perforce expert I'm astounded that you would claim that
> revisions 'have to' start at 1 in a new branch.  That's just not
> true and I know you know that.
> 
> The file history is lost, that's plenty to harp about. Yes, through
> the integration history, theoretically anything can be found, but
> then why do we need this tool?  It's not doing anything for us we
> can't do ourselves with no tools other than 'cp' and 'mkdir'. It's
> supposed to make this stuff easier, and spelunking through a
> gazillion branches is not easier.  And then we can never archive off
> and retire any branches.
> 
> If we are doing our branching and integrating correctly, the histories
> aren't lost.  Yes, if we are doing them incorrectly, then histories
> start over at revision #1 in each branch, but that's not the way it's
> supposed to work.  You should [almost] never have to do a 'p4
> integrate -i' to create a branch.  Certainly not when you are
> creating a branch off of _main_ or returning changes to _main_ from a
> branch.
> 
> If you think our current results are adequate, just try and research
> the history of changes to a file like
> nfx-tree/code/ssc-nfxsh/cmd_system.c.  It's absurd to even try.  I
> popped up the revision history of said file, and I've attached the
> picture that came up.  I think it's a pretty clear illustration of
> what I'm trying to impart.
> 
> 
> KLR> Your statements above are completely incorrect and misinformed
> Andy, please do not hold to them or propagate them to others. In
> correcting them one need not look any further than the first two dozen
> pages of the Introduction to Perforce:
> 
> http://www.perforce.com/perforce/doc.072/manuals/intro/intro.pdf
> 
> On the top of page 21, under the Branching and Integration chapter, it
> clearly states:
> 
> * when you submit the changelist with the target files, the target
> files in the new codeline are at revision #1
> 
> * integration records enable you to examine the history of files in
> the new codeline, including the fact that they were created by means
> of integration from the source files.
> 
> The very definitions of branching and revision control dictate the
> branched files do *not* keep the same revision number...how could
> they? For example, if you branched main#5 into two concurrent release
> or project branches, they both obviously can't be #6 by your
> logic...the branch information is part and parcel of the revision
> histories for a file. The second bullet item above reiterates that
> the integration records are an integral part of the history and must
> be used, which is precisely the same reason you need to use the
> filelog command instead of fstat, which is what you used to provoke
> this whole discussion in the first place.
> 
> After starting off with your incorrect statements of fact, you then
> went on to insult me further and imply I don't know how to do
> branching or SCM properly, and then go on to make yet another
> incorrect statement about creating branches with the p4 integrate -i
> flag, and that that's the reason why you think things are messed up
> in the first place.
> 
> Huh???
> 
> Again, if you take just a few minutes to stop and read anything at all
> about creating branches in Perforce, you'd know that the -i flag has
> no meaning in branch creation. By definition, files are created as
> children out of a parent branch, therefore it's impossible to have an
> 'indirectly-branched' branch. It makes no sense to state that, and in
> any case shows no understanding of the underlying mechanisms. Like I
> said, this is all in the Intro guides, so it's no big secret.
> 
> Lastly, you use as an example an unfiltered branch graph of
> cmd_system.c and state it too bewildering to use. If you look up the
> Help or Intro to P4V, or just look at the Filtering pane on the left,
> you'll find that the thing to do if you're going to go that route is
> to filter out all the branches that aren't relevant. For most intents
> and purposes the list should contain the current working branches,
> the currently supported release and maintenance branches, and the
> last couple project branches. This will give you everything you need
> in almost all cases, and with a branch graph of maybe 5-10 branches
> total for past, present, and future, it becomes quite easy to figure
> things out. You can see this from the attached output of my P4V
> revision graph for the file cmd_system.c. From here you simply
> left-click on any revision point on the graph and select 'Diff From
> Previous Revision' to see that change, or use the more general
> 'Diff...' entry from the pop-up menu to act as a front end to diffing
> anything in the depot via the p4 diff2 command functionality. When
> you have your graph filtered as you like, click on the Cog menu item
> and edit the 'Default Settings for Filter Tree', setting your current
> view as the default.
> 
> Alternatively, you can also use the Time-Lapse View instead of
> Revision Graph and enable Show Integration History, Multiple
> Revisions, and Show Lifetimes, to get a different view into a file's
> evolution inline with the source code.
> 
> -Ken
> 
> P.S. You don't have to come off belligerent and confrontational all
> the time Andy, especially when it's clear you haven't taken the time
> to get your facts straight about the tools, or about me. All of these
> things could have been brought up much more productively as "How do I
> do thus-and-so?" or "Is there an easier way to do this particular
> task?" instead of your method of accosting people. I think your
> fellow ONStor employees deserve at least some civility from you, and
> I can state personally that you quickly lose my interest and support
> with your current methods of communication.
