On Wed, Sep 30, 2009 at 11:37:23AM -0400, Bob Archer wrote:
> >>On Wed, Sep 30, 2009 at 6:03 AM, Gabriel SCOLAN <gabriel.scolan_at_sagem.com<mailto:gabriel.scolan_at_sagem.com>> wrote:
> >>In version 1.6.x, the following limitation on File external is mentioned:
> >>File externals cannot refer to files from other repositories. A file external's URL must always be in the same repository as the URL that the file external will >be inserted into
> >>Why does this limitation exist ? Is there an objective to remove this limitation in the up an coming version 1.6.x or 1.7 ?
>
> >The issue is quite simple: What if that remote repository is no longer available or the server to the external repository has changed? What if >that remote repository upgraded to a new version of Subversion that isn't compatible with your client? You might get to a point where it is >now impossible to checkout and build your project.
>
> >You also now have the responsibility of your Subversion client suddenly having to access another repository which will probably require >different credentials or be using a different protocol.
> But, don't all those issues exist for directory externals which can be pointed to another repository?
>
I think it was simply a matter of ease-of-implementation.
Recall that each working copy comes from a single repository location.
Directory externals are implemented as nested working copies,
so each directory external can come from a distinct repository.
File externals are different, they are implemented as switched files.
Switching files only works within the same repository (we're talking
about switch, not switch --relocate). There exist restrictions in
the code which enforce this, and they have been around much longer
than file externals.
I see no reason why it should not be possible to make cross-repository
switching for single files possible. But it's not an easy task.
It would require working copy format changes, possibly changes in the
way RA (repository access) sessions are opened and used, and additional
changes all over the place to make the behaviour consistent (e.g. to ensure
that there exists no corner case where svn now runs into a 'path does not
exist in repository' error).
The current solution is much less intrusive and was much easier to
implement, but is less flexible as a result.
I am not aware of any plans to remove this limitation, but everybody
is of course welcome to pick up the ball and improve the status quo.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402147
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-30 17:56:56 CEST