Return-Path: 
 <users-return-19195-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-users-archive@minotaur.apache.org
Delivered-To: apmail-subversion-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id AC3C010E28
	for <apmail-subversion-users-archive@minotaur.apache.org>;
 Thu, 15 Aug 2013 21:04:06 +0000 (UTC)
Received: (qmail 17732 invoked by uid 500); 15 Aug 2013 21:04:04 -0000
Delivered-To: apmail-subversion-users-archive@subversion.apache.org
Received: (qmail 17681 invoked by uid 500); 15 Aug 2013 21:04:04 -0000
Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@subversion.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@subversion.apache.org>
List-Post: <mailto:users@subversion.apache.org>
List-Id: <users.subversion.apache.org>
Delivered-To: mailing list users@subversion.apache.org
Received: (qmail 17058 invoked by uid 99); 15 Aug 2013 21:03:56 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 21:03:56 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of dlellis@rockwellcollins.com
 designates 205.175.225.241 as permitted sender)
Received: from [205.175.225.241] (HELO secvs02.rockwellcollins.com)
 (205.175.225.241)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 21:03:48 +0000
Received: from nosuchhost.198.131.in-addr.arpa (HELO
 collinscrsmtp01.rockwellcollins.com) ([131.198.63.132])
  by mail-virt.rockwellcollins.com with ESMTP; 15 Aug 2013 16:03:27 -0500
In-Reply-To: 
 <CAOAgVpy9CdUKuCHTeDGFTgow+xoWeukNR9L3knbNQ2ZGbX9Bxg@mail.gmail.com>
References: 
 <OFF155594E.21E036B5-ON88257BC2.007E8623-88257BC2.007F0B83@rockwellcollins.com>
	<OF0D541C73.2F69F9D2-ON86257BC7.006553D1-86257BC7.0067B4C5@LocalDomain>
	<OFD66E75A7.68AF0CA6-ON88257BC7.00682D53-88257BC7.0068BF0C@rockwellcollins.com>
	<CAOAgVpxRMbT4odtwfnVQaEygOE3+TxpzUP8xfLRz3b1ykS_6Kw@mail.gmail.com>
	<CAOAgVpwoevspt6jPk_f-A=guagiM1jaQm5fsBAEFY+aCO64+Uw@mail.gmail.com>
	<CAOAgVpyOHW5vzGwcnJdQDc02E8j98amAA=cvEKUoz_Jfqm6n3g@mail.gmail.com>
	<37BDE060-8006-43D0-A62E-CEB19DF86B98@ryandesign.com>
	<CAOAgVpw-OQmVV352rApN1hpWrvJbLVaYagoynzLG2NqrDiGL7Q@mail.gmail.com>
	<OFF7E6ED96.EB992F54-ON88257BC8.00577C39-88257BC8.0060F644@rockwellcollins.com>
	<CAOAgVpwi_Gkb9mqSMWr4aOWWNx1bdG+y=wMsoDXeH4-uhX+8JA@mail.gmail.com>	<OF6CB3
 <CAOAgVpy9CdUKuCHTeDGFTgow+xoWeukNR9L3knbNQ2ZGbX9Bxg@mail.gmail.com>
X-Disclaimed: 47338
To: Les Mikesell <lesmikesell@gmail.com>
Cc: Ben Reser <breser@apache.org>,
	Ivan Zhakov <ivan@visualsvn.com>,
	Johan Corveleyn <jcorvel@gmail.com>,
	kmradke@rockwellcollins.com,
	Ryan Schmidt <subversion-2012c@ryandesign.com>,
	"users@subversion.apache.org" <users@subversion.apache.org>
MIME-Version: 1.0
Subject: Re: How to change paths on an external file without a full update
 --depth
 infinity?
X-KeepSent: 25B757CA:A9F32B77-88257BC8:00736E2C;
 type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP2 March 23, 2011
From: dlellis@rockwellcollins.com
Message-ID: 
 <OF25B757CA.A9F32B77-ON88257BC8.00736E2C-88257BC8.0073AC2C@rockwellcollins.com>
Date: Thu, 15 Aug 2013 14:03:27 -0700
X-MIMETrack: Serialize by Router on
 CollinsCRSMTP01/CedarRapids/Collins/Rockwell(Release
 8.5.2FP2 HF162|May 16, 2011) at 08/15/2013 04:03:28 PM,
	Serialize complete at 08/15/2013 04:03:28 PM
Content-Type: multipart/alternative;
 boundary="=_alternative 0073AC1088257BC8_="
X-Virus-Checked: Checked by ClamAV on apache.org

This is a multipart message in MIME format.
--=_alternative 0073AC1088257BC8_=
Content-Type: text/plain; charset="US-ASCII"

> >
> > It commits a new revision of what the file external pointed to - 
pretty
> > handy.  If you are pegged, it will not automagically update your 
pegged
> > revision (as I'd expect), so unless you are on the HEAD or update your 
peg
> > to what just committed, an update will revert your WC back to the 
pegged
> > version.
> 
> I'd actually expect it to be pretty confusing if you had multiple
> people committing changes based from different back-rev pegged
> references anywhere near the same time frame.  Does your external
> 'notify about new versions' tool help with that?   Don't you get
> conflicting changes that you'd want branches to help isolate?

Yes, its obvious to users when they are not on the latest revision of the 
file, but they c/would still go through a merge process if need be.

Its actually very straight-forward as we intentionally focused on 
targeting non-CM-guru folks.

--=_alternative 0073AC1088257BC8_=
Content-Type: text/html; charset="US-ASCII"

<tt><font size=2><br>
&gt; &gt;<br>
&gt; &gt; It commits a new revision of what the file external pointed to
- pretty<br>
&gt; &gt; handy. &nbsp;If you are pegged, it will not automagically update
your pegged<br>
&gt; &gt; revision (as I'd expect), so unless you are on the HEAD or update
your peg<br>
&gt; &gt; to what just committed, an update will revert your WC back to
the pegged<br>
&gt; &gt; version.<br>
&gt; <br>
&gt; I'd actually expect it to be pretty confusing if you had multiple<br>
&gt; people committing changes based from different back-rev pegged<br>
&gt; references anywhere near the same time frame. &nbsp;Does your external<br>
&gt; 'notify about new versions' tool help with that? &nbsp; Don't you
get<br>
&gt; conflicting changes that you'd want branches to help isolate?<br>
</font></tt>
<br><tt><font size=2>Yes, its obvious to users when they are not on the
latest revision of the file, but they c/would still go through a merge
process if need be.</font></tt>
<br>
<br><tt><font size=2>Its actually very straight-forward as we intentionally
focused on targeting non-CM-guru folks.</font></tt><font size=2 face="sans-serif"><br>
</font>
--=_alternative 0073AC1088257BC8_=--