xlinks - Moving a label

[JeanDeSpaey]

Hi,

I am using PlasticSCM.0 239.2 (windows 7) and I have a problem with moving a label in an xlinked repository.

The configuration is as follows:

- A workspace "Workspace_TestWorkspace" connected to a repository "testworkspace" on my local computer.

- In the workspace there is a folder "TestWorkspace" (checked in). Within that folder is an xlinked folder "lib" referring

to a repository "testworkspace_lib". (cm xlink -w lib / cs:8@testworkspace_lib@localhost:8087)

The idea is that the project creates a library (dll) in the lib folder (repository) and that other projects can use this

repository in their projects.

The working changeset (branch explorer in current workspace) = 16

The working changeset in the xlinked "lib" repository = 8

I created a label "Label2" (using the command line to be able to create the label in all xlinked repositories). This works

fine; both cs16 (from workspace) and cs8 (in xlinked repository) have the correct label.

I then alter a file in the xlinked lib folder and check in the file (using GUI pending changes...). The working changeset in

both the current workspace and xlinked lib repository is incremented.

Then I want to move the label "Label2" in both repositories. This is not possible!!!!! (not from the command line and not from

the GUI).

The label is moved in the current workspace (changeset 17) but the label in the xlinked repository remains on CS:8

The command "cm label lb:Label2@rep:testworkspace_lib@localhost:8087 cs:9@rep:testworkspace_lib@localhost:8087" gives

the error "Error: object reference not set to an instance of an object".

The only way to move the label in the xlinked repo is to use the repo in a new workspace and to use the GUI to appy the

label to the workspace content. This is an unworkable solution because one needs to create a workspace for each lib.

Is there some way of moving the label (or is this a bug in the code)?

[Guest]

Altough it's possible to apply a label in a main repository and all the xlinked repositories as well using the command line this is a 'facility' not a feature; I mean: there is no relationship between the label "LB001" in rep1 and "LB001" in rep2 at all.

So the system is not smart enough to know where to move the label (actually: should the label be moved? in some scenarios this seems to make sense, but in others not.)

That's why we've introduced the expand labels option in the command line but not in the GUI, because it's a hacker-option, not a really feature.

I'm afraid that we cannot develop such a feature currently :-(

Best,

Luis

[JeanDeSpaey]

Hi Luis,

Thanks for your reply.

After experimenting I was able to move the label in the xlinked repository using the command line tools. But...

Apparently the command "cm label label_spec changeset_spec" is not working as expected with fully qualified label and changeset specs.

When I execute the following command (in the root folder of the workspace) "cm label lb:LB002@testworkspace_lib@localhost:8087 cs:9@testworkspace_lib@localhost:8087"

the following error is generated: "Error: Object reference not set to an instance of an object".

However, when (on the command line) I go to the folder that is mounted by the xlink command and I execute: "cm label lb:LB002 cs:9" everything works as expected; the label

is placed on the correct changeset.

Apparently, the location where a command is executed plays a role, even if the command fully describes what Plastic should do. This makes it very hard to work with the

system as you have to remember all these things.

Regards,

Jean

[manu]

Hello ,

I just want to inform you that I've reproduced your problem locally and it's now inside our bug tracking system, thanks for reporting it.

Apparently, the location where a command is executed plays a role, even if the command fully describes what Plastic should do. This makes it very hard to work with the

system as you have to remember all these things.

Your have your point, we are always committed to create an intuitive system, this kind of feedback help us to improve our system.

[Guest]

Hi there, this bug was fixed long time ago, in Plastic SCM 4.1.10.434, so please upgrade your setup if you're still experiencing this problem. I made a deep refactor in the label command because I detected several bugs there, this one among others. Let say that the command was not that robust if you tried some corner use cases.

 

I was assigned this ticket and noticed that this bug was already fixed, sorry for the delay, I hope you've been tuned to Plastic SCM releases and checked that this one was solved.