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

RE: svn:externals ../ in local path

From: Dimitri Yanculovici <dimitri.yanculovici_at_orange-ftgroup.com>
Date: Mon, 9 Feb 2009 10:44:24 +0100

Hi Blair,

Thank you for your suggestions.
I think I will opt for the first one (a directory dedicated to checkouts,
with no content but only externals definitions...)

Just to let you know my special case:

I work on the Eclipse IDE. I use it to create platform projects and
component projects. Platforms are built by assembly of components; so
platform projects refer to component projects.

I want to put those Eclipse projects in an SCM. The constraints are the
followings:
  - Do not duplicate code on the repository: if two platforms instantiate
the same component, this component must not appear in two different
locations in the repository (=> impose the tree structure of the
repository).
  - Automate the multiple checkouts using as less actions as possible: the
goal of the IDE is to break the back of the work for the user (=>
svn:externals)
  - On a checkout of a platform, the referenced components must be checkout
as well and placed at the same level in the local folder (workspace for
Eclipse users) than the platform's one (=> ../ in the local path of the
svn:externals associated to the platform project).

I think that it can be a recurrent issue for people using svn inside an IDE.
As you say there is several ways to by-pass the issue; but I don't think
that they are as intuitive as the management of "../".

Regards,
Dimitri.

-----Message d'origine-----
De : Blair Zajac [mailto:blair_at_orcaware.com]
Envoyé : samedi 7 février 2009 00:34
À : Dimitri Yanculovici
Cc : dev_at_subversion.tigris.org
Objet : Re: svn:externals ../ in local path

Dimitri Yanculovici wrote:
> Hi Blair,
>
> Thanks for your answer.
>
> Here is what I want to do:
>
> My repository tree structure is:
>
> <repository>
> |- components/
> | |- component1/
> | |- component2/
> | `- component3/
> `- platforms/
> `- platform1/ <- svn:externals
>
> "platform1" refers to "component1",2,3 thus what I need after a checkout
of
> "platform1" is:
>
> <local_current_dir>
> |- component1/
> |- component2/
> |- component3/
> `- platform1/
>
>
> So the only way (that I've found) to automate this (excluding the
individual
> checkout of the 3 components and the platform) would be to add
svn:externals
> properties on the "platform1/" directory as follow:
>
> ../component1/ http://repository_url/components/component1/
> ../component2/ http://repository_url/components/component2/
> ../component3/ http://repository_url/components/component3/
>
>
> But ../component1/ is not supported...
>
>
> If I put the svn:externals on the parent directory (here it's
"platforms/").
> I can obtain the following tree structure after a checkout of
"platforms/":
>
> <local_current_dir>
> `- platforms/
> |- component1/
> |- component2/
> |- component3/
> `- platform1/
>
> But it's not what I want to do. I really need to force the checkout of the
> three components during the checkout of platform1 and not platforms.
>
> You may think that it's the design of my repository's tree structure which
> is not adapted, but I have other constraints which force me to build it
like
> that...

It would be good to hear those constraints to justify work on this feature.
Howver, I don't see this feature being implemented anytime soon in svn.
There
are some solutions. You could have another directory called 'checkouts'
that
has externals to platform1, component{1,2,3} and then a single checkout
grabs
everything the way you want. Or you could have the externals on your
platforms
and use sparse checkouts to get only the platform you need.

Regards,
Blair

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1128481
Received on 2009-02-09 10:51:22 CET

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

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