Migration to the OSOR subversion repository

The gvSIG subversion repository was moved from its own server at the gvsig.org domain to a server hosted in OSOR during the week of April 12th 2010.

The easiest way is to do a checkout of the project again in a new workspace. However, if we have changes to upload, another option is to change the reference to the subversion server in our own workspace.

At first, we have two options for this:

All of this, project by project. If we have a unix shell (we are on linux, mac, windows with the cygnus utilities, etc.) we can use the following instructions (including to create a script) to migrate a complete workspace of the gvSIG core:

# Andami
svn switch --relocate \
    https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/frameworks/_fwAndami \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/frameworks/_fwAndami \
    _fwAndami

# Root projects
for project in build binaries org.gvsig.core.maven.dependencies; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/${project} \
    ${project}; 
done

# Applications
for project in app*; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/applications/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/applications/${project} \
    ${project}; 
done

# Libraries
for project in lib*; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/libraries/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/libraries/${project} \
    ${project}; 
done

# Extensions
for project in ext* org.gvsig.symbology; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/extensions/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/extensions/${project} \
    ${project}; 
done

Developing gvSIG 1.10+ projects with an eye on gvSIG 2.0

The differences between versions 1.X and 2.X are very important in some areas of the application. There are important changes relating to:

In the light of these changes, there is no simple answer to the question What needs to be taken into account when initiating a development in the 1.X line and then later migrating to the 2 line?

The first issue that arises is that compatibility can't be maintained. Upon further reflection, there are some recommendations that can be followed, some more difficult than others. Some of them are listed here and developers will have to decide on their applicability to their projects:

In general it is a good idea to read the sections on Creating a gvSIG project and Migrating projects to gvSIG 2.0 in the gvSIG 2.0 developers guide.