On Fri, Oct 19, 2012 at 1:00 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> Oh yes. Eventually I'd like to see something like this:
>
> * The functionality of repo-relative externals replaced with some
> flavour of in-repo links, so that the client doesn't even have to
> know about them.
> o ... though quite likely the client will have to have /some/ way
> to know about the fact that it can see the same file twice under
> different paths in the WC
> * Most of the current uses of externals to other repositories replaced
> by better handling of remote branches (including support for remote
> merges) -- Julian and I have talked on and off about how to
> implement this.
Indeed remote merges would be helpful to a lot of workflows. Our
support for vendor branches could essentially be fixed by this and
Subversion front ends to other version control systems have become so
prevalent that people could even merge from other version control
systems.
> This only leaves the case where you really want to pull the WC together
> from different repositories, and that would require new UI to exploit
> the potential of WC-NG. I'd recomment starting by:
>
> * deprecating the svn:externals property
> * completely deprecating file externals (in the sense that,
> eventually, we'd stop supporting including files from external
> repositories in the working copy).
>
> I know this will seem like a step backward, but really, I can't think of
> a good argument for continuing to indefinitely support a feature that we
> knew was broken from day one.
That's roughly what I was thinking. I hadn't really considered the
file external case. What are the problems with it (it's been added
since I haven't been active and I've never used it so I have no idea
what the problems are with it)?
Received on 2012-10-21 20:50:17 CEST