XLINK question

[GoneCamping]

Currently evaluating whether to use Plastic SCM or not, but so far, I'm impressed.  I've successfully gone through the installation and the tutorial, and have a couple of questions about using XLINK.  We are relatively new to VCS methodologies/techniques, so I may not be correctly using the XLINK; if so, let me know.

 

We develop embedded applications, and as such, we often licence software libraires (as source code) from third party suppliers (i.e. RTOSs, GUIs, etc.).  The licences are for source code (as opposed to linkable object files), as they need to be compiled for specific embedded MCU's/platforms/etc. with specific optimisations (speed or size) depending on the project.  These libraries are regularly updated by their maintainers, and we generally release updates of our products using the latest version of these libraries.

 

Here's my question: how do I correctly add the 3rd party library to a repo, and use it in my projects' repos?  I know I need to use XLINK, but the libraries come with a bunch of other files/documents.  For instance, one specific library has the following structure:

 

\GUI_XX.YY.ZZ (root of ZIP file I get from GUI library supplier, where XX.YY.ZZ represent the version number and build)

    \doc (contains version specific documentation for using the library)

    \source (contains several sub-directories for various parts of the library)

        \core (contains a bunch of .c, and .h files)

        \bitmaps (contains a bunch of .c, and .h files)

        \fonts (contains a bunch of .c, and .h files)

        \other components, I think you get the idea

    \examples (contains .c code that shows how to use/demonstrate the GUI)

 

So, as you see, I have a bunch of file that I want to "archive" in a repo for that library.  I want the documentation and examples to follow the libray source code, as developpers need to have access to them when they use the library.  However, they won't be modifying any of these files (nor the source, for that matter, the whole GUI repo can be read-only as far as I'm concerned.)

 

I'm assuming (correctly?) the library will have its own repo "main line", and as each release becomes available from the supplier, it will "grow".  From 1.1.46, I may go to 1.2.0, to 1.3.2, to 2.0.0, etc.  I don't expect this main line to branch at all (and consequently, no merges either.)  Only linear changesets as they are added over time.

 

Now, on to the questions...

 

Do I need to create a workspace for the library?  Can I just link to the \source sub-directory (using XLINK) when I create a repo for our project?  I don't want to actually "download" the documentation, examples, etc. into the project workspace, but the developper may do so on a "per case" basis for consultation.  The \source WILL have to be downloaded, as it's needed to compile the project.  However, should the contents of \source change (by mistake), I don't want these changes to be "committable" to the library's repo.  Is this possible?

 

Let me know if I'm trying to use XLINK the correct way, or not.

 

Thanks!

 

[GoneCamping]

Even more confused now...

 

I just read this: http://www.plasticscm.com/infocenter/technical-articles/component-based-development.aspx, and wonder if it wouldn't be more appropriate for my use-case...  Selectors?  Are these what I should be looking at instead of XLINKs?

[calbzam]

Hi,

 

- I would suggest to create a new repository to manage the libraries. This way you can link this repo to other repos using Xlinks. 

 

- If you don´t want to download all the files to your workspace you can use cloaking rules: Cloaked items are items that the update operation won't download by default from the repository to the workspace. Download can be forced to use the update forced operation instead. This is convenient in some scenarios, for instance when there are big files in the repository that are updated often, but you don't really work with them, so you prefer to skip downloading those cloaked files every time you switch the workspace to a different branch or do an update of the workspace.

Cloaked items are defined as entries in file named cloaked.conf. The submenu adds or removes those entries to the cloaked.conf file based on the item that right clicked on.

 

- I also think that a good permissions policy in your libraries repo would fit in your case. Using the GUI you can go to Repositories --> right click --> Permissions, and define who can create a revison, make a branch, read... Permission rules are very interesting when

 

Regards,

Carlos

[talt]

Hi,

 

Can you please clarify the difference between   http://www.plasticsc...evelopment.aspx and using Xlinks?

I tested the use of xlinks for similar purpuses.

 

Thanks,

Tal.

[calbzam]

Hi, 

 

This article is about a Plastic 3 feature. Is the way we linked repositories in Plastic 3. This article is not applicable in Plastic 4. In Plastic 4 we only use Xlinks. It´s easier to work with Xlinks 

 

Regards,

Carlos 

[talt]

Thanks!

 

I have some further questions regarding Xlink:

 

- when I edit Xlink and change CS to a different one , it will be good to have a column of label so I can easily peak the labeled CS.

 

- continue of the first question, is there a way to filter CS to labeled only?

 

Thanks again,

Tal.

[calbzam]

Hi TaIT,

 

At the moment, is not possible to filter CS by label. I think is a good idea, You can add your ideas to our uservoice system and we will try to implement it: http://plasticscm.uservoice.com

Check the possibilities you have filtering by CS:(from the "cm showfindobjects" command):CHANGESET

        attribute

        attrvalue

        branch

        changesetid

        comment

        date

        guid

        id

        onlywithrevisions

        owner

        parent

        repllogid

        replsrcdate

        replsrcid

        replsrcrepository

        replsrcserver

        returnparent

​

Regards,

Carlos

[GoneCamping]

Thanks Carlos for the replies.  Seems I was reading "old doc." too...  XLinks is the way to go!

 

The cloaking function also seems to be what I'm looking for to control what is actually downloaded.

 

JL

[manu]

Hi,

 

we have just implemented a couple of improvements in the xlinks - cloaked workflow. You can get them using the 4.1.10.434 release or later.

 

Best regards,

Manuel Lucio Dallo.