Return-Path: 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 7770710FB7 for ; Thu, 15 Aug 2013 15:12:56 +0000 (UTC) Received: (qmail 77808 invoked by uid 500); 15 Aug 2013 15:12:54 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 77753 invoked by uid 500); 15 Aug 2013 15:12:47 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 77733 invoked by uid 99); 15 Aug 2013 15:12:46 -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 15:12:46 +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 15:12:38 +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 10:12:10 -0500 In-Reply-To: <37BDE060-8006-43D0-A62E-CEB19DF86B98@ryandesign.com> References: <37BDE060-8006-43D0-A62E-CEB19DF86B98@ryandesign.com> X-Disclaimed: 2334 To: Ryan Schmidt Cc: Les Mikesell , Ben Reser , Ivan Zhakov , Johan Corveleyn , kmradke@rockwellcollins.com, "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: 70DC95BB:476E4D6C-88257BC8:00500561; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP2 March 23, 2011 From: dlellis@rockwellcollins.com Message-ID: Date: Thu, 15 Aug 2013 08:12:09 -0700 X-MIMETrack: Serialize by Router on CollinsCRSMTP01/CedarRapids/Collins/Rockwell(Release 8.5.2FP2 HF162|May 16, 2011) at 08/15/2013 10:12:11 AM, Serialize complete at 08/15/2013 10:12:11 AM Content-Type: multipart/alternative; boundary="=_alternative 0053826688257BC8_=" X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. --=_alternative 0053826688257BC8_= Content-Type: text/plain; charset="US-ASCII" > > Once you copy, you break the link. If you were to make a change to the > > copy, no one else would then see it. > > No one else would see it with externals either, except that you > wrote a custom tool to analyze the externals, see if a newer > revision of the original exists, and show that to the user. If you > can do that with externals, you can do that with copies too. (Use > "svn log --stop-on-copy" to find out where the copy came from, then > see if there are newer revisions of that.) The challenge I then see on this is one of finding all instances of foo.c. If you have foo.c copied/forked fifty times to different projects, each of which has branched a couple of times, how do you programmatically find all different instances of foo.c (to let a developer choose which may be most appropriate?) If you have good ideas, I'm very open to listening. Also if you have to projects that both want foo.c and both have valid changes to make to the file, how does that get managed when they are copies? Its a trivial implementation when it is implemented as a file external. We also have instances where we purposely want multiple copies of the same exact file within the same project. We can effectively manage this through file externals to a structured "datastore" (AKA a set of folders within a repo). Regardless of where and how a team decides to structure their project, all files are neatly organized in this one section of the repo (that is considered taboo to directly interact with). The ability to have a specific file having many "copies" of itself and not care about its position within the repository is a powerful feature. I understand this may diverge a bit from SVN's core thoughts on CM, but if SVN can support odd variations to its use, it becomes an even more indispensable building block. Diversity in approaches is good. >From a feature perspective, externals are a very appropriate method to accomplish this (really a CM implementation of symlinks). If we're saying that externals from an implementation standpoint are not quite appropriate at this time, I get that argument. What is the general consensus as to where externals are on the roadmap? I may not convince the team that externals are really really useful (even if abused) in this application, but I'm hoping that the team does appreciate the general usefulness of externals and keeps maturing the feature. Thanks Dan --=_alternative 0053826688257BC8_= Content-Type: text/html; charset="US-ASCII"
> > Once you copy, you break the link.  If you were to make a change to the
> > copy, no one else would then see it.
>
> No one else would see it with externals either, except that you
> wrote a custom tool to analyze the externals, see if a newer
> revision of the original exists, and show that to the user. If you
> can do that with externals, you can do that with copies too. (Use
> "svn log --stop-on-copy" to find out where the copy came from, then
> see if there are newer revisions of that.)

The challenge I then see on this is one of finding all instances of foo.c.  If you have foo.c copied/forked fifty times to different projects, each of which has branched a couple of times, how do you programmatically find all different instances of foo.c (to let a developer choose which may be most appropriate?)  If you have good ideas, I'm very open to listening.

Also if you have to projects that both want foo.c and both have valid changes to make to the file, how does that get managed when they are copies?  Its a trivial implementation when it is implemented as a file external.  

We also have instances where we purposely want multiple copies of the same exact file within the same project.  We can effectively manage this through file externals to a structured "datastore" (AKA a set of folders within a repo).  Regardless of where and how a team decides to structure their project, all files are neatly organized in this one section of the repo (that is considered taboo to directly interact with).  The ability to have a specific file having many "copies" of itself and not care about its position within the repository is a powerful feature.  I understand this may diverge a bit from SVN's core thoughts on CM, but if SVN can support odd variations to its use, it becomes an even more indispensable building block.  Diversity in approaches is good.

>From a feature perspective, externals are a very appropriate method to accomplish this (really a CM implementation of symlinks).  If we're saying that externals from an implementation standpoint are not quite appropriate at this time, I get that argument.  What is the general consensus as to where externals are on the roadmap?  

I may not convince the team that externals are really really useful (even if abused) in this application, but I'm hoping that the team does appreciate the general usefulness of externals and keeps maturing the feature.

Thanks
Dan

--=_alternative 0053826688257BC8_=--