Repository versioning

  • Thread starter Thread starter Larry Waibel
  • Start date Start date
L

Larry Waibel

Let's say that I create a component that uses a repository and release the
component. Then I update a file in the repository. I want the old component
to use the old file and a new version of the component to use the new file.
When I update the component, does it create a new repository (GUID) with the
new file? Thanks!
 
Larry Waibel said:
Let's say that I create a component that uses a repository and release the
component. Then I update a file in the repository. I want the old component
to use the old file and a new version of the component to use the new file.
When I update the component, does it create a new repository (GUID) with the
new file? Thanks!
Click to expand...

In Target Designer you can only select the latest version of any component. It
is not possible to select any other version of that component. The 3 strategies
available to you are ...

1) If you need to be able to use both versions of the component in new projects
then you must create two completely different components (one for the old
version and another for the new one).

2) If you need to be able to use the new version of the component in new
projects, and still have access to the old version for old projects then you can
have two different versions of the same component.

3) If you never need to use the older version of the component again then you
can replace the existing component with the new one.

If option 2 applies I suggest you see the following example.

I have a new version of an old driver, and the only difference is that file
'xyz.dll' has changed. To update the existing component so that I can still
re-build older projects that use the old version, update existing projects to
use the newer version or create new projects that use the new version I would
follow this procedure.

a) If your existing component has not been marked as 'released'; mark it as
'released', save it and import it into the database. This will ensure that the
'old' version in the database is not replaced by the 'new' version.
Note: If existing projects use a non-released version of the component then you
must updated them at this point to use the released version.

b) Modify the component to allow further editing by using the 'Update
Component' option.

c) Modify the component to support the new file. As the existing file is being
changed all I have to do is to change the 'source name' for file 'xyz.dll' to be
'v2_xyz.dll'.

d) Save the new component and import it into the database.

e) Manually copy the new version of 'xyz.dll' into the repository as
'v2_xyz.dll'. This leaves two files in the repository 'xyz.dll' (copied into
the image as xyz.dll) if the old version is used, and 'v2_xyz.dll' (also copied
into the image as xyz.dll) if the new version is used.

You can now use the new version of the component in your projects. Once you
have proved that it works correctly you can mark it as released.

David
 
From: "David Harris" <[email protected]>
Subject: Re: Repository versioning
Date: Fri, 21 Oct 2005 17:38:50 +0100
Newsgroups: microsoft.public.windowsxp.embedded



In Target Designer you can only select the latest version of any component. It
is not possible to select any other version of that component. The 3 strategies
available to you are ...

1) If you need to be able to use both versions of the component in new projects
then you must create two completely different components (one for the old
version and another for the new one).

2) If you need to be able to use the new version of the component in new
projects, and still have access to the old version for old projects then you can
have two different versions of the same component.

3) If you never need to use the older version of the component again then you
can replace the existing component with the new one.

If option 2 applies I suggest you see the following example.

I have a new version of an old driver, and the only difference is that file
'xyz.dll' has changed. To update the existing component so that I can still
re-build older projects that use the old version, update existing projects to
use the newer version or create new projects that use the new version I would
follow this procedure.

a) If your existing component has not been marked as 'released'; mark it as
'released', save it and import it into the database. This will ensure that the
'old' version in the database is not replaced by the 'new' version.
Note: If existing projects use a non-released version of the component then you
must updated them at this point to use the released version.

b) Modify the component to allow further editing by using the 'Update
Component' option.

c) Modify the component to support the new file. As the existing file is being
changed all I have to do is to change the 'source name' for file 'xyz.dll' to be
'v2_xyz.dll'.

d) Save the new component and import it into the database.

e) Manually copy the new version of 'xyz.dll' into the repository as
'v2_xyz.dll'. This leaves two files in the repository 'xyz.dll' (copied into
the image as xyz.dll) if the old version is used, and 'v2_xyz.dll' (also copied
into the image as xyz.dll) if the new version is used.

You can now use the new version of the component in your projects. Once you
have proved that it works correctly you can mark it as released.

David
Click to expand...
Hmmmm, I thought the whole reason they went to all the trouble of having 'release'
and 'update' components was so you could choose the appropriate (at least)
'released' one and that repository versioning would be part of that. Since it now
looks like I have to handle all of the versioning control for my projects myself,
I'm not sure why they even bothered with versioning components.
 
Larry Waibel said:
Hmmmm, I thought the whole reason they went to all the trouble of having
'release'
and 'update' components was so you could choose the appropriate (at least)
'released' one and that repository versioning would be part of that.
Since it now
looks like I have to handle all of the versioning control for my projects
myself,
I'm not sure why they even bothered with versioning components.
Click to expand...

TD only ever allows you to 'use the version defined in the SLX file' or 'Use
the latest version'. Once you have upgraded a component to the latest
version you can never go back to the older one. It is possible to save an
SLX file in XML format and then 'hack' it to reference an older component
version, but that is something I have only ever used as a last resort.

In general the strategy I use is ...

When I release an image to a customer (or at a suitable points in the
development process) I archive the log produced by building the system (it
contains a list of components and their versions), the SLX file it was built
from and all the custom components used in it (SLD files & repository
sources). That way I always have enough information to re-install XPe and
set it up so that I can build the same image again.

David
 
Back
Top