Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Eclipse workspace is unmovable, useless for source control
Eclipse workspace is unmovable, useless for source control [message #315203] Sat, 05 May 2007 02:56 Go to next message
No real name is currently offline No real nameFriend
Messages: 9
Registered: July 2009
Junior Member
Hi all,

The current 3.2.x Eclipse workspace stores the absolute path of a project
location in:


metadata/.plugins/org.eclipse.core.resources/.projects/MyPro ject/.location

This is truly a bad design, because you cannot move the workspace
(.metadata) directory to somewhere else, or check into source control then
out into somebody else's environment. I am surprise that no one has
complained about this years ago already.

Eclipse already support embedding macros like ${WorkspaceDirPath} in
string configuration settings. The .location file should allow and honor
macros so that workspace and projects under the workspace directory can be
location independent. The current version fails of such macro exist in
this file.

For the Linux version, Import existing project dialog should include a
third pre-defined location call "Workspace" in addition to "Home" and
"File System". If a project in the subdirectory of current workspace is
selected, the any location regarding the project should always use the
${WorkspaceDirPath} macro instead of the absolute path.

If I have time, I will look into creating a patch or enhancement for this.
What I see right now makes no sense.

--Michael
Re: Eclipse workspace is unmovable, useless for source control [message #315209 is a reply to message #315203] Sat, 05 May 2007 11:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Michael,

None of us normally feel compelled to check the whole workspace as a
unit into CVS (and the IDE doesn't even support that). A workspace is
like a sandbox and one normally commits only individual projects
(typically plugins) into CVS (which the IDE supports directly). For
another individual who wants to check out the same projects, it's
possible to export a Team Project Set which can then be imported to set
up quickly the same set of CVS projects elsewhere. In addition,
individual projects can also be exported to an archive and can be
imported from an archive. And of course there are patches that can be
used to deal with deltas and share them.

It's important to keep in mind that a project does not physically need
to be nested in the workspace. You can point the project at any
physical location when it's being created so it's not generally possible
to make this location information always be relative to the workspace
itself.


Michael Chen wrote:
> Hi all,
>
> The current 3.2.x Eclipse workspace stores the absolute path of a
> project location in:
>
>
> metadata/.plugins/org.eclipse.core.resources/.projects/MyPro ject/.location
>
>
> This is truly a bad design, because you cannot move the workspace
> (.metadata) directory to somewhere else, or check into source control
> then out into somebody else's environment. I am surprise that no one
> has complained about this years ago already.
>
> Eclipse already support embedding macros like ${WorkspaceDirPath} in
> string configuration settings. The .location file should allow and
> honor macros so that workspace and projects under the workspace
> directory can be location independent. The current version fails of
> such macro exist in this file.
>
> For the Linux version, Import existing project dialog should include a
> third pre-defined location call "Workspace" in addition to "Home" and
> "File System". If a project in the subdirectory of current workspace
> is selected, the any location regarding the project should always use
> the ${WorkspaceDirPath} macro instead of the absolute path.
>
> If I have time, I will look into creating a patch or enhancement for
> this. What I see right now makes no sense.
>
> --Michael
>
>
Re: Eclipse workspace is unmovable, useless for source control [message #315216 is a reply to message #315209] Sat, 05 May 2007 14:30 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,

From what I can see, .location file is the only critical spot that
prevented workspace from being location independent. It would require
minimum effort to make this work. Workspace is already a logical project
grouping unit, so why not have this feature as well.

Also, I believe all Eclipse contributors should use of relative path and
macros like ${WorkspaceDirPath} whenever possible. On Linux, if a
symbolic link of a directory is presented to Eclipse, Eclipse should use
it as-is and not resolve it into absolute path. Things like that are good
practices and can make the program more intuitive and user-friendly.

Thanks

--Michael

Ed Merks wrote:
> Michael,

> None of us normally feel compelled to check the whole workspace as a
> unit into CVS (and the IDE doesn't even support that). A workspace is
> like a sandbox and one normally commits only individual projects
> (typically plugins) into CVS (which the IDE supports directly). For
> another individual who wants to check out the same projects, it's
> possible to export a Team Project Set which can then be imported to set
> up quickly the same set of CVS projects elsewhere. In addition,
> individual projects can also be exported to an archive and can be
> imported from an archive. And of course there are patches that can be
> used to deal with deltas and share them.

> It's important to keep in mind that a project does not physically need
> to be nested in the workspace. You can point the project at any
> physical location when it's being created so it's not generally possible
> to make this location information always be relative to the workspace
> itself.
Re: Eclipse workspace is unmovable, useless for source control [message #315217 is a reply to message #315216] Sat, 05 May 2007 15:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------080502080504060905040503
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

A workspace is a sandbox and isn't an appropriate thing to check into a
repository in my opinion. How would two projects ever share anything if
each had a separate workspace?

I'm not sure you understood my point that when a project is created you
can specify any location for it.


This doesn't involve using a symbolic link and lets you specify a
location that's on a different drive from the workspace.

So while I agree it would make sense for the information stored in the
..metadata to be made relative when possible during save and to be
resolved correctly during load (like EMF does when it saves and loads
resources) so that a workspace can be easily moved, it's clear this
can't be done in all cases. In in any case, it still doesn't make it a
good idea to commit your whole workspace to CVS because it's not an
appropriately fine grained using of sharing.

You have to ask yourself why millions of people have been using this for
years without this being seen as a serious problem that prevents them
from using a repository...


Michael Chen wrote:
> Ed,
>
> From what I can see, .location file is the only critical spot that
> prevented workspace from being location independent. It would require
> minimum effort to make this work. Workspace is already a logical
> project grouping unit, so why not have this feature as well.
>
> Also, I believe all Eclipse contributors should use of relative path
> and macros like ${WorkspaceDirPath} whenever possible. On Linux, if a
> symbolic link of a directory is presented to Eclipse, Eclipse should
> use it as-is and not resolve it into absolute path. Things like that
> are good practices and can make the program more intuitive and
> user-friendly.
>
> Thanks
>
> --Michael
>
> Ed Merks wrote:
>> Michael,
>
>> None of us normally feel compelled to check the whole workspace as a
>> unit into CVS (and the IDE doesn't even support that). A workspace
>> is like a sandbox and one normally commits only individual projects
>> (typically plugins) into CVS (which the IDE supports directly). For
>> another individual who wants to check out the same projects, it's
>> possible to export a Team Project Set which can then be imported to
>> set up quickly the same set of CVS projects elsewhere. In addition,
>> individual projects can also be exported to an archive and can be
>> imported from an archive. And of course there are patches that can
>> be used to deal with deltas and share them.
>
>> It's important to keep in mind that a project does not physically
>> need to be nested in the workspace. You can point the project at any
>> physical location when it's being created so it's not generally
>> possible to make this location information always be relative to the
>> workspace itself.
>
>


--------------080502080504060905040503
Content-Type: multipart/related;
boundary="------------000402070703000202080405"


--------------000402070703000202080405
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
A workspace is a sandbox and isn't an appropriate thing to check into a
repository in my opinion.
Re: Eclipse workspace is unmovable, useless for source control [message #315218 is a reply to message #315217] Sat, 05 May 2007 17:17 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,

I am involved in a fairly large C/C++ project and investigating the use of
CDT. This project contains 80+ smaller components that correspond to 80+
projects shared by many developers from multiple offices via a single
source control.

I am hoping that a single Eclipse workspace can serve as a logic unit to
contain all of these 80+ projects. Quite reasonable approach and
expectation, don't you thing? (BTW, I never suggested to use 80+
workspaces.)

If workspace is movable, then I can just create that at the top of the
source control tree and those 80+ projects in their appropriate
subdirectories, check all the project files as well as the top .metadata/
directory into source control. That would be the end of it. I don't
think I am asking too much.

If you insist upon the current use of workspace, then I suggest create
something called "Project Group", or "Solution" in Microsoft land, which
is movable and source control friendly. However, that will be duplicated
the role of workspace.

Speaking of Microsoft Visual Studio Solution, one can create logical
folders (does not exist in file system) in a solution and create/move
projects into that folder. A very nice feature to have when you are
dealing with 80+ projects, which on Elcipse show up as a long flat list in
the workspace.

Thanks

--Michael

Ed Merks wrote:
> Michael,

> A workspace is a sandbox and isn't an appropriate thing to check into a
> repository in my opinion. How would two projects ever share anything if
> each had a separate workspace?

> I'm not sure you understood my point that when a project is created you
> can specify any location for it.


> This doesn't involve using a symbolic link and lets you specify a
> location that's on a different drive from the workspace.

> So while I agree it would make sense for the information stored in the
> ..metadata to be made relative when possible during save and to be
> resolved correctly during load (like EMF does when it saves and loads
> resources) so that a workspace can be easily moved, it's clear this
> can't be done in all cases. In in any case, it still doesn't make it a
> good idea to commit your whole workspace to CVS because it's not an
> appropriately fine grained using of sharing.

> You have to ask yourself why millions of people have been using this for
> years without this being seen as a serious problem that prevents them
> from using a repository...
Re: Eclipse workspace is unmovable, useless for source control [message #315223 is a reply to message #315218] Sat, 05 May 2007 17:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Michael,

Feel free to ignore my advice but you should realize you will make
faster progress when you go with the grain rather than against it. More
comments below...


Michael Chen wrote:
> Ed,
>
> I am involved in a fairly large C/C++ project and investigating the
> use of CDT. This project contains 80+ smaller components that
> correspond to 80+ projects shared by many developers from multiple
> offices via a single source control.
>
> I am hoping that a single Eclipse workspace can serve as a logic unit
> to contain all of these 80+ projects. Quite reasonable approach and
> expectation, don't you thing? (BTW, I never suggested to use 80+
> workspaces.)
No, I don't think it's a good approach and probably it's not even a
reasonable approach. It's not how anyone developing at Eclipse is doing
it. So stray from the beaten path at your own risk.
>
> If workspace is movable, then I can just create that at the top of the
> source control tree and those 80+ projects in their appropriate
> subdirectories, check all the project files as well as the top
> .metadata/ directory into source control. That would be the end of
> it. I don't think I am asking too much.
I think you are flying in the face of good advice, but that's your
choice to make.
>
> If you insist upon the current use of workspace, then I suggest create
> something called "Project Group", or "Solution" in Microsoft land,
> which is movable and source control friendly. However, that will be
> duplicated the role of workspace.
I did point you to at Team Project Sets as the way that folks do this at
Eclipse. I too work on a large project where in the end my workspace
has more than 150 projects all coming from many different teams. Your
approach would not work in such an environment since each team would
have a different workspace. Your approach won't even work in the IDE
period, because you can't use the IDE to check in or check out the whole
workspace itself. I suppose you'll be using command line tools instead.
>
> Speaking of Microsoft Visual Studio Solution, one can create logical
> folders (does not exist in file system) in a solution and create/move
> projects into that folder. A very nice feature to have when you are
> dealing with 80+ projects, which on Elcipse show up as a long flat
> list in the workspace.
Eclipse has what are called working sets that can be used for grouping
and filtering.
>
> Thanks
>
> --Michael
>
> Ed Merks wrote:
>> Michael,
>
>> A workspace is a sandbox and isn't an appropriate thing to check into
>> a repository in my opinion. How would two projects ever share
>> anything if each had a separate workspace?
>
>> I'm not sure you understood my point that when a project is created
>> you can specify any location for it.
>
>
>> This doesn't involve using a symbolic link and lets you specify a
>> location that's on a different drive from the workspace.
>
>> So while I agree it would make sense for the information stored in
>> the ..metadata to be made relative when possible during save and to
>> be resolved correctly during load (like EMF does when it saves and
>> loads resources) so that a workspace can be easily moved, it's clear
>> this can't be done in all cases. In in any case, it still doesn't
>> make it a good idea to commit your whole workspace to CVS because
>> it's not an appropriately fine grained using of sharing.
>
>> You have to ask yourself why millions of people have been using this
>> for years without this being seen as a serious problem that prevents
>> them from using a repository...
>
>
>
Re: Eclipse workspace is unmovable, useless for source control [message #315232 is a reply to message #315223] Sun, 06 May 2007 02:43 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 9
Registered: July 2009
Junior Member
Ed,

A quick question before I look into Team Project Set (or working set), can
you check that logical grouping into source control (is it movable)?

Thanks

--Michael
Re: Eclipse workspace is unmovable, useless for source control [message #315235 is a reply to message #315232] Sun, 06 May 2007 12:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------070107050804080407070004
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

It's just a simple XML file like this so it can be version controlled.

<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
<provider id="org.eclipse.team.cvs.core.cvsnature">
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.orbit /net.sourceforge.lpg.lpgjavaruntime,net.sourceforge.lpg.lpgj avaruntime,v1_0 "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gm f/plugins/org.apache.batik,org.apache.batik "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gm f/plugins/org.apache.batik.pdf,org.apache.batik.pdf "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.draw2 d,org.eclipse.draw2d "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf,org.eclipse.emf "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf-feature,org.eclipse.emf-feature "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/e xamples/org.eclipse.emf.activities,org.eclipse.emf.activitie s "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf.ant,org.eclipse.emf.ant "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/d oc/org.eclipse.emf.cheatsheets,org.eclipse.emf.cheatsheets "/>
<project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf.codegen,org.eclipse.emf.codegen "/>

Probably it's something you would keep on a webpage so folks could
download it and then import it to pick up all the necessary projects
directly from CVS.


Michael Chen wrote:
> Ed,
>
> A quick question before I look into Team Project Set (or working set),
> can you check that logical grouping into source control (is it movable)?
>
> Thanks
>
> --Michael
>


--------------070107050804080407070004
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
It's just a simple XML file like this so it can be version controlled. <br>
<blockquote><small>&lt;?xml version="1.0" encoding="UTF-8"?&gt;</small><br>
<small>&lt;psf version="2.0"&gt;</small><br>
<small>&lt;provider id="org.eclipse.team.cvs.core.cvsnature"&gt;</small><br >
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.orbit /net.sourceforge.lpg.lpgjavaruntime,net.sourceforge.lpg.lpgj avaruntime,v1_0 "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gm f/plugins/org.apache.batik,org.apache.batik "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gm f/plugins/org.apache.batik.pdf,org.apache.batik.pdf "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.draw2 d,org.eclipse.draw2d "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf,org.eclipse.emf "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf-feature,org.eclipse.emf-feature "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/e xamples/org.eclipse.emf.activities,org.eclipse.emf.activitie s "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf.ant,org.eclipse.emf.ant "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/d oc/org.eclipse.emf.cheatsheets,org.eclipse.emf.cheatsheets "/&gt;</small><br>
<small>&lt;project
reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/tools,org.eclipse.emf/p lugins/org.eclipse.emf.codegen,org.eclipse.emf.codegen "/&gt;</small><br>
</blockquote>
Probably it's something you would keep on a webpage so folks could
download it and then import it to pick up all the necessary projects
directly from CVS.
Re: Eclipse workspace is unmovable, useless for source control [message #315247 is a reply to message #315203] Sun, 06 May 2007 19:52 Go to previous messageGo to next message
Matt McCutchen is currently offline Matt McCutchenFriend
Messages: 32
Registered: July 2009
Member
On Sat, 2007-05-05 at 02:56 +0000, Michael Chen wrote:
> The current 3.2.x Eclipse workspace stores the absolute path of a project
> location in:
>
> metadata/.plugins/org.eclipse.core.resources/.projects/MyPro ject/.location
>
> This is truly a bad design, because you cannot move the workspace
> (.metadata) directory to somewhere else, or check into source control then
> out into somebody else's environment.

If you set a project to "use default location", Eclipse always looks for
it in a subdirectory of the workspace with the same name as the project
and doesn't use a .location file. Thus, moving the entire workspace
(with the project inside it) presents no problem. If you want Eclipse
to look for the project at a path relative to the workspace, just make
an appropriate relative symlink at the default location, and Eclipse
will follow it blindly. You can even recover much of the functionality
of macros using symlinks to other symlinks.

Example directory structure:

path/
to/
foo-projects/
A/
.project
B/
.project
workspace/
foo-project-loc -> ../path/to/foo-projects
foo-A -> foo-project-loc/A
foo-B -> foo-project-loc/B

I tend to agree that it's better design to use relative rather than
absolute paths and never to pre-follow symlinks when storing paths.
However, in this case, there's an easy workaround, so I do not see a
need to change Eclipse's behavior for non-default-located projects.

Regarding source control:

I think it's a terrible idea to check .metadata/ into source control
because it contains all sorts of internal states, caches, and histories.
Attempting to synchronize it among multiple developers will cause
source-control conflicts and confuse Eclipse very badly. It would be
workable to check in the entire workspace except .metadata/ ; still,
Team Project Sets may be a better way to accomplish what you want.

Matt
Re: Eclipse workspace is unmovable, useless for source control [message #315248 is a reply to message #315247] Sun, 06 May 2007 23:55 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 9
Registered: July 2009
Junior Member
Matt,

Your suggestions are exactly what I am looking for, practical and precise.
However, there are still two problems:

1) Symbolic link is not supported on Windows, in which case, one have no
choice but to create the workspace and projects inside the source tree.

2) Since a project name cannot have directory delimiters, "/" or "\",
therefore, all projects in the workspace much be at the top level of the
source tree.

Most complex projects are not structured like that, so "use default
location" won't work with projects exist deep inside the source tree. Say
a product with lots of projects, you are forced to place all of them at
the top level with the workspace.

Thanks

--Michael

Matt McCutchen wrote:
> On Sat, 2007-05-05 at 02:56 +0000, Michael Chen wrote:
>> The current 3.2.x Eclipse workspace stores the absolute path of a project
>> location in:
>>
>> metadata/.plugins/org.eclipse.core.resources/.projects/MyPro ject/.location
>>
>> This is truly a bad design, because you cannot move the workspace
>> (.metadata) directory to somewhere else, or check into source control then
>> out into somebody else's environment.

> If you set a project to "use default location", Eclipse always looks for
> it in a subdirectory of the workspace with the same name as the project
> and doesn't use a .location file. Thus, moving the entire workspace
> (with the project inside it) presents no problem. If you want Eclipse
> to look for the project at a path relative to the workspace, just make
> an appropriate relative symlink at the default location, and Eclipse
> will follow it blindly. You can even recover much of the functionality
> of macros using symlinks to other symlinks.

> Example directory structure:

> path/
> to/
> foo-projects/
> A/
> .project
> B/
> .project
> workspace/
> foo-project-loc -> ../path/to/foo-projects
> foo-A -> foo-project-loc/A
> foo-B -> foo-project-loc/B

> I tend to agree that it's better design to use relative rather than
> absolute paths and never to pre-follow symlinks when storing paths.
> However, in this case, there's an easy workaround, so I do not see a
> need to change Eclipse's behavior for non-default-located projects.

> Regarding source control:

> I think it's a terrible idea to check .metadata/ into source control
> because it contains all sorts of internal states, caches, and histories.
> Attempting to synchronize it among multiple developers will cause
> source-control conflicts and confuse Eclipse very badly. It would be
> workable to check in the entire workspace except .metadata/ ; still,
> Team Project Sets may be a better way to accomplish what you want.

> Matt
Re: Eclipse workspace is unmovable, useless for source control [message #315346 is a reply to message #315248] Wed, 09 May 2007 00:50 Go to previous message
Matt McCutchen is currently offline Matt McCutchenFriend
Messages: 32
Registered: July 2009
Member
On Sun, 2007-05-06 at 23:55 +0000, Michael Chen wrote:
> Your suggestions are exactly what I am looking for, practical and precise.

I try. :)

> However, there are still two problems:
>
> 1) Symbolic link is not supported on Windows, in which case, one have no
> choice but to create the workspace and projects inside the source tree.
>
> 2) Since a project name cannot have directory delimiters, "/" or "\",
> therefore, all projects in the workspace much be at the top level of the
> source tree.

Indeed, on Windows before Vista, the projects need to be immediate
children of the workspace. (I hear Windows Vista supports symlinks.)
However, in at least CVS and Subversion, it's possible to set up a magic
directory in the repository that, when checked out, collects other parts
of the repository in an arrangement different from the real one. (In
CVS, use symlinks in the repository; in Subversion, use svn:externals
definitions.) That way, you can arrange the projects as you like; Linux
clients check out the real project structure and a workspace full of
symlinks, and Windows clients check out the magic directory and get a
workspace full of projects.

This should satisfy your requirements unless you need the projects to be
custom-arranged even in pre-Vista Windows checkouts, in which case I
would recommend letting Eclipse reference the projects absolutely. If I
understand correctly, you originally wanted the projects relative in the
hope that users could check out a workspace to any location with
pre-done Eclipse project mappings, but that's impossible anyway because
it's unsafe to source-control .metadata/ . So all you lose is the
ability for a pre-Vista Windows user to move his/her workspace without
remapping the projects in Eclipse, which isn't much.

Matt
Previous Topic:Can I overwrite a class implementation in host plugin using fragments
Next Topic:[launcher] launch eclipse with eclipse.exe out of eclipse file tree (3.3 M6+)
Goto Forum:
  


Current Time: Thu Mar 28 12:36:50 GMT 2024

Powered by FUDForum. Page generated in 0.10023 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top