subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlel...@rockwellcollins.com
Subject Re: How to change paths on an external file without a full update --depth infinity?
Date Thu, 15 Aug 2013 15:12:09 GMT
> > 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


Mime
View raw message