On Thu, Aug 15, 2013 at 10:12 AM, <dlel...@rockwellcollins.com> wrote:
>
>> > 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.
There is no difference in that question than finding where the
'future' copies of a pegged external target went. You can only do
either if you have a convention for a canonical path.
> 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.
How so? I assume you also have to handle cases either way: where both
projects want the same change and where both projects need different
changes - where typical svn users would have branches/tags to
distinguish them. But regardless of how you identify the target
file, there shouldn't be any effective difference between copying a
version into your directory or using a file external as long as you
don't modify it in place and commit it back - something your external
tool could track.
> 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.
Again, you get the history in a copy. You can tell if they are the
same. Or, on unix-like systems you can use symlinks to a canonical
copy within the project.
> 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 agree that externals are very useful, but most projects would use
them at subdirectory levels for component libraries where they work
nicely, not for thousands of individual file targets. Is there
really no natural grouping - perhaps even of sets of combinations that
have been tested together that you could usefully group in
release-tagged directories?
> 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.
Please make the distinction between file externals - which are sort of
an exception with special handling, and normal externals. Subversion
uses directories as a natural sort of project container - which, not
surprisingly fits the model of most things you want to manage on
computers, and some reasonable number of directory-level externals
'just work' without special considerations. I'm not against better
performance, of course, but it makes sense to me to make pragmatic
design decisions for the same reasons you might avoid throwing
millions of files in one flat directory even in a non-versioned
scenario. Theoretically, you should be able to do that, but in
practice it isn't going to perform as well as something with better
structure.
--
Les Mikesell
lesmikes...@gmail.com
