> > 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
Received on 2013-08-15 17:13:02 CEST