> > 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
