[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Réf. : Re: File externals

From: Gabriel SCOLAN <gabriel.scolan_at_sagem.com>
Date: Wed, 30 Sep 2009 18:44:43 +0200

thanks to all of you for all this interesting feedback.
best regards

Stefan Sperling <stsp_at_elego.de>

30/09/2009 17:56
Remis le : 30/09/2009 17:56
        Pour : Bob Archer <bob.archer_at_amsi.com>
        cc : David Weintraub <qazwart_at_gmail.com>, Gabriel SCOLAN
<gabriel.scolan_at_sagem.com>, "users_at_subversion.tigris.org"
        Objet : Re: File externals

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


" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."

" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-30 18:45:29 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.